バックアップが存在しない、または、バックアップからのリストアが行えない場合のデータベース復旧手順

データベースが破損しエラーが返されたり、アクセスできないといった状況が発生した場合、バックアップからリストアするという対処がもっとも一般的かつ確実な対応であり、SQL Server サポートでは、通常、バックアップからのリカバリ手順をご案内しております。 しかしながら、バックアップを採取していなかったり、バックアップからのリストアに失敗したという場合もあります。 今回は、そのようなバックアップからのリストアが行えない場合のデータベースの修復方法を紹介します。

※ 注意事項 ※

• 以下の手順は検証済みの手順ですが、必ずしもデータベースの復旧を保証しているものではありません。手順の実施につきましては、自己責任において行ってください。

• データベースの破損状況によっては、以下で紹介する修復手順を実施しても、データベースに接続でき、アプリケーションが実行できるまでの状態に復旧できない場合もあります。その場合はデータベースの再作成が必要となります。

• 本手順を実施すると、トランザクションの一貫性が失われる場合があります。トランザクションの一貫性が保たれているかどうかの確認は、対象データベースに格納されているデータ間の関連性を熟知している方、もしくは、この手順を実施する方の責任において実施する必要があります。トランザクションの一貫性が保たれているかどうかの確認が行えない場合には、この手順を実施しないで下さい。 

■修復手順

1. 対象データベースのファイルコピーを行います。

SQL Server サービスを停止し、対象データベースファイルのファイルバックアップ（別フォルダにデータベースファイルをコピー）を行います。

データベースファイル、ログファイルのファイルパスは以下のクエリにて確認可能です。以降の手順で予期しない問題が発生した場合、このファイルを用いて手順 1. の状態まで戻すことができます。バックアップ完了後、SQL Server サービスを再起動します。

select d.name as databasename,f.name as filename ,f.physical_name as filepath
from sys.master_files f,sys.databases d where d.database_id = f.database_id
GO

2. Microsoft SQL Server Management Studio を起動し、sa 等の管理者権限をもつ sysadmin ロールメンバとして SQL Server へ接続します。

3. [新しいクエリ] を選択します。

4. 下記のコマンドを実行し、整合性を確認します。

DBCC CHECKDB([データベース名])
GO       

データベースが「未確認」状態、「復旧待ち」状態である場合は、上記コマンドは実行できません。 その場合は、下記のように、対象データベースを緊急モードに変更後、DBCC CHECKDBコマンドを実行します。     

USE master
GO
ALTER DATABASE [データベース名] SET EMERGENCY
GO
DBCC CHECKDB([データベース名])
GO

緊急モードに変更することにより、システム管理者はデータベースに読み取り専用でアクセスできるようになります。

5. 出力された結果を確認します。

DBCC CHECKDB コマンド結果に、エラーメッセージが含まれる場合は、そのエラーに対する対処が必要です。

repair_rebuild、repair_allow_data_loss を指定した DBCC CHECKDB による修復については、以下の点に注意が必要です。

   1. テーブル間に制約があっても考慮されない。

   2. repair_rebuild オプションを指定した場合、File Stream に関わるエラーは修復されない（すべてのエラーが修復されるわけではない）。

   3. repair_allow_data_loss オプションを指定した場合、トランザクションの一貫性が失われる可能性がある。破損したデータは削除され、DBCC CHECKDB では、どのデータが削除されたかは示されない。

以上のとおり、DBCC CHECKDB により修復を行ったとしても、必ずしも元通りの状態になるわけではありません。上記オプションを使用してデータベースの修復を行い、データベース自体の整合性エラーがなくなったとしても、そのデータベースをアプリケーションで利用できるとは限りません。修復したデータベースを用いて問題なくアプリケーションが利用可能かどうかは、ユーザー自身で確認する必要があります。 アプリケーションで利用できなかった場合はデータベースの再構築が必要となる場合もあります。

そのため、DBCC CHECKDB に修復オプションを指定したデータベース修復は、バックアップ等も用いた復旧が行えない場合の最後の手段であり、テーブル間の関連性やデータの内容を熟知しており、DBCC CHECKDB による修復後、その結果を確認できる方が責任を持って行う必要があります。

削除されたデータについてマイクロソフトに問い合わせいただいても、どのようなデータが削除されたのかについては確認することはできません。

6. DBCC CHECKDB 結果に出力されたオプションを利用して、データベースの修復を実施します。

まず、シングルユーザーモードに変更します。

ALTER DATABASE [データベース名] SET SINGLE_USER
GO

シングルユーザーへ変更しようとしているデータベースにアクセスしているユーザーがいる場合、ALTER DATABASE ステートメントはそのユーザーがデータベースへのアクセスを終了するまで待機状態になります。コマンドタイムアウトが設定されている場合にはタイムアウトになります。

データベースにアクセスしているユーザーを強制的に切断してシングルユーザーへ変更する場合は実行中の ALTER DATABASE ステートメントをキャンセルし、代わりに以下を実行します。

ALTER DATABASE [データベース名] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

データベースをシングルユーザーに変更後、修復オプションを指定した DBCC CHECKDB を実行します。DBCC CHECKDB に指定する修復オプションは、手順 4. で確認したオプションです。

DBCC CHECKDB('データベース名','REPAIR_ALLOW_DATA_LOSS')
GO

または

ALTER DATABASE [データベース名] SET ONLINE
GO
DBCC CHECKDB('データベース名','REPAIR_REBUILD')
GO

データベースが緊急モードの状態で REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB を実行すると、トランザクション ログが壊れている場合には、トランザクション ログが再構築されます。ただし、トランザクション ログの再構築の結果、トランザクションの一貫性が失われる場合があります。

また、DBCC CHECKDB が正常に終了した場合は、データベースの状態は ONLINE に設定されますが、データベースにはトランザクション上、一貫しない部分が 1 つ以上含まれる可能性があります。

DBCC CHECKDB がエラーなく実行完了したとしても、次の手順 7. でエラーが検出される可能性があります。必ず、手順 7. の整合性確認チェックを行ってください。

DBCC CHECKDB はすべてのエラーを修復できるわけではありません。DBCC CHECKDB が修復処理自体のエラーを報告した場合は、DBCC CHECKDB ではデータベースを修復することはできません。

7. DBCC CHECKDB を修復オプションなしで実行し、エラーが存在しないことを確認します。

DBCC CHECKDB('データベース名')
GO

DBCC CHECKDB コマンドにてエラーが検出された場合は、メッセージで示された修復オプションを指定した DBCC CHECKDB により、手順 6. および 7. をエラーがなくなるまで繰り返します。ただし、修復を繰り返しても報告されるエラー内容に変化がみられない場合、そのエラーは修復不可能なエラーです。

8. DBCC CHECKDB コマンドでエラーが 0 になったことを確認後、下記のコマンドを実行し、制約に関する整合性をチェックします。

USE [データベース名]           
GO      
DBCC CHECKCONSTRAINTS      
GO       

上記手順 7. の DBCC CHECKDB は、データフォーマットに関するチェックは実施されますが、制約に関するチェックは行われません。そのため、修復対象のデータベースで FOREIGN KEY 制約や CHECK 制約を使用している場合は、データベースの修復完了後、DBCC CHECKCONSTRAINTS コマンドを実行し、制約の整合性についても確認する必要があります。

9. データベースをマルチユーザーに戻します。

ALTER DATABASE [データベース名] SET MULTI_USER           

10. 必要に応じて下記のコマンドを実行し、該当のデータベースの復旧モデルを「完全」に戻します。

上記手順 6. で REPAIR_ALLOW_DATA_LOSS 句を指定して DBCC CHECKDB コマンドを実行し、破損個所の復旧をおこなった場合、該当のデータベースの復旧モデルが「単純」へと変更されます。そのため、必要に応じてデータベースの復旧モデルを元の復旧モデルに戻します。      

ALTER DATABASE [データベース名] SET RECOVERY FULL
GO             

「一括ログ」モデルに戻す場合は、'ALTER DATABASE [データベース名] SET RECOVERY BULK_LOGGED' を実行します。

以上でデータベースの修復作業は完了です。

その後、削除されたデータの特定や、クライアントからの接続可否、アプリケーションからの使用に問題がないかどう可能かなど、そのシステムおよびアプリケーションの観点で問題がないかどうかについて確認します。

また、必ず「バックアップ」をご採取ください。