September 2, 2014 at 2:44 am
Hi all,
A couple of days ago I got several reported corruptions in our SharePoint 2010 databases, so I take the service offline to our users and restore the affected databases from backup - no problems so far.
I then put the service back online for the users and all is well, until the following day when I get the same errors for a different bunch of SharePoint 2010 databases.
This time the sceptic in me decided to manually re-run the DBCC checks for the affected databases and lo and behold I find that they are all consistent.
We are running SQL Server 2012 SP1, and below is an example of one such consistency error (I've stripped out the rest of the information for ease of viewing):
Msg 2536, Sev 16, State 1, Line 1 : DBCC results for 'AllDocStreams'. [SQLSTATE 01000]
Msg 2593, Sev 16, State 1, Line 1 : There are 2039 rows in 187 pages for object "AllDocStreams". [SQLSTATE 01000]
Msg 8990, Sev 16, State 1, Line 1 : CHECKDB found 0 allocation errors and 8 consistency errors in table 'AllDocStreams' (object ID 661577395). [SQLSTATE 01000]
CHECKDB found 0 allocation errors and 8 consistency errors in database 'WSS_Content_CortexShare_PrMaOf'. [SQLSTATE 01000]
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (WSS_Content_CortexShare_PrMaOf). [SQLSTATE 01000]
DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000]
And the results of the manual DBCC check:
DBCC results for 'AllDocStreams'.
There are 2039 rows in 187 pages for object "AllDocStreams".
CHECKDB found 0 allocation errors and 0 consistency errors in database 'WSS_Content_CortexShare_PrMaOf'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
This has happened repeatedly over the last couple of days since - the automated job reports inconsistencies but then a manual DBCC check confirms that no consistencies exist on those databases. I have changed the time of the automated job to ensure it doesn't clash with any other SQL or SharePoint jobs but the issue still occurs.
Has anyone seen this behaviour before in their SharePoint 2010 databases as I'm at a loss as to why this is occurring now as it's been fine for the last year since implementation up until now.
Any help will be greatly appreciated - cheers,
RainhamWolf
September 2, 2014 at 3:43 am
check the logs for storage related errors, you may well find there related errors being reported
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply