99zardoz (10/5/2011)
Just a thought for everyone and more of a question than a suggestion but in this situation would not be worth shrinking the log file with DBCC SHRINKFILE?
Shrinkfile would have failed, the log header was corrupt. No amount of shrinking would help here, the problem was not that the log was too large, it was that the log was corrupt.
As there is only simple recovery, the contents of the log file are of little practical value anyway arent they?
Do you like your database consistent and durable or corrupt with missing data? If the latter, sure, they're of little practical use. The point of the log is to ensure durability of transactions and consistency of data no matter what. The backing up of the log for point-in-time recovery is a secondary usage.
p.s. this issue is 8 months old and very likely resolved one way or another by now.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability