error 17883 scheduler hung

[icahn]

Recently, no users could login to our SQL Server 2000 SP3 instance. sqlserver.exe was taking 100% cpu and I was seeing these messages in the error log,

The Scheduler 0 appears to be hung. SPID 75, ECID 0, UMS Context 0x398F5DB0.

After 20 mins, the problem mysteriously corrected itself and everybody could login again.

The condition started happening at about 5:00pm, and I noticed the txn log backup that was scheduled at 5:00pm did not start till after the logins were 'enabled' again.

Has anyone here experienced this? According to MS knowledge base articles 810885, 319892 this can happen with autoextend on, but I've noticed some postings where turning this off did not help. What is best way to fix this? The errorlog shows no other problem other than this message (repeated), yet MS says this message is only the symptom, not cause.

Any ideas appreciated.

 

[oublie]

As Microsoft mention as long as this is happening out of hours all you can really do is live with the problem. However, it may be worth checking when your nightly jobs run to ensure there is no outage caused by the problem i.e. allow an extra half hour for the job + this 'Feature' to run.

 

[icahn]

Well, it's happening during office hours now! And no user can use any application running off our 40+ production databases, each time for 20 mins.

Microsoft support suggest applying a hotfix 816840, which is not yet available for general distribution, just produces more diagnostics (ie doesn't actually fix the problem) and even the readme says to wait for SP4!

Anyone had any experience with this hotfix or error 17883?

Thnx.

 

[grimwyre]

This may help. Our SQL clusters also got an error 17883 at about the same time every day we looked. At this time, the event logs were being extracted and copied to another server, then event logs were reset. One of the event logs was about 40Mb. So could there be a file transfer activity of some form causing the lockout? Our system should not have any users at this time so we can't check, but an admin user was developing a SQL extract and got thrown out.