web-dev-qa-db-ja.com

遅いAlways Onコミットの診断

2ノードのAlways On可用性グループ、1つの同期レプリカ。

同期レプリカが非常に定期的に同期しなくなります。セカンダリレプリカでログバックアップが発生すると、次のようにredo_queue_sizeがすぐにいっぱいになる短いラグが発生するパターンが表示されます。

enter image description here

[1]: https://i.sta

次のリンクのガイダンスを見ると、私の問題は、トランザクションを強化しようとしたときにREDOスレッドが経験する競合が主な原因であると思われます。

https://technet.Microsoft.com/en-us/library/dn135335（v = sql.110）.aspx

トランザクションログのバックアップが実行されると、レプリカはさらに同期しなくなり、この問題は、セカンダリレプリカで実行されるレポートによっても悪化します。

その間、トランザクションログのバックアップは巨大です-平均1.2GBですが、それより大きくなることもあります。

私の知る限り、データベースでTDEを有効にしているため、ログのバックアップは大きくなりますが、実際にはこれほど大きくなるとは思っていませんでした。これが、セカンダリレプリカでの遅いコミットに最も貢献しているものだと思います。

同期レプリカの遅いコミットを診断するために推奨されるパフォーマンスカウンターはありますか？理論を検証するために他に何ができますか？

私の問題はここで説明されているものと同じようです： https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

セカンダリレプリカでこのトレースフラグを有効にするだけですか、それとも両方のノードに適用する必要がありますか？

編集：私は午前6時にREDOキューを確認しましたが、回復時間が15〜20分で、常に少しずつ増加している膨大な数を見つけました。次に、DBCC TRACEON (3459, -1)を使用してトレースフラグを適用し、数分後にREDOコマンドの数が非常に急速に減少することを発見しました。これまでのところ、問題はこのトレースフラグによって軽減されたようですが、おそらくこれにより、SQL Server 2014のように、すべてのトランザクションがセカンダリレプリカのログに強化され、シングルスレッドモードになるため、セカンダリレプリカが遅れる可能性があります。非並列スレッド化の結果として、プライマリの書き込み負荷が高い場合。

performanceavailability-groupssql-server-2016windows-server
5
Peter

私が経験していた問題：

  1. 同期セカンダリレプリカが半永久的に遅れる
  2. 巨大なログのバックアップ

これらは、トレースフラグ3459を有効にすることで解決されました。私の場合、フラグがparallel_redo_flow_control dirty_page_table_lock parallel_drain_redo_workerの待機タイプを即座に修正し、REDOキューのサイズが急速に減少したことを確認するのは非常に簡単でした。

バグレポートで、マイクロソフトがこれを「アサーション」と呼ぶのはなぜでしょうか。 https://support.Microsoft.com/en-us/help/3200975/fix-assertion-occurs-when-you-use-二次複製の並列やり直し

SQLServerCentral.comからJason AKA CirqueDeSQLeilへのクレジット https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

3
Peter