私には簡単に理解できない状況があり、このフォーラムで他の人に提案があるかどうか尋ねたいと思いました。
Windows Server 2008R2 EnterpriseでSQL Server 2008 R2 Standard SP3を実行しています。
データベースにはいくつかのメンテナンスが必要でしたが、その後、別のサーバーに復元する必要がありました。 COPY_ONLYで実行される完全なdbバックアップと、4つのtlogバックアップのセットがあります。
FULL
からBULK_LOGGED
復旧モデルに変更BULK_LOGGED
からFULL
復旧モデルに変更復元サーバーでのドライブ文字の変更により、すべてのバックアップの復元にはWITH MOVEを使用する必要があります。
回復手順:
RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'
WITH
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1
RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'
WITH
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1
RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'
WITH
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1
最終的なtlogの復元は100%に達し、エラー3456で失敗します。
ファイル1のデータベース「SomeDB」、ファイル「SystemData」の368ページを処理しました.
ファイル1のデータベース「SomeDB」、ファイル「SystemDataPDS」の7656520ページを処理しました.
ファイル1のデータベース「SomeDB」、ファイル「SystemData_log」の172430ページを処理しました.
メッセージ3456、レベル16、状態1、行1
トランザクションレコード(0:1016710921)、ページ(4:8088)、データベース 'SomeDB'(データベースID 6)のログレコード(210388:123648:232)をやり直すことができませんでした。ページ:LSN =(0:0:1)、タイプ=11。ログ:OpCode = 4、コンテキスト11、PrevPageLSN:(210388:122007:1)。データベースのバックアップから復元するか、データベースを修復します。メッセージ3013、レベル16、状態1、行1 RESTORE LOGが異常終了しています。
完全なdbバックアップが問題ないことを確認するためだけに、CHECKDB
を実行して復元したところ、エラーは発生しませんでした。
すべてのフィードバックを歓迎します。
前もって感謝します、
ネッドカワウソ
エラー3456がスローされる理由を理解するには、少し前に戻り、SQL Serverが回復のこのコーナーをどのように処理するかを理解する必要があります。
SQL Serverが操作をやり直していて、そのやり直しがページの変更である場合、SQL Serverはすばやくチェックします。ページヘッダーには最終的にPageLSN
があり、これはそのページを変更した最後のLSNを示し、ページによって記録されます。このように考えると、ページは変更を加えた最後のLSNを追跡し続けます。これはPageLSN
です。
ログに記録されたページ変更操作があるたびに、そのログレコードにはいくつかのLSNが含まれます。つまり、ログレコードのLSN(...Current LSN)であり、それからと呼ばれるものがあります。ページLSN(PrevPageLSN
今後)。したがって、ページを変更すると、ログレコードに書き込まれるデータの1つは、ページを変更する前の最後のLSNとしてページが示すものです。
このように考えてみてください...あなたの車はそれに取り組んでいる必要があります。メカニックジョンはあなたの車で作業します。エンジンベイには小さなタグがあり、メカニックジョンは「ジョンがこの車で最後に作業した」と書きます。次に、車を別の店に持ち込むと、メカニックマークはエンジンベイを調べ、メカニックジョンが最後にこの車で作業したことを確認します。彼はデータシートにこの情報を書いています。 SQL Serverについても同様です。
これはやや混乱を招く可能性があるため、ページの順次変更に関する以下の画像と、PageLSN
とPrevPageLSN
の関係をご覧ください。
ページの操作(復元、回復、HAなど)をredoする必要があるときに、これらすべてが機能するので、ループバックしてみましょう。 SQL Serverがページ操作をやり直す必要がある場合、ページのPageLSN
がログレコードに含まれるPrevPageLSN
と一致するかどうかを確認するために、健全性チェックを行います。等しくない場合は、エラー3456がスローされます。
次の方法を含むエラーメッセージを分析しましょう。
トランザクションID(0:1016710921)のログレコード(210388:123648:232)、ページ(4:8088)、データベース 'SomeDB'(データベースID 6)をやり直すことができませんでした。 ページ:LSN =(0:0:1)、タイプ=11。ログ:OpCode = 4、コンテキスト11 PrevPageLSN:(210388:122007:1)。データベースのバックアップから復元するか、データベースを修復します。メッセージ3013、レベル16、状態1、行1 RESTORE LOGが異常終了しています。
エラーの原因となる不等式がある2つのデータを太字にしています。 PageLSN
は0:0:1(これはページのヘッダーにあります)であり、PrevPageLSN
is210388:122007:1(これは、やり直そうとしていたログレコードのデータで見つかりました)。これらは明らかに等しくないため、err3456です。
したがって、このイベントのwhyを見つけるには、ここに格差がある理由を見つける必要があります。 4:8088ページのライフサイクルを実際に追跡し、切断の場所を確認する必要があります。残念ながら、これ以上の情報や実践的なトラブルシューティングがなければ、この回復操作の背景とエラーの原因を説明する以外にできることはあまりありません。