zurgboi
asked on
WHAT IS THE CAUSE OF EVENT ID 17052???
OS = NT Server /w SP6
DB = MS SQL 7
We came in this morning and our SQL Server was not available to users for a particular piece of software. We received the message below.
EVENT ID: 17052
ERROR: 9001, SEVERITY: 21, STATE: 1
"THE LOG FOR 'TEMPDB' IS NOT AVAILABLE.
If someone can tell me the cause of this problem, that would be great. I can't find anything on this.
Also, I rebooted the server and it started back up fine.
Thanks.
DB = MS SQL 7
We came in this morning and our SQL Server was not available to users for a particular piece of software. We received the message below.
EVENT ID: 17052
ERROR: 9001, SEVERITY: 21, STATE: 1
"THE LOG FOR 'TEMPDB' IS NOT AVAILABLE.
If someone can tell me the cause of this problem, that would be great. I can't find anything on this.
Also, I rebooted the server and it started back up fine.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
severity 21 indicative of a hardware troubles, probably it run out of space, but due to the way tempdb is treated ( read angellll's post ) you would not be able to verify my guess. So, heads up, monitor tempdb usage / log growth during nightly jobs.
--Cheers
--Cheers
ASKER
That does shed some light but does not really answer my question. I can not seem to find any reason why that would happen. It must have been a hardware failure because there was a checkdisk run during the reboot, maybe?
What can be done so that if this happens again the server will take care of itself?
What can be done so that if this happens again the server will take care of itself?
![Avatar of Guy Hengel [angelIII / a3]](https://filedb.experts-exchange.com/files/public/2013/11/25/ddbe0ea6-aa6e-4279-b781-57b735dd3ea0.jpeg){kind=small}
what can be done so the server takes care of itself...
Now, SQL Server as such cannot take care of this, but you can build a monitoring "application" around this, using scripts or commercial applications, which would restart SQL Server if necessary.
However, be aware that the applications accessing the database should consider that this could happen, if they need to run 24/7
CHeers
Now, SQL Server as such cannot take care of this, but you can build a monitoring "application" around this, using scripts or commercial applications, which would restart SQL Server if necessary.
However, be aware that the applications accessing the database should consider that this could happen, if they need to run 24/7
CHeers
The above problem can be solved by stopping and starting sql server services (reboot does the same, but full server). This drops the tempdb database, and recreates it (taking model database as template). This explains WHY after the reboot, everything is fine.
CHeers