次の方法で共有

  • [アーティクル]

バックアップの破損による SQL Server 復元エラーの対応

バックアップ メディアが破損している場合、復元エラーが発生します。復元エラーは、オペレーティング システムにより通知されるか、チェックサムにより検出される可能性があります。いずれの場合でも、対応方法には次の 3 つがあります。

  • エラーを解決し、復元操作を再開する。

  • エラーにかかわらず復元を続行し、復元操作の完了後にデータベースを修復する。

  • 復元操作を中止し、破損したバックアップを使用しない別の復旧プランを使用する。

注意注

メディア セットやバックアップ セットには、Microsoft Tape Format として解釈されるために最低限必要な適切な情報が含まれている必要があります。この情報がない場合、復元操作は停止し、バックアップの形式が無効であることを通知します。

エラーの解決後に復元操作を再開

エラーは次の方法で解決する場合があります。

  • テープ デバイスでエラーが発生している場合は、テープ ドライブを清掃するか、交換します。

  • ディスク デバイスの場合は、デバイス エラーを解決するか、破損しているファイルを置換します。

  • メディア セットがミラー化されている場合は、破損したメディアを別のミラー上の該当するメディアに置き換えます。

エラーを無視して続行

注記注意

RESTORE ステートメントで WITH CONTINUE_AFTER_ERROR を指定すると、データベースの復元が試行されます。ただし、データベースの復旧を妨げるさまざまな種類の破損があります。他の代替策がなくなるまでは、CONTINUE_AFTER_ERROR オプションを使用しないことを強くお勧めします。

CONTINUE_AFTER_ERROR オプションを指定すると、エラーの発生後も復元操作が続行され、復元可能なデータが復元されます。また、ロールフォワードが発生するため、後続のトランザクション ログ バックアップを適用できます。ロールフォワード中にエラーが発生し、目的の時点まで復旧できなかった場合は、このエラーがログに記録されます。復旧ポイントに達すると、可能な場合はデータベースがオンラインになります。復旧を完了できない場合、データベースはオフラインのままです。

どの程度のデータが失われるかは、発生したエラーにより異なります。たとえば、あるページのチェックサムが正しくなく、そのページのみが問題であった場合、メディアの読み取りと処理は続行されます。逆に、テープ デバイスから I/O エラーが報告された場合は、復元操作はエラー後に読み取りを続行できず、テープの残りのデータが復元できない可能性があります。

エラー発生後も復元を続行するように指定している場合、検証に失敗したページは、ディスクに書き込まれ、suspect_pages テーブルとエラー ログに記録されます。

ベスト プラクティス :  WITH CONTINUE_AFTER_ERROR を使用してデータを復元した後、エラー ログでエラーの詳細を確認します。また、RESTORE ステートメントから直接取得したすべてのメッセージを保存して分析します。

エラーを無視して続行するには

RESTORE の基本構文は次のとおりです。

RESTORE DATABASE database_name FROM backup_device WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]

オフライン データベースの管理

エラーを無視して続行された復元シーケンスが完了した時点で、DBCC CHECKDB を使用してデータベースを修復できる場合があります。RESTORE CONTINUE_AFTER_ERROR を使用した後で CHECKDB を最も効率的に実行するには、DBCC CHECKDB コマンドで WITH TABLOCK オプションを使用することをお勧めします。詳細については、「DBCC CHECKDB (Transact-SQL)」を参照してください。すべての修復オプションを使用できます。必要最低限の修復レベルを特定するには、修復オプションを指定せずに DBCC CHECKDB を実行します。破損が激しい場合は、データベースを修復できるだけの情報が存在しない場合があります。

現状のデータに制限付きでアクセスするには、ALTER DATABASE コマンドの EMERGENCY オプションを使用して、データベースのモードを緊急モードにします。