Bagikan melalui


Memantau performa untuk grup ketersediaan AlwaysOn

Berlaku untuk: SQL Server

Aspek performa Grup Ketersediaan AlwaysOn sangat penting untuk mempertahankan perjanjian tingkat layanan (SLA) untuk database misi penting Anda. Memahami bagaimana grup ketersediaan mengirim log ke replika sekunder dapat membantu Anda memperkirakan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) implementasi ketersediaan Anda dan mengidentifikasi hambatan dalam grup ketersediaan atau replika yang berkinerja buruk. Artikel ini menjelaskan proses sinkronisasi, menunjukkan kepada Anda cara menghitung beberapa metrik utama, dan memberi Anda tautan ke beberapa skenario pemecahan masalah performa umum.

Proses sinkronisasi data

Untuk memperkirakan waktu sinkronisasi penuh dan mengidentifikasi hambatan, Anda perlu memahami proses sinkronisasi. Penyempitan performa dapat berada di mana saja dalam proses, dan menemukan hambatan dapat membantu Anda menggali lebih dalam masalah yang mendasar. Gambar dan tabel berikut mengilustrasikan proses sinkronisasi data:

Sinkronisasi data grup ketersediaan

Sequence Deskripsi langkah Komentar Metrik yang berguna
1 Pembuatan log Data log dihapus ke disk. Log ini harus direplikasi ke replika sekunder. Rekaman log memasukkan antrean kirim. SQL Server:Byte log database > di-flushed\sec
2 Tangkap Log untuk setiap database diambil dan dikirim ke antrean mitra yang sesuai (satu per pasangan replika database). Proses penangkapan ini berjalan terus menerus selama replika ketersediaan terhubung dan pergerakan data tidak ditangguhkan karena alasan apa pun, dan pasangan replika database ditunjukkan untuk Disinkronkan atau Disinkronkan. Jika proses pengambilan tidak dapat memindai dan mengantrekan pesan dengan cukup cepat, antrean pengiriman log akan dibangun. SQL Server:Availability Replica > Bytes Sent to Replica\sec, yang merupakan agregasi dari jumlah semua pesan database yang diantrekan untuk replika ketersediaan tersebut.

log_send_queue_size (KB) dan log_bytes_send_rate (KB/detik) pada replika utama.
3 Kirim Pesan dalam setiap antrean database-replika dihapus antrean dan dikirim melalui kawat ke replika sekunder masing-masing. SQL Server:Byte Replika > Ketersediaan yang dikirim ke transport\sec
4 Terima dan cache Setiap replika sekunder menerima dan menyimpan cache pesan. Penghitung kinerja SQL Server:Byte Log Replika > Ketersediaan Diterima/detik
5 Mengeras Log dihapus pada replika sekunder untuk pengerasan. Setelah flush log, pengakuan dikirim kembali ke replika utama.

Setelah log diperkeras, kehilangan data dihindari.
Penghitung kinerja SQL Server:Byte Log Database > Dihapus/dtk

Jenis tunggu HADR_LOGCAPTURE_SYNC
6 Mengulangi Ulangi halaman yang dibersihkan pada replika sekunder. Halaman disimpan dalam antrean pengulangan saat menunggu untuk direalone. SQL Server:Database Replica > Redone Bytes/dtk

redo_queue_size (KB) dan redo_rate.

Jenis tunggu REDO_SYNC

Gerbang kontrol aliran

Grup ketersediaan dirancang dengan gerbang kontrol aliran pada replika utama untuk menghindari konsumsi sumber daya yang berlebihan, seperti sumber daya jaringan dan memori, pada semua replika ketersediaan. Gerbang kontrol alur ini tidak memengaruhi status kesehatan sinkronisasi replika ketersediaan, tetapi dapat memengaruhi performa keseluruhan database ketersediaan Anda, termasuk RPO.

Setelah log diambil pada replika utama, log tunduk pada dua tingkat kontrol alur. Setelah ambang pesan dari salah satu gerbang tercapai, pesan log tidak lagi dikirim ke replika tertentu atau untuk database tertentu. Pesan dapat dikirim setelah pesan pengakuan diterima untuk pesan yang dikirim untuk membawa jumlah pesan terkirim di bawah ambang batas.

Selain gerbang kontrol alur, ada faktor lain yang dapat mencegah pesan log dikirim. Sinkronisasi replika memastikan bahwa pesan dikirim dan diterapkan dalam urutan nomor urutan log (LSN). Sebelum pesan log dikirim, LSN-nya juga memeriksa nomor LSN terendah yang diakui untuk memastikan bahwa itu kurang dari salah satu ambang batas (tergantung pada jenis pesan). Jika kesenjangan antara dua angka LSN lebih besar dari ambang batas, pesan tidak dikirim. Setelah celah berada di bawah ambang batas lagi, pesan dikirim.

SQL Server 2022 meningkatkan batasan jumlah pesan yang diizinkan setiap gerbang. Dengan menggunakan bendera pelacakan 12310, batas yang ditingkatkan juga tersedia untuk versi SQL Server berikut, dimulai dengan: SQL Server 2019 CU9, SQL Server 2017 CU18, dan SQL Server 2016 SP1 CU16.

Tabel berikut membandingkan batas pesan:

SQL Server 2022, dan versi SQL Server yang didukung (dimulai dengan SQL Server 2019 CU9, SQL Server 2017 CU18, dan SQL Server 2016 SP1 CU16) yang mengaktifkan bendera pelacakan 12310 lihat batas berikut:

Tingkat Jumlah gerbang Jumlah pesan Metrik yang berguna
Transportasi 1 per replika ketersediaan 16384 Database_transport_flow_control_action peristiwa yang diperluas
Database 1 per database ketersediaan 7168 DBMIRROR_SEND

Hadron_database_flow_control_action peristiwa yang diperluas

Dua penghitung kinerja yang berguna, SQL Server:Kontrol Aliran Replika > Ketersediaan/detik dan SQL Server:Availability Replica > Flow Control Time (ms/detik), menunjukkan kepada Anda, dalam detik terakhir, berapa kali kontrol aliran diaktifkan dan berapa banyak waktu yang dihabiskan untuk menunggu kontrol alur. Waktu tunggu yang lebih tinggi pada kontrol alur diterjemahkan ke RPO yang lebih tinggi. Untuk informasi selengkapnya tentang jenis masalah yang dapat menyebabkan waktu tunggu yang tinggi pada kontrol alur, lihat Memecahkan Masalah: Grup ketersediaan melebihi RPO.

Memperkirakan waktu failover (RTO)

RTO dalam SLA Anda tergantung pada waktu failover implementasi AlwaysOn Anda pada waktu tertentu, yang dapat dinyatakan dalam rumus berikut:

Perhitungan RTO grup ketersediaan

Penting

Jika grup ketersediaan berisi lebih dari satu database ketersediaan, maka database ketersediaan dengan Tfailover tertinggi menjadi nilai pembatasan untuk kepatuhan RTO.

Waktu deteksi kegagalan, Tdetection, adalah waktu yang diperlukan sistem untuk mendeteksi kegagalan. Kali ini tergantung pada pengaturan tingkat kluster dan bukan pada replika ketersediaan individual. Bergantung pada kondisi failover otomatis yang dikonfigurasi, failover dapat dipicu sebagai respons instan terhadap kesalahan internal SQL Server penting, seperti spinlock tanpa intim. Dalam hal ini, deteksi dapat secepat laporan kesalahan sp_server_diagnostics (Transact-SQL) dikirim ke kluster WSFC (interval default adalah 1/3 dari batas waktu pemeriksaan kesehatan). Failover juga dapat dipicu karena waktu habis, seperti batas waktu pemeriksaan kesehatan kluster telah kedaluwarsa (30 detik secara default) atau sewa antara DLL sumber daya dan instans SQL Server telah kedaluwarsa (20 detik secara default). Dalam hal ini, waktu deteksi adalah selama interval batas waktu. Untuk informasi selengkapnya, lihat Kebijakan failover fleksibel untuk failover otomatis grup ketersediaan (SQL Server).

Satu-satunya hal yang perlu dilakukan replika sekunder untuk menjadi siap untuk failover adalah agar pengulangan mengejar ke akhir log. Waktu pengulangan, Tredo, dihitung menggunakan rumus berikut:

Perhitungan waktu pengulangan grup ketersediaan

di mana redo_queue adalah nilai dalam redo_queue_size dan redo_rate adalah nilai dalam redo_rate.

Waktu overhead failover, Toverhead, mencakup waktu yang diperlukan untuk mengalihkan kluster WSFC dan untuk membuat database online. Waktu ini biasanya singkat dan konstan.

Memperkirakan potensi kehilangan data (RPO)

RPO di SLA Anda tergantung pada kemungkinan hilangnya data implementasi Always On Anda pada waktu tertentu. Kemungkinan kehilangan data ini dapat dinyatakan dalam rumus berikut:

Perhitungan RPO grup ketersediaan

di mana log_send_queue adalah nilai log_send_queue_size dan laju pembuatan log adalah nilai SQL Server:Byte Log Database > Flushed/dtk.

Peringatan

Jika grup ketersediaan berisi lebih dari satu database ketersediaan, maka database ketersediaan dengan Tdata_loss tertinggi menjadi nilai pembatasan untuk kepatuhan RPO.

Antrean pengiriman log mewakili semua data yang dapat hilang dari kegagalan bencana. Pada pandangan pertama, penasaran bahwa tingkat pembuatan log digunakan alih-alih laju pengiriman log (lihat log_send_rate). Namun, ingatlah bahwa menggunakan laju pengiriman log hanya memberi Anda waktu untuk disinkronkan, sementara RPO mengukur kehilangan data berdasarkan seberapa cepat itu dihasilkan, bukan pada seberapa cepat itu disinkronkan.

Cara yang lebih sederhana untuk memperkirakan Tdata_loss adalah dengan menggunakan last_commit_time. DMV pada replika utama melaporkan nilai ini untuk semua replika. Anda dapat menghitung perbedaan antara nilai untuk replika utama dan nilai untuk replika sekunder untuk memperkirakan seberapa cepat log pada replika sekunder mengejar replika utama. Seperti yang dinyatakan sebelumnya, perhitungan ini tidak memberi tahu Anda potensi kehilangan data berdasarkan seberapa cepat log dihasilkan, tetapi seharusnya mendekati.

Memperkirakan RTO & RPO dengan dasbor SSMS

Di Grup Ketersediaan AlwaysOn, RTO dan RPO dihitung dan ditampilkan untuk database yang dihosting pada replika sekunder. Pada dasbor replika utama, RTO dan RPO dikelompokkan menurut replika sekunder.

Untuk melihat RTO dan RPO di dalam dasbor, lakukan hal berikut:

  1. Di SQL Server Management Studio, perluas simpul Ketersediaan Tinggi AlwaysOn, klik kanan nama grup ketersediaan Anda, dan pilih Tampilkan Dasbor.

  2. Pilih Tambahkan/Hapus Kolom di bawah tab Kelompokkan menurut . Periksa Perkiraan Waktu Pemulihan(detik) [RTO] dan Perkiraan Kehilangan Data (waktu) [RPO].

    Cuplikan layar memperlihatkan dasbor RPO RTO.

Perhitungan RTO database sekunder

Perhitungan waktu pemulihan menentukan berapa banyak waktu yang diperlukan untuk memulihkan database sekunder setelah failover terjadi. Waktu failover biasanya pendek dan konstan. Waktu deteksi tergantung pada pengaturan tingkat kluster dan bukan pada replika ketersediaan individual.

Untuk database sekunder (DB_sec), perhitungan dan tampilan RTO-nya didasarkan pada redo_queue_size dan redo_rate:

Perhitungan RTO

Kecuali kasus sudut, rumus untuk menghitung RTO database sekunder adalah:

Rumus untuk menghitung RTO

Perhitungan RPO database sekunder

Untuk database sekunder (DB_sec), perhitungan dan tampilan RPO-nya didasarkan pada is_failover_ready, last_commit_time, dan database utamanya yang berkorelasi (DB_pri) last_commit_time. Ketika database.is_failover_ready sekunder = 1, maka daa disinkronkan, dan tidak ada kehilangan data yang akan terjadi setelah failover. Namun, jika nilai ini adalah 0, maka ada kesenjangan antara last_commit_time pada database utama dan last_commit_time pada database sekunder.

Untuk database utama, last_commit_time adalah waktu ketika transaksi terbaru telah dilakukan. Untuk database sekunder, last_commit_time adalah waktu penerapan terbaru untuk transaksi pada database utama yang telah berhasil diperkeras pada database sekunder juga. Angka ini harus sama untuk database utama dan sekunder. Kesenjangan antara kedua nilai ini adalah durasi di mana transaksi yang tertunda belum diperkeras pada database sekunder, dan akan hilang jika terjadi failover.

Perhitungan RPO

Penghitung Kinerja yang digunakan dalam rumus RTO/RPO

  • redo_queue_size (KB) [digunakan dalam RTO]: Ukuran antrean pengulangan adalah ukuran log transaksi antara last_received_lsn dan last_redone_lsn. last_received_lsn adalah ID blok log yang mengidentifikasi titik di mana semua blok log telah diterima oleh replika sekunder yang menghosting database sekunder ini. Last_redone_lsn adalah nomor urutan log dari rekaman log terakhir yang direbus pada database sekunder. Berdasarkan kedua nilai ini, kita dapat menemukan ID blok log awal (last_received_lsn) dan blok log akhir (last_redone_lsn). Ruang antara kedua blok log ini kemudian dapat mewakili bagaimana mungkin blok log transaksi belum di-redone. Ini diukur dalam Kilobyte(KB).
  • redo_rate (KB/dtk) [digunakan dalam RTO]: Nilai akumulatif yang mewakili pada periode waktu yang berlalu, berapa banyak log transaksi (KB) yang telah di-redone pada database sekunder dalam Kilobyte(KB)/escond.
  • last_commit_time (Datetime) [digunakan dalam RPO]: Untuk database utama, last_commit_time adalah waktu ketika transaksi terbaru telah dilakukan. Untuk database sekunder, last_commit_time adalah waktu penerapan terbaru untuk transaksi pada database utama yang telah berhasil diperkeras pada database sekunder juga. Karena nilai ini pada sekunder harus disinkronkan dengan nilai yang sama pada primer, kesenjangan apa pun antara kedua nilai ini adalah perkiraan kehilangan data (RPO).

Memperkirakan RTO dan RPO menggunakan DMV

Dimungkinkan untuk mengkueri sys.dm_hadr_database_replica_states DMV dan sys.dm_hadr_database_replica_cluster_states untuk memperkirakan RPO dan RTO database. Kueri di bawah ini membuat prosedur tersimpan yang menyelesaikan kedua hal tersebut.

Catatan

Pastikan untuk membuat dan menjalankan prosedur tersimpan untuk memperkirakan RTO terlebih dahulu, karena nilai yang dihasilkannya diperlukan untuk menjalankan prosedur tersimpan untuk memperkirakan RPO.

Membuat prosedur tersimpan untuk memperkirakan RTO

  1. Pada replika sekunder target, buat prosedur tersimpan proc_calculate_RTO. Jika prosedur tersimpan ini sudah ada, letakkan terlebih dahulu, lalu buat ulang.
   if object_id(N'proc_calculate_RTO', 'p') is not null
       drop procedure proc_calculate_RTO
   go
   
   raiserror('creating procedure proc_calculate_RTO', 0,1) with nowait
   go
   --
   -- name: proc_calculate_RTO
   --
   -- description: Calculate RTO of a secondary database.
   -- 
   -- parameters:	@secondary_database_name nvarchar(max): name of the secondary database.
   --
   -- security: this is a public interface object.
   --
   create procedure proc_calculate_RTO
   (
   @secondary_database_name nvarchar(max)
   )
   as
   begin
 	  declare @db sysname
 	  declare @is_primary_replica bit 
 	  declare @is_failover_ready bit 
 	  declare @redo_queue_size bigint 
 	  declare @redo_rate bigint
 	  declare @replica_id uniqueidentifier
 	  declare @group_database_id uniqueidentifier
 	  declare @group_id uniqueidentifier
 	  declare @RTO float 

 	  select 
 	  @is_primary_replica = dbr.is_primary_replica, 
 	  @is_failover_ready = dbcs.is_failover_ready, 
 	  @redo_queue_size = dbr.redo_queue_size, 
 	  @redo_rate = dbr.redo_rate, 
 	  @replica_id = dbr.replica_id,
 	  @group_database_id = dbr.group_database_id,
 	  @group_id = dbr.group_id 
 	  from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs 	on dbr.replica_id = dbcs.replica_id and 
 	  dbr.group_database_id = dbcs.group_database_id  where dbcs.database_name = @secondary_database_name

 	  if  @is_primary_replica is null or @is_failover_ready is null or @redo_queue_size is null or @replica_id is null or @group_database_id is null or @group_id is null
 	  begin
 	  	print 'RTO of Database '+ @secondary_database_name +' is not available'
 	  	return
 	  end
 	  else if @is_primary_replica = 1
 	  begin
 	  	print 'You are visiting wrong replica';
 	  	return
 	  end

 	  if @redo_queue_size = 0 
 	  	set @RTO = 0 
 	  else if @redo_rate is null or @redo_rate = 0 
 	  begin
 	  	print 'RTO of Database '+ @secondary_database_name +' is not available'
 	  	return
 	  end
 	  else 
 	  	set @RTO = CAST(@redo_queue_size AS float) / @redo_rate
   
 	  print 'RTO of Database '+ @secondary_database_name +' is ' + convert(varchar, ceiling(@RTO))
 	  print 'group_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_id)
 	  print 'replica_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @replica_id)
 	  print 'group_database_id of Database '+ @secondary_database_name +' is ' + convert(nvarchar(50), @group_database_id)
   end
  1. Jalankan proc_calculate_RTO dengan nama database sekunder target:
 exec proc_calculate_RTO @secondary_database_name = N'DB_sec'
  1. Output menampilkan nilai RTO dari database replika sekunder target. Simpan group_id, replica_id, dan group_database_id untuk digunakan dengan prosedur tersimpan estimasi RPO.

    Contoh Output:
    RTO database DB_sec' adalah 0
    group_id Database DB4 adalah F176DD65-C3EE-4240-BA23-EA615F965C9B
    replica_id Database DB4 adalah 405554F6-3FDC-4593-A650-2067F5FABFFD
    group_database_id Database DB4 adalah 39F7942F-7B5E-42C5-977D-02E7FFA6C392

Membuat prosedur tersimpan untuk memperkirakan RPO

  1. Pada replika utama, buat prosedur tersimpan proc_calculate_RPO. Jika sudah ada, letakkan terlebih dahulu, lalu buat ulang.
   if object_id(N'proc_calculate_RPO', 'p') is not null
   				drop procedure proc_calculate_RPO
   go
   
   raiserror('creating procedure proc_calculate_RPO', 0,1) with nowait
   go
   --
   -- name: proc_calculate_RPO
   --
   -- description: Calculate RPO of a secondary database.
   -- 
   -- parameters:	@group_id uniqueidentifier: group_id of the secondary database.
   --				@replica_id uniqueidentifier: replica_id of the secondary database.
   --				@group_database_id uniqueidentifier: group_database_id of the secondary database.
   --
   -- security: this is a public interface object.
   --
   create procedure proc_calculate_RPO
   (
    @group_id uniqueidentifier,
    @replica_id uniqueidentifier,
    @group_database_id uniqueidentifier
   )
   as
   begin
   	  declare @db_name sysname
   	  declare @is_primary_replica bit
   	  declare @is_failover_ready bit
   	  declare @is_local bit
   	  declare @last_commit_time_sec datetime 
   	  declare @last_commit_time_pri datetime      
   	  declare @RPO nvarchar(max) 

   	  -- secondary database's last_commit_time 
   	  select 
   	  @db_name = dbcs.database_name,
   	  @is_failover_ready = dbcs.is_failover_ready, 
   	  @last_commit_time_sec = dbr.last_commit_time 
   	  from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and 
   	  dbr.group_database_id = dbcs.group_database_id  where dbr.group_id = @group_id and dbr.replica_id = @replica_id and dbr.group_database_id = @group_database_id

   	  -- correlated primary database's last_commit_time 
   	  select
   	  @last_commit_time_pri = dbr.last_commit_time,
   	  @is_local = dbr.is_local
   	  from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states dbcs on dbr.replica_id = dbcs.replica_id and 
   	  dbr.group_database_id = dbcs.group_database_id  where dbr.group_id = @group_id and dbr.is_primary_replica = 1 and dbr.group_database_id = @group_database_id

   	  if @is_local is null or @is_failover_ready is null
   	  begin
   	  	print 'RPO of database '+ @db_name +' is not available'
   	  	return
   	  end

   	  if @is_local = 0
   	  begin
   	  	print 'You are visiting wrong replica'
   	  	return
   	  end  

   	  if @is_failover_ready = 1
   	  	set @RPO = '00:00:00'
   	  else if @last_commit_time_sec is null or  @last_commit_time_pri is null 
   	  begin
   	  	print 'RPO of database '+ @db_name +' is not available'
   	  	return
   	  end
   	  else
   	  begin
   	  	if DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0
   	  	begin
   	  		print 'RPO of database '+ @db_name +' is not available'
   	  		return
   	  	end
   	  	else
   	  		set @RPO =  CONVERT(varchar, DATEADD(ms, datediff(ss ,@last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114)
   	  end
   	  print 'RPO of database '+ @db_name +' is ' + @RPO
     end
  1. Jalankan proc_calculate_RPO dengan group_id, replica_id, dan group_database_id database sekunder target.
  exec proc_calculate_RPO @group_id= 'F176DD65-C3EE-4240-BA23-EA615F965C9B',
       @replica_id =  '405554F6-3FDC-4593-A650-2067F5FABFFD',
       @group_database_id  = '39F7942F-7B5E-42C5-977D-02E7FFA6C392'
  1. Output menampilkan nilai RPO dari database replika sekunder target.

Pemantauan untuk RTO dan RPO

Bagian ini menunjukkan cara memantau grup ketersediaan Anda untuk metrik RTO dan RPO. Demonstrasi ini mirip dengan tutorial GUI yang diberikan dalam model kesehatan Always On, bagian 2: Memperluas model kesehatan.

Elemen waktu failover dan potensi perhitungan kehilangan data dalam Memperkirakan waktu failover (RTO) dan Memperkirakan potensi kehilangan data (RPO) disediakan dengan nyaman sebagai metrik performa dalam status Replika Database faset manajemen kebijakan (lihat Melihat faset manajemen berbasis kebijakan pada objek SQL Server). Anda dapat memantau kedua metrik ini sesuai jadwal dan diberi tahu ketika metrik melebihi RTO dan RPO Anda.

Skrip yang ditunjukkan membuat dua kebijakan sistem yang dijalankan pada jadwal masing-masing, dengan karakteristik berikut:

  • Kebijakan RTO yang gagal ketika perkiraan waktu failover melebihi 10 menit, dievaluasi setiap 5 menit

  • Kebijakan RPO yang gagal ketika perkiraan kehilangan data melebihi 1 jam, dievaluasi setiap 30 menit

  • Kedua kebijakan memiliki konfigurasi yang identik pada semua replika ketersediaan

  • Kebijakan dievaluasi di semua server, tetapi hanya pada grup ketersediaan yang replika ketersediaan lokalnya adalah replika utama. Jika replika ketersediaan lokal bukan replika utama, kebijakan tidak dievaluasi.

  • Kegagalan kebijakan ditampilkan dengan nyaman di Dasbor AlwaysOn saat Anda melihatnya di replika utama.

Untuk membuat kebijakan, ikuti instruksi di bawah ini pada semua instans server yang berpartisipasi dalam grup ketersediaan:

  1. Mulai layanan SQL Server Agent jika belum dimulai.

  2. Di SQL Server Management Studio, dari menu Alat , klik Opsi.

  3. Di tab SQL Server Always On , pilih Aktifkan kebijakan AlwaysOn yang ditentukan pengguna dan klik OK.

    Pengaturan ini memungkinkan Anda menampilkan kebijakan kustom yang dikonfigurasi dengan benar di Dasbor AlwaysOn.

  4. Buat kondisi manajemen berbasis kebijakan menggunakan spesifikasi berikut:

    • Nama: RTO

    • Faset: Status Replika Database

    • Bidang: Add(@EstimatedRecoveryTime, 60)

    • Operator: <=

    • Nilai: 600

    Kondisi ini gagal ketika potensi waktu failover melebihi 10 menit, termasuk overhead 60 detik untuk deteksi kegagalan dan failover.

  5. Buat kondisi manajemen berbasis kebijakan kedua menggunakan spesifikasi berikut:

    • Nama: RPO

    • Faset: Status Replika Database

    • Bidang: @EstimatedDataLoss

    • Operator: <=

    • Nilai: 3600

    Kondisi ini gagal ketika potensi kehilangan data melebihi 1 jam.

  6. Buat kondisi manajemen berbasis kebijakan ketiga menggunakan spesifikasi berikut:

    • Nama: IsPrimaryReplica

    • Faset: Grup Ketersediaan

    • Bidang: @LocalReplicaRole

    • Operator: =

    • Nilai: Primary

    Kondisi ini memeriksa apakah replika ketersediaan lokal untuk grup ketersediaan tertentu adalah replika utama.

  7. Buat kebijakan manajemen berbasis kebijakan menggunakan spesifikasi berikut:

    • Halaman umum :

      • Nama: CustomSecondaryDatabaseRTO

      • Periksa kondisi: RTO

      • Terhadap target: Setiap DatabaseReplicaState di IsPrimaryReplica AvailabilityGroup

        Pengaturan ini memastikan bahwa kebijakan hanya dievaluasi pada grup ketersediaan yang replika ketersediaan lokalnya adalah replika utama.

      • Mode evaluasi: Sesuai jadwal

      • Jadwal: CollectorSchedule_Every_5min

      • Diaktifkan: dipilih

    • Halaman deskripsi :

      • Kategori: Peringatan database ketersediaan

        Pengaturan ini memungkinkan hasil evaluasi kebijakan ditampilkan di Dasbor AlwaysOn.

      • Deskripsi: Replika saat ini memiliki RTO yang melebihi 10 menit, dengan asumsi overhead 1 menit untuk penemuan dan failover. Anda harus segera menyelidiki masalah performa pada instans server masing-masing.

      • Teks yang akan ditampilkan: RTO Terlampaui!

  8. Buat kebijakan manajemen berbasis kebijakan kedua menggunakan spesifikasi berikut:

    • Halaman umum :

      • Nama: CustomAvailabilityDatabaseRPO

      • Periksa kondisi: RPO

      • Terhadap target: Setiap DatabaseReplicaState di IsPrimaryReplica AvailabilityGroup

      • Mode evaluasi: Sesuai jadwal

      • Jadwal: CollectorSchedule_Every_30min

      • Diaktifkan: dipilih

    • Halaman deskripsi :

      • Kategori: Peringatan database ketersediaan

      • Deskripsi: Database ketersediaan telah melebihi RPO Anda 1 jam. Anda harus segera menyelidiki masalah performa pada replika ketersediaan.

      • Teks yang akan ditampilkan: RPO Terlampaui!

Setelah selesai, dua pekerjaan SQL Server Agent baru dibuat, satu untuk setiap jadwal evaluasi kebijakan. Pekerjaan ini harus memiliki nama yang dimulai dengan syspolicy_check_schedule.

Anda dapat melihat riwayat pekerjaan untuk memeriksa hasil evaluasi. Kegagalan evaluasi juga dicatat di log aplikasi Windows (di Pemantau Peristiwa) dengan ID Peristiwa 34052. Anda juga dapat mengonfigurasi SQL Server Agent untuk mengirim pemberitahuan tentang kegagalan kebijakan. Untuk informasi selengkapnya, lihat Mengonfigurasi pemberitahuan untuk memberi tahu administrator kebijakan tentang kegagalan kebijakan.

Skenario pemecahan masalah performa

Tabel berikut mencantumkan skenario pemecahan masalah terkait performa umum.

Skenario Deskripsi
Pemecahan masalah: Grup ketersediaan melebihi RTO Setelah failover otomatis atau failover manual yang direncanakan tanpa kehilangan data, waktu failover melebihi RTO Anda. Atau, ketika Anda memperkirakan waktu failover replika sekunder penerapan sinkron (seperti mitra failover otomatis), Anda menemukan bahwa itu melebihi RTO Anda.
Pemecahan masalah: Grup ketersediaan melebihi RPO Setelah Anda melakukan failover manual paksa, kehilangan data Anda lebih dari RPO Anda. Atau, ketika Anda menghitung potensi kehilangan data dari replika sekunder penerapan asinkron, Anda menemukan bahwa itu melebihi RPO Anda.
Pemecahan masalah: Perubahan pada replika utama tidak tercermin pada replika sekunder Aplikasi klien berhasil menyelesaikan pembaruan pada replika utama, tetapi mengkueri replika sekunder menunjukkan bahwa perubahan tidak tercermin.

Peristiwa yang diperluas yang berguna

Peristiwa yang diperluas berikut ini berguna saat memecahkan masalah replika dalam status Sinkronisasi .

Nama Acara Kategori Saluran Replika ketersediaan
redo_caught_up transaksi Debug Sekunder
redo_worker_entry transaksi Debug Sekunder
hadr_transport_dump_message alwayson Debug Primer
hadr_worker_pool_task alwayson Debug Primer
hadr_dump_primary_progress alwayson Debug Primer
hadr_dump_log_progress alwayson Debug Primer
hadr_undo_of_redo_log_scan alwayson Analitik Sekunder