Recommended Recovery Options for Corrupt Objects

Question

Hello ,
  When I ran DBCC CHECKDB on one of my databases, I noticed few objects being corrupt.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:915964) allocated to object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data). The off-row data node at page (1:915964), slot 0, text ID 1910439936 is referenced by page (1:914286), slot 0, but was not seen in
the scan.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:915966) allocated to object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data). The off-row data node at page (1:915966), slot 0, text ID 1910439936 is referenced by page (1:914286), slot 0, but was not seen in
the scan.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:915969) allocated to object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1105439012, index ID 1, partition ID 72057594129612800, alloc unit ID 72057594152419328 (type LOB data). The off-row data node at page (1:915969), slot 0, text ID 1910439936 is referenced by page (1:914286), slot 0, but was not seen in
the scan.
Whats the best recommended practice to rectify these problems?. I would minimize the data loss as much as possible. I could use REPAIR_ALLOW_DATA_LOSS to repair but worried
about the dataloss. Trying to figure out any other better alternate approach available?.
I90Runner

Answer 1

There are so many good articles which talks about such issues at length.
I got this snapshot for you:
If any errors are reported by DBCC CHECKDB, we recommend restoring the database from the database backup instead of running REPAIR with one of the REPAIR options. If no backup exists, running repair corrects the errors reported. The repair option to use
is specified at the end of the list of reported errors. However, correcting the errors by using the REPAIR_ALLOW_DATA_LOSS option might require deleting some pages, and therefore some data.
Under some circumstances, values might be entered into the database that are not valid or out-of-range based on the data type of the column. DBCC CHECKDB can detect column values that are not valid for all column data types. Therefore, running DBCC
CHECKDB with the DATA_PURITY option on databases that have been upgraded from earlier versions of SQL Server might reveal preexisting column-value errors. Because SQL Server cannot automatically repair these errors, the column value must be manually updated.
If CHECKDB detects such an error, CHECKDB returns a warning, the error number 2570, and information to identify the affected row and manually correct the error.
The repair can be performed under a user transaction to let the user roll back the changes that were made. If repairs are rolled back, the database will still contain errors and must be restored from a backup. After repairs are completed, back up the database.
There is always some good practices to follow:
1. Maintain at-least two set of backup types.
2. Maintain never fail Backup Validation at Local DR and DR location for the backup you do for databases.
3. Maintain some Backup review process for all of these on daily\weekly\yearly basis.
4. Add job to do DBCC CheckDB on weekend at -least for you while adjusting with rebuild\upd stats job which might be already for you.
Now, if you have time to correct this issues, wherein you have made sure that this issue really exists then do following things:
1. Identify the objects which are marked as corrupted and check where DBCC is saying corrupted and why and make a note of that.
2. Take a backup of the database and restore on any dev\testing server and check these objects and whether you can restore with T-sql option like data from original table to temp table and drop\create table again. As mentioned above pointer may help you.
This way you will be able to recover database to  a great extent which was stopping from helicopter snap of DBCC CheckDB.
Let me know, how it goes for you.
Santosh Singh