Diagnosing Microsoft SQL Server error 9001: The log for the database is not available

Over the weekend a website I run stopped functioning, recording the following error in the Event Viewer each time a request is made to the website:

Event ID: 9001

The log for database 'database name' is not available. Check the event log for related error messages. Resolve any errors and restart the database.

The website is hosted on a dedicated server, so I am able to RDP into the server and poke around. The LDF file for the database exists in the C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA folder, but attempting to do any work with the database from Management Studio results in a dialog box reporting the same error - 9001: The log for database is not available...

This is the first time I've received this error, and I've been hosting this site (and others) on this dedicated web server for over two years now.

It is my understanding that this error indicates a corrupt log file. I was able to get the website back online by Detaching the database and then restoring a backup from a couple days ago, but my concern is that this error is indicative of a more sinister problem, namely a hard drive failure.

I emailed support at the web hosting company and this was their reply:

There doesn't appear to be any other indications of the cause in the Event Log, so it's possible that the log was corrupted. Currently the memory's resources is at 87%, which also may have an impact but is unlikely.

Can the log just "become corrupted?"

My question: What are the next steps I should take to diagnose this problem? How can I determine if this is, indeed, a hardware problem? And if it is, are there any options beyond replacing the disk?

Thanks

Solution 1:

Well over 99% of database corruption problems are to do the storage system. Half of the remaining problems are due to bad memory, with the other half being bugs in SQL Server.

Odds are it is a storage problem.

If it happens again run DBCC CHECKDB against the database and this will give you more information about the corruption, and if the problem can be fixed without doing a restore. You will probably need to bring the database online in emergency mode to run checkdb against the database.

Memory usage being at 87% has nothing to do with the problem. SQL Server will run the memory all the way to 100% (or close to it) by design.

Solution 2:

I was able to solve this by taking the database offline in Management Studio then immediately bringing it back online. dbcc checkdb had thrown errors which were resolved after doing this. I can't say why this worked only that it did work.