AlwaysOn可用性グループlog_send_rate

仮想マシンでWindows 2012およびSQL Server 2012を実行しているすべてのAlwaysOnセットアップとベアメタルで、log_send_rate sys.dm_hadr_database_replica_statesが一貫して誤った値を返していることがわかりました 。

例（同期モードの場合）

sys.dm_hadr_database_replica_states.log_send_rate（ave = 36,571（kb / sはbolで表示））

Perfmon-SQLServer：可用性レプリカ-レプリカに送信されたバイト数/秒（最大= 486,000.000、平均= 259,000.000）

Perfmon-SQLServer：Databases-ログフラッシュされたバイト数/秒（最大= 653,044.000、平均= 341,000.000）

これに関する投稿を見たことがありませんが、正しく機能していないようです。正しいlog_send_rate値は、AlwaysOnの監視に役立ちます。

他の誰かがこれを経験しましたか？

はい、これはService Pack 2の累積的な更新プログラム3で最近修正されました。KB記事は次のとおりです。http：//support.microsoft.com/kb/3012182

「FIX：sys.dm_hadr_database_replica_statesのLog_Send_Rate列は、SQL Server 2012のレートを正確に反映できません」

理由log_send_rate（とredo_rate）は、我々は思考の時間タイプの中断のないポイントを介したデータ転送に使用されている場合は特に、理解し、「相関」には少しトリッキーですが、これら2つのレートは、アクティブな時間の間に計算されていることを常にではありません。

つまり、log_send_rate送信されるログブロックがある場合、は調整されますが、静かでプライマリレプリカがログの送信を待機している場合、はダウンしません。同様に、逆にを使用するセカンダリでも同じredo_rateです。

実稼働環境の1つで発生している遅延の問題のトラブルシューティングの一環として、log_send_rate値を調べてきました。

ここで述べたように、フィールドの定義が間違っていることをマイクロソフトに提案しました（http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx）。「ログレコードがセカンダリデータベースに送信される速度（キロバイト（KB）/秒）」

以下の私の定義の方が良いと思います。それは...「ログレコードが送信キューからクリアされるレート」であり、ログレコードは、すべてのセカンダリですでに強化されている場合にのみ、このキューからクリアできます。それらのレコードが到着するのにかかった時間、それらが硬化されるのにかかった時間、およびセカンダリがACKをプライマリに返信するのにかかった時間に関係なく、送信および受信しました。

見た目は同じに見えても、それは非常に異なる定義です。データをローカルのメモリキュー（log_send_queue）から、別の地域、国、またはデータセンターのセカンダリに送信するよりもはるかに速く削除できます。

ニコス

@Thomas（私はまだここにコメントを追加することができません。お詫びします。仕事のメールを提供し、オフラインで話し合い、合意に達したらここで更新できますか？）こんにちはThomas

残念ながら、あなたの論点は正しいものの、それは問題になっている点ではありません。はい、あなたが説明したすべての理由のために関連付けるのは難しいですが、私が強調しようとしている問題ではありません。

ポイントは、DMVのフィールド「log_send_rate」は、実際にはログレコードがレプリカに送信されるレートではないということです。

より正確には、ログレコードが送信キューから削除される速度であり、ログレコードがすでにセカンダリに送信され、セカンダリで強化されてから、ACKをプライマリに送信した後のレートです。その後、プライマリ送信キューからクリアできます。

これは、最初の投稿に含めたリンクに記載されている意味とはまったく異なります。また、ローカルのデータセンターとの間でレートを送信するのではなく、地域間（ロンドンからニューヨークなど）のクロスレートの送信レートを処理しているときに、差異がはるかにわかりやすくなります。