Tentukan mengapa perubahan replika utama tidak tercermin pada replika sekunder untuk grup ketersediaan Always On
Berlaku untuk: 
SQL Server
Aplikasi klien berhasil menyelesaikan pembaruan pada replika utama, tetapi mengkueri replika sekunder menunjukkan bahwa perubahan tidak tercermin. Kasus ini mengasumsikan bahwa ketersediaan Anda memiliki status sinkronisasi yang sehat. Dalam kebanyakan kasus, perilaku ini menyelesaikannya sendiri setelah beberapa menit.
Jika perubahan masih belum tercermin pada replika sekunder setelah beberapa menit, mungkin ada hambatan dalam alur kerja sinkronisasi. Lokasi hambatan tergantung pada apakah replika sekunder diatur ke penerapan sinkron atau penerapan asinkron.
Penerapan sinkron
Setiap pembaruan yang berhasil pada replika utama telah disinkronkan ke replika sekunder, atau bahwa rekaman log telah dihapus untuk pengerasan pada replika sekunder. Oleh karena itu, penyempitan harus dalam proses pengulangan yang terjadi setelah log dibersihkan pada replika sekunder.
Namun, setelah pengulangan tertangkap, semua beban kerja baca pada replika sekunder adalah isolasi rekam jepret:
Transaksi jangka panjang pada replika utama
Ulangi replika sekunder
Penerapan asinkron
Karena penerapan asinkron mengakui transaksi segera setelah disiram ke disk lokal, hambatan dapat berada di mana saja setelah titik itu:
Transaksi jangka panjang pada replika utama
Latensi atau throughput jaringan
Log harden pada replika sekunder
Ulangi replika sekunder
Bagian berikut menjelaskan penyebab umum perubahan pada replika utama yang tidak tercermin pada replika sekunder untuk kueri baca-saja.
Transaksi aktif jangka panjang
Transaksi jangka panjang pada replika utama mencegah pembaruan dibaca pada replika sekunder.
Penjelasan
Semua beban kerja baca pada replika sekunder adalah kueri isolasi rekam jepret. Dalam isolasi rekam jepret, klien baca-saja melihat database ketersediaan pada replika sekunder di titik awal transaksi aktif terlama di log redone. Jika transaksi belum dilakukan selama berjam-jam, transaksi terbuka memblokir semua kueri baca-saja agar tidak melihat pembaruan baru.
Diagnosis dan resolusi
Pada replika utama, gunakan DBCC OPENTRAN (Transact-SQL) untuk melihat transaksi aktif terlama dan lihat apakah dapat digulung balik. Setelah transaksi aktif terlama digulung balik dan disinkronkan ke replika sekunder, beban kerja baca pada replika sekunder dapat melihat pembaruan dalam database ketersediaan hingga awal transaksi aktif terlama saat itu.
Latensi jaringan tinggi atau throughput jaringan rendah menyebabkan penumpukan log pada replika utama
Latensi jaringan tinggi atau throughput rendah dapat mencegah log dikirim ke replika sekunder dengan cukup cepat.
Penjelasan
Replika utama mengaktifkan kontrol alur pada pengiriman log ketika telah melebihi jumlah maksimum pesan yang tidak diakui yang diizinkan yang dikirim ke replika sekunder. Hingga beberapa pesan ini diakui, tidak ada lagi blok log yang dapat dikirim ke replika sekunder. Situasi ini dapat berdampak lebih serius pada potensi kehilangan data, mungkin membahmari tujuan titik pemulihan (RPO) Anda.
Diagnosis dan resolusi
Nilai DMV tinggi log_send_queue_size dapat menunjukkan log ditahan di replika utama. Membalikkan nilai ini dengan log_send_rate dapat memberi Anda perkiraan kasar tentang seberapa cepat data dapat terjebak pada replika sekunder.
Selain itu, berguna untuk memeriksa dua objek performa SQL Server:Availability Replica > Flow Control Time (ms/dtk) dan SQL Server:Availability Replica > Flow control/sec. Mengalikan kedua nilai ini menunjukkan kepada Anda dalam detik terakhir berapa banyak waktu yang dihabiskan untuk menunggu kontrol alur dihapus. Semakin lama waktu tunggu kontrol alur, semakin rendah laju pengiriman.
Di bawah ini adalah daftar metrik yang berguna dalam mendiagnosis latensi dan throughput jaringan. Anda dapat menggunakan alat Windows lainnya seperti ping.exe untuk mengevaluasi pemanfaatan jaringan.
Penghitung kinerja
SQL Server:Database > Log Bytes Flushed/secPenghitung kinerja
SQL Server:Database Mirroring > Send/Receive Ack TimePenghitung kinerja
SQL Server:Availability Replica > Bytes Sent to Replica/secPenghitung kinerja
SQL Server:Availability Replica > Bytes Sent to Transport/secPenghitung kinerja
SQL Server:Availability Replica > Flow Control Time (ms/sec)Penghitung kinerja
SQL Server:Availability Replica > Flow Control/secPenghitung kinerja
SQL Server:Availability Replica > Resent Messages/sec
Untuk memperbaiki masalah ini, coba tingkatkan bandwidth jaringan Anda atau hapus atau kurangi lalu lintas jaringan yang tidak perlu.
Beban kerja pelaporan lain memblokir utas pengulangan dari menjalankan
Utas pengulangan pada replika sekunder diblokir untuk membuat perubahan bahasa definisi data (DDL) oleh kueri baca-saja yang berjalan lama. Utas pengulangan harus dibuka blokirnya sebelum dapat membuat pembaruan lebih lanjut tersedia untuk beban kerja baca.
Penjelasan
Pada replika sekunder, kueri baca-saja memperoleh kunci stabilitas skema (Sch-S). Kunci ini Sch-S dapat memblokir utas pengulangan agar tidak memperoleh kunci modifikasi skema (Sch-M) untuk membuat perubahan DDL apa pun. Utas pengulangan yang diblokir tidak dapat menerapkan rekaman log hingga tidak diblokir.
Diagnosis dan resolusi
Saat utas pengulangan diblokir, peristiwa yang diperluas yang disebut sqlserver.lock_redo_blocked dihasilkan. Selain itu, Anda dapat mengkueri sys.dm_exec_request DMV pada replika sekunder untuk mengetahui sesi mana yang memblokir utas REDO, lalu Anda dapat mengambil tindakan korektif. Kueri berikut mengembalikan ID sesi beban kerja pelaporan yang memblokir utas pengulangan.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Anda dapat membiarkan beban kerja pelaporan selesai, di mana utas pengulangan tidak diblokir, atau Anda dapat membuka blokir utas pengulangan segera dengan menjalankan perintah KILL (Transact-SQL) pada ID sesi pemblokiran.
Utas ulang tertinggal karena ketidakcocokan sumber daya
Beban kerja pelaporan besar pada replika sekunder telah memperlambat performa replika sekunder, dan utas pengulangan telah tertinggal.
Penjelasan
Saat menerapkan rekaman log pada replika sekunder, utas pengulangan membaca rekaman log dari disk log, lalu untuk setiap rekaman log, ia mengakses halaman data untuk menerapkan catatan log. Akses halaman dapat terikat I/O (mengakses disk fisik) jika halaman belum ada di kumpulan buffer. Jika ada beban kerja pelaporan terikat I/O, beban kerja pelaporan bersaing untuk sumber daya I/O dengan utas pengulangan dan dapat memperlambat utas pengulangan. Situasi ini tidak hanya memengaruhi beban kerja pelaporan lainnya dari melihat data yang diperbarui, tetapi juga memengaruhi RTO.
Diagnosis dan resolusi
Anda dapat menggunakan kueri DMV berikut untuk melihat seberapa jauh utas pengulangan telah tertinggal, dengan mengukur perbedaan antara kesenjangan antara last_redone_lsn dan last_received_lsn.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
Jika utas pengulangan memang tertinggal, Anda perlu menyelidiki akar penyebab penurunan performa pada replika sekunder. Jika ada ketidakcocokan I/O dengan beban kerja pelaporan, Anda dapat menggunakan Resource Governor untuk mengontrol siklus CPU yang digunakan oleh beban kerja pelaporan untuk secara tidak langsung mengontrol siklus I/O yang diambil, hingga batas tertentu. Misalnya, jika beban kerja pelaporan Anda menggunakan 10 persen CPU tetapi beban kerja terikat I/O, Anda dapat menggunakan Resource Governor untuk membatasi penggunaan sumber daya CPU hingga 5 persen untuk membatasi beban kerja baca, yang meminimalkan dampak pada I/O.