geoffbtbc
asked on
Cross-server queries
Our production system is a quad-processor server with 2gb of ram dedicated to SQL. It runs SQL7 in 6.0 emulation mode due to the old software package we use.
Our web server is running SQL 2k with 3gb of ram and quad processors. Connections are TCP/IP over 10/100 Ethernet (soon to be gigabit).
A program on the web server, written in VB6 and ADO, provides detailed data from our production system to our intranet. Another similar one is written in VB.NET and ADO.NET.
Occasionally, Enterprise Manager on our production system is unable to provide process activity details, returning an error showing a timeout waiting for locks.
Our diagnostic program has shown processes running from the web server with Shared table locks on some of our critical tables. I am assured that the program is read only (except for temp tables I noticed), so why is it locking tables? I have assumed that the query comes to the production server without optimization, and because of the way it is written,
it isn't optimized there and so starts doing table locks while it retrieves data.
I have thought of having the web server program and its stored procedures changed to do SELECT .... WITH NO LOCK to try any ease this problem. DTS would take care of update transactions, but these are inquiry only.
I am looking for any ideas to get out of this hole.
Our web server is running SQL 2k with 3gb of ram and quad processors. Connections are TCP/IP over 10/100 Ethernet (soon to be gigabit).
A program on the web server, written in VB6 and ADO, provides detailed data from our production system to our intranet. Another similar one is written in VB.NET and ADO.NET.
Occasionally, Enterprise Manager on our production system is unable to provide process activity details, returning an error showing a timeout waiting for locks.
Our diagnostic program has shown processes running from the web server with Shared table locks on some of our critical tables. I am assured that the program is read only (except for temp tables I noticed), so why is it locking tables? I have assumed that the query comes to the production server without optimization, and because of the way it is written,
it isn't optimized there and so starts doing table locks while it retrieves data.
I have thought of having the web server program and its stored procedures changed to do SELECT .... WITH NO LOCK to try any ease this problem. DTS would take care of update transactions, but these are inquiry only.
I am looking for any ideas to get out of this hole.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
- With a shared table lock, they can do anything they want except modify the structure of the table.
- How long the process stays active all depends on how your web stuff is set up.
- How long the process stays active all depends on how your web stuff is set up.
ASKER
I was under the impression from SQL 7 BOL that a shared lock stopped any other transaction from updating the data, which is why a table lock causes problems.
The web process should have timed-out in only a couple of minutes, but the production process wouldn't know that ?
The web process should have timed-out in only a couple of minutes, but the production process wouldn't know that ?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
1) EM stinks for locking, I cant believe how many times EM has been the cause of deadlocks. etc.
better to use sp_who2 to get running processes state (i have even tweaked this into a sp_who3 for better performance). and sp_lock2 for viewing locks.
2) ? the web server has SQL on it, you do understand that this can cause performance problems having SQL and IIS on same box ?
3) yes i agree that a performance monitoring tool should probably make a lot of use of WITH(NOLOCK) hint.
better to use sp_who2 to get running processes state (i have even tweaked this into a sp_who3 for better performance). and sp_lock2 for viewing locks.
2) ? the web server has SQL on it, you do understand that this can cause performance problems having SQL and IIS on same box ?
3) yes i agree that a performance monitoring tool should probably make a lot of use of WITH(NOLOCK) hint.
ASKER
Thanks for the ideas!
The web server does have SQL on it, but that is not where I am seeing the problems;however, that server is using a linked server connection to production to query and insert data there.
I am using SQL Diagnostic Monitor from Idera to monitor all SQL servers. I have just found Microsoft's article on sp_blocker_pss70 and a script to monitor blocking, and then info on how to compare this to Profiler run at the same time, so I am going to crank that up. I still get the feeling at times that the web server finishes its process before production does, leaving resources allocated in production that should and need to be reclaimed.
The web server does have SQL on it, but that is not where I am seeing the problems;however, that server is using a linked server connection to production to query and insert data there.
I am using SQL Diagnostic Monitor from Idera to monitor all SQL servers. I have just found Microsoft's article on sp_blocker_pss70 and a script to monitor blocking, and then info on how to compare this to Profiler run at the same time, so I am going to crank that up. I still get the feeling at times that the web server finishes its process before production does, leaving resources allocated in production that should and need to be reclaimed.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
If I 'lose' the original request from the webserver, will the production server not keep the lock until all the dataset has been returned?
In one case, the production process had been active for over 20 minutes.