ApexSQL Recoverは、誤操作によって削除されてしまったデータを、バックアップが無くても、復旧する最後の手段です。
すべての DB管理者 は、失われたデータを回復するという課題に一度は直面したことがあるでしょう。
DELETE 、TRUNCATE TABLE 、DROP TABLES 、データベースの破損など、データが失われる可能性のあるさまざまな方法があります。
もちろん、これらのトラブルが発生したときに、バックアップやデータベースのスナップショットなど、大惨事から回復するさまざまなテクニックがあることは誰もが知っています。
しかし、マーフィーのルールがあり、何も計画通りにいかない場合もあります。
さらに不幸なことに、バックアップがとれていなかった、ということがあるかもしれません。ジョブが失敗したのに気付かなかったのかもしれません。最初からバックアップ計画に追加されていなかった新しいデータベースかもしれません。
このようなピンチになってもパニックにならないでください
ApexSQL Recoverを使用すると、データベースの完全バックアップまたは差分バックアップがなく、トランザクション ログ バックアップもない場合でも、可能な限りSQL データベース レコードを回復できます。
ApexSQL Recover の仕組みを理解するために、テーブルデータが削除されたときに何が起こるかを説明します。
テーブル データはデータ ページに保存されます。テーブル レコードを削除すると、そのレコードはデータ ページからすぐには削除されませんが、新しいレコードによって上書きされるようにマークされます。このようなレコードは表示されなくなりますが、ApexSQL Recover はそれらのレコードを読み取り、元に戻すスクリプトを作成できます。
ApexSQL Recover は次の機能を提供します。
- DELETE 操作からのデータ回復
削除操作はトランザクション ログに完全に記録されますが、データ ファイルからすぐに削除されるとは限りません。したがって、ApexSQL Recover は、ログを読み取るか、データページから抽出するかの両方によってこのデータをサルベージします - TRUNCATE 操作からのデータ回復
SQL Server で TRUNCATE TABLE ステートメントが実行されると、データを含むページはすぐに割り当てが解除されます。これは基本的に、再利用のマークが付けられていることを意味します。SQL Server は、TRUNCATE TABLE ステートメントをオンライン トランザクション ログに完全に記録しますが、ページ割り当てのみを記録することで効率的に記録するため、TRUNCATE TABLE が発生した後にトランザクション ログを使用してデータを抽出することが困難になります。このため、ApexSQL Recoverがこのデータを回復するために使用する主な手法は、データファイル内の割り当て解除されたページを見つけて、データがまだ利用可能かどうかを確認することです。 - DROP TABLE 操作からのデータ回復
ApexSQL Recover は、削除されたテーブルのスキーマとデータの両方を回復できます。このオプションを選択すると、ApexSQL Recover は構造のみ、データのみ、またはその両方をリカバリすることを提案します。truncate 操作と同様に、drop table 操作も効率的にログに記録されます。テーブル構造はトランザクション ログから取得できますが、データはデータ ファイルから回復する必要があります。 - 削除されたBLOBの抽出
バイナリ ラージ オブジェクト (BLOB) は、通常のデータと同じ方法で SQL Server に保存されません。オブジェクトのサイズにより、この種類のデータは必然的に複数のページを保存する必要があるためです。これは、行オーバーフロー データ (varbinary、nvarchar、sqvariant、varchar 型) または LOB データ (text、ntext、または image 型) のいずれかとして使用できます。このようなオブジェクトが失われた場合、トランザクション ログでは見つからないため、ApexSQL Recover はこのタイプのデータをデータ ファイルから抽出します
このように、ApexSQL Recover では、回復時間を短縮するために、データの損失方法に応じてさまざまなオプションが提供されます。
データがどのように失われたかわからない場合、または選択したオプションがうまくいかない場合は、すべてのオプションを試してみてください。これらのオプションはデータの回復に異なる方法を使用するため、オプションが異なると成功率が低かったり高かったりする可能性があります。リカバリを最大限に成功させるには、できるだけ多くの追加のデータ ソースを提供する必要があります。
回復の成功率は、次のようなさまざまな要因によって異なります。
- データベースの復旧モデル
- データが失われたとき
- インシデント発生後どれくらい早く回復を試みるか
- 以前のバックアップ、ログ バックアップ、切り離されたデータ ファイルなど、利用可能な追加のデータ ソース
このページにたどりついた、ピンチのDB管理者がすぐにやらないといけないこと
データ損失が発生した場合、データ損失に関する情報は通常、データベース データ ファイル (MDF) とトランザクション ログ ファイル (LDF)内に含まれています。
時間が経つにつれて、レコードが上書きされる可能性が高くなります。削除後にトランザクションが発生すると、レコードが上書きされ、永久に失われる可能性が高くなります。
したがって、データ消失が検出された後、できるだけ早くMDFファイルとLDFファイルを保護することが最も重要です。
- データが失われた直後の状態で、データベースをオフラインにするか、読み取り専用状態に設定します。
これにより、MDF ファイルの上書きが防止され、MDF および LDF ファイルをコピーできるようになります。 - データベースの MDF ファイルと LDF ファイルをコピーします。
- 作業用の別のSQLサーバにそれらを新しいデータベースとしてアタッチします
- ApexSQL Recoverの評価版を入手して実行し、データ復旧が可能か判断します。
データ消失した後のデータベースを完全バックアップしても、役に立たないことに注意してください。
削除された（上書き対象としてマークされた）レコードはバックアップに含まれないためです。
また、古いバックアップを無理にリストアしてみることは絶対に避けるべきです。
データベースのバックアップをリストアすると、リカバリの再構築に使用される MDF および LDF ファイルの情報が上書きされるため、その古いバックアップの後に発生したすべてのデータと構造の変更の復元ができなくなります。