I recently repaired a single corrupt page in one of the tables in a 70gb database.

I had a backup which included the data contained in the page so I went about using DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS. I then transferred the rows from the old database back to the newly repaired database.

After running a DBCC CHECKDB WITH NO_INFOMSGS to make sure everything was okay again I then ran a full backup. The backup is 10gb less than the previous backups (like the one I took before the repair with CONTINUE_ON_ERRORS).

What is the reason for this? Does the DBCC repair do any reordering of pages which would recover space or something similar? Table sizes look similar to previous but I'm a little worried there could be missing data.

2 Answers 2


When you transferred data, you probably compacted data by an implied index rebuild.

Or the REPAIR_ALLOW_DATA_LOSS lived up to it's name...

  • I was very careful to restore the data from the missing page. It was only 20 rows. I do think a rebuild happened on a couple of indexes because CHECKDB did list some indexes as part of the repair. Will CHECKDB delete data that isn't in the corrupt page as part of the repair? I hope not ;) Commented Jan 20, 2012 at 1:57

Just a thought...

Have you enabled the compression option for the previous or current full backup?

If compression option was enabled for the current full backup alone, then it is obvious for lesser full backup data size.

Or, the database might have been compacted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.