|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
I have a dept who would prefer I repair instead of restore else they'll lose 4 hours of work:
DBCC CHECKDB with PHYSICAL_only output:
DBCC results for 'sysdevcq'. Msg 8909, Level 16, State 1, Line 2 Table error: Object ID 0, index ID 0, page ID (1:1515894). The PageId in the page header = (0:2). CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single object. Msg 8928, Level 16, State 1, Line 2 Object ID 181575685, index ID 255: Page (1:1515893) could not be processed. See other errors for details. Msg 8939, Level 16, State 98, Line 2 Table error: Object ID 181575685, index ID 255, page (1:1515893). Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057 and -1. Msg 8928, Level 16, State 1, Line 2 Object ID 181575685, index ID 255: Page (1:1515894) could not be processed. See other errors for details. There are 0 rows in 0 pages for object 'cq.attachments_blob'. CHECKDB found 0 allocation errors and 3 consistency errors in table 'cq.attachments_blob' (object ID 181575685). Msg 8928, Level 16, State 1, Line 2 Object ID 629577281, index ID 0: Page (1:2085142) could not be processed. See other errors for details. Msg 8941, Level 16, State 102, Line 2 Table error: Object ID 629577281, index ID 0, page (1:2085142). Test (sorted [i].offset <= m_freeData) failed. Slot 3, offset 0x202c is invalid. There are 0 rows in 0 pages for object 'cq.history'. CHECKDB found 0 allocation errors and 2 consistency errors in table 'cq.history' (object ID 629577281). CHECKDB found 0 allocation errors and 6 consistency errors in database 'sysdevcq'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (sysdevcq ). DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Can I repair or shall I restore? Where is Paul Randall when I need him.... :)
cheers
thanks
SQL_EXPAT
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
please note this is a SQL2000 instance - I posted to the wrong forum. sorry.
thanks
SQL_EXPAT
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
I have gone with the RESTORE. Data loss was not option. cheers
thanks
SQL_EXPAT
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:57 PM
Points: 37,687,
Visits: 29,945
|
|
Paul will probably be along in a few hours. Or he might be on vacation.
Restore is always the preferred option. Repair is, in most cases, for when you can't restore because you have no clean backup (or no backup at all).
If you have backups and the DB's in full recovery, then you can restore with absolutely no loss of work. Back up the tail of the log, restore the full backup, restore all the logs, in order. If you had repaired, you would have lost two pages of the table cq.history, plus the LOB data for those rows.
Have you checked the windows event log and any RAID/SAN logs that you have? Typically corruption's a hardware issue.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 1:23 PM
Points: 1,905,
Visits: 1,601
|
|
Repairing here would have lost two pages of table data - but I might still have been tempted to restore the backups and see if those two pages were in the backup with the data on - then run repair to deallocate the pages in the corrupt database and pull over the deleted data from the restored copy.
Restore *is* usually the way to recover with no data-loss, but a more severe downtime SLA might trump the data-loss SLA and force a repair rather than a restore... especially if the backup strategy doesn't support targetted restores. Shame you're on 2000 - you might have been able to use single-page restore to get through this.
Certainly looks like I/O subsystem corruption to me - possibly a RAID controller having stale-read problems?
Thanks
Paul Randal CEO, SQLskills.com: Check out SQLskills online training! Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
Hi Gail and Paul
Thanks for the reply. I restored from our backup and ran DBCC CHECKDB with NO_INFOMSGS again and we still have corruption:
Msg 8909, Level 16, State 1, Line 1 Table error: Object ID 0, index ID 0, page ID (1:1515894). The PageId in the page header = (0:2). CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single object. Msg 8928, Level 16, State 1, Line 1 Object ID 181575685, index ID 255: Page (1:1515893) could not be processed. See other errors for details. Msg 8939, Level 16, State 98, Line 1 Table error: Object ID 181575685, index ID 255, page (1:1515893). Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057 and -1. Msg 8928, Level 16, State 1, Line 1 Object ID 181575685, index ID 255: Page (1:1515894) could not be processed. See other errors for details. CHECKDB found 0 allocation errors and 3 consistency errors in table 'cq.attachments_blob' (object ID 181575685). CHECKDB found 0 allocation errors and 4 consistency errors in database 'sysdevcq'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (sysdevcq ).
I will now go back to tape to get an earlier backup. In the meantime I'm going to attempt a repair on the current DB.
cheers
thanks
SQL_EXPAT
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:57 PM
Points: 37,687,
Visits: 29,945
|
|
Means that the corruption was present in that backup. Do you run checkDB regularly?
If this is 2005, check the error log for the startup messages. As SQL brings the DBs online, it will print a message to the error log saying when CheckDB last ran without errors
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
this is an old server where we weren't running regular DBCCs but from now on I will.
thanks
SQL_EXPAT
|
|
|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Today @ 11:09 AM
Points: 31,416,
Visits: 13,730
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, September 27, 2012 9:09 PM
Points: 136,
Visits: 383
|
|
Great tip. It would be nice to also get a warning in the error log if a CHECKDB has never been run against the databases.
Alan Cranfield
thanks
SQL_EXPAT
|
|
|
|