These are broken links to statsistics blobs. If you DBCC PAGE the pages referenced in the errors, you'll be able to see what indexes the stats are for. Then try...

No - it's nothing to do with clustering - it's the I/O subsystem. Possibly bad memory on the primary node. Can you run memory diagnostics on it?

This looks exactly like a stale read issue from an I/O subsystem controller. It's definitely the data files that are corrupt, not the log file.

Yeah, that's a little high 🙂

Do you have page checksums enabled for the database? Are you seeing 823 or 824 errors in the errorlog? These would be proof that it's the I/O subsystem and avoid...

These two errors together lead me to believe there's something wrong with your I/O subsystem. The CHECKDB issue is caused most commonly when the I/O subsystem is overloaded (can you...

Yes, if that solution works for you.

You also need to investigate why this happened. Torn-page commonly happens when the server loses power and some component of the I/O subsystem fails...

Here you go: Misconceptions about running DMVs on database with lower compatibility levels

ok - will do. It's lunchtime - nothing else to do 🙂

That page has been corrupted (torn-page is usually from power-outage - did that happen?) and is not recoverable. You've got two choices - restore from a backup (possibly even a...

You don't need to use DBCC SHOWCONTIG for databases in non-90 compat modes. As long you run the DMV script in a database that's in 90-compat mode, it'll work fine...

See my blog Importance of proper transaction log size management

Be careful running a script like this that touches all indexes on all databases. Even though the LIMITED mode is only oging to read the level of the index above...

Nope - that can't happen with DBCC in 2000 and beyond. It's stale read issue on your I/O subsystem, or something similar, or you're doing something and by the time...

Cheers - onsite at customer right now 🙂