Grup Ketersediaan AlwaysOn log_send_rate

Pada semua pengaturan AlwaysOn kami, menjalankan Windows 2012 dan SQL Server 2012 di mesin virtual dan pada bare-metal, saya menemukan bahwa log_send_rate sys.dm_hadr_database_replica_statessecara konsisten mengembalikan nilai yang salah.

Misalnya (untuk mode sinkron)

sys.dm_hadr_database_replica_states.log_send_rate (ave = 36.571 (kb / s tercantum dalam bol))

Perfmon - SQLServer: Replika Ketersediaan - Bytes Dikirim ke Replika / detik (maks = 486.000.000, rata-rata = 259.000.000)

Perfmon - SQLServer: Databases - Log Bytes Flushed / sec (maks = 653.044.000, rata-rata = 341.000.000)

Saya belum melihat pos tentang ini tetapi tampaknya tidak berfungsi dengan benar. Nilai yang benar log_send_rateberguna untuk memonitor AlwaysOn.

Adakah orang lain yang mengalami ini?

Ya, ini diperbaiki baru-baru ini di Service Pack 2, Pembaruan Kumulatif 3. Inilah artikel KB: http://support.microsoft.com/kb/3012182

"FIX: Log_Send_Rate kolom di sys.dm_hadr_database_replica_states tidak dapat mencerminkan tingkat secara akurat di SQL Server 2012"

Alasan mengapa log_send_rate(dan redo_rate) agak sulit untuk dipahami dan "dikorelasikan", terutama ketika kita terbiasa dengan transfer data melalui titik waktu jenis pemikiran yang tidak terganggu adalah bahwa kedua tingkat ini dihitung selama masa aktif, tidak setiap saat .

Dengan kata lain, log_send_rateakan menyesuaikan ketika ada blok log yang dikirim, tetapi itu tidak akan turun ketika itu tenang dan replika utama sedang menunggu log untuk dikirim. Demikian juga sebaliknya pada secondaries dengan redo_rate.

Saya telah melihat nilai log_send_rate sebagai bagian dari pemecahan masalah masalah latensi yang kami miliki di salah satu lingkungan produksi kami.

Saya telah mengusulkan kepada Microsoft bahwa definisi mereka tentang bidang ini salah, sebagaimana disebutkan di sini ( http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx ). "Nilai di mana catatan log dikirim ke database sekunder, dalam kilobyte (KB) / detik."

Saya pikir definisi saya di bawah ini lebih baik. Itu adalah ... "Tingkat di mana catatan log dihapus dari antrian kirim", dan catatan log hanya dapat dihapus dari antrian ini ketika mereka telah dikeraskan pada semua sekunder, dan itu hanya dapat terjadi ketika mereka sudah dikirim dan diterima, terlepas dari berapa lama waktu yang dibutuhkan untuk catatan itu tiba, dan berapa lama waktu yang dibutuhkan untuk dikeraskan, dan berapa lama yang dibutuhkan untuk pengiriman sekunder untuk mengembalikan aset ke primer.

Itu definisi yang sangat berbeda, bahkan jika mereka terlihat sama secara kosmetik. Data dapat dihapus dari antrian memori lokal (log_send_queue) jauh lebih cepat daripada yang dapat dikirim ke sekunder di wilayah lain, negara atau pusat data.

Nikos

@ Thomas (Saya masih terlalu noob untuk menambahkan komentar di sini, permintaan maaf. Jika lebih mudah saya dapat memberikan email kantor saya dan kami dapat berdiskusi secara offline, dan memperbarui di sini ketika konsensus tercapai?) Hai Thomas

Sayangnya, meskipun poin Anda benar, ini bukan poin yang dipertaruhkan. Ya, lebih sulit untuk berkorelasi untuk semua alasan yang telah Anda jelaskan, tetapi ini bukan masalah yang saya coba soroti.

Intinya adalah, bahwa bidang "log_send_rate" di DMV sebenarnya bukan tingkat di mana catatan log dikirim ke replika.

Lebih tepatnya, ini adalah tingkat di mana catatan log dihapus dari antrian kirim, SETELAH mereka telah dikirim ke sekunder, mengeras di sekunder, dan kemudian mengirim ack kembali ke primer. Hanya dengan demikian mereka dapat dihapus dari antrian pengiriman utama.

Itu makna yang sama sekali berbeda dari yang tercantum dalam tautan yang saya sertakan dalam posting pertama saya. Ini juga jauh lebih mudah untuk melihat perbedaan ketika Anda berurusan dengan lintas regional (seperti London ke New York) mengirim tarif, daripada mengirim tarif dari dan ke pusat data lokal.