いつログ配布の復元ジョブがスタンバイモードで完了にマークされますか
ログ配布復元ジョブの背後にあるロジックをまだ取得できないため、以前の質問をより正確に編集しています。
説明できないことがありますが、最善を尽くします。
セカンダリで10:00に実行される夜間ログ配布復元ジョブがありますPM毎日1回。復元が開始されると、前回の実行で完了した場所からログバックアップが選択されます。ログがどのように理解されるか復元は Kinsリンク ごとに行われますが、LS復元は現在の実行時間にできるだけ近づこうとして完了しますが、その時間は30分、20時間、または1時間のギャップで変わることがあります。
Ls restoreがこれをチェックする方法はまだ明確ではありませんが、完了するのに最適な時期です。これは、LSジョブを介してデータが復元される時刻をユーザーに通知することにより、スタンバイデータベースからデータを照会およびフェッチできるようにします。
重複としてマークされた前の質問@ ログ配布の復元の仕組み
例：LSの復元は午前3時30分に完了します。復元されたログバックアップの場合、午前2時45分に到着したファイルは復元されましたが、午前3時と3時15分には復元されませんでした。したがって、これら2つのファイルがコピーされるかどうかを考えただけで、LS復元がそれらを無視して完了した理由は何ですか。 LSのバックアップとLSのコピーは15分ごとに行われますが、10時に1回復元します。
組み込みのストアドプロシージャを利用して調査し、うまくいけばこれを修正してみます。
たとえば、マスターデータベースでセカンダリサーバー上でこれを実行してみます。
EXEC sp_help_log_shipping_secondary_database @secondary_database = '<database name>'
これにより、関心のある「restore_all」という名前の列を含む結果セットが返されます。それが0の場合、リストアジョブが実行されると、1つのトランザクションログファイルのみをリストアした後に停止します。それ以外の場合は、できるだけ多く適用されます。
状況に応じて正しく構成されていない場合は、次のように変更できます。
EXEC sp_change_log_shipping_secondary_database @secondary_database = '<database name>', @restore_all = 1
うまくいけば、これが問題の修正に役立つか、少なくとも根本的な原因の検索を後押しするのに役立ちます。