Always On kullanılabilirlik grupları için performansı izleme

Şunlar için geçerlidir: SQL Server

Always On Kullanılabilirlik Gruplarının performans yönü, görev açısından kritik veritabanlarınız için hizmet düzeyi sözleşmesini (SLA) korumak için çok önemlidir. Kullanılabilirlik gruplarının günlükleri ikincil çoğaltmalara nasıl gönderebileceğini anlamak, kullanılabilirlik uygulamanızın kurtarma süresi hedefini (RTO) ve kurtarma noktası hedefini (RPO) tahmin etmeye ve kötü performans gösteren kullanılabilirlik gruplarında veya çoğaltmalarda performans sorunlarını belirlemenize yardımcı olabilir. Bu makalede eşitleme işlemi açıklanır, bazı önemli ölçümlerin nasıl hesaplandığı gösterilir ve yaygın performans sorun giderme senaryolarından bazılarının bağlantıları sağlanır.

Veri eşitleme işlemi

Tam eşitleme süresini tahmin etmek ve performans sorununu belirlemek için eşitleme işlemini anlamanız gerekir. Performans sorunu sürecin herhangi bir yerinde olabilir ve performans sorununu bulmak, temel alınan sorunları daha ayrıntılı incelemenize yardımcı olabilir. Aşağıdaki şekilde ve tabloda veri eşitleme işlemi gösterilmektedir:

Kullanılabilirlik grubu veri eşitlemesinin ekran görüntüsü.

Sequence	Adım açıklaması	Yorumlar	Yararlı ölçümler
1	Günlük oluşturma	Günlük verileri diske yazılır. Bu kayıt ikincil kopyalara çoğaltılması gerekir. Günlük kayıtları gönderme kuyruğuna girer.	SQL Server:Veritabanı Günlük Bayt Artışı/sn >
2	Capture	Her veritabanı için günlükler yakalanır ve ilgili iş ortağı kuyruğuna gönderilir (veritabanı çoğaltma çifti başına bir tane). Kullanılabilirlik replikası bağlı kaldığı ve veri aktarımı herhangi bir sebeple durdurulmadığı sürece, veritabanı replikası çifti Eşitlenme Sürecinde veya Eşitlenmiş durumda gösteriliyorsa, bu yakalama işlemi aralıksız devam eder. Yakalama işlemi iletileri yeterince hızlı tarayamaz ve sıraya alamazsa günlük gönderme kuyruğu biriker.	SQL Server:Kullanılabilirlik Çoğaltması > Çoğaltmaya Gönderilen Bayt/sn, bu kullanılabilirlik çoğaltması için kuyruğa alınan tüm veritabanı iletilerinin toplamının toplamıdır. Birincil çoğaltmada log_send_queue_size (KB) ve log_bytes_send_rate (KB/sn).
3	Send	Her veritabanı çoğaltması kuyruğundaki iletiler sıralanır ve ilgili ikincil çoğaltmaya kablo üzerinden gönderilir.	SQL Server:Aktarıma gönderilen Baytları/sn Kullanılabilirlik Replikası >
4	Alma ve önbelleğe alma	Her ikincil çoğaltma iletiyi alır ve önbelleğe alır.	Performans sayacı SQL Server: Alınan Kullanılabilirlik Replika > Günlük Bayt/sn
5	Harden	Günlük, dayanıklılık sağlama amacıyla ikincil replikada yazılır. Günlük temizleme (flush) işlemi tamamlandıktan sonra, birincil replikaya bir onay gönderilir. Günlük sağlamlaştırıldıktan sonra veri kaybı önlenir.	Performans sayacı SQL Server:Veritabanı > Günlük Baytları Boşaltıldı/sn Bekleme türü HADR_LOGCAPTURE_SYNC
6	Yeniden yap	İkincil kopyadaki temizlenmiş sayfaları yeniden yap. Sayfalar yeniden işlenecek şekilde beklerken yeniden işleme kuyruğunda tutulur.	SQL Server:Veritabanı Çoğaltması > Yeniden Yapılan Bayt/sn redo_queue_size (KB) ve redo_rate. Bekleme türü REDO_SYNC

Akış denetim geçitleri

Kullanılabilirlik grupları, tüm kullanılabilirlik çoğaltmalarında ağ ve bellek kaynakları gibi aşırı kaynak tüketimini önlemek için birincil çoğaltmadaki akış denetim geçitleriyle tasarlanmıştır. Bu akış kontrol kapıları, kullanılabilirlik çoğaltmalarının eşitleme sağlık durumunu etkilemez; ancak RPO dahil olmak üzere kullanılabilirlik veritabanlarınızın genel performansını etkileyebilir.

Günlükler birincil çoğaltmada kaydedildikten sonra iki akış kontrolü seviyesine tabidir. Herhangi bir geçidin ileti eşik değeri aşıldığında, günlük iletileri artık belirli bir replikaya veya belirli bir veritabanı için gönderilmez. Onay iletileri alındıktan sonra iletiler gönderilebilir, böylece gönderilen iletilerin sayısı eşik seviyesinin altına düşürülür.

Akış kontrol kapılarına ek olarak, günlük iletilerinin gönderilmesini önleyebilecek başka bir faktör daha vardır. Çoğaltmaların eşitlenmesi, iletilerin günlük dizisi numaraları (LSN) sırasına göre gönderilmesini ve uygulanmasını sağlar. Günlük iletisi gönderilmeden önce, LSN'sinin en düşük kabul edilen LSN numarasına karşı kontrol edilerek ileti türüne bağlı eşiklerden birinin altında olup olmadığından emin olunur. İki LSN numarası arasındaki boşluk eşikten büyükse iletiler gönderilmez. Boşluk yeniden eşiğin altına indikten sonra iletiler gönderilir.

SQL Server 2022 (16.x), sınırları her geçidin izin verdiği ileti sayısına artırır. Aşağıdaki sürümlerden başlayarak, sınırı artırmak için başlangıçta izleme bayrağı 12310 kullanın: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18 ve SQL Server 2016 (13.x) SP1 CU16. Bu izleme bayrağı ile DBCC TRACEONkullanılamaz.

Aşağıdaki tablo ileti sınırlarını karşılaştırır:

Yeni sınırlar
Eski sınırlar

12310 izleme bayrağını etkinleştiren SQL Server sürümleri için, yani SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 ve sonraki sürümlerine: aşağıdaki sınırlara bakın.

Seviye	Kapı sayısı	İleti sayısı	Yararlı ölçümler
Taşıma	Kullanılabilirlik replikası başına 1	16384	Genişletilmiş olay `database_transport_flow_control_action`
Veritabanı	Kullanılabilirlik veritabanı başına 1	7168	DBMIRROR_SEND Genişletilmiş olay `hadron_database_flow_control_action`

12310 izleme bayrağı etkinleştirilmiş olmayan desteklenmeyen SQL Server sürümleri veya desteklenen SQL Server sürümleri (SQL Server 2019 CU9, SQL Server 2017 CU18 ve SQL Server 2016 SP1 CU16 ile başlayarak) için aşağıdaki sınırlara bakın:

Seviye	Kapı sayısı	İleti sayısı	Yararlı ölçümler
Taşıma	Kullanılabilirlik replikası başına 1	8192	Genişletilmiş olay `database_transport_flow_control_action`
Veritabanı	Kullanılabilirlik veritabanı başına 1	1792 (x64) 1600 (x86)	DBMIRROR_SEND Genişletilmiş olay `hadron_database_flow_control_action`

SQL Server:Kullanılabilirlik Çoğaltma > Akışı denetimi/sn ve SQL Server:Kullanılabilirlik Çoğaltma > Akışı Denetim Zamanı (ms/sn) adlı iki yararlı performans sayacı, son saniye içinde akış denetiminin kaç kez etkinleştirildiğini ve akış denetimi beklerken ne kadar süre harcandığını gösterir. Akış denetiminde daha uzun bekleme süresi daha yüksek RPO'ya çevrilir. Akış denetiminde yüksek bekleme süresine neden olabilecek sorun türleri hakkında daha fazla bilgi için Bkz. Sorun giderme: Zaman uyumsuz taahhüt edilebilirlik grubu çoğaltmalarıyla olası veri kaybı.

Yük devretme süresini tahmin (RTO)

SLA'nızdaki RTO, Always On uygulamanızın herhangi bir zamanda yük devretme süresine bağlıdır ve bu süre aşağıdaki formülde ifade edilebilir:

Kullanılabilirlik grupları RTO hesaplamasının ekran görüntüsü.

Önemli

Bir kullanılabilirlik grubu birden fazla kullanılabilirlik veritabanı içeriyorsa, en yüksek Tfailover'a sahip kullanılabilirlik veritabanı RTO uyumluluğu için sınırlayıcı değer olur.

Hata algılama süresi olan Tdetection, sistemin hatayı algılama süresidir. Bu süre, kullanılabilirlik replikalarına değil, küme düzeyi ayarlarına bağlıdır. Yapılandırılmış otomatik yük devretme koşuluna bağlı olarak, başıboş spinlock'lar gibi SQL Server'da meydana gelen kritik bir hataya anında tepki olarak yük devretme harekete geçirilebilir. Bu durumda algılama, Windows Server Failover Cluster'a (WSFC) sp_server_diagnostics hata raporu gönderildiğinde hızla algılanabilir. Varsayılan aralık, sistem durumu denetimi zaman aşımının 1/3'dür. Küme sistem durumu denetimi zaman aşımı süresinin dolması (varsayılan olarak 30 saniye) veya kaynak DLL ile SQL Server örneği arasındaki kiralamanın süresi (varsayılan olarak 20 saniye) dolması gibi bir zaman aşımı nedeniyle yük devretme tetiklenebilir. Bu durumda algılama süresi, zaman aşımı aralığı kadar uzundur. Daha fazla bilgi için bkz. Kullanılabilirlik grubunun (SQL Server) otomatik yük devretmesi için esnek yük devretme ilkesi.

İkincil replikanın yük devretmeye hazır hale gelmesi için yapması gereken tek şey, yeniden işlemenin günlüğün sonuna kadar yetişmesidir. Yineleme süresi olan Tredo, aşağıdaki formül kullanılarak hesaplanır:

Kullanılabilirlik gruplarının yineleme zamanı hesaplamasının ekran görüntüsü.

burada redo_queue, redo_queue_size değerindeki değerdir ve redo_rate, redo_rate değerindeki değerdir.

Yük devretme ek yükü süresi olan Toverhead, WSFC kümesinde yük devretme yapmak ve veritabanlarını çevrimiçi duruma getirmek için gereken süreyi içerir. Bu süre genellikle kısa ve sabittir.

Olası veri kaybını tahmin edin (RPO)

SLA'nızdaki RPO, her zaman Always On uygulamanızın olası veri kaybına bağlıdır. Bu olası veri kaybı aşağıdaki formülde ifade edilebilir:

Kullanılabilirlik grupları RPO hesaplamasının ekran görüntüsü.

burada log_send_queuelog_send_queue_size değeridir ve günlük oluşturma hızıSQL Server:Database > Log Bytes Flushed/sec değeridir.

Uyarı

Kullanılabilirlik grubu birden fazla kullanılabilirlik veritabanı içeriyorsa, en yüksek Tdata_loss sahip kullanılabilirlik veritabanı RPO uyumluluğu için sınırlayıcı değer olur.

Günlük gönderme kuyruğu, yıkıcı bir hatadan kaybolabilecek tüm verileri temsil eder. İlk bakışta, günlük gönderme hızı yerine günlük oluşturma oranının kullanılması şaşırtıcıdır (bkz. log_send_rate). Ancak, günlük gönderme hızını kullanmanın yalnızca eşitleme süresini belirttiğini, RPO'nun ise veri kaybını, ne kadar hızlı eşitlendiğine göre değil, verinin ne kadar hızlı oluşturulduğuna göre ölçtüğünü unutmayın.

Tdata_loss tahmin etmenin daha basit bir yolu last_commit_time kullanmaktır. Birincil kopyadaki DMV, tüm kopyalar için bu değeri bildirir. Birincil ve ikincil çoğaltmaların değerleri arasındaki farkı hesaplayarak, ikincil çoğaltmanın birincil çoğaltmaya ne kadar hızlı yetiştiğini tahmin edebilirsiniz. Daha önce belirtildiği gibi, bu hesaplama günlüğün ne kadar hızlı oluşturulduğuna bağlı olarak olası veri kaybını göstermez, ancak yakın bir tahmin olmalıdır.

SSMS panosuyla RTO ve RPO tahmini

Always On Kullanılabilirlik Grupları'nda RTO ve RPO, ikincil replikalarda barındırılan veritabanları için hesaplanır ve görüntülenir. SQL Server Management Stuiod (SSMS) panosunda, birincil çoğaltmada RTO ve RPO ikincil çoğaltmaya göre gruplandırılır.

Panodaki RTO ve RPO'yu görüntülemek için aşağıdaki adımları uygulayın:

SQL Server Management Studio'da Always On Yüksek Kullanılabilirlik düğümünü genişletin, kullanılabilirlik grubunuzun adına sağ tıklayın ve Panoyu Göster'i seçin.
Gruplandırmaya göre sekme altında Sütun Ekle/Kaldır'ı seçin. Her ikisini de kontrol edin: Tahmini Kurtarma Süresi (saniye) [RTO] ve Tahmini Veri Kaybı (süre) [RPO].

İkincil veritabanı RTO'sunun hesaplanması

Kurtarma süresi hesaplaması, bir yük devretme işleminden sonra ikincil veritabanını kurtarmak için ne kadar süre gerektiğini belirler. Yük devretme süresi genellikle kısa ve sabittir. Algılama süresi, erişilebilirlik replikalarının tek tek durumuna değil, küme düzeyi ayarlarına bağlıdır.

İkincil veritabanı DB_sec için, RTO'sunun hesaplanması ve görüntülenmesi, redo_queue_size ve redo_rate temel alınarak gerçekleştirilir.

RTO Hesaplaması'nın ekran görüntüsü.

Köşedeki durumlar dışında, ikincil veritabanının RTO'sunu hesaplama formülü şöyledir:

İkincil veritabanı RPO'sunun hesaplanması

İkincil veritabanı (DB_sec) için RPO'sunun hesaplanması ve görüntülenmesi, is_failover_ready, last_commit_time ve ilişkili birincil veritabanının (DB_pri) last_commit_time değerlerini temel alır. değeri DB_sec.is_failover_ready olduğunda 1, birincil ve ikinciller arasındaki veriler eşitlenir ve yük devretme sonrasında veri kaybı olmaz. Ancak, bu değer 0 ise, birincil veritabanındaki last_commit_time ile ikincil veritabanındaki last_commit_time arasında bir boşluk vardır.

Birincil veritabanı için, last_commit_time en son işlemin işlendiği zamandır. İkincil veritabanı için, last_commit_time birincil veritabanından yapılan ve ikincil veritabanında da başarıyla sağlamlaştırılmış olan işlem için en son işleme süresidir. Bu sayı hem birincil hem de ikincil veritabanı için aynıdır. Ancak bu iki değer arasındaki boşluk, bekleyen işlemlerin ikincil veritabanında henüz sağlamlaştırılmadığı ve başarısızlık devri durumunda kaybedilebileceği süredir.

RPO Hesaplaması'nın ekran görüntüsü.

RTO/RPO formüllerinde kullanılan performans ölçümleri

redo_queue_size (KB): RTO'da kullanılan yeniden yapma kuyruğu boyutu, last_received_lsn ile last_redone_lsn ve arasındaki işlem günlüklerinin boyutudur. last_received_lsn Değer, bu ikincil veritabanını barındıran ikincil çoğaltma tarafından tüm günlük bloklarının alındığı noktayı tanımlayan günlük bloğu kimliğidir. değeri last_redone_lsn , ikincil veritabanında yeniden yapılan son günlük kaydının günlük sırası numarasıdır. Bu iki değere bağlı olarak, başlangıç günlük bloğunun () ve bitiş günlük bloğunun (last_received_lsnlast_redone_lsn) kimliklerini bulabiliriz. Bu iki günlük bloğu arasındaki boşluk, kaç işlem günlüğü bloğunun henüz yeniden işlenmediğini gösterebilir. Bu, Kilobayt(KB) cinsinden ölçülür.
redo_rate (KB/sn): RTO hesaplamasında kullanılan bu, saniye başına ikincil veritabanında işlem günlüğünün (KB) ne kadarının yeniden ayarlandığını veya yeniden oynatıldığını gösteren bir kümülatif değerdir.
last_commit_time (datetime): RPO'da kullanılan bu değerin birincil ve ikincil veritabanı arasında farklı bir anlamı vardır. Birincil veritabanı için last_commit_time en son işlemin işlendiği zamandır. İkincil veritabanı için, last_commit_time birincil veritabanındaki işlem için en son commit'tir ve ikincil veritabanında da başarıyla sağlamlaştırılmıştır. İkincil değerdeki bu değer birincil değerdeki aynı değerle eşitlenmesi gerektiğinden, bu iki değer arasındaki boşluk veri kaybı tahminidir (RPO).

DMV'leri kullanarak RTO ve RPO'yu tahmin etme

Veritabanının RPO ve RTO'sunu tahmin etmek için sys.dm_hadr_database_replica_states ve sys.dm_hadr_database_replica_cluster_states DMV'lerini sorgulamak mümkündür. Aşağıdaki sorgular her iki işlemi de yerine getiren saklı yordamlar oluşturur.

Uyarı

İlk olarak RTO'yu tahmin etmek için saklı yordamı oluşturup çalıştırdığınızdan emin olun; çünkü ürettiği değerler, RPO'yu tahmin etmek için saklı yordamı çalıştırmakta gereklidir.

RTO'yu tahmin etmek için saklı yordam oluştur

Hedef ikincil replikada saklı yordam proc_calculate_RTO oluşturun. Bu saklı yordam zaten varsa, önce silin ve sonra yeniden oluşturun.

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

Hedef ikincil veritabanı adıyla yürüt proc_calculate_RTO :

EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';

Çıktı, hedef ikincil çoğaltma veritabanının RTO değerini görüntüler. group_id, replica_id ve group_database_id'i RPO tahmini saklı yordamıyla kullanmak üzere kaydedin.

Örnek Çıktı:

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

RPO'yu tahmin etmek için bir saklı yordam oluşturun

Birincil çoğaltmada saklı prosedür proc_calculate_RPO oluşturun. Eğer zaten mevcutsa, önce silin ve sonra yeniden oluşturun.

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

proc_calculate_RPO'ı çalıştırın ve hedef ikincil veritabanının group_id, replica_id ve group_database_id'ini girin.

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

Çıkış, hedef ikincil kopya veritabanının RPO değerini görüntüler.

RTO ve RPO için izleme

Bu bölümde RTO ve RPO ölçümleri için kullanılabilirlik gruplarınızın nasıl izleneceği gösterilmektedir. Bu gösterim, Her Zaman Açık sağlık modeli, bölüm 2: Sağlık modelini genişletme kısmında verilen GUI öğreticisine benzer.

Yük devretme zamanını tahmin etme (RTO) ve Olası veri kaybını tahmin etme (RPO) içindeki yük devretme süresi ve olası veri kaybı hesaplamalarının öğeleri, ilke yönetimi modelinde Veritabanı Çoğaltma Durumu'nda performans ölçümleri olarak rahatça sağlanır. Daha fazla bilgi için bkz. SQL Server Nesnesinde İlke Tabanlı Yönetim modellerini görüntüleme. Bu iki ölçümü bir zamanlamaya göre izleyebilir ve ölçümler sırasıyla RTO ve RPO'nuzu aştığında uyarı alabilirsiniz.

Gösterilen betikler, kendi zamanlamalarına göre çalıştırılan ve aşağıdaki özelliklere sahip iki sistem ilkesi oluşturur.

Tahmini yük devretme süresi 10 dakikayı aştığında başarısız olan ve 5 dakikada bir değerlendirilen bir RTO ilkesi
Tahmini veri kaybı 1 saati aştığında başarısız olan ve 30 dakikada bir değerlendirilen bir RPO ilkesi
İki politika, tüm erişilebilirlik replikalarında aynı yapılandırmaya sahiptir.
İlkeler tüm sunucularda değerlendirilir, ancak yalnızca yerel kullanılabilirlik çoğaltmasının birincil çoğaltma olduğu kullanılabilirlik gruplarında değerlendirilir. Yerel kullanılabilirlik çoğaltması birincil çoğaltma değilse ilkeler değerlendirilmez.
İlke hataları, birincil replika üzerinde görüntülendiğinde Always On Gösterge Panelinde kolayca görüntülenir.

İlkeleri oluşturmak için kullanılabilirlik grubuna katılan tüm sunucu örneklerinde şu yönergeleri izleyin:

Henüz başlatılmadıysa SQL Server Agent hizmetini başlatın.
SQL Server Management Studio'da, Araçları menüsünden Seçenekleröğesini seçin.
SQL Server Always On sekmesinde Kullanıcı tanımlı AlwaysOn ilkesini etkinleştir'i ve ardından Tamam'ı seçin.

Bu ayar, Her Zaman Açık Pano'da düzgün yapılandırılmış özel ilkeleri görüntülemenizi sağlar.
Aşağıdaki belirtimleri kullanarak ilke tabanlı bir yönetim koşulu oluşturun:
- İsim: RTO
- Özellik: Veritabanı Çoğaltma Durumu
- Alan: Add(@EstimatedRecoveryTime, 60)
- İşleç: <=
- Değer: 600
Bu koşul, olası yük devretme süresi 10 dakikayı aştığında, hata algılama ve yük devretme için toplam 60 saniyelik ek süreyle birlikte başarısız olur.
Aşağıdaki belirtimleri kullanarak ikinci bir ilke tabanlı yönetim koşulu oluşturun:
- İsim: RPO
- Özellik: Veritabanı Çoğaltma Durumu
- Alan: @EstimatedDataLoss
- İşleç: <=
- Değer: 3600
Olası veri kaybı 1 saati aştığında bu koşul başarısız olur.
Aşağıdaki belirtimleri kullanarak üçüncü bir ilke tabanlı yönetim koşulu oluşturun:
- İsim: IsPrimaryReplica
- Facet: Kullanılabilirlik Grubu
- Alan: @LocalReplicaRole
- İşleç: =
- Değer: Primary
Bu koşul, belirli bir kullanılabilirlik grubu için yerel kullanılabilirlik çoğaltmasının birincil çoğaltma olup olmadığını denetler.
Aşağıdaki belirtimleri kullanarak ilke tabanlı bir yönetim ilkesi oluşturun:
- Genel sayfa:
  - İsim: CustomSecondaryDatabaseRTO
  - Koşul kontrolü: RTO
  - Hedeflere karşı: IsPrimaryReplica AvailabilityGroup içindeki her DatabaseReplicaState
    
    Bu ayar, ilkenin yalnızca yerel kullanılabilirlik çoğaltmasının birincil çoğaltma olduğu kullanılabilirlik gruplarında değerlendirilmesini sağlar.
    - Değerlendirme modu: Zamanlamaya göre
    - Zamanlama: CollectorSchedule_Every_5min
    - Etkin: seçili
- Açıklama sayfası:
  - Kategori: Kullanılabilirlik veritabanı uyarıları
    
    Bu ayar, ilke değerlendirme sonuçlarının Her Zaman Açık Pano'da görüntülenmesini sağlar.
    - Açıklama: Mevcut çoğaltmanın, bulma ve yük devretme için 1 dakikalık ek yük varsayılarak RTO'su 10 dakikayı aşıyor. İlgili sunucu örneğindeki performans sorunlarını hemen araştırmanız gerekir.
    - Görüntülenecek metin: RTO Aşıldı!
Aşağıdaki belirtimleri kullanarak ikinci bir ilke tabanlı yönetim ilkesi oluşturun:
- Genel sayfa:
  - İsim: CustomAvailabilityDatabaseRPO
  - Koşul kontrolü: RPO
  - Hedeflere karşı: IsPrimaryReplica AvailabilityGroup içindeki her DatabaseReplicaState
  - Değerlendirme modu: Zamanlamaya göre
  - Zamanlama: ToplayıcıZamanlama_Her_30Dakika
  - Etkin: seçili
- Açıklama sayfası:
  - Kategori: Kullanılabilirlik veritabanı uyarıları
  - Açıklama: Kullanılabilirlik veritabanı 1 saatlik RPO'nuzu aştı. Kullanılabilirlik çoğaltmalarında performans sorunlarını hemen araştırmanız gerekir.
  - Görüntülenecek metin: RPO Aşıldı!

Tamamladığınızda, ilke değerlendirme zamanlamalarının her biri için birer tane olmak üzere iki yeni SQL Server Ajansı işi oluşturulur. Bu görevlerin adı syspolicy_check_schedule ile başlamalıdır.

Değerlendirme sonuçlarını incelemek için iş geçmişini görüntüleyebilirsiniz. Değerlendirme hataları, Windows uygulama günlüğüne (Olay Görüntüleyicisi'nde) Olay Kimliği 34052 ile de kaydedilir. AYRıCA SQL Server Aracısı'nı ilke hatalarıyla ilgili uyarılar gönderecek şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz. İlke Yöneticilerine İlke Hatalarını Bildirmek için Uyarıları Yapılandırma.

Performans sorunlarını giderme senaryoları

Aşağıdaki tabloda performansla ilgili yaygın sorun giderme senaryoları listeleniyor.

Senaryo	Açıklama
Sorun giderme: Kullanılabilirlik grubu RTO'yu aştı	Veri kaybı olmadan otomatik yük devretme veya planlı el ile yük devretme işleminden sonra yük devretme süresi RTO'nuzu aşıyor. Öte yandan, zaman uyumlu işleme ikincil çoğaltmasının (otomatik yük devretme iş ortağı gibi) yük devretme süresini tahmin ettiğinizde RTO'nuzu aştığını fark edebilirsiniz.
Sorun giderme: Kullanılabilirlik grubu RPO'yu aştı	Zorlamalı el ile yük devretme gerçekleştirdikten sonra, veri kaybınız RPO'nuzdan daha fazla olur. Veya zaman uyumsuz-commit ikincil replikasının olası veri kaybını hesapladığınızda, bunun RPO'nuzu aştığını görebilirsiniz.
Sorun giderme: Birincil çoğaltmadaki değişiklikler ikincil çoğaltmaya yansıtılmıyor	İstemci uygulaması birincil çoğaltmadaki bir güncelleştirmeyi başarıyla tamamlar, ancak ikincil çoğaltmayı sorgulamak değişikliğin yansıtılamadığını gösterir.

Yararlı genişletilmiş olaylar

Aşağıdaki genişletilmiş olaylar, Eşitleme durumundaki çoğaltma sorunlarını giderirken yararlıdır.

Olay Adı	Kategori	Kanal	Kullanılabilirlik yedeği
`redo_caught_up`	işlemler	Hata ayıklama	İkincil
`redo_worker_entry`	işlemler	Hata ayıklama	İkincil
`hadr_transport_dump_message`	`alwayson`	Hata ayıklama	Birincil
`hadr_worker_pool_task`	`alwayson`	Hata ayıklama	Birincil
`hadr_dump_primary_progress`	`alwayson`	Hata ayıklama	Birincil
`hadr_dump_log_progress`	`alwayson`	Hata ayıklama	Birincil
`hadr_undo_of_redo_log_scan`	`alwayson`	Analitik	İkincil

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-10-10