Server: Msg 8928, Level 16, State 1, Line 1 Object ID 1289107683, index ID 0: Page (1:8244) could not be processed. See other errors for details. Server: Msg 8944, Level 16, State 1, Line 1 Table Corrupt: Object ID 1289107683, index ID 0, page (1:8244), row 11. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 148 and 2. DBCC results for 'FOutStanding'. There are 9242 rows in 187 pages for object 'FOutStanding'. CHECKTABLE found 0 allocation errors and 2 consistency errors in table 'FOutStanding' (object ID 1289107683). repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKTABLE (FMComp005.dbo.FOutStanding ).Now, if I ask my client to run DBCC CheckTable with repair_allow_data_loss option, I know, some data will be lost. Is there any way to know beforehand, what data will be lost?
In order to determine the rows having consistency or allocation issues on a specific table, DBCC CHECKTABLE commands...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
should be issued and will indicate the pages with the issues. Rather then issuing the DBCC CHECKTABLE with the REPAIR_ALLOW_DATA_LOSS, it may be more advantageous to following these steps:
- Issue DBCC CHECKDB to determine all errors in a specific database
- Issue DBCC CHECKCATALOG to determine any schema related issues in a specific database
- Issue DBCC CHECKTABLE to determine the errors on the specific table
- Create another table with the same DDL as the tables with an issue and add a suffix of '_New'
- Issue SELECT statements with a WHERE clause utilizing a range against the original table to determine which can be read
- It may be necessary to fine to this query to a single row and then to particular columns to determine which data is not retrievable
- Insert the data via a SELECT statement into the '_New' table
- Issue DBCC CHECKTABLE to verify that the new table is error free
- Attempt to salvage the remainder of the data from query a previous backup
- Backup the database
- Rename the original table to have a suffix of '_Old'
- Rename the '_New' table to have no suffix
- Drop the '_Old' table
- Test the application to ensure it performs as expected
- Issue DBCC CHECKDB to ensure no allocation or consistency issues in the entire database
If this does not solve the problem, then issue DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, but expect to lose the data originally indicated in the DBCC CHECKDB statement plus the potential for any data with a linkage pointer.
Discover the benefits of DBCC CHECKDB for Analysis Services 2016
Dig Deeper on Microsoft SQL Server Installation
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.