September 3, 2014 at 11:02 am
Over the weekend I noticed a schedule DB integrity check failing. The DB size is about 225GB and in the past have had no issues. At first I received two emails with errors like this:
DESCRIPTION: Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0x80004005. You need to restart SQL Server to use CLR integration features.
DESCRIPTION:A read of the file 'E:\VDBs\CORELIBRARY.mdf' at offset 0x000004c44f0000 succeeded after failing 3 time(s) with error: 23(Data error (cyclic redundancy check).). Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Which I thought was odd, and after looking at the job that ran the CHECKDB, I decided to run it myself:
DBCC CHECKDB('SSRS') WITH ALL_ERRORMSGS , NO_INFOMSGS
This was the output:
Msg 6512, Level 16, State 27, Line 6
Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0x80004005. You need to restart SQL Server to use CLR integration features.
Msg 6512, Level 16, State 27, Line 6
Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0x80004005. You need to restart SQL Server to use CLR integration features.
There's no other messages outputted to the screen.
Has anyone encountered this error before when running a DBCC CHECKDB?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
September 3, 2014 at 11:43 am
Interestingly enough, running this returned no errors
EXECUTE sp_MSforeachtable 'PRINT ''?''; DBCC CHECKTABLE ([?]) WITH NO_INFOMSGS, ALL_ERRORMSGS'
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
September 3, 2014 at 12:11 pm
CheckTable isn't all that checkDB does. Try CheckAlloc and CheckCatalog.
Have you tried the restart that the message mentions?
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
September 3, 2014 at 12:16 pm
Thanks Gail, as always I appreciate the feedback. Yes, I tried the restart and while it resolved the CLR issues, it still comes back after running a full blown CHECKDB on this database.
I was starting small with the CHECKTABLE, but will run the others as time allows today.
EDIT: I am restoring another copy of the database to a different server to do additional testing
Thanks!
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
September 4, 2014 at 10:43 am
Interesting.
On the other server where I restored the latest full/diff backup, I ran a serious of checks (including the ones you mentioned) and finished it all off with DBCC CHECKDB('SSRS') WITH ALL_ERRORMSGS, NO_INFOMSGS - no longer getting errors.
:ermm:
I guess that eliminates issues with the database being corrupted.
I am curious about why the CHECKDB process needs CLR 2.0 though. Do you know why this is needed?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply