Question : Using "dbcc checkdb('dbname')", the best way to check DB integrity?

I'm running Sybase 11.9.2, with raw partitions, on AIX.  Is using "dbcc checkdb('dbname')" the best (I know it's not speed wise...but in reliablity) way to check the DB for integrity.  What all does it check for?  I'm gathering that it would report ANY problems with my DB...is that accurate?   ...also, is there any issue with running concurrent with user activity, or is it better to run in single user mode?  I've run it a few times, always concurrently with other user activity, and even at times concurrent with the backup (which becuase of how long it takes could not be helped) and have not seen any issues - but I've read a few things that indicate that maybe I cannot trust the results this way?  

I'm asking this becuase our DB workload has been increasing considerably lately, thus my concern for possible corruption or other problems has increased, and I want to make sure I am checking things in a reliable way.

I've not had an error in the few times I've done the check, only reports of "The total number of pages which could be garbage collected to freee up some space is ###"  - When I get these messages with any considerable number of pages to collect, I have been running a "reorg rebuild" on the table...  Is this the correct action to take?  Is there a better response action to these?

Appreciate all you guys do...

Thanks

Answer : Using "dbcc checkdb('dbname')", the best way to check DB integrity?

I don't disagree with anything Bill's said (I very seldom do 8-) ), but I'm afraid there's more that should be said.

> I'm gathering that it would report ANY problems with my DB...is that accurate?

No. Completely not accurate.

dbcc checkdb validates the internal structure of each page in the database being checked. There is a lot of complicated things that are checked here, but what's important is that this is only confirmed that each page looks like a properly constructed page. (From memory I think there are also some data vs index comparisons made but I won't swear to that.) I think checkdb also checks page linkage between pages in a page chain.

But this does not check everything that could be a problem with your database. I'm sorry to say, but dbcc checkdb is only one of three dbccs you must run to being able to detect all problems.

You also need dbcc checkcatalog. This checks referential integrity between system tables in the database (ie. do all rows in syscolumns refer to object ids that actually exist in sysobjects; do all tables actually have at least one column, etc). This is very fast to run and minimally intrusive. Its speed is proportional to the number of objects in the database, but the size of those objects are not important. This usually runs in seconds.

You also need the most important dbcc - dbcc checkalloc. Checkalloc looks at every page marked as "allocated" and confirms it is actually used (has data), and more importantly, is used by the object it was marked as allocated to. Then it reads every page that is used, and confirms that the page is known and actually allocated to the object it belongs to. If a page had data on it but wasn't correctly allocated, it could be reallocated and be overwritten. If a page was allocated but not actually used, this isn't quite so serious but it can break various operations until it is fixed, and obviously that page is now wasted space as it can't be used for anything.

Summary: Regardless of how often or when you run dbcc, you must run ALL THREE of checkdb, checkalloc and checkcatalog to know that you have caught any corruptions. (Sybase likes to talk about "inconsistencies" but let's speak plainly - any database inconsistency is corruption.)

Now to your other points. Nightly dbcc is unlikely to be providing you value in proportion to what it is costing. Dbcc checkdb has to read every used page at least once; checkalloc has to read every page at least twice. These reads are issued like regular reads from a SELECT statement - ie. they need to take out shared (read) locks, which will block writers. Normally each shared lock is released as soon as the read completes, but still, that's locking you maybe didn't need.

It's probably most common for production systems to do a weekly dbcc. Questions that would help determine what was a good answer for you are things like "If data was corrupt and irretrievable, how long it is ok to wait before finding out?" Maybe that really is nightly; for some sites it is. However since you need to run three dbccs per database, not just the one you currently are, I suspect you won't be able to run all three nightly.

You could consider alternating, perhaps checkdb one night and checkalloc the next. If you aren't already, you could also run multiple dbccs (on different databases) concurrently, up to the number of engines ASE has been configured for. You definitely don't want to do this while the system is being used for anything else!! There are various ASE tuning measures that can help speed up dbcc performance (the main one is to configure your data cache(s) for "large I/O" - you can read up on this in the Performance & Tuning Guide).

If you have a dedicated secondary Test or Dev system of the same size, you can load your backups into that and run your dbccs there, without disturbing production at all. Dump and load tends to make corruption a good deal worse, so if a database comes up clean after both a dump and load, you can have high confidence the source database is also healthy.

Your other question was whether the dbcc is being compromised by being run while other work is being done. The quality of dbcc is not affected by this - you are just as likely to detect any corruptions. You may however get some false positives which could occur if a page is written to mid-flight, or between any of the "multi-pass" stages (ie checkalloc, check usage against allocation, and then the page is deallocated before checking allocation against usage - this will look like a corruption). Mostly this happens in the transaction log. If you get any spurious errors like this, you can run the table-level versions of dbcc (checktable and tablealloc) against whatever object was reported in the error.

Hope this helps! The only really important thing to take away from this essay is that no, checkdb is NOT enough on its own, you must also be doing checkcatalog and checkalloc. (There is also dbcc checkstorage which was intended to replace these - it is faster but less reliable, you run it but if it flags a problem, you fall back to the older and slower checkdb/checkalloc or their table-level equivalents).

Good luck!