web-dev-qa-db-ja.com

ログ配布は「非同期」ですが、失敗しているジョブはありません

サーバーから同じサーバーに、インスタンスが異なるだけのログ配布を構成しました。

Primary serverは次のように構成されています。

LSBACKUP_MyDatabase-25分ごと

Secondary server：

LSCOPY_MyDatabase-1分ごと

LSRESTORE_MyDatabase-10分ごと

何が起こっているのですか？プライマリバックアップジョブは正常に実行されています（もっと多くの履歴があり、最後の2つを表示しています）。

enter image description here

フォルダーには、TRNファイルが表示されます。

enter image description here

セカンダリインスタンスでは、LSCOPYとLSRESTOREも問題ありません。ファイルをコピーしていますが、問題はここにあります。復元ジョブがこの「メッセージ」を報告しています（ジョブは正常に実行されるため、エラーではないと思います）。

メッセージ

2015-12-29 09：10：02.41スキップされたログバックアップファイル。セカンダリDB： 'MyDatabase'、ファイル： '\ ServerIP\instancia g\BACKUP\Log_Sp_Secundario\MyDatabase_20151229104500.trn'

2015-12-29 09：10：02.41セカンダリデータベース 'MyDatabase'に適用できるログバックアップファイルが見つかりませんでした

2015-12-29 09：10：02.42復元操作は成功しました。セカンダリデータベース： 'MyDatabase'、復元されたログバックアップファイルの数：0

2015-12-29 09：10：02.42古いログバックアップファイルを削除しています。プライマリデータベース： 'MyDatabase'

2015-12-29 09：10：02.42復元操作は成功しました。セカンダリID： '5a0a361c-039c-40a3-9c39-af5e338c7f72'

次に、LSALERT_ジョブの履歴をクリックして表示すると、次のメッセージでエラーが報告されます。

enter image description here

ユーザーとして実行されたメッセージ：CMDO\gdladmin。ログ配布セカンダリデータベースVMWGDLPRD04\GDLIC2014.GDL_ICの復元しきい値は45分で、同期されていません。 8323分間、復元は実行されませんでした。復元された待ち時間は0分です。エージェントログとログ配布モニター情報を確認します。 [SQLSTATE 42000]（エラー14421）。ステップは失敗しました。

マイクロソフトのサポートページの1つによると、ログ間にギャップがあるかどうかを示すこのクエリがあります。何もありません：

SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = 'MyDatabase')
ORDER BY 
    s.backup_finish_date DESC;

私はインターネット全体を検索してきましたが、情報が不足しているこれらのdbaブログと、プライマリデータベースが削除された（明らかにそうではなかった）と言う投稿しか見つかりませんでした。

プライマリインスタンスは2012です。セカンダリは2014です。セカンダリデータベースはリカバリモードです。

これを修正するには、すべてのログ配布を再作成する必要がありますか？

sql-serverlog-shipping
5
Racer SQL

まあそれは修正されませんでした。再びログ配布を再現すると思います

の前に、それを試してみて、最新の差分バックアップを探してセカンダリに復元してみませんか。

上記のような状況もあり、次のことがわかりました。

これは、共有されたフォルダー（プライマリとセカンダリの共通バックアップの場所）が共有されなくなった（クラスターリソースの問題のため）NWグリッチが原因で発生し、その結果、ログバックアップがセカンダリにコピーされなかった復元ジョブは完了しましたが、LSは同期が取れていないと言い続けましたが、ギャップがありました。

さて、今回のケースでは、最新の完全バックアップを復元して、不足しているLSNチェーンを同期させ、その後、復元ジョブが次のログバックアップファイルを選択し、LSが同期されました。

5
KASQLDBA

私はLSAlertの仕事を一粒の塩でとっています。その問題をトラブルシューティングすると、髪が抜けてしまいました！最終的に、ログのバックアップ、コピー、および復元ジョブは期待どおりに機能していました。

モニターサーバーでLSAlertエラーメッセージが表示される場合は、次の点を考慮してください。

  • 監視サーバーの日時は、プライマリサーバーの日時と異なる場合があります。また、システムの日付または時刻がモニターまたはプライマリサーバーで変更された可能性もあります。
  • 監視サーバーがオフラインでオンラインに戻った場合、log_shipping_primariesテーブルのフィールドは、アラートメッセージジョブが実行される前に現在の値で更新されません。
  • プライマリサーバーで実行されるログ配布コピージョブは、監視サーバーのmsdbデータベースに接続して、log_shipping_primariesテーブルのフィールドを更新しない場合があります。これは、監視サーバーとプライマリサーバー間の認証の問題の結果である可能性があります。
  • セカンダリサーバーで実行されているログ配布の復元ジョブは、監視サーバーのmsdbデータベースに接続して、正しい値でlog_shipping_secondariesテーブルを更新できません。これは、セカンダリサーバーと監視サーバー間の認証の問題の結果である可能性があります。
  • バックアップアラートのしきい値に小さい値または誤った値を設定した可能性があります。理想的には、この値を、SLAしきい値とバックアップジョブの頻度に基づいて設定する必要があります。
  • プライマリサーバーのバックアップジョブが失敗している可能性があります。その場合、バックアップジョブの履歴とプライマリサーバーのSQLエラーログのエラーメッセージを確認する必要があります。

意図したとおりに復元が行われていることを確認する方法はいくつかあります。次のクエリは、ログの復元プロセスでギャップを見つけるのに役立ちます。

 SELECT 
    s.database_name,s.backup_finish_date,y.physical_device_name
FROM 
    msdb..backupset AS s INNER JOIN
    msdb..backupfile AS f ON f.backup_set_id = s.backup_set_id INNER JOIN
    msdb..backupmediaset AS m ON s.media_set_id = m.media_set_id INNER JOIN
    msdb..backupmediafamily AS y ON m.media_set_id = y.media_set_id
WHERE 
    (s.database_name = ‘databaseNamePrimaryServer’)
ORDER BY 
    s.backup_finish_date DESC;

完全な開示、私はこの「プラグ」から何も得ていません、そして私はRed Gateで働いていません、それはログ配布を監視する無料のリアルタイム監視ツールです。

Red Gateログ配布モニター

Microsoft TechNet記事

1
Sean Perkins

次の表をチェックしてみてください-そこに置くべきではないレコードがあるかどうかを確認してください。

log_shipping_primary_databases log_shipping_secondary log_shipping_monitor_primary log_shipping_monitor_secondary

削除した場合、それらを削除するとアラートがクリアされます。

0
Some Guy

トラブルシューティングのヒントを投稿していただきありがとうございます。私も同じ問題に直面しましたが、トラブルシューティングでは良い記事や関連するヘルプが得られませんでした。

この投稿には同様の問題があり、ほぼすべてが一致しましたが、まだ解決できません。以下の表の値を確認し、この問題を修正するために更新して解決しました。

プライマリサーバー

log_shipping_primary_databases log_shipping_monitor_primary

セカンダリサーバー

log_shipping_secondary log_shipping_monitor_secondary

Log_shipping_monitor_secondaryテーブルを確認すると、「last_restored_file」列と「last_restored_latency」列の値がnullであることがわかりました。これは、どのジョブが成功したかによってSQLが正確なファイルを選択できなかったため、「last_restored_file」を最後に復元されたものに更新しましたセカンダリサーバーからのログファイルパス。

この問題を修正するために、「last_restored_latency」（私の場合）を更新する必要がある場合もあります。このフィールドを更新するときは、最後のバックアップが完了してからの正確な分数を入力してください。

お役に立てれば ：）

よろしく、Bipin Singh、SQL Server DBA

0
Bipin Singh