How can you tell whether your data is corrupt?
If you have corruption, how do you work out what’s wrong with the database?
How do you ensure you have a valid backup?
If you don’t have a valid backup, how and what do you repair?
If you do have a backup, how do you work out whether you should restore or repair? And at what granularity?
How do you go about determining what went wrong in the first place?
It’s all about limiting downtime and data-loss when a corruption occurs - from knowing the tools to understanding the choices to planning a successful strategy. Some of the features discussed: torn-page detection and page checksums, IO read-retry, backup checksums, consistency checks (DBCC CHECKDB and related commands), and database repairs. Facing database corruption is almost inevitable in every DBAs career - make sure you're prepared when it happens to you.
Meet the Presenter
Paul started in the industry in 1994 working for DEC on the VMS file system and check/repair tools. In 1999 he moved to Microsoft to work on SQL Server, specifically on DBCC. For SQL Server 2000, he concentrated on index fragmentation (writing DBCC INDEXDEFRAG, DBCC SHOWCONTIG) and various algorithms in DBCC CHECKDB. During SQL Server 2005 development was the lead developer/manager of one the core dev teams in the Storage Engine, responsible for data access and storage (DBCC, allocation, indexes & heaps, pages/records, text/LOB storage, snapshot isolation, etc). He also spent several years rewriting DBCC CHECKDB/repair. Since SQL Server 2005 shipped, Paul has managed the Program Management team for the core Storage Engine to become more focused on customer/partner engagement and feature set definition. Paul regularly presents at conferences around the world on high-availability, disaster recovery and Storage Engine internals. His popular blog is at http://blogs.msdn.com/sqlserverstorageengine
SA Innovation Centre, L2 Santos House
Thursday, 14 June 2007