Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk:
SQL Server
Setelah failover otomatis atau failover manual terencana tanpa kehilangan data pada grup ketersediaan, Anda mungkin mendapati bahwa waktu failover melebihi sasaran waktu pemulihan (RTO). Atau, ketika Anda memperkirakan waktu failover replika sekunder dengan komit sinkron (seperti mitra failover otomatis) menggunakan metode dalam Memantau kinerja untuk Grup Ketersediaan Always On, Anda mendapati bahwa waktu tersebut melebihi RTO Anda.
Jika failover otomatis Anda masih belum berhasil diselesaikan, lihat Pemecahan masalah failover otomatis di lingkungan Always On SQL Server 2012.
Bagian berikut menjelaskan penyebab umum untuk waktu failover yang melebihi RTO.
Beban kerja pelaporan memblokir utas redo agar tidak dapat berjalan
Utas redo pada replika sekunder terhalang untuk melakukan perubahan DDL oleh kueri baca-saja yang berjalan dalam waktu lama.
Penjelasan
Pada replika sekunder, kueri baca-saja memperoleh kunci stabilitas skema (Sch-S). Kunci Sch-S ini dapat memblokir utas redo agar tidak memperoleh kunci modifikasi skema (Sch-M) untuk melakukan perubahan DDL apa pun. Thread redo yang diblokir tidak dapat menerapkan catatan log sampai blokirnya dibuka. Setelah pemblokirannya dibuka, proses tersebut dapat terus menyusul hingga akhir log dan memungkinkan proses undo dan failover berikutnya berlanjut.
Diagnosis dan resolusi
Saat utas redo diblokir, peristiwa diperluas bernama sqlserver.lock_redo_blocked akan 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 dari kueri hanya-baca yang memblokir utas redo.
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, setelah itu utas redo akan dibuka blokirnya, atau Anda dapat segera membuka blokir utas redo dengan menjalankan perintah KILL (Transact-SQL) pada ID sesi yang memblokir.
Utas redo tertinggal karena perebutan sumber daya
Beban kerja pelaporan yang besar pada replika sekunder telah menyebabkan kinerja replika sekunder melambat, dan utas redo telah tertunda.
Penjelasan
Saat menerapkan catatan log pada replika sekunder, utas redo membaca catatan log dari disk log, lalu untuk setiap catatan log, mengakses halaman data untuk menerapkan catatan log tersebut. Akses halaman dapat terikat I/O (mengakses disk fisik) jika halaman belum ada di kumpulan buffer. Jika ada beban kerja pelaporan yang bergantung pada I/O, beban kerja pelaporan akan bersaing memperebutkan sumber daya I/O dengan utas redo dan dapat memperlambat utas redo.
Diagnosis dan resolusi
Anda dapat menggunakan kueri DMV berikut untuk melihat seberapa jauh utas redo telah tertinggal, dengan mengukur selisih gap 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 redo memang tertinggal, Anda perlu menyelidiki akar penyebab penurunan kinerja 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 mengonsumsi 10 persen CPU tetapi beban kerja tersebut bergantung pada I/O, Anda dapat menggunakan Resource Governor untuk membatasi penggunaan sumber daya CPU hingga 5 persen guna memperlambat beban kerja pembacaan, sehingga meminimalkan dampaknya pada I/O.