データ損失のシナリオを引き起こす可能性のある問題は数多くあります。データ損失後にDB管理者 が最初に行う必要があるのは、注意深く確実に、とり扱うことです。
データを確実に回復できるように、または悪意のある変更を元に戻すために、インシデントの直後に次の手順を実行することを強くお勧めします。
- データベースをデタッチします
- データベースのMDFファイルとLDFファイルのコピーを作成します。
- MDF および LDF のコピーを別のサーバーに移動し、アタッチします。
- 既存のデータベースまたはトランザクション ログのバックアップを他のサーバーにコピーします。
インシデント後の予防策が講じられた後、最高の回復率を確保するために、最も適切な回復シナリオを選択する必要があります。
以下は、ユーザーがそれぞれの回復シナリオに最適なアプローチを選択できるようにすることを目的としたフローチャートです。
特定のシナリオにおける追加補足事項
- ライブデータベースへの接続は利用できないが、データベースの完全バックアップは存在する場合
この場合、最大限の結果を得るには、データベース バックアップからの抽出機能を使用する必要があります。このオプションを使用すると、ユーザーはデータベースの完全なバックアップを別の場所に復元し、そこから抽出する必要がなく、特定のテーブルのデータや構造のみを抽出できるため、時間とスペースの両方を節約できます。回復されたデータは、新しいデータベースに追加することも、回復プロセスを容易にするために SQL スクリプトの形で追加することもできます。 - データベースが完全復旧モデルではない場合の DELETE または DROP 操作からの復旧
ApexSQL Recover のすべての機能は、データベースが完全復旧モデルにある場合にのみ使用できます。単純な復旧モデルでは、ディスク領域の消費を最小限に抑えるために SQL Server が ldf 内の情報を上書きするため、トランザクション ログ エントリが存在せず、ApexSQL Recover が必要とする情報が利用可能であることが保証されません。
これにより、情報ソースとして MDF ファイル内のデータのみが残りますが、このデータも SQL Server によって定期的に上書きされるため、信頼性が低く、すでに失われている可能性があります。これらすべてを念頭に置くと、単純な復旧モデルでデータベースを操作する場合、復旧範囲は制限されます。留意すべき点の 1 つは、復旧の必要性が認識されたら、すぐにデータベースをオフライン モードに切り替えて試行することが重要であるということです。また、ldf と mdf の両方のリカバリ ソース情報を可能な限り完全な状態に保ちます。 - トランザクションログが切り捨てられ、利用可能なバックアップがない場合の DROP または DELETE 操作からの回復
DELETE または DROP テーブル操作からのリカバリが実行される場合、ApexSQL Recover はトランザクション ログ ファイル (オンライン、バックアップ、またはデタッチ) のデータを使用してリカバリを実行します。トランザクション ログ ファイルが利用できない場合でも、ApexSQL Recover はこのデータがデータベース MDF ファイルにまだ存在するかどうかをチェックするため、リカバリを実行できます。これは、SQL Server がデータを論理的に削除し、実際にはデータが削除済みとして即座にマークされるためです。データは最初の適切な機会に MDF ファイルに上書きされます。これは数時間後、場合によっては数日後になる場合もあります。この事実により、適切な回復の可能性を確保するために、冒頭で説明した事故後の行動が非常に重要かつ不可欠になります。 - データベースが単純復旧モデルにある場合のUPDATE 、INSERT、ALTER、CREATE、または DROP オブジェクト操作からの復旧
ApexSQL Recover (および ApexSQL ログも) で特定のデータベースのすべてのトランザクションを表示/回復するには、データベースの回復モデルを「フル」に設定する必要があります。リカバリ モデルが simple に設定されている場合、トランザクション ログ ファイルには限られた量のデータしか含まれず、監査/リカバリに使用できるのは最新の操作のごく一部のみです。 - トランザクションログ ファイルの不完全なチェーンの監査または回復
オンライン トランザクション ログ ファイルが切り捨てられた場合、あらゆる結果を期待できるようにするには、トランザクション ログ バックアップの完全なチェーンを提供することが不可欠です。これにより、ApexSQL Recover (および ApexSQL ログも) で履歴データを作成できます。リカバリし、行の履歴を追跡します。各 UPDATE には先行するステートメントとして少なくとも INSERT ステートメントがあり、データ履歴は異なる可能性があるため、これは UPDATE 操作をリカバリする場合に特に重要です。トランザクション ログ バックアップの完全なチェーンが利用できない場合、UPDATE 操作で完全な詳細が欠落し、監査/回復の結果が不完全になる可能性があります。さらに、トランザクション ログ チェーンが壊れた場合、ツールは完全な履歴を作成するために追加の処理を実行する必要があるため、回復プロセスのパフォーマンスが低下します。