Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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:Database > bajty logu vyprázdněné/sekundu |
| 2 | Zajmout | Protokoly pro každou databázi se zaznamenávají a odesílají do odpovídající partnerské fronty (jedna pro každou dvojici databáze a repliky). Tento proces zachytávání běží nepřetržitě, pokud je replika dostupnosti připojená, přičemž přesun dat není z jakéhokoli důvodu pozastaven, a pár repliky databáze se zobrazuje jako synchronizující nebo synchronizovaný. Pokud proces zachytávání nedokáže zprávy rychle proskenovat a zařadit do fronty, hromadí se fronta na 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 danou 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 vyřadí z fronty a elektronicky se odešlou do příslušné sekundární repliky. | SQL Serveru: Replika dostupnosti > odeslané bajty do přenosu za 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 > bajtů protokolu vyprázdněných 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í ve frontě opakování, protože čekají na opětovné dokončení. |
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 branami řízení 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 dostupnosti. Tyto brány řízení toku nemají vliv na stav synchronizace dostupnostních replik, ale můžou ovlivnit celkový výkon databází dostupnosti, včetně 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 existuje 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 protokolu je nejprve zkontrolováno její LSN vůči nejnižšímu potvrzenému číslu LSN, aby se zajistilo, že je menší než jedna z prahových hodnot (v závislosti 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 zvyšuje limity počtu 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 počínaje SQL Server 2019 CU9, SQL Server 2017 CU18 a SQL Server 2016 SP1 CU16.
Následující tabulka porovnává omezení zpráv:
SQL Server 2022 a podporované verze SQL Serveru (počínaje SQL Serverem 2019 CU9, SQL Serverem 2017 CU18 a SQL Serverem 2016 SP1 CU16), které používají příznak trasování 12310, vidí 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álosti 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 dlouhou dobu čekání při řízení toku, najdete v tématu Řešení potíží: Skupina dostupnosti překročila cíle bodu obnovení (RPO).
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ách sp_server_diagnostics (Transact-SQL) do clusteru WSFC (výchozí interval je 1/3 časového limitu pro kontrolu stavu). Převzetí služeb při selhání lze také spustit kvůli vypršení časového limitu, například pokud vypršel časový limit kontroly stavu clusteru (ve výchozím nastavení 30 sekund) nebo pokud vypršel pronájem 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).
Jedinou věcí, kterou sekundární replika musí udělat, aby se připravila na převzetí služeb při selhání, je, aby znovu zachytila 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í služeb při selhání, Toverhead, zahrnuje dobu potřebnou k převzetí služeb při selhání clusteru WSFC a převést databáze do režimu online. 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 odeslání protokolu představuje všechna data, která je možné ztratit z závažného selhání. Na první pohled je zvědavé, ž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í protokolu vám poskytuje čas pro synchronizaci. Naopak, RPO (cíl bodu obnovení) měří ztrátu dat podle toho, jak rychle se data generují, nikoli jak rychle se synchronizují.
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ěla by to být úzká aproximace.
Odhad RTO a RPO & pomocí řídicího panelu SSMS
Ve skupinách s vysokou dostupností Always On se pro databáze umístěné na sekundárních replikách vypočítává a zobrazuje RTO a RPO. Na řídicím panelu primární repliky jsou RTO (Cíl obnovy času) a RPO (Cíl bodu obnovení) seskupeny podle sekundární repliky.
Pro zobrazení RTO a RPO na řídicím panelu postupujte následovně:
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.
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í 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í bodu obnovení založen na parametrech jako jeho `is_failover_ready`, `last_commit_time` a odpovídajícím `last_commit_time` primární databáze (DB_pri). Pokud sekundární database.is_failover_ready = 1, pak se daa synchronizuje 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 v primární databázi a last_commit_time v sekundární databázi mezera.
U primární databáze je last_commit_time čas, kdy byla potvrzena nejnovější transakce. U sekundární databáze je last_commit_time nejnovějším časem potvrzení transakce v primární databázi, která byla úspěšně posílena i v sekundární databázi. Toto číslo by mělo být stejné pro primární i sekundární databázi. Mezera mezi těmito dvěma hodnotami představuje časový úsek, během něhož čekající transakce nebyly zapsány v sekundární databázi a v případě přepnutí by došlo ke ztrátě.
Čítače výkonu používané ve vzorcích RTO/RPO
- redo_queue_size (KB) [použité v RTO]: Velikost fronty zápisu je úsek transakčních protokolů mezi last_received_lsn a last_redone_lsn. 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. Last_redone_lsn je pořadové číslo protokolu posledního záznamu protokolu, který byl opětovně proveden v 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 dosud nebylo znovu provedeno. Měří se v kilobajtech (KB).
- redo_rate (KB/s) [použité v RTO]: Akumulovaná hodnota, která ukazuje, kolik transakčního logu (KB) bylo zapsáno zpět v sekundární databázi v kilobajtech (KB) za sekundu během určitého časového úseku.
- last_commit_time (Datetime) [použité v RPO]: U primární databáze je last_commit_time čas, kdy byla potvrzena poslední transakce. U sekundární databáze je last_commit_time nejnovější čas potvrzení transakce z primární databáze, který byl úspěšně zapsán i do sekundární databáze. 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, aby bylo možné odhadnout cíl bodu obnovení (RPO) a plánovanou dobu obnovení (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
- 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 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
- Spusťte proc_calculate_RTO s názvem cílové sekundární databáze:
exec proc_calculate_RTO @secondary_database_name = N'DB_sec'
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 databázového DB_sec je 0
group_id databáze DB4 je F176DD65-C3EE-4240-BA23-EA615F965C9B
replica_id databáze DB4 je 405554F6-3FDC-4593-A650-2067F5FABFFD
group_database_id databáze DB4 je 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Vytvoření uložené procedury pro odhad RPO (cíle bodu obnovení)
- 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 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
- Spusťte proc_calculate_RPO s group_idcílové sekundární databáze, replica_ida group_database_id.
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'
- 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 výpočtů potenciální ztráty dat v Odhad 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 ve správním aspektu politiky Stav repliky databáze (viz Zobrazení spravovaných aspektů politiky 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 místní replika dostupnosti není primární replikou, zásady se nevyhodnocují.
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 pokynů níže ve všech instancích serveru, které se účastní skupiny dostupnosti:
spusťte službu agenta SQL Serveru, pokud ještě není spuštěná.
V aplikaci SQL Server Management Studio v nabídce Tools klepněte na Možnosti.
Na kartě SQL Server Always On vyberte Povolit uživatelsky definované zásady Always On a klikněte na OK.
Toto nastavení umožňuje zobrazit správně nakonfigurované vlastní zásady na řídicím panelu AlwaysOn.
Pomocí následujících specifikací vytvořte podmínku správy založenou na zásadách:
Název:
RTOfacet: 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 na detekci selhání i převzetí služeb při selhání.
Vytvořte druhou podmínku správy založenou na zásadách s využitím následujících specifikací:
Název:
RPOfacet: stav repliky databáze
pole:
@EstimatedDataLossoperátor: <=
hodnota:
3600
Tato podmínka selže, když potenciální ztráta dat překročí 1 hodinu.
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:
IsPrimaryReplicaAspekt: Skupina dostupnosti
pole:
@LocalReplicaRoleOperátor: =
hodnota:
Primary
Tato podmínka zkontroluje, jestli je replika místní dostupnosti pro danou skupinu dostupnosti primární replikou.
Pomocí následujících specifikací vytvořte zásady správy založené na zásadách:
Obecná stránka:
Název:
CustomSecondaryDatabaseRTOZkontrolujte podmínku:
RTOproti 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!
Pomocí následujících specifikací vytvořte druhou zásadu správy založenou na zásadách .
stránka Obecné:
Název:
CustomAvailabilityDatabaseRPOZkontroluj podmínku:
RPOproti cílům: Every DatabaseReplicaState v IsPrimaryReplica AvailabilityGroup
režim vyhodnocení: Podle plánu
Plán: CollectorSchedule_Every_30min
Povoleno: vybrané
Popis stránky
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, které začínají na 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, které správcům zásad oznámí 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 |
|---|---|---|---|
| zopakovat_dohnáno | transakce | Ladění | Sekundární |
| opětovný_vstup_pracovníka | transakce | Ladění | Sekundární |
| hadr_transport_dump_message | alwayson |
Ladicí | Primární |
| hadr_worker_pool_task | alwayson |
Ladění | Primární |
| hadr_primární_průběh_výpisu | alwayson |
Ladění | Primární |
| hadr_dump_log_progress | alwayson |
Ladění | Primární |
| hadr_undo_of_redo_log_scan | alwayson |
Analytický | Sekundární |