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:

Urutan	Deskripsi langkah	Komentar	Metrik yang berguna
1	Pembuatan catatan	Data log dihapus ke disk. Log ini harus direplikasi ke replika sekunder. Rekaman log masuk ke dalam antrean kirim.	SQL Server:Byte log basis data > dibersihkan per detik
2	Menangkap	Log untuk setiap database dicatat dan dikirim ke antrean mitra yang sesuai (satu per pasangan basis data replika). Proses pengambilan ini berjalan secara terus-menerus selama replika ketersediaan terhubung dan pergerakan data tidak ditangguhkan karena alasan apa pun, dan pasangan replika database ditunjukkan sebagai Menyinkronkan atau Tersinkronkan. Jika proses pengambilan tidak dapat memindai dan mengantrekan pesan dengan cukup cepat, antrean pengiriman log akan menumpuk.	SQL Server:Availability Replica > Byte Dikirim ke Replika/detik, 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 replika database dikeluarkan dari antrean dan dikirim melalui jaringan ke replika sekunder masing-masing.	SQL Server:Replika Ketersediaan > Byte yang dikirim ke transport/detik
4	Terima dan simpan dalam cache	Setiap replika sekunder menerima dan menyimpan cache pesan.	Penghitung kinerja >
5	Mengeras	Log dikosongkan di replika sekunder untuk memastikan daya tahan. Setelah pembersihan log, konfirmasi dikirim kembali ke replika utama. Setelah log diperkeras, kehilangan data dihindari.	Penghitung kinerja SQL Server:Database > Bytes Log Dibuang/dtk Jenis waktu tunggu HADR_LOGCAPTURE_SYNC
6	Mengulangi	Kembalikan halaman yang dihapus pada replika sekunder. Halaman disimpan dalam antrean redo saat menunggu untuk diproses ulang.	SQL Server:Database Replica > Redone Bytes/detik redo_queue_size (KB) dan redo_rate. Tipe tunggu REDO_SYNC

Gerbang pengaturan 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 pengendalian aliran. 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 sesuai urutan nomor urut log (LSN). Sebelum pesan log dikirim, LSN-nya juga diperiksa terhadap nomor LSN terendah yang diakui untuk memastikan bahwa LSN tersebut di bawah 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 akan dikirim.

SQL Server 2022 (16.x) meningkatkan batasan jumlah pesan yang diizinkan setiap gerbang. Dengan menggunakan Bendera Pelacakan 12310, batas yang ditingkatkan juga tersedia untuk versi SQL Server berikut: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.

Tabel berikut membandingkan batas pesan:

Batas baru

Untuk versi SQL Server yang mengaktifkan Bendera Pelacakan 12310, yaitu SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16, dan versi yang lebih baru, lihat batas berikut:

Tingkat	Jumlah gerbang	Jumlah pesan	Metrik yang berguna
Transportasi	1 per replika ketersediaan	16384	Peristiwa Diperluas database_transport_flow_control_action
Database	1 per database ketersediaan	7168	DBMIRROR_SEND Peristiwa diperpanjang hadron_database_flow_control_action

Batas lama

Untuk versi SQL Server yang tidak didukung, atau versi SQL Server yang didukung (dimulai dengan SQL Server 2019 CU9, SQL Server 2017 CU18, dan SQL Server 2016 SP1 CU16) yang tidak mengaktifkan Bendera Pelacakan 12310, lihat batas berikut:

Tingkat	Jumlah gerbang	Jumlah pesan	Metrik yang berguna
Transportasi	1 per replika ketersediaan	8192	Peristiwa diperluas database_transport_flow_control_action
Database	1 per database ketersediaan	1792 (x64) 1600 (x86)	DBMIRROR_SEND Acara yang diperpanjang hadron_database_flow_control_action

Dua penghitung kinerja yang berguna, SQL Server:Availability Replica > Kontrol Aliran/detik dan SQL Server:Availability Replica > Waktu Kontrol Aliran (ms/detik), menunjukkan kepada Anda, dalam detik terakhir, berapa kali kontrol aliran diaktifkan dan berapa banyak waktu yang dihabiskan untuk menunggu kontrol aliran. 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 pengaturan aliran, lihat Memecahkan Masalah: Potensi kehilangan data dengan replika grup ketersediaan dengan komitmen asinkron.

Memperkirakan waktu pemulihan (RTO)

RTO dalam SLA Anda tergantung pada waktu failover dari implementasi Always On Anda pada momen tertentu, yang dapat dinyatakan dengan rumus berikut:

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. Waktu ini bergantung pada pengaturan tingkat pengelompokan dan bukan pada replika ketersediaan individual. Bergantung pada kondisi failover otomatis yang dikonfigurasi, failover dapat dipicu sebagai respons instan terhadap kesalahan kritikal internal SQL Server, seperti spinlock yatim piatu. Dalam hal ini, deteksi dapat secepat ketika laporan kesalahan sp_server_diagnostics dikirim ke Kluster Failover Windows Server (WSFC). Interval bawaan adalah sepertiga dari batas waktu pemeriksaan kesehatan. Failover juga dapat dipicu karena waktu habis, misalnya ketika waktu habis pemeriksaan kesehatan kluster telah kedaluwarsa (30 detik secara bawaan) atau ketika sewa antara sumber daya DLL dan instans SQL Server telah kedaluwarsa (20 detik secara bawaan). Dalam hal ini, waktu deteksi adalah sepanjang interval waktu habis. Untuk informasi lebih lanjut, lihat Kebijakan failover yang fleksibel untuk otomatisasi failover dalam grup ketersediaan (SQL Server).

Hal satu-satunya yang perlu dilakukan replika sekunder agar siap untuk failover adalah memastikan proses redo menyusul hingga akhir log. Waktu pengulangan, Tredo, dihitung menggunakan rumus berikut:

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 melakukan failover kluster WSFC dan untuk mengaktifkan database. Waktu ini biasanya singkat dan konstan.

Memperkirakan potensi kehilangan data (RPO)

RPO dalam SLA Anda bergantung pada kemungkinan kehilangan data dari implementasi Always On Anda setiap saat. Kemungkinan kehilangan data ini dapat dinyatakan dalam rumus berikut:

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

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, menarik bahwa laju 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 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 dan RPO dengan dasbor SSMS

Di Grup Ketersediaan AlwaysOn, RTO dan RPO dihitung dan ditampilkan untuk database yang dihosting pada replika sekunder. Di dasbor SQL Server Management Studio (SSMS), pada replika utama, RTO dan RPO dikelompokkan oleh replika sekunder.

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

1. Di SQL Server Management Studio, perluas simpul Always On High Availability, 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].

   

Perhitungan RTO basis data 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:

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

Perhitungan RPO (Recovery Point Objective) untuk database sekunder

Untuk database sekunder (DB_sec), perhitungan dan tampilan RPO-nya didasarkan pada is_failover_ready, , last_commit_timedan nilai database utama (DB_pri) last_commit_time yang berkorelasi. Ketika nilai DB_sec.is_failover_ready adalah 1, maka data antara primer dan sekunder disinkronkan, dan tidak ada kehilangan data yang 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 komit terbaru untuk transaksi dari database utama yang telah berhasil disimpan secara permanen pada database sekunder. Angka ini sama untuk database utama dan sekunder. Namun, kesenjangan antara kedua nilai ini adalah durasi di mana transaksi yang tertunda belum diperkeras pada database sekunder, dan mungkin hilang jika terjadi failover.

Metrik performa yang digunakan dalam rumus RTO/RPO

• redo_queue_size (KB): Ukuran antrean redo, yang digunakan dalam RTO, adalah ukuran log transaksi di antara last_received_lsn dan last_redone_lsn. Nilainya 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. Nilai 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 berapa banyak blok log transaksi yang belum di-redone. Ini diukur dalam Kilobyte(KB).

• redo_rate (KB/detik): Digunakan dalam perhitungan RTO, ini adalah nilai kumulatif yang menunjukkan berapa banyak log transaksi (KB) yang telah direone atau diputar ulang pada database sekunder per detik.

• last_commit_time (tanggalwaktu): Digunakan dalam RPO, nilai ini memiliki arti yang berbeda antara database utama dan sekunder. Untuk database utama, last_commit_time adalah waktu ketika transaksi terbaru dilakukan. Untuk database sekunder, last_commit_time adalah penerapan terbaru untuk transaksi pada database utama yang berhasil diperkuat 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 membuat kueri DMV sys.dm_hadr_database_replica_states dan sys.dm_hadr_database_replica_cluster_states untuk memperkirakan RPO dan RTO dari sebuah 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 simpanan ini sudah ada, hapus 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 AS sysname;
       DECLARE @is_primary_replica AS BIT;
       DECLARE @is_failover_ready AS BIT;
       DECLARE @redo_queue_size AS BIGINT;
       DECLARE @redo_rate AS BIGINT;
       DECLARE @replica_id AS UNIQUEIDENTIFIER;
       DECLARE @group_database_id AS UNIQUEIDENTIFIER;
       DECLARE @group_id AS UNIQUEIDENTIFIER;
       DECLARE @RTO AS 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 AS dbr
            INNER JOIN sys.dm_hadr_database_replica_cluster_states AS 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
   

2. Jalankan proc_calculate_RTO dengan nama database sekunder target:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. 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 of Database DB_sec' is 0
   group_id of Database DB4 is F176DD65-C3EE-4240-BA23-EA615F965C9B
   replica_id of Database DB4 is 405554F6-3FDC-4593-A650-2067F5FABFFD
   group_database_id of Database DB4 is 39F7942F-7B5E-42C5-977D-02E7FFA6C392
   

Membuat prosedur tersimpan untuk memperkirakan RPO

1. Pada replika utama, buat prosedur tersimpan proc_calculate_RPO. Jika sudah ada, hapus 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 AS sysname;
       DECLARE @is_primary_replica AS BIT;
       DECLARE @is_failover_ready AS BIT;
       DECLARE @is_local AS BIT;
       DECLARE @last_commit_time_sec AS DATETIME;
       DECLARE @last_commit_time_pri AS DATETIME;
       DECLARE @RPO AS NVARCHAR (MAX);
       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 AS dbr
            INNER JOIN sys.dm_hadr_database_replica_cluster_states AS 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;
       SELECT @last_commit_time_pri = dbr.last_commit_time,
              @is_local = dbr.is_local
       FROM sys.dm_hadr_database_replica_states AS dbr
            INNER JOIN sys.dm_hadr_database_replica_cluster_states AS 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
   
   -- secondary database's last_commit_time -- correlated primary database's last_commit_time
   

2. Jalankan proc_calculate_RPO dengan group_id, replica_id, dan group_database_id pada target database sekunder.

   EXECUTE 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';
   

3. Output menampilkan nilai RPO dari database replika sekunder target.

Memantau 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. Untuk informasi selengkapnya, lihat Menampilkan 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 identik pada semua replika ketersediaan.

• Evaluasi kebijakan dilakukan di semua server, tetapi hanya pada grup ketersediaan di mana replika ketersediaan lokal adalah replika utama. Jika replika ketersediaan lokal bukan replika utama, kebijakan tidak dievaluasi.

• Kegagalan kebijakan ditampilkan dengan nyaman di Always On Dashboard ketika Anda melihatnya pada replika utama.

Untuk membuat kebijakan, ikuti instruksi 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 , pilih Opsi.

3. Di tab SQL Server Always On , pilih Aktifkan kebijakan AlwaysOn yang ditentukan pengguna dan pilih 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: Keadaan Replika Database
   • Bidang: Add(@EstimatedRecoveryTime, 60)
   • Operator: <=
   • Nilai: 600

   Kondisi ini gagal ketika waktu failover yang potensial melebihi 10 menit, termasuk tambahan waktu 60 detik untuk deteksi kegagalan dan failover.

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

   • Nama: RPO
   • Faset: Keadaan 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 di mana replika ketersediaan lokal adalah replika utama.

       • Evaluasi mode: Sesuai jadwal

       • Jadwal: JadwalPengumpul_Setiap_5menit

       • 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 kinerja pada instans server yang bersangkutan.

       • Teks yang akan ditampilkan: RTO (Waktu Penundaan Terlampaui)

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

   • Halaman umum :

     • Nama: CustomAvailabilityDatabaseRPO
     • Periksa kondisi: RPO
     • Melawan target: Setiap DatabaseReplicaState dalam Kelompok Ketersediaan IsPrimaryReplica
     • Evaluasi mode: Sesuai jadwal
     • Jadwal: Jadwal Kolektor Setiap 30 Menit
     • 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 Anda selesai, dua tugas Agen SQL Server baru akan dibuat, masing-masing 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 Waktu Pemulihan yang Ditargetkan (RTO) Anda. Atau, ketika Anda memperkirakan durasi waktu failover replika sekunder dengan komitmen sinkron (seperti mitra failover otomatis), Anda mendapati bahwa durasinya melebihi target RTO Anda.
Mengatasi 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 dengan komit 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 tambahan 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	Pemecahan Kesalahan	Sekunder
redo_worker_entry	transaksi	Pemecahan Kesalahan	Sekunder
hadr_transport_dump_message	alwayson	Pemecahan Kesalahan	Primer
hadr_worker_pool_task	alwayson	Pemecahan Kesalahan	Primer
hadr_dump_primary_progress	alwayson	Pemecahan Kesalahan	Primer
hadr_dump_log_progress	alwayson	Pemecahan Kesalahan	Primer
hadr_undo_of_redo_log_scan	alwayson	Analitik	Sekunder