That was it. This table is a heap.

Thanks for the help.

I verified the row counts using COUNT(*) and they match, as I would expect. However, the publisher has a much larger data size.

What if I can catch it while its occurring? What query would show me while its occurring?

So then I should only have to set up maintenance on the primary and it will automatically be performed on the replicas too.

Nice script, but can't you get the same information in Management Studio just by listing a database's tables in the Object Explorer and sorting by space used?

Yep.

So it turns out that the solution is going to be clearing out the bad block at the storage level via a Netapp tool. We've tested the process on...

We did run CHECKDB on production and it did come back clean. On the Snap copy we made CHECKDSK was run and it found the bad block and marked...

We can try that, but we'll have to find a window to bring down production.

All of our testing has been on a snapshot backup. We're not trying anything in production.

Too late, the boss already fired off the SHRINK command. It completed successfully so we tried another BACKUP. Still fails at the same spot with the same error....

We did make a snapshot so that we could test it without risking production. The CHECKDB came back in 30 minutes completely clean. No errors or corruptions. ...

Unfortunately is the native SQL back up that is failing.

GilaMonster (5/31/2012)

---

CheckDB Taking 8 hours on a 300GB database? That sounds like a serious IO contention problem in and of itself. I've done checkDB of TB sized databases faster than...

Here's the error from the Backup:

BackupIoRequest::WaitForIoCompletion: read failure on backup device 'T:\Data\T2KAdmin.mdf'. Operating system error 23(Data error (cyclic redundancy check).).

We're going to be running a DBCC CHECKDB but it takes...