I'm sure you've been there - something causes corruption in the database. You blame the hardware, the hardware guys blame the software. There's no smoking gun and the hardware diagnostics come back clean. What can you do?
This is the hardware diagnostic you really want to run. It simulates a very heavy SQL Server workload and should do a far better job of discovering flaws in your hardware setup than individual hardware vendors' diagnostics will. We recommend that you run it before installing a system as well as using it to expose hardware as the problem in difficult-to-diagnose corruption problems.
Youc an find info on it at http://support.microsoft.com/default.aspx?scid=kb;en-us;231619 and there will be an updated version released in the next month or so (I'll blog when it gets out).
This is a cool new feature of 2005. It's a per-database option that will write an error-detection checksum on each page when it is flushed from the buffer pool. When a page is subsequently read again, the checksum is recalculated and checked against that stored on the page..
Here are some points to note about page checksums (they debunk a bunch of common misconceptions):
Bad page checksums will result in IO errors being reported:
Page checksums should vastly reduce the number of undiagnosed corruption problems (saving time and hassle for you and our support team). Now all you need to do is make sure you have that excellent backup strategy to go with it...
It starts with restoring to disimiliar hardware.. Try doing a fresh install of SQL and see how it attaches itself to the hardware, then create a database, then back it up , using veritas, TSM, or whatever else you can find out there. Then, simulate a disaster. Restore this to disimilar hardware. GOOD LUCK ... If you really want to blow a blood vessel..do system state restore as well... I know what the problem is and the solution... It is really simple...
PingBack from http://drugsmoviesblog.info/sql-server-storage-engine-how-can-you-prove-that-hardware-is-the/