July 8, 2009 at 7:52 am
My server has gone down and is very slow at this moment. One log file has increased more than 76GB and I have found following error when I try to shrink this file. This is because of some offending process that is also using the resources which I need to shrink the file.
"Lock request timeout period exceeded."
I have also run sp_who2. I have found that many of the transactions are sleeping. What does sleeping means? If transaction is in sleeping should I kill this. Long back I remember that I killed one spid where the status was sleeping and this started getting rolled back for 5 hours and then I have to restart the m\c. Any heads up!!
-MJ
Please do not print mails and docx unless it is absolutely necessary. Spread environmental awareness.
July 8, 2009 at 8:17 am
Don't kill any dormant processes (only as a last resort). There is a reason SQL doesn't clean them up itself...
It looks to me that one your queries could be missing a COMMIT statement...this often causes a large transaction log (if the cause isn't otherwise obvious).
July 8, 2009 at 10:37 am
So the status is sleeping when the process is waiting for resources for long... Is there any time period which switch this from running to sleeping status, David.
-MJ
Please do not print mails and docx unless it is absolutely necessary. Spread environmental awareness.
July 9, 2009 at 3:18 pm
Try by running dbcc opentran() under that database and see the oldest transaction. Check what spid it has and whts it doing in background(might be a old left out connection due to open mgmt. studio). See if you can kill it as it might be holding your log.
MJ
July 10, 2009 at 7:03 am
if you have a small group with query analyzer access, have them shut down their analyzer windows one at a time and you'll likely see one say something about 'uncommitted transactions' on the way out. that'll force it to commit. had to do that yesterday with a db saying its in transition. couldnt run sp_who or anything. went down there and had both contractors shut down all their windows and exit management studio, problem solved.
if that doesnt work, dbcc opentran, and you can see what it's doing with sp_lock(spid). it'll probably sit there looking the same forever. kill (spid) will kill it.
still no guarantee that it's not gonna rollback for awhile if you dont know what it was doing.
July 10, 2009 at 7:36 am
Hello marty streetman,
I don't think that your statement is correct in your first paragraph. This can never happen that sql query analyzer or management studio is causing open transaction issues...
-LK
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply