May 17, 2013 at 12:12 pm
I have a 2tb database with one table that has apparently been corrupted (torn page). Since we only run the DBCC Checkdb once a week (no time for daily on this large a database). The DBCC returns the following error - I am leaving out all the clean messages as its just noise:
At the top of DBCC report:
Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:14060424) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (1:14060425) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
Later at the table checks:
DBCC results for 'RPT_DAILY_KPI_CUST_MATERIAL_old'.
Msg 8928, Level 16, State 1, Line 1
Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 112017351901184 (type In-row data): Page (1:14060423) could not be processed. See other errors for details.
Msg 8928, Level 16, State 1, Line 1
Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 112017351901184 (type In-row data): Page (1:14060424) could not be processed. See other errors for details.
Msg 8928, Level 16, State 1, Line 1
Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 112017351901184 (type In-row data): Page (1:14060425) could not be processed. See other errors for details.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 112017351901184 (type In-row data). Page (1:14060426) is missing a reference from previous page (1:14060425). Possible chain linkage problem.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 112017351901184 (type In-row data). Page (4:15685472) is missing a reference from previous page (1:14060423). Possible chain linkage problem.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 393492328611840 (type In-row data), page (1:14060423). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -1.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 393492328611840 (type In-row data). Page (1:14060423) was not seen in the scan although its parent (4:15685688) and previous (1:14060422) refer to it. Check any previous errors.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 393492328611840 (type In-row data). Page (1:14060424) was not seen in the scan although its parent (4:15685688) and previous (4:15685511) refer to it. Check any previous errors.
Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1709249144, index ID 1, partition ID 393492328611840, alloc unit ID 393492328611840 (type In-row data). Index node page (4:15685688), slot 51 refers to child page (1:14060425) and previous child (1:14060424), but they were not encountered.
There are 121254588 rows in 1443509 pages for object "RPT_DAILY_KPI_CUST_MATERIAL_old".
CHECKDB found 0 allocation errors and 9 consistency errors in table 'RPT_DAILY_KPI_CUST_MATERIAL_old' (object ID 1709249144).
This table is not in use. We confirmed it by renaming it to _old and only when it is read by support staff do any errors pop up, The table is not being updated.
The Instance is 64 bit SQL 2008 R2 Sp1.
Can we simply drop this table - or do we risk the database going suspect by doing that?
Our other alternative is to take an outage and run a DBCC repair. The users do not want that, but they also would not appreciate a suspect database.
May 17, 2013 at 2:06 pm
Can you post the last few lines of the CheckDB output please. Or the entire output when run WITH NO_INFOMSGS?
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
May 18, 2013 at 8:19 am
Thanks for hanging in there with me. The closing statement on the DBCC are as follows:
CHECKDB found 0 allocation errors and 11 consistency errors in database 'MB_DW_USA'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (MB_DW_USA).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
As I stated above, we would prefer to solve this without taking a 5 hour outage to repair with data loss. Its a big deal to the users that the DB remain online if at all possible.
How about simply truncating the table? Not even dropping it?
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply