Error 9001, Severity: 21, State: 1 The log for database 'DB_NAME' is not available I have a SQL Server 2008 R2.

I got a mail that the backup had failed, I opened the SQL log viewer and started browsing.
And i found these two errors a bunch of times.

error 1:

Date        31-01-2013 13:20:30
Log     SQL Server (Current - 01-02-2013 05:13:00)

Source      spid20s

Message Error: 9001, Severity: 21, State: 1.


error 2:

Date        31-01-2013 13:20:30
Log     SQL Server (Current - 01-02-2013 05:13:00)

Source      spid20s

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


After a little googling, I had read a few times that the errors indicated that the DB or log file maybe corrupt.
I read that I could confirm it, by running a DBCC CHECKDB 'DB_NAME', so i did, and here are the last to lines of the output:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'DB_NAME'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.


The output shows that the DB isn't corrupt. But can the log file still be corrupt?

I also read that one solution might be run something called "Emergency Mode Repair" to fix the corrupt files. But some users did NOT recommend it. 

Could another solution be to delete the log file completely and then create a new?.
These symptoms sometimes occur when AutoClose in database settings is turned on. Deactivate it and try again. I had the same errors with 2008R2 Express Edition vor a Sharepoint Foundation 2010 database instance a short time ago. I investigated and found for example:


http://www.sqlservercentral.com/Forums/Topic1037190-1550-1.aspx
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/acfacc5e-bf1e-474d-825e-9eff927e0311/the-log-for-database-xtrans-is-not-available
https://stackoverflow.com/questions/15771371/the-log-for-database-x-is-not-available


Then I changed "AutoClose" to off and the troubles had gone. Before that, I had to take the affected databases offline and online again.

The errors occured everytime a scheduled job did a DBCC CHECKDB. A manually started check of the databases did not show any error.