Strategies when DBCC CheckDB REPAIR_ALLOW_DATA_LOSS can’t repair a database

To get it out of the way, in this scenario we are repairing a number database where no backups were taken from before the corruption, so restoring a backup is not an option. Not my database 🙂

Upon running DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS we get thousands of errors that look like this:

Msg 8928, Level 16, State 1, Line 7 Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24911) could not be processed.  See other errors for details.         Repairing this error requires other errors to be corrected first. Msg 8965, Level 16, State 1, Line 7 Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24911), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.         Repairing this error requires other errors to be corrected first. Msg 8928, Level 16, State 1, Line 7 Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24912) could not be processed.  See other errors for details.         Repairing this error requires other errors to be corrected first. Msg 8965, Level 16, State 1, Line 7 Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24912), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.         Repairing this error requires other errors to be corrected first. Msg 8928, Level 16, State 1, Line 7 Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24913) could not be processed.  See other errors for details.         Repairing this error requires other errors to be corrected first. 

Running it repeatedly does not reduce the errors, so it looks like DBCC cannot repair this.

My next thought was to try and identify and delete the problematic rows in the table. When I tried deleting a known-problematic row though, it also errored, so my current thought is to extract known-good rows into a new table with the same schema as the old, drop the old table and rename the new one to match the old one.

The problem with this is that SQL Server, instead of providing a catchable error, simply drops the connection whenever a problem row is encountered, so I can’t seem to find a programmatic way to identify the ‘good’ rows.

Is there any way in T-SQL to force it to provide a nice catchable error so I can iterate through the table and pull out the good rows, or some ‘advanced’ mode of DBCC CHECKDB that might be able to repair it that isn’t obvious anywhere on the web?