SQL Server Storage Engine

Another disaster recovery 'advice' gem...

I just saw this on one of the forums - it's another wonderful piece of advice to studiously avoid.

Scenario: Drive goes bad and causes a torn page error. User wants to fix the problems and move the database to a different drive.

The advice given by one person was just to detach the database with the torn-page error, move it to the new drive and re-attach it.

Luckily there were a few other sensible people around (I was on a plane flying back from TechEd) to interject some real advice, including:

  • using the backups rather than copying files about
  • or, if no backup exists, moving it by stopping SQL Server, copying the files off the bad drive, swapping out the bad drive, putting in the new drive with the same drive letter as the damaged ones, copying the files back into exactly the same directory path as before and restarting SQL Server. Also, taking a backup of the damaged database before doing all of this.

So why was detach/attach bad advice? The problem comes with the process of doing the attach. It's quite possible that the damaged page(s) are required during attach, and if they're damaged then attach will fail and there's nothing you can do to force it to work.

Bottom line: don't ever detach a damaged database if you don't have valid backups to restore from.

Published Sunday, June 18, 2006 6:06 PM by Paul Randal - MSFT

Comments

 

SqlNews said:

Its been almost a month since the Storage Engine Blog was started and as Kimberley Tripp has mentioned its...
June 18, 2006 5:28 PM
 

» Blog Archive » Disaster Recovery - SQL Server Storage Engine : Another disaster recovery 'advice' gem… said:

September 29, 2006 4:12 PM
Anonymous comments are disabled

About Paul Randal - MSFT

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 and DBCC SHOWCONTIG) plus various algorithms in DBCC CHECKDB. During SQL Server 2005 development Paul 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 and repair. For SQL Server 2008, Paul managed the Program Management team for the core Storage Engine to become more focused on customer/partner engagement and feature set definition. In 2007, after 8.5 years on the SQL Server team, Paul left Microsoft to join his wife, Kimberly Tripp, running SQLskills.com and pursuing his passion for presenting and consulting. Paul regularly presents at conferences and user groups around the world on high-availability, disaster recovery and Storage Engine internals. His popular blog is at http://www.sqlskills.com/blogs/paul/.

© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker