Monitorování výkonu skupin dostupnosti AlwaysOn

platí pro:SQL Server

Aspekt výkonu skupin dostupnosti AlwaysOn je zásadní pro zachování smlouvy o úrovni služeb (SLA) pro důležité databáze. Pochopení toho, jak skupiny dostupnosti přenášejí protokoly do sekundárních replik, vám pomůže odhadnout cíl doby obnovení (RTO) a cíl bodu obnovení (RPO) vaší implementace dostupnosti a identifikovat úzká místa v případě špatného výkonu skupin dostupnosti nebo replik. Tento článek popisuje proces synchronizace, ukazuje, jak vypočítat některé klíčové metriky a poskytuje odkazy na některé běžné scénáře řešení potíží s výkonem.

Proces synchronizace dat

Pokud chcete odhadnout dobu úplné synchronizace a identifikovat kritické body, musíte pochopit proces synchronizace. Kritické body výkonu můžou být kdekoli v procesu a vyhledání kritického bodu vám může pomoct prozkoumat hlubší informace o hlubších problémech. Následující obrázek a tabulka znázorňují proces synchronizace dat:

Posloupnost	Popis kroku	Komentáře	Užitečné metriky
1	Generování protokolů	Data protokolu jsou zapsána na disk. Tento záznam musí být replikován do sekundárních kopií. Záznamy protokolu vstupují do fronty pro odesílání.	SQL Server:Bajty protokolů databáze > jsou vyprázdněné za sekundu
2	Zachytávání	Záznamy pro každou databázi jsou zachyceny a odeslány do příslušné partnerské fronty (jedna na každou dvojici databáze a její repliky). Tento proces zachytávání běží nepřetržitě, pokud je replika dostupnosti připojená a z jakéhokoli důvodu se přesun dat pozastaví a pár repliky databáze se zobrazuje jako synchronizovaný nebo synchronizovaný. Pokud proces zachytávání nedokáže dostatečně rychle naskenovat a zařadit zprávy do fronty, začne se hromadit fronta odesílání protokolů.	SQL Server: Replika > dostupnosti Bajty odeslané do repliky/s, což je agregace součtu všech databázových zpráv zařazených do fronty pro tuto repliku dostupnosti. log_send_queue_size (KB) a log_bytes_send_rate (KB/s) na primární replice.
3	Poslat	Zprávy v každé frontě repliky databáze se odřazují a jsou odeslány po síti do příslušné sekundární repliky.	SQL Server: Replika dostupnosti > Bajty odeslané na přenos/sekundu
4	Přijmout a uložit do mezipaměti	Každá sekundární replika zprávu přijme a ukládá do mezipaměti.	Čítač výkonu SQL Server: Replika dostupnosti > Bajty protokolu přijaté za sekundu
5	Ztvrdnout	Protokol se vyprázdní na sekundární replice pro posílení zabezpečení. Po vyprázdnění protokolu se potvrzení odešle zpět k primární replice. Jakmile je protokol zpevněn, ztrátě dat se vyhnete.	Čítač výkonu SQL Server:Database > bajty protokolu zapsané za sekundu Typ čekání HADR_LOGCAPTURE_SYNC
6	Předělat	Proveďte znovu operaci pro vyprázdnění stránek na sekundární replice. Stránky se uchovávají v přepisovací frontě, protože čekají na přepis.	SQL Server:Replika databáze > přepracované bajty za sekundu redo_queue_size (KB) a redo_rate. Typ čekání REDO_SYNC

Brány řízení proudění

Skupiny dostupnosti jsou navrženy s kontrolními bránami toku na primární replice, aby se zabránilo nadměrné spotřebě prostředků, jako jsou síťové a paměťové prostředky, na všech replikách skupin dostupnosti. Tyto brány řízení toku nemají vliv na stav synchronizace dostupnostních replik, ale mohou ovlivnit celkový výkon vašich dostupnostních databází, včetně cíle bodu obnovení (RPO).

Po zachycení protokolů na primární replice se na ně vztahují dvě úrovně řízení toku. Po dosažení prahové hodnoty zprávy kterékoliv brány se zprávy protokolu již neposílají do konkrétní repliky nebo pro konkrétní databázi. Zprávy lze odeslat po přijetí zpráv potvrzení pro odeslané zprávy, aby se počet odeslaných zpráv dostal pod prahovou hodnotu.

Kromě bran řízení toku je další faktor, který může zabránit odesílání zpráv protokolu. Synchronizace replik zajišťuje, že se zprávy odesílají a aplikují v pořadí podle čísla protokolu (LSN). Před odesláním zprávy je její LSN také zkontrolováno oproti nejnižšímu potvrzenému číslu LSN, aby bylo zajištěno, že je menší než jedna z prahových hodnot, což závisí na typu zprávy. Pokud je mezera mezi dvěma čísly LSN větší než prahová hodnota, zprávy se neodesílají. Jakmile mezera opět klesne pod prahovou hodnotu, zprávy se odešlou.

SQL Server 2022 (16.x) zvyšuje limity na počet zpráv, které každá brána umožňuje. Pomocí příznaku trasování 12310 je zvýšený limit dostupný také pro následující verze SQL Serveru: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.

Následující tabulka porovnává omezení zpráv:

nové limity

Pro verze SQL Serveru, které umožňují příznak trasování 12310, konkrétně SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 a novější, vezměte v úvahu následující omezení:

Úroveň	Počet bran	Počet zpráv	Užitečné metriky
Přeprava	1 na dostupnostní repliku	16384	Rozšířená událost database_transport_flow_control_action
Databáze	1 pro databázi dostupnosti	7168	DBMIRROR_SEND Rozšířená událost hadron_database_flow_control_action

Staré limity

Nepodporované verze SQL Serveru nebo podporované verze SQL Serveru (počínaje verzí SQL Server 2019 CU9, SQL Server 2017 CU18 a SQL Server 2016 SP1 CU16), které nemají povolený příznak trasování 12310, viz následující omezení:

Úroveň	Počet bran	Počet zpráv	Užitečné metriky
Přeprava	1 na dostupnostní repliku	8192	Rozšířená událost database_transport_flow_control_action
Databáze	1 pro databázi dostupnosti	1792 (x64) 1600 (x86)	DBMIRROR_SEND Rozšířená událost hadron_database_flow_control_action

Dva užitečné čítače výkonu, SQL Server:Replika dostupnosti > řízení toku/s a SQL Server:Replika dostupnosti > Čas řízení toku (ms/s), ukazují v poslední sekundě, kolikrát bylo řízení toku aktivováno a kolik času bylo stráveno čekáním na řízení toku. Delší čekací doba u řízení toku znamená vyšší RPO. Další informace o typech problémů, které můžou způsobit vysokou dobu čekání na řízení průtoku, najdete v tématu Řešení potíží: Potenciální ztráta dat u replik skupiny dostupnosti s asynchronním potvrzením.

Odhad doby převzetí služeb při selhání (RTO)

RTO ve vašem SLA závisí na době převzetí služeb při selhání implementace Always On v každém okamžiku, což lze vyjádřit následujícím vzorcem:

Důležitý

Pokud skupina dostupnosti obsahuje více než jednu databázi dostupnosti, stane se z databáze dostupnosti s nejvyšší hodnotou Tfailover limitující hodnota pro dodržování předpisů RTO.

Doba detekce selhání, Tdetection, je doba, která trvá, než systém zjistí selhání. Tentokrát závisí na nastavení na úrovni clusteru a ne na jednotlivých replikách dostupnosti. V závislosti na stavu automatického převzetí služeb při selhání, který je nakonfigurovaný, se dá převzetí služeb při selhání aktivovat jako okamžitá odpověď na kritickou vnitřní chybu SQL Serveru, jako jsou osamocené spinlocky. V tomto případě může být detekce stejně rychlá jako odeslání zprávy o chybě sp_server_diagnostics do clusteru pro převzetí služeb při selhání Windows Serveru (WSFC). Výchozí interval je 1/3 z časového limitu kontroly stavu. Převzetí služeb při selhání se může aktivovat také při dosažení časového limitu, například při vypršení časového limitu kontroly stavu clusteru (ve výchozím nastavení 30 sekund) nebo při vypršení platnosti pronájmu mezi knihovnou DLL prostředků a instancí SQL Serveru (ve výchozím nastavení 20 sekund). V tomto případě je doba detekce stejně dlouhá jako interval časového limitu. Pro více informací si přečtěte část Flexibilní zásady převzetí služeb při selhání pro automatické převzetí služeb při selhání dostupnostní skupiny (SQL Server).

Jediné, co musí sekundární replika udělat, aby byla připravena na převzetí při selhání, je dohnat zpracování až na konec protokolu. Čas opakování Tredo se vypočítá pomocí následujícího vzorce:

kde redo_queue je hodnota v redo_queue_size a redo_rate je hodnota v redo_rate.

Režijní doba převzetí, Toverhead, zahrnuje dobu potřebnou k převzetí clusteru WSFC při selhání a zprovoznění databází. Tento čas je obvykle krátký a konstantní.

Odhad potenciální ztráty dat (RPO)

Cíl bodu obnovení ve vašem SLA závisí na možné ztrátě dat vaší implementace Always On v daném okamžiku. Tuto možnou ztrátu dat lze vyjádřit v následujícím vzorci:

kde log_send_queue je hodnota log_send_queue_size a rychlost generování protokolů je hodnota SQL Server:Database > bajtů protokolu vyprázdněných za sekundu.

Varování

Pokud skupina dostupnosti obsahuje více než jednu databázi dostupnosti, pak se databáze dostupnosti s nejvyšší Tdata_loss stane mezní hodnotou k dodržení RPO.

Fronta odesílání protokolu představuje všechna data, která je možné ztratit při závažném selhání. Na první pohled je zajímavé, že se místo rychlosti odesílání protokolů používá rychlost generování protokolů (viz log_send_rate). Mějte ale na paměti, že použití rychlosti odesílání logů vám dává čas k synchronizaci, zatímco bod obnovení (RPO) měří ztrátu dat na základě toho, jak rychle se generuje, ne na rychlosti synchronizace.

Jednodušší způsob odhadu Tdata_loss je použití last_commit_time. Dynamické zobrazení managementu (DMV) na primární replice uvádí tuto hodnotu pro všechny repliky. Můžete vypočítat rozdíl mezi hodnotou primární repliky a hodnotou sekundární repliky a odhadnout, jak rychle sekudární replika dohání primární repliku. Jak jsme uvedli dříve, tento výpočet vám neřekne potenciální ztrátu dat na základě toho, jak rychle se protokol vygeneruje, ale mělo by se jednat o blízkou aproximaci.

Odhad RTO a RPO pomocí řídicího panelu SSMS

Ve skupinách dostupnosti Always On jsou hodnoty RTO a RPO počítány a zobrazeny pro databáze hostované na sekundárních replikách. Na řídicím panelu SQL Server Management Stuiod (SSMS) se na primární replice seskupí rto a cíl bodu obnovení (RPO) sekundární replikou.

Pokud chcete zobrazit plánovanou dobu obnovení a cíl bodu obnovení na řídicím panelu, proveďte následující kroky:

1. V aplikaci SQL Server Management Studio rozbalte uzel Always On Vysoká dostupnost, klikněte pravým tlačítkem na název skupiny dostupnosti a vyberte možnost Zobrazit řídicí panel.

2. Vyberte Přidat nebo Odebrat Sloupce na kartě Seskupovat Podle. Zkontrolujte Odhadovanou Dobu Obnovení (sekundy) [RTO] a Odhadovanou Ztrátu Dat (čas) [RPO].

   

Výpočet RTO sekundární databáze

Výpočet doby obnovení určuje, kolik času je potřeba k obnovení sekundární databáze po převedení. Doba převzetí služeb při selhání je obvykle krátká a konstantní. Doba detekce závisí na nastavení na úrovni clusteru a ne na jednotlivých replikách dostupnosti.

Pro sekundární databázi (DB_sec) je výpočet a zobrazení její RTO založen na jejím redo_queue_size a redo_rate:

Kromě rohových případů vzorec pro výpočet RTO sekundární databáze je:

Výpočet RPO sekundární databáze

Pro sekundární databázi (DB_sec) je výpočet a zobrazení cíle bodu obnovení založen na jeho is_failover_ready, last_commit_time a hodnotách DB_pri jeho korelované primární databáze (last_commit_time). Pokud je hodnota DB_sec.is_failover_ready rovna 1, data mezi primárním a sekundárními se synchronizují a při převzetí služeb při selhání nedojde ke ztrátě dat. Pokud je však tato hodnota 0, je mezi last_commit_time na primární databázi a last_commit_time na sekundární databázi mezera.

U primární databáze last_commit_time je čas, kdy byla potvrzena nejnovější transakce. U sekundární databáze je last_commit_time nejnovější čas zápisu transakce z primární databáze, která byla úspěšně zabezpečena i v sekundární databázi. Toto číslo je stejné pro primární i sekundární databázi. Mezera mezi těmito dvěma hodnotami je však časový interval, ve kterém nebyly nevyřízené transakce v sekundární databázi potvrzeny a v případě selhání může dojít ke ztrátě.

Metriky výkonu používané ve vzorcích RTO/RPO

• redo_queue_size (KB): Velikost fronty opakování používané v RTO je velikost transakčních protokolů mezi jeho last_received_lsn a last_redone_lsn. Hodnota last_received_lsn je ID bloku protokolu identifikující bod, do kterého byly přijaty všechny bloky protokolu sekundární replikou, která je hostitelem této sekundární databáze. Hodnota last_redone_lsn je logické pořadové číslo posledního záznamu protokolu, který byl zopakován na sekundární databázi. Na základě těchto dvou hodnot můžeme najít ID počátečního bloku protokolu (last_received_lsn) a koncového bloku protokolu (last_redone_lsn). Mezera mezi těmito dvěma bloky protokolu pak může představovat, kolik bloků transakčního protokolu ještě není znovu provedeno. Měří se v kilobajtech (KB).

• redo_rate (KB/s): Používá se při výpočtu RTO, jedná se o kumulativní hodnotu, která ukazuje, kolik transakčního protokolu (KB) bylo znovu provedeno nebo přehráno v sekundární databázi za sekundu.

• last_commit_time (datetime): Používá se v RPO, tato hodnota má jiný význam mezi primární a sekundární databází. U primární databáze je čas, last_commit_time kdy byla potvrzena nejnovější transakce. U sekundární databáze last_commit_time je nejnovější potvrzení transakce v primární databázi, která byla úspěšně posílena i v sekundární databázi. Vzhledem k tomu, že tato hodnota na sekundárním serveru by měla být synchronizována se stejnou hodnotou na primárním serveru, všechny mezery mezi těmito dvěma hodnotami jsou odhadem ztráty dat (RPO).

Odhad RTO a RPO pomocí zobrazení dynamické správy

Je možné dotazovat zobrazení dynamické správy sys.dm_hadr_database_replica_states a sys.dm_hadr_database_replica_cluster_states k odhadu RPO a RTO databáze. Následující dotazy vytvářejí uložené procedury, které dělají obě věci.

Poznámka

Nejprve vytvořte a spusťte uloženou proceduru pro odhad RTO, protože hodnoty, které vytváří, jsou nezbytné ke spuštění uložené procedury pro odhad RPO.

Vytvoření uložené procedury pro odhad RTO

1. Na cílové sekundární replice vytvořte uloženou proceduru proc_calculate_RTO. Pokud už tato uložená procedura existuje, nejprve ji odstraňte a pak ji znovu vytvořte.

   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. Spusťte proc_calculate_RTO s názvem cílové sekundární databáze:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. Výstup zobrazí hodnotu RTO cílové sekundární databáze repliky. Uložte group_id, replica_ida group_database_id pro použití s uloženou procedurou odhadu bodu obnovení.

   Ukázkový výstup:

   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
   

Vytvoření uložené procedury pro odhad RPO (cíle bodu obnovení)

1. Na primární replice vytvořte uloženou proceduru proc_calculate_RPO. Pokud už existuje, nejprve ho zahoďte a vytvořte ho znovu.

   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. Spusťte proc_calculate_RPO s group_id, replica_id a group_database_id pro cílovou sekundární databázi.

   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. Výstup zobrazí hodnotu RPO pro sekundární repliku cílové databáze.

Monitorování RTO a RPO

Tato část ukazuje, jak monitorovat skupiny dostupnosti pro metriky RTO a RPO. Tato ukázka je podobná kurzu grafického uživatelského rozhraní v Modelu stavu AlwaysOn, část 2: Rozšíření modelu stavu.

Prvky doby převzetí služeb při selhání a potenciálních výpočtů ztráty dat v odhadu doby převzetí služeb při selhání (RTO) a odhad potenciální ztráty dat (RPO) jsou pohodlně poskytovány jako metriky výkonu v oblasti správy zásad Stav repliky databáze. Další informace najdete v tématu Zobrazení aspektů správy na základě zásad na objektu SQL Serveru. Tyto dvě metriky můžete sledovat podle pravidelného harmonogramu a být upozorněni, když metriky překračují vaši dobu obnovy (RTO) a cíl bodu obnovy (RPO).

Ukázkové skripty vytvářejí dvě systémové zásady, které se spouštějí podle příslušných plánů, s následujícími vlastnostmi:

• Zásada RTO, která selže, když odhadovaná doba převzetí služeb při selhání překročí 10 minut, se vyhodnotí každých 5 minut.

• Zásada RPO, která selže, když odhadovaná ztráta dat překročí 1 hodinu, se vyhodnocuje každých 30 minut.

• Dvě zásady mají shodnou konfiguraci na všech replikách dostupnosti.

• Zásady se vyhodnocují na všech serverech, ale pouze u skupin dostupnosti, kde je místní replika primární replikou. Pokud replika místní dostupnosti není primární replikou, zásady nejsou vyhodnocovány.

• Selhání zásad se pohodlně zobrazují na řídicím panelu AlwaysOn, když je zobrazíte na primární replice.

Pokud chcete vytvořit zásady, postupujte podle těchto pokynů ve všech instancích serveru, které se účastní skupiny dostupnosti:

1. Pokud ještě není spuštěná, spusťte službu agenta SQL Serveru.

2. V SQL Server Management Studio v nabídce Nástroje vyberte Možnosti.

3. Na kartě SQL Server Always On vyberte Povolit zásady Always On definované uživatelem a vyberte OK.

   Toto nastavení umožňuje zobrazit správně nakonfigurované vlastní zásady na řídicím panelu AlwaysOn.

4. Pomocí následujících specifikací vytvořte podmínku správy založenou na zásadách:

   • Název: RTO
   • Facet: Stav repliky databáze
   • pole: Add(@EstimatedRecoveryTime, 60)
   • operátor: <=
   • hodnota: 600

   Tato podmínka selže, když potenciální doba převzetí služeb při selhání překročí 10 minut, včetně 60sekundové režie pro detekci selhání i převzetí služeb při selhání.

5. Vytvořte druhou podmínku správy založenou na zásadách s využitím následujících specifikací:

   • Název: RPO
   • Facet: Stav repliky databáze
   • pole: @EstimatedDataLoss
   • operátor: <=
   • hodnota: 3600

   Tato podmínka selže, když potenciální ztráta dat překročí 1 hodinu.

6. Vytvořte třetí podmínku správy založenou na zásadách s využitím následujících specifikací:

   • Název: IsPrimaryReplica
   • Aspekt: Skupina dostupnosti
   • pole: @LocalReplicaRole
   • Operátor: =
   • hodnota: Primary

   Tato podmínka zkontroluje, jestli je replika místní dostupnosti pro danou skupinu dostupnosti primární replikou.

7. Pomocí následujících specifikací vytvořte zásady správy založené na zásadách:

   • Obecná stránka:

     • Název: CustomSecondaryDatabaseRTO

     • Zkontrolujte podmínku: RTO

     • proti cílům: Každý stav repliky databáze v IsPrimaryReplica AvailabilityGroup

       Toto nastavení zajistí, že se politika vyhodnotí jenom u skupin dostupnosti, pro které je replika místní dostupnosti primární replikou.

       • režim vyhodnocení: Podle plánu

       • Plán: CollectorSchedule_Every_5min

       • Povoleno: vybráno

   • Popis stránka:

     • Kategorie: Upozornění databáze dostupnosti

       Toto nastavení umožňuje zobrazit výsledky vyhodnocení zásad na řídicím panelu AlwaysOn.

       • Popis: Aktuální replika má RTO, které překračuje 10 minut, při předpokladu režijní rezervy 1 minuty pro zjišťování a převzetí služeb při selhání. Měli byste okamžitě prozkoumat problémy s výkonem na příslušné instanci serveru.

       • Text k zobrazení: RTO bylo překročeno!

8. Pomocí následujících specifikací vytvořte druhou zásadu správy založenou na zásadách .

   • Obecná stránka:

     • Název: CustomAvailabilityDatabaseRPO
     • Zkontrolujte podmínku: RPO
     • proti cílům: Každý stav repliky databáze v IsPrimaryReplica AvailabilityGroup
     • režim vyhodnocení: Podle plánu
     • Plán: CollectorSchedule_Every_30min
     • Povoleno: vybráno

   • Popis stránka:

     • Kategorie: Upozornění databáze dostupnosti

     • Popis: Databáze dostupnosti překročila váš cíl bodu obnovení (RPO), který je 1 hodina. Měli byste okamžitě analyzovat problémy s výkonem na replikách dostupnosti.

     • Text k zobrazení: RPO byl překročen!

Po dokončení se vytvoří dvě nové úlohy agenta SQL Serveru, jednu pro každý plán vyhodnocení zásad. Tyto úlohy by měly mít názvy začínající syspolicy_check_schedule.

Historii úloh můžete zobrazit a zkontrolovat výsledky vyhodnocení. Chyby vyhodnocení se zaznamenávají také v protokolu aplikací systému Windows (v Prohlížeči událostí) s ID události 34052. Agenta SQL Serveru můžete také nakonfigurovat tak, aby odesílala upozornění na selhání zásad. Další informace najdete v tématu Konfigurace výstrah pro upozornění správců zásad na selhání zásad.

Scénáře řešení potíží s výkonem

Následující tabulka uvádí běžné scénáře řešení potíží souvisejících s výkonem.

Scénář	Popis
Řešení potíží: Skupina dostupnosti překročila RTO	Po automatickém převzetí služeb nebo plánovaném ručním převzetí bez ztráty dat přesahuje doba převzetí váš RTO. Nebo když odhadnete dobu převzetí služeb při selhání sekundární repliky se synchronním potvrzením (například partnera s automatickým převzetím služeb při selhání), zjistíte, že překračuje vaše RTO.
Řešení potíží: Skupina dostupnosti překročila cílovou hodnotu pro bod obnovy	Po provedení vynuceného ručního přepnutí při selhání je ztráta dat větší než vaše plánovaná hodnota RPO. Nebo když při výpočtu potenciální ztráty dat sekundární repliky asynchronního potvrzení zjistíte, že překračuje váš cíl bodu obnovení (RPO).
Řešení potíží: Změny v primární replice se neprojeví na sekundární replice	Klientská aplikace úspěšně dokončí aktualizaci primární repliky, ale dotazování sekundární repliky ukazuje, že se změna neprojeví.

Užitečné rozšířené události

Následující rozšířené události jsou užitečné při odstraňování potíží s replikami ve stavu synchronizující.

Název události	Kategorie	Kanál	Replika dostupnosti
redo_caught_up	transakce	Ladění	Sekundární
redo_worker_entry	transakce	Ladění	Sekundární
hadr_transport_dump_message	alwayson	Ladění	Primární
hadr_worker_pool_task	alwayson	Ladění	Primární
hadr_dump_primary_progress	alwayson	Ladění	Primární
hadr_dump_log_progress	alwayson	Ladění	Primární
hadr_undo_of_redo_log_scan	alwayson	Analytický	Sekundární