SQL Server の障害復旧

  • [アーティクル]

SQL Server: バックアップを使用して障害から復旧する

Paul S. Randal

復元方法を知らなければ、SQL Server のバックアップを作成する意味がありません。データベースの完全バックアップよりも複雑なバックアップを所有している場合は、データベースを必要な時点の状態に復元できるように、RESTORE のいくつかのオプションを把握している必要があります。

複雑なデータベース レイアウトやバックアップ戦略を採用していて、たとえば、1 つのファイルまたはファイル グループを復元したり、部分的なデータベースの可用性を活用したりする必要がある場合は、なおさらです。
効率的なバックアップ戦略を展開し、バックアップが有効であれば、目標復旧時間 (RTO) 内に目標復旧時点 (RPO) まで、障害から復旧できます。この 3 部構成のシリーズの最初の記事では、バックアップのさまざまな種類とバックアップ戦略の立て方について説明しました (詳細については、2009 年 7 月号「SQL Server のバックアップについて」(英語) を参照してください)。

この記事では、復元のしくみと一般的ないくつかの復元操作の実行方法について説明します。2009 年 7 月号のバックアップに関する記事と、その冒頭で紹介した参考資料を読んでおくと役に立ちます。また、特定の時点への復元、部分的なデータベースの可用性を使用したオンラインの部分復元など、より複雑な操作についても説明します。

バックアップに関する前回の記事と同じように、この記事では、RESTORE 構文のしくみやすべての復元操作の具体的な手順については説明しません。構文のしくみや詳細については、SQL Server オンライン ブックで詳しく説明されています。詳細 (特に、この記事で使用している例) については、「RESTORE (Transact-SQL)」を参照してください。実際、RESTORE には非常に多数のオプションが用意されており、このオプションについての記事を 1 本執筆できるくらいです。「バックアップと復元を行う方法に関するトピック (SQL Server Management Studio)」では、ツールを使用して復元を実行する方法について説明しています。

復元の 4 つのフェーズ

復元のしくみについて説明しましょう。復元操作は、最大で次の 4 つのフェーズで構成されます。

  1. ファイルの作成と初期化
  2. データおよび/またはトランザクション ログのコピー
  3. 復旧の再実行フェーズ
  4. 復旧の元に戻すフェーズ

障害復旧の主な目的の 1 つは、できるだけ早くデータベースをオンライン状態に戻すことです。障害復旧計画に (たとえば、データベース ミラーへのフェールオーバーではなく) バックアップの復元が含まれている場合は、復元プロセスをできるだけ迅速に実行する必要があります。この 4 つの各復元手順を見て、この一連の手順を迅速に進めるためにできることを考えてみましょう。

データとログ ファイルが既に存在している場合は、基本的に 1 つ目の手順は省略できます。つまり、既存のデータベースを上書きする場合は、復元を実行する前にデータベースを削除してはなりません。代わりに、最初の復元操作で WITH REPLACE オプションを使用して、SQL Server に既存のファイルを使用するよう指示します。ファイルが存在しない場合は、ファイルが作成されて初期化されます。ファイルの作成は短時間で終わりますが、ファイルをゼロで初期化する処理には時間がかかる場合があります。

セキュリティ上の理由により、既定で、すべてのデータベース ファイルはゼロで初期化されます。SQL Server インスタンスの瞬時初期化を有効にして、データ ファイルの作成および拡張の操作 (復元中に必要となる操作を含む) におけるゼロで初期化する処理をスキップできます。これにより、データ ファイルのサイズが 1 TB 未満でも、数時間のダウンタイムを削減できる場合があります。トランザクション ログ自体の循環性により、トランザクション ログ ファイルは必ずゼロで初期化されます。

これについては、私のブログ記事 (英語) の瞬時初期化のカテゴリを参照してください (オンライン ブックの参考トピックも紹介しています)。

フェーズの 2 つ目の項目が、"～および/またはトランザクション ログ" となっていることを不思議に思っている方もいるでしょう。前回の記事を読んだ方は、トランザクションの一貫性がある特定の時点の状態にデータベースが復元されるようにするために、すべての完全バックアップと差分バックアップにもトランザクション ログ レコードが含まれていることを覚えているでしょう。フェーズ 2 は単なるコピー操作で、データは処理しません。そのため、この手順を迅速に進める主な方法は、パフォーマンスが優れた I/O サブシステムを用意することです。これは、ハードウェアで問題を解決できる数少ない例の 1 つです。

コピー フェーズを高速化する他の方法としては、なんらかのバックアップ圧縮テクノロジを使用できます。この場合は、SQL Server 2008 にネイティブなテクノロジか、サードパーティ製のソリューションの 1 つのどちらかを使用します。コピー フェーズは、バックアップ メディアからの読み取りと、データおよびログ ファイルへの書き込みの、2 つのプロセスで構成されています。(圧縮したバックアップ メディアを使用して) 読み取りを少なくできる場合は、使用する CPU リソースは若干増えますが、全体的なプロセスを高速化できます。

フェーズ 3 とフェーズ 4 の目的は、トランザクション ログに基づいて復旧を実行して、データベースをトランザクションの一貫性がある特定の時点に戻すことです。復旧の詳細については、2009 年 2 月号の記事「SQL Server のログ記録と復旧について」で説明しました。後で説明しますが、フェーズ 4 は省略可能です。

復元中に復旧する必要があるトランザクション ログの量が増えると、復元にかかる時間が長くなります (これについては、これ以上の説明は不要でしょう)。たとえば、1 週間前に作成したデータベースの完全バックアップとその時点から 1 時間ごとに作成したトランザクション ログ バックアップがある場合、復元プロセスでは、基本的に、先週に実行したすべてのトランザクションを再生します。この問題の解決策については、前回の記事で説明しました (差分バックアップを完全バックアップとログ バックアップに追加するという戦略です)。

データベースの差分バックアップには、最後にデータベースの完全バックアップを作成してから変更されたすべてのデータ ファイルのページが含まれるので、これを復元操作で使用することで、データベースの完全バックアップを作成してから差分バックアップを作成するまでの間に発生したすべてのトランザクションを再生する必要がなくなります。これにより、データベースの復元にかかる時間を大幅に短縮できます。ただし、この場合は、もう少し複雑なバックアップ戦略を使用する必要があります。

詳細については、オンライン ブックの「SQL Server におけるバックアップと復元のパフォーマンスの最適化」を参照してください。

復元する必要があるデータを特定する

障害発生時に、まず行う必要があるのは、破損した部分を特定することです。破損した部分を特定することで、障害から復旧するために実行する必要がある作業を特定できます。ストレージ メディアで障害が発生している場合は、次の可能性が考えられます。

  • データベース全体が破損している (たとえば、データベースを格納しているものが破損しているか、データベースが単一のデータ ファイルである場合に、そのファイルが破損している)
  • 複数のファイル グループで構成されたデータベースで、1 つのファイル グループが破損している
  • 複数のファイルで構成されたファイル グループで、1 つのファイルが破損している
  • データベース内の 1 ページが破損している
  • データベース全体に破損が見られる

SQL Server エラー ログで、ファイルにアクセスできない、ページの読み取りエラー (ページのチェックサムのエラー、破損ページの検出エラーなど) が発生した、または全般的な破損が発生した、という通知を調べることによって、破損箇所を突き止めることができます。破損が発生している場合は、通常、DBCC CHECKDB の整合性チェック操作を実行して、破損の程度を把握します。

整合性チェックの説明については、ごく簡単に紹介するにとどめておきますが、詳細については、2008 年 11 月の Tech-Ed IT Forum で私が行ったプレゼンテーション「データベースの破損を乗り切る - 検出から解決まで」 のビデオや、今年初めに TechNet Radio でデータベースの破損について説明したインタビュー (英語) を視聴することができます (インタービューは、ここからダウンロードできます)。

障害は、I/O サブシステムやサーバーの障害に限ったことではありません。人的エラーについても考慮する必要があります。データベース テーブル (またはデータベース テーブルのデータ) は、適切にプログラムされていないアプリケーションや、入念にデザインされていない Transact-SQL ステートメント (運用サーバーで作業していることに気が付かなかったというシナリオ) により、誤って削除されてしまうことがよくあります。そのような場合は、復元する必要があるデータや、復元する時点を把握するのが非常に難しくなる場合があります。特に、ミスを犯したことを白状する人がいない場合はなおさらです。運が良ければ、既定のトレースによる標準的なレポートを使用して、DDL 操作を引き続き使用することができたり、ログ記録から DELETE ステートメントを検出できることがありますが、ほとんどの場合、データベースに対して行われた操作とそれを行ったユーザーに関する記録はありません。この状況からの復旧については、後で詳しく説明します。いつだれが誤ってデータを削除してしまったのかにかかわらず、復旧までの時間が長くなればなるほど (つまり、問題を認識するまでの時間が長くなればなるほど)、復旧作業が困難になる可能性があります。

そのため、データベースで完全復旧モデルが採用されていて、トランザクション ログが破損していない場合は、まず、ログ末尾のバックアップを実行して、障害が発生する時点までのすべてのトランザクションがバックアップされていることを確認します。この最終的なトランザクション ログ バックアップには、障害が発生する時点までのすべてのトランザクションが含まれているので、これを使用して、データベースをできる限り最新の状態に復元されるようにできます。

つまり、復元する必要があるデータを特定してから、復元できるデータを特定する必要があります。

復元できるデータを特定する

復元操作の目的は、復元するバックアップの量を抑えることによって、復元操作を可能な限り迅速に実行して、RTO 内に操作を完了し、RPO まで復旧することです。

ここで鍵となるのは "どのバックアップを使用できるのか" ということです。手元にあるバックアップが 1 週間前に作成したデータベースの完全バックアップのみで、データベース全体が破損している場合、復元のオプションは 1 つしかありません。それは、1 週間前の時点にデータベースを復元することです。この場合、障害発生以降のすべてのデータは失われます。簡単に言うと、バックアップ戦略では、いつ何時でも、障害が発生した場合に必要なデータを復元できるようにしておく必要があります。これについては、前回の記事で説明しました。

使用できるバックアップをどのようにして判断するのかというと、まず、msdb データベース内のさまざまなバックアップ履歴テーブルをクエリします。これらのテーブルには、バックアップ履歴テーブルのデータが最後に消去した時点以降に、SQL Server インスタンスで実行されたすべてのバックアップのレコードが含まれています。

バックアップ自体については、バックアップ ファイルの名前に、データベース、バックアップの種類、およびバックアップの実行日時を含めることで、バックアップをひとめで識別できるようにすることをお勧めします。これを行っていない場合は、RESTORE HEADERONLY コマンドを使用して、バックアップ ファイルに含まれているものを調べることができます。このコマンドを実行すると、バックアップ ファイルのヘッダーの内容 (バックアップ自体について説明しているメタデータ) が表示されます。詳細については、オンライン ブックの「バックアップ情報の表示」を参照してください。

いずれかの方法を使用して、使用する復元シーケンスを特定し、破損したデータや誤って削除したデータを復元します。復元シーケンスとは、復元する必要がある一連のバックアップと、それらを復元する際の適切な順序のことです。復元シーケンスは、(データベース、ファイル グループ、またはファイルの) 単一の完全バックアップのように単純な場合や、一連の複雑な完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップで構成されている場合があります。

たとえば、バックアップ戦略で、データベースの完全バックアップ、データベースの差分バックアップ、およびトランザクション ログのバックアップを使用するシナリオがあるとします。システムで障害が発生してデータ ファイルが破損した場合の復元シーケンスを考えてみましょう。図 1 にこの例を示します。

この場合、最も短くて迅速な復元シーケンスは、最新のデータベースの完全バックアップ (F)、最新のデータベースの差分バックアップ (D2) の順に復元して、その後に、すべての後続のトランザクション ログ バックアップとログ末尾のバックアップ (L7 および L8) を復元するというものです。

復元シーケンスを計画する場合に直面する難しい問題の 1 つは、データの復元に必要な最も古いトランザクション ログ バックアップを特定することです。これは、"最小 LSN (最小ログ シーケンス番号)" の特定とも呼ばれます。 図 1 の例では、トランザクション ログ バックアップの L7 と L8 のみが必要です。というのも、データベースの差分バックアップ D2 を使用すると、D2 以前のすべてのトランザクション ログ バックアップよりも最近の時点の状態にデータベースが復元されるためです。

図 1. 復元シーケンスの例

SQL Server では、以前の不要なトランザクション ログ バックアップを復元できますが、このようなバックアップは使用されないので、基本的に障害復旧の時間の浪費でしかありません。図 1 の例で、差分バックアップ D2 で障害が発生したり、これが削除されたりした場合を考えてみましょう。図 2 に、この状況を示します。

図 2. データベースの差分バックアップで破損が発生した場合の復元シーケンス

このシナリオでは、最も短くて迅速な復元シーケンスは、最新のデータベースの完全バックアップ (F)、次に最も新しいデータベースの差分バックアップ (D1) の順に復元し、その後に、それ以降のすべてのトランザクション ログ バックアップ (L4、L5、L6、L7、および L8) を復元するというものです。このシーケンスは、バックアップ D1、L4、L5、および L6 が使用できる状態であれば可能です。バックアップをすぐに削除すると、障害が発生した場合に問題が発生する可能性があるため、バックアップはすぐに削除しないようにすることが重要です。

たとえば、データベースの完全バックアップ F が破損した場合に、以前のデータベースの完全バックアップを使用できなければ、データベースを復旧することができません。データベースの差分バックアップ D2 の完了後すぐにデータベースの差分バックアップ D1 を削除すると、図 2 のシナリオは実現不可能となり、復元シーケンスには、データベースの完全バックアップ以降のすべてのトランザクション ログ バックアップが含まれることになります。この場合、復元シーケンスは非常に長くなる可能性があります。

"以前のバックアップはいつ削除するべきか" という疑問が生じますが、画一的な答えはなく、ケース バイ ケースになります。バックアップを一定期間保持する法的な義務がなければ、バックアップを保持する期間は皆さんの自由ですし、バックアップ戦略や必要なディスク領域にも左右されます。とにかく、新しいバックアップを作成後、すぐに以前のバックアップを削除しないようにしてください。また、古いバックアップを削除する場合は、少なくとも 1 ～ 2 つのバックアップの完全なサイクルを保持しておくことをお勧めします。古いバックアップを削除する前に、新しいバックアップをテストするのが理想的です。

トランザクション ログ バックアップに関しては、これが最終的な代替の復元シーケンスになるため、一般的に、最後にデータベースの完全バックアップを実行した時点以降の、すべてのトランザクション ログ バックアップを保持している必要があります。トランザクション ログ バックアップのチェーンに含まれる 1 つのトランザクション ログ バックアップが削除されたり破損したりした場合、復元操作では、そのギャップを超えて処理を続行することはできません。前回の記事で説明したように、バックアップの整合性を確認することは、データを適切に復元できるようにするうえで重要です。

復元できるデータを特定する方法に関する詳細については、オンライン ブックの包括的なトピック「SQL Server データベースの復元シーケンスの処理」を参照してください。

復元シナリオの例

最も一般的な復元シナリオでは、1 つのデータベースの完全バックアップと、1 つまたは複数のトランザクション ログ バックアップを使用して、データベースを完全バックアップより新しい状態に復元します。これは、SQL Server Management Studio (SSMS) または Transact-SQL を使用して実行できます。ただし、RESTORE ステートメントを直接使用する場合には注意事項があります。

バックアップを復元したら、復元操作は 3 とおりの方法で完了できます。これらはすべて、復旧の元に戻すフェーズに関係します。復元シーケンスに含まれる一連のバックアップが復元されたら、復旧の再実行フェーズが必ず実行されます。しかし、元に戻すフェーズは、トランザクション ログ バックアップのチェーンで最後のバックアップが復元されるまで実行されません。これは、復旧が完了した時点で、それ以上トランザクション ログ バックアップが適用されなくなるので、復元シーケンスのすべての復元で、復旧の元に戻すフェーズを実行しないように指定する必要があるからです。

残念ながら、既定では、復旧の元に戻すフェーズが実行されます。これは、RESTORE ステートメントで WITH RECOVERY オプションを使用するのと同じ効果があります。複数のバックアップを復元する場合には、各バックアップで WITH NORECOVERY オプションを指定する必要があることに注意してください。実際、復元シーケンスのすべての復元で WITH NORECOVERY オプションを使用し、後で手動で復旧を完了するのが最も安全な方法です。1 つのデータベースの完全バックアップと 2 つのトランザクション ログ バックアップを復元してから、手動で復旧を完了してデータベースをオンライン状態に戻す、Transact-SQL コードの例を次に示します。

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
WITH REPLACE, CHECKSUM, NORECOVERY;
GO

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
WITH NORECOVERY;
GO

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
WITH NORECOVERY;
GO

RESTORE DATABASE DBMaint2008 WITH RECOVERY;
GO

ここでは、データベースの完全バックアップの復元で CHECKSUM オプションを使用して、復元するデータベース内のすべてのページ チェックサムが復元されたことも確認しています。

最初の RESTORE ステートメントで WITH NORECOVERY オプションを指定しないと、次のエラーが返されます。

メッセージ 3117、レベル 16、状態 1、行 1
ロールフォワードできる状態のファイルがないので、ログまたは差分バックアップは復元できません。
メッセージ 3013、レベル 16、状態 1、行 1
RESTORE LOG が異常終了しています。

使用するオプションには注意する必要があります。適切なオプションを使用しないと、長時間にわたる復元シーケンスを最初からやり直さなければならないおそれがあります。また、復旧が完了した後に元に戻す方法もありません。

ただし、このような処理を行う WITH STANDBY という興味深いオプションがあります。これは、前述の 3 つのオプションの 3 つ目です。WITH STANDBY オプションは、復旧の元に戻すフェーズを実行することによって機能しますが、実行した処理が (名前とパスを指定できる "UNDO" ファイルに) 記録されるので、データベースに読み取り専用でアクセスできます。このデータベースのトランザクションには一貫性があり、復元シーケンスを継続することもできます。復元シーケンスを継続する場合は、(UNDO ファイルの内容を使用して) 元に戻す操作が無効になり、次のトランザクション ログ ファイルが復元されます。これは、ログ配布セカンダリ データベースへの読み取り専用アクセスの許可および復元シーケンスにおけるデータベースの内容の確認という 2 つのシナリオで役に立ちます。

復旧の原因となった障害で、たとえば、テーブルが誤って削除されている場合は、特定の時点への復元を実行することをお勧めします。特定の時点への復元を実行する状況にはいくつかありますが、最も一般的なのは、データベースを復元する必要がある場合に、復旧が特定の時間を超えて続行されないようにする場合です。この場合は、WITH STOPAT オプションを使用して、トランザクション ログの復元が、テーブルが削除された時点を超えて続行されないようにします。たとえば、上記の Transact-SQL コードの例を使用して、データベースが午前 1 時 45 分を超えて復元されないようにする必要がある場合は、2 つ目の RESTORE LOG ステートメントで次の構文を使用します。

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
WITH NORECOVERY, STOPAT = '2009-05-17 01:45:00.000';
GO

STOPAT オプションと STANDBY オプションを組み合わせて、適切な時点まで復元が行われたかどうかを確認することもできます。適切な時点でなかった場合は、数秒後の時間を指定するなどして、同一のトランザクション ログ バックアップを復元します。このような種類の操作は非常に面倒ですが、操作が行われた時刻がわからない場合には、これが唯一の解決策となる可能性があります。

これらのオプションと RESTORE ステートメントの他のオプションの包括的な説明については、オンライン ブックの「RESTORE の引数 (Transact-SQL)」を参照してください。

SQL Server 2005 Enterprise Edition で導入された最もすばらしい新機能の 1 つは、部分的なデータベースの可用性です。この機能を使用すると、複数のファイル グループで構成されたデータベースをオンライン状態にして、少なくともプライマリ ファイル グループがオンライン状態であれば、このデータベースを使用することができます。当然ながら、オフライン状態のファイル グループのデータにはアクセスできませんが、この機能を使用すると、大規模なデータベースを別個のファイル グループに分割して、簡単かつ迅速に復旧できます。Enterprise Edition 限定で追加されたもう 1 つの機能では、データベースの他の部分が処理で使用されている最中に、オンライン状態での部分復元 (たとえば、複数のファイル グループで構成されたデータベースに含まれる 1 つのファイル グループの復元) を実行できます。

この 2 つの機能を組み合わせることによって、非常に高度で効率的な復元シナリオを実現できます (ただし、データベースが復元シナリオに対応するように設計されていることと、適切なバックアップがあることが条件となります)。

SQL Server に関するテクニカル記事「Microsoft SQL Server 2005 データベースの部分可用性」(https://download.microsoft.com/download/b/d/2/bd2c89b5-ad72-49b2-9583-d72f807a8638/PartialDBAvailability.doc) では、詳細なすばらしい記事に加えて、いくつかの広範な例を参照できます。また、Kimberly L. Tripp が Tech-Ed EMEA のセッションで発表した「SQL Server 2005 の VLDB 可用性と復旧の戦略」 の映像記録 (所要時間 75 分) も視聴する価値があります。

別の場所に復元する際の考慮事項

最も単純な復元シナリオは、データベースが、通常アタッチされているのと同じ SQL Server インスタンス上に、同じ名前で復元する場合です。このシナリオから遠ざかるにつれて、復元操作は複雑になります。

データベースを同一のインスタンス上に別の名前で復元する場合は、要素 (DTS/SSIS パッケージ、データベース メンテナンス プラン、アプリケーションの文字列など、データベース名に依存するすべての要素) に変更を加えなければならない可能性があります。

データベースを同じサーバー上の異なるインスタンスに復元する場合は、状況は次のようにさらに複雑になります。

  • SQL Server ログインが異なるか、存在しない場合があります。
  • SQL エージェント ジョブおよび DTS/SSIS パッケージが異なるか、存在しない場合があります。
  • マスター データベースが異なるため、ユーザー定義のストアド プロシージャが見つからない場合があります。
  • SQL Server インスタンスの名前が異なるため、クライアントで接続の問題が発生する場合があります。
  • データベースを異なるサーバー上のインスタンスに復元する場合は、上記の内容がすべて該当します。また、Windows アカウントが異なっていたり、別の Windows ドメインに復元されたりするなど、セキュリティ上の問題が発生する可能性もあります。
  • もう 1 つの考慮事項は、データベースを復元する SQL Server のエディションです。機能の中には、データベースで使用した場合に、そのデータベースが Enterprise Edition 限定になってしまうものがあります。このようなデータベースは、Standard Edition (またはそれ以下) の SQL Server インスタンス上には復元できません。
  • SQL Server 2000 以前では問題ありませんでしたが、SQL Server 2005 では、テーブルやインデックスのパーティション分割を使用すると、データベースが Enterprise Edition 限定になります。SQL Server 2008 では、次の機能が提供されています。
  • Change Data Capture
  • 透過的なデータ暗号化
  • データ圧縮
  • パーティション分割

これらの機能はすべて、sysadmin 特権を使用して有効にする必要があります (ただし、テーブルの所有者が有効にできるデータ圧縮は除きます)。そのため、Standard Edition インスタンスへの復元を含む障害復旧計画が機能しなくなる可能性があります。DMV の sys.dm_db_persisted_sku_features を使用すると、これらの機能がデータベース内で使用されているかどうかを特定し、それに応じて障害復旧計画を調整できます。

復元について掘り下げる

バックアップに関する前回の記事と同じように、復元操作にも多くの側面があるので、この記事では、すべてについて説明することができませんでした。ただし、基本的なことについては説明したので、オンライン ブックやブログを参照して、詳細な情報を入手することができます。オンライン ブックでは、最初に「復元と復旧の概要 (SQL Server)」を参照することをお勧めします。また、私のブログ (英語) では、バックアップと復元に関するカテゴリの投稿から読み始めると、多くの情報を入手できます。

この記事から習得していただきたい重要なことは、バックアップを使用して適切にデータベースを復旧するには、復旧時に実行する必要がある操作を把握するために実践する必要があるということです。大きなプレッシャーを感じる障害復旧の最中に、RESTORE ステートメントの構文について学習したいとは思わないでしょう。また、計画したバックアップ戦略では、ビジネス要件を満たしたデータを状態で復旧することができない場合もあります。バックアップに時間がかかりすぎて復元できなかったり、ログ バックアップが誤って互いに上書きされたり、SQL Server 2008 の透過的なデータ暗号化を有効にするのに使用するサーバー証明書のバックアップを実行し忘れたりするかもしれません。

障害に備えるための最適な方法は、実行する手順を記載した復元計画を作成して、利用できるバックアップとバックアップを復元する際の順序を特定するのに役立つ一連のスクリプトを準備しておくことです。私は常に、チーム内で最も経験のある DBA が復元計画を作成し、最も経験の浅い DBA がこれをテストして、すべてのメンバーが手順を安全に実行できるようにすることをお勧めしています。ただし、そのような選択の余地がない DBA は、自分で計画を立てて、その計画を実行できるようにしておく必要があります。

次回の記事では、利用できるバックアップがない場合にデータベースの破損から復旧する方法と、バックアップがない場合でも修復処理を実行することをお勧めする理由について説明します。
それまでは、いつものように、ご意見やご質問は Paul@SQLskills.com (英語のみ) までお寄せください。

この記事の技術校閲者を務めてくれた Kimberly L. Tripp に感謝します。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあり、Microsoft Regional Director でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Randal は障害復旧、高可用性、およびデータベース メンテナンスの専門家であり、世界中のカンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul (英語) で、Twitter (英語) は @PaulRandal という ID で公開されています。