Always On rendelkezésre állási csoportok teljesítményének figyelése

A következőkre vonatkozik:SQL Server

Az Always On rendelkezésre állási csoportok teljesítménybeli aspektusa elengedhetetlen a kritikus fontosságú adatbázisok szolgáltatásiszint-szerződésének (SLA) fenntartásához. Annak megértése, hogy a rendelkezésre állási csoportok hogyan küldik el a naplókat a másodlagos replikákra, segíthet megbecsülni a rendelkezésre állási megvalósítás helyreállítási időkorlátját (RTO) és helyreállításipont-célkitűzését (RPO), és azonosíthatja a rosszul teljesítő rendelkezésre állási csoportok vagy replikák szűk keresztmetszeteit. Ez a cikk ismerteti a szinkronizálási folyamatot, bemutatja, hogyan számíthatja ki a főbb metrikák némelyikét, és hivatkozásokat biztosít néhány gyakori teljesítmény-hibaelhárítási forgatókönyvre.

Adatszinkronizálási folyamat

A teljes szinkronizálási idő becsléséhez és a szűk keresztmetszet azonosításához ismernie kell a szinkronizálási folyamatot. A teljesítmény szűk keresztmetszete bárhol előfordulhat a folyamatban, és a szűk keresztmetszet megtalálása segíthet mélyebben feltárni a mögöttes problémákat. Az alábbi ábra és táblázat az adatszinkronizálási folyamatot szemlélteti:

Következés	Lépés leírása	Megjegyzések	Hasznos metrikák
1	Naplógenerálás	A rendszer kiüríti a naplóadatokat a lemezre. Ezt a naplót a másodlagos replikákra kell replikálni. A naplórekordok a küldési üzenetsorba kerülnek.	SQL Server:Adatbázisnapló > bájtok kiürítése másodpercenként
2	Capture	Az egyes adatbázisok naplói rögzítve lesznek, és a megfelelő partnersorba kerülnek (adatbázis-replika páronként egyet). Ez a rögzítési folyamat folyamatosan fut, amíg a rendelkezésre állási replika csatlakoztatva van, és az adatmozgás nincs felfüggesztve semmilyen okból, valamint az adatbázis-replika pár szinkronizálási vagy szinkronizált állapotban van. Ha a rögzítési folyamat nem tudja elég gyorsan beolvasni és sorba állítani az üzeneteket, a naplóküldési üzenetsor feldúsul.	SQL Server:Rendelkezésre állási replika > Másolatnak küldött bájtok/másodperc, amely az adott rendelkezésre állási replikához várólistára helyezett összes adatbázis-üzenet összesített összege. log_send_queue_size (KB) és log_bytes_send_rate (KB/s) az elsődleges replikán.
3	Küld	Az egyes adatbázis-replika üzenetsorok üzenetei ki lesznek véve, és a megfelelő másodlagos replikára kerülnek a kapcsolaton keresztül.	>
4	Fogadás és gyorsítótárazás	Minden másodlagos replika megkapja és gyorsítótárazza az üzenetet.	Teljesítményszámláló SQL Server:Rendelkezésre állási replika > Naplóbájtok fogadva/másodperc
5	Megkeményedik	A napló kiürítésre kerül a másodlagos replikán a tartósság érdekében. A napló kiürítése után a rendszer nyugtát küld az elsődleges replikának. A napló megszilárdításra kerülése után az adatvesztés elkerülhető.	Teljesítményszámláló SQL Server:Database > Log Bytes Flushed/sec Várakozás típusa HADR_LOGCAPTURE_SYNC
6	Újra megcsinál	A másodlagos replikán újból kell írni az ürített lapokat. A lapok az ismétlési sorban maradnak, miközben várnak az újra feldolgozásra.	SQL Server:Database Replica > Újrakezdett bájt/mp redo_queue_size (KB) és redo_rate. Várakozási típus: REDO_SYNC

Áramlásvezérlő kapuk

A rendelkezésre állási csoportokat úgy tervezték, hogy az elsődleges replikákon elhelyezett áramvezérlő kapuk segítségével elkerüljék a túlzott erőforrás-felhasználást, mint például a hálózati és memóriaerőforrások túlzott használatát, az összes rendelkezésre állási replikán. Ezek a folyamatvezérlő kapuk nem befolyásolják a rendelkezésre állási replikák szinkronizálási állapotát, de hatással lehetnek a rendelkezésre állási adatbázisok általános teljesítményére, beleértve az RPO-t is.

Miután a naplókat rögzítették az elsődleges replikán, két adatáramlás-vezérlési szintnek vannak alávetve. Miután elérte bármelyik kapu üzenetküszöbét, a rendszer többé nem küld naplóüzeneteket egy adott replikának vagy egy adott adatbázisnak. Az üzenetek akkor küldhetők el, ha nyugtázási üzenetek érkeznek az elküldött üzenetekhez, hogy az elküldött üzenetek száma a küszöbérték alá csökkenjen.

A folyamatvezérlési kapuk mellett van egy másik tényező is, amely megakadályozhatja a naplóüzenetek küldését. A replikák szinkronizálása biztosítja az üzenetek küldését és alkalmazását a naplóütemezési számok (LSN) sorrendjében. A naplóüzenet elküldése előtt az LSN-t a legalacsonyabb elismert LSN-számmal is összehasonlítjuk, hogy megbizonyosodjunk róla: kisebb-e a küszöbértékek egyikénél (ami az üzenet típusától függ). Ha a két LSN-szám közötti különbség nagyobb, mint a küszöbérték, a rendszer nem küldi el az üzeneteket. Ha a rés ismét a küszöbérték alatt van, a rendszer elküldi az üzeneteket.

Az SQL Server 2022 (16.x) növeli az egyes kapuk által megengedett üzenetek számát. A következő kiadásoktól kezdve használja a 12310-es nyomkövetési zászlót az indításnál a korlát növeléséhez: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18 és SQL Server 2016 (13.x) SP1 CU16. Ezt a nyomkövetési jelzőt nem lehet a DBCC TRACEON-vel használni.

Az alábbi táblázat az üzenetkorlátokat hasonlítja össze:

Új korlátok

Az SQL Server 12310 nyomkövetési jelzőt engedélyező verziói, nevezetesen az SQL Server 2022 (16.x), az SQL Server 2019 (15.x) CU9, az SQL Server 2017 (14.x) CU18, az SQL Server 2016 (13.x) SP1 CU16 és újabb verziók esetében lásd a következő korlátozásokat:

Szint	Kapuk száma	Üzenetek száma	Hasznos metrikák
Szállítás	1 replikánként a rendelkezésre állás szerint	16384	Bővített esemény database_transport_flow_control_action
Adatbázis	Rendelkezésre állási adatbázisonként 1	7168	DBMIRROR_SEND Bővített esemény hadron_database_flow_control_action

régi korlátok

Az SQL Server nem támogatott verziói vagy az SQL Server támogatott verziói (kezdve az SQL Server 2019 CU9-zel, az SQL Server 2017 CU18-val és az SQL Server 2016 SP1 CU16-tal), amelyeknél a 12310 trace flag nincs engedélyezve, tekintse meg a következő korlátozásokat:

Szint	Kapuk száma	Üzenetek száma	Hasznos metrikák
Szállítás	1 replikánként a rendelkezésre állás szerint	8192	Bővített esemény database_transport_flow_control_action
Adatbázis	Rendelkezésre állási adatbázisonként 1	1792 (x64) 1600 (x86)	DBMIRROR_SEND Bővített esemény hadron_database_flow_control_action

Két hasznos teljesítményszámláló, SQL Server:Rendelkezésre állási replika > Folyamatvezérlés/mp és SQL Server:Rendelkezésre állási replika > folyamatvezérlési idő (ms/mp), az utolsó másodpercben megmutatja, hogy hányszor aktiválták a folyamatvezérlést, és mennyi időt töltöttek a folyamatvezérlésre való várakozással. A folyamatvezérlésnél a hosszabb várakozási idő magasabb RPO-t eredményez. Az olyan problémák típusairól, amelyek nagy várakozási időt okozhatnak a folyamatvezérlőn, tekintse meg a hibaelhárítást: Lehetséges adatvesztés aszinkron véglegesítési rendelkezésre állási csoport replikákkal.

Átállási idő becslése (RTO)

Az SLA RTO-ja az Always On implementáció feladatátvételi idejétől függ, amely az alábbi képletben fejezhető ki:

Fontos

Ha egy rendelkezésre állási csoport több rendelkezésre állási adatbázist is tartalmaz, akkor az RTO-megfelelőség korlátértéke a legmagasabb rendelkezésre állású adatbázis lesz.

A hibaészlelési idő (Tdetection) az az idő, amely alatt a rendszer észleli a hibát. Ez az idő a fürtszintű beállításoktól függ, és nem az egyes rendelkezésre állási replikáktól. A konfigurált automatikus átkapcsolási feltételtől függően az átkapcsolás azonnali válaszként indítható egy kritikus SQL Server belső hibára, például olyan problémákra, mint az árva spinlockok. Ebben az esetben az észlelés olyan gyors lehet, mint a sp_server_diagnostics hibajelentés elküldése a Windows Server feladatátvevő fürtnek (WSFC). Az alapértelmezett időköz az állapot-ellenőrzési időkorlát 1/3-a. Az átkapcsolás egy időtúllépés miatt is aktiválható. Például, ha a fürt állapot-ellenőrzési időkorlátja lejárt (alapértelmezés szerint 30 másodperc), vagy ha az erőforrás DLL és az SQL Server-példány közötti kölcsönzési idő lejárt (alapértelmezés szerint 20 másodperc). Ebben az esetben az észlelési idő megegyezik az időtúllépési időközzel. További információért lásd: a rendelkezésre állási csoport (SQL Server) automatikus feladatátvételére vonatkozó rugalmas feladatátvételi szabályzat .

A másodlagos replikának csak arra van szüksége, hogy a visszajátszás utolérje a napló végét, hogy fel legyen készülve a feladatátvételre. Az ismétlési idő (Tredo) kiszámítása a következő képlettel történik:

ahol redo_queue a redo_queue_size értéke, redo_rate pedig a redo_rateértéke.

A feladatátvételi többletterhelési idő (Toverhead) magában foglalja a WSFC-fürt feladatátvételéhez és az adatbázisok online állapotba helyezéséhez szükséges időt. Ez az idő általában rövid és állandó.

Lehetséges adatvesztés becslése (RPO)

Az SLA-ban meghatározott RPO attól függ, hogy bármely időpontban mekkora adatveszteség történhet az Always On implementáció során. Ez a lehetséges adatvesztés a következő képletben fejezhető ki:

ahol a log_send_queue a log_send_queue_size értéke, és a naplógenerálási sebesség a SQL Server:Database > Log Bytes Flushed/secértéke.

Figyelmeztetés

Ha egy rendelkezésre állási csoport több rendelkezésre állási adatbázist is tartalmaz, akkor a legmagasabb Tdata_loss rendelkező rendelkezésre állási adatbázis lesz az RPO-megfelelőség korlátértéke.

A naplóküldési üzenetsor azokat az adatokat jelöli, amelyek elveszhetnek egy katasztrofális hibából. Első pillantásra érdekes, hogy a naplógenerálási arányt használja a rendszer a naplóküldési sebesség helyett (lásd log_send_rate). Ne feledje azonban, hogy a naplóküldési sebesség használata csak időt ad a szinkronizálásra, míg az RPO az adatvesztést a létrehozási sebesség alapján méri, nem pedig a szinkronizálási sebesség alapján.

A Tdata_loss becslésének egyszerűbb módja a last_commit_timehasználata. Az elsődleges replika esetében a DMV szerint minden replika számára ezt az értéket jelenti. Az elsődleges replika és a másodlagos replika értéke közötti különbség kiszámításával megbecsülheti, hogy a másodlagos replika naplója milyen gyorsan utoléri az elsődleges replikát. Ahogy korábban már említettem, ez a számítás nem mutatja meg a napló létrehozásának gyorsságán alapuló lehetséges adatvesztést, de közel közelítésnek kell lennie.

RTO és RPO becslése az SSMS-irányítópulttal

Az Always On rendelkezésre állási csoportokban a rendszer kiszámítja és megjeleníti az RTO-t és az RPO-t a másodlagos replikákon üzemeltetett adatbázisokhoz. Az SQL Server Management Stuiod (SSMS) irányítópultján, az elsődleges replikán az RTO és az RPO a másodlagos replika szerint van csoportosítva.

Az RTO és az RPO irányítópulton belüli megtekintéséhez hajtsa végre a következő lépéseket:

1. Az SQL Server Management Studióban bontsa ki az Always On High Availability csomópontot, kattintson a jobb gombbal a rendelkezésre állási csoport nevére, és válassza Irányítópult megjelenítéselehetőséget.

2. Válassza a "Csoportosítás" lap alatt található "Oszlop hozzáadása/eltávolítása" lehetőséget. Ellenőrizze mind a "Becsült helyreállítási idő (másodperc)" [RTO], mind a "Becsült adatvesztés (idő)" [RPO] mezőket.

   

Másodlagos adatbázis RTO-jának kiszámítása

A helyreállítási idő kiszámítása meghatározza, hogy mennyi időre van szükség a másodlagos adatbázis visszaállításához, miután megtörténik egy feladatátvétel. A feladatátvételi idő általában rövid és állandó. Az észlelés ideje a fürtszintű beállításoktól függ, és nem az egyes replikák rendelkezésre állásától.

Egy másodlagos adatbázis (DB_sec) esetében az RTO kiszámítása és megjelenítése a következőken redo_queue_sizeredo_ratealapul:

A sarokeseteket kivéve a másodlagos adatbázis RTO-jának kiszámításához használt képlet a következő:

Másodlagos adatbázis RPO-jának kiszámítása

Egy másodlagos adatbázis (DB_sec) esetében az RPO kiszámítása és megjelenítése a saját , is_failover_readyés a korrelált elsődleges adatbázis (last_commit_time)DB_priértékein last_commit_timealapul. Ha a DB_sec.is_failover_ready értéke 1, akkor az elsődleges és a másodlagos példányok közötti adatok szinkronizálva vannak, és átváltáskor nem történik adatvesztés. Ha azonban ez az 0érték, akkor az elsődleges adatbázis és a last_commit_timelast_commit_time másodlagos adatbázis közötti különbség van.

Az elsődleges adatbázis esetében a last_commit_time legutóbbi tranzakció véglegesítése az időpont. A másodlagos adatbázis esetében az last_commit_time elsődleges adatbázisból származó tranzakció legutóbbi véglegesítési ideje, amelyet a másodlagos adatbázison is sikeresen megerősítettek. Ez a szám az elsődleges és a másodlagos adatbázis esetében is megegyezik. A két érték közötti különbség azonban az az időtartam, amelyben a függőben lévő tranzakciók nem lettek megerősítve a másodlagos adatbázisban, és feladatátvétel esetén elveszhetnek.

Az RTO/RPO-képletekben használt teljesítménymetrikák

• redo_queue_size (KB): Az RTO-ban használt újravégrehajtási várólista méret a tranzakciónaplók méretét az alábbi állapotok között last_received_lsn és last_redone_lsn határozza meg. Az last_received_lsn érték az a naplóblokk azonosítója, amely azonosítja azt a pontot, ahová az összes naplóblokkot a másodlagos adatbázist üzemeltető másodlagos replika fogadta. Az last_redone_lsn érték a másodlagos adatbázisban utoljára újra alkalmazott naplórekord naplósorozat száma. E két érték alapján megtalálhatjuk a kezdő naplóblokk (last_received_lsn) és a záró naplóblokk (last_redone_lsn) azonosítóit. A két naplóblokk közötti térköz azt jelképezi, hogy hány tranzakciónapló-blokkot még nem dolgoztak fel újra. Ez kilobájtban (KB) van mérve.

• redo_rate (KB/s): Az RTO-számításban használatos összegző érték, amely azt mutatja, hogy a tranzakciónapló (KB) mekkora részét adták újra vagy játsszák vissza másodpercenként a másodlagos adatbázisban.

• last_commit_time (datetime): Az RPO-ban használt értéknek más jelentése van az elsődleges és a másodlagos adatbázis között. Az elsődleges adatbázis last_commit_time esetében az az időpont, amikor a legutóbbi tranzakció véglegesítésre került. A másodlagos adatbázis esetében ez last_commit_time a legutóbbi véglegesítés az elsődleges adatbázis tranzakciójára vonatkozóan, amelyet a másodlagos adatbázison is sikeresen megerősítettek. Mivel ezt az értéket a másodlagoson ugyanazzal az értékkel kell szinkronizálni az elsődlegesen, a két érték közötti különbség az adatvesztés becslése (RPO).

RTO és RPO becslése DMV-k használatával

Az adatbázis RPO-jának és RTO-jának becsléséhez lekérdezhető a DMV-sys.dm_hadr_database_replica_states és sys.dm_hadr_database_replica_cluster_states. Az alábbi lekérdezések olyan tárolt eljárásokat hoznak létre, amelyek mindkét dolgot végrehajtják.

Jegyzet

Mindenképpen hozza létre és futtassa a tárolt eljárást az RTO első becsléséhez, mivel az általa előállított értékek szükségesek az RPO becsléséhez használt tárolt eljárás futtatásához.

Tárolt eljárás létrehozása az RTO becsléséhez

1. A másodlagos célreplikán hozzon létre tárolt eljárást proc_calculate_RTO. Ha ez a tárolt eljárás már létezik, először vesse el, majd hozza létre újra.

   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. Hajtsa végre proc_calculate_RTO a másodlagos céladatbázis nevével:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. A kimenet megjeleníti a cél másodlagos replikaadatbázis RTO-értékét. Mentse a group_id, replica_idés a group_database_id értékeket az RPO-becslés tárolt eljárásához való használatra.

   Mintakimenet:

   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
   

Tárolt eljárás létrehozása az RPO becsléséhez

1. Az elsődleges replikán hozzon létre tárolt eljárást proc_calculate_RPO. Ha már létezik, először törölje, majd hozza létre újból.

   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. Hajtsa végre proc_calculate_RPO a cél másodlagos adatbázis group_id, replica_id és group_database_id használatával.

   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. A kimenet megjeleníti a cél másodlagos replikaadatbázis RPO-értékét.

RTO és RPO figyelése

Ez a szakasz bemutatja, hogyan figyelheti a rendelkezésre állási csoportokat az RTO- és RPO-metrikák esetében. Ez a bemutató hasonló az Az Always On állapotmodell 2. része: Az állapotmodell kiterjesztésecímű oktatóanyaghoz.

A feladatátvételi idő és a lehetséges adatveszteség-számítások elemei a feladatátvételi idő becslése (RTO) és a lehetséges adatvesztés becslése (RPO) esetében a szabályzatkezelési szempontú adatbázisreplikaállapot teljesítménymetrikáiként vannak megadva. További információ: Szabályzatalapú felügyeleti aspektusok megtekintése EGY SQL Server-objektumon. Ezt a két metrikát ütemezés szerint figyelheti, és riasztást kaphat, ha a metrikák túllépik az RTO-t és az RPO-t.

A bemutatott szkriptek két rendszerszabályzatot hoznak létre, amelyek a saját ütemezésük szerint futnak, a következő jellemzőkkel:

• Olyan RTO-szabályzat, amely akkor hiúsul meg, ha a becsült feladatátvételi idő meghaladja a 10 percet, kiértékelése 5 percenként történik

• Olyan RPO-szabályzat, amely akkor meghiúsul, ha a becsült adatvesztés meghaladja az 1 órát, 30 percenként kiértékelve

• A két politika konfigurációja minden rendelkezésre állási replikán azonos.

• A szabályzatok kiértékelése az összes kiszolgálón történik, de csak azon rendelkezésre állási csoportokon, amelyeknél a helyi rendelkezésre állási replika az elsődleges replika. Ha a helyileg elérhető replika nem az elsődleges replika, a szabályokat nem értékelik ki.

• A szabályzathibák világosan megjelennek az Always On irányítópulton, amikor az elsődleges replikán tekinti meg.

A szabályzatok létrehozásához kövesse az alábbi utasításokat a rendelkezésre állási csoportban részt vevő összes kiszolgálópéldányon:

1. Indítsa el az SQL Server Agent szolgáltatást , ha még nem indult el.

2. Az SQL Server Management Studióban az Eszközök menüben válassza a Beállításoklehetőséget.

3. Az SQL Server Always On lapján válassza a Felhasználó által definiált Always On szabályzat engedélyezése , majd az OK gombot.

   Ezzel a beállítással megfelelően konfigurált egyéni szabályzatokat jeleníthet meg az Always On irányítópulton.

4. Hozzon létre egy házirendalapú felügyeleti feltételt a következő specifikációk használatával:

   • név: RTO
   • Facet: Adatbázis-replika állapot
   • mező: Add(@EstimatedRecoveryTime, 60)
   • operátor: <=
   • Érték: 600

   Ez a feltétel akkor hiúsul meg, ha a lehetséges feladatátvételi idő meghaladja a 10 percet, beleértve a hibaészlelés és a feladatátvétel 60 másodperces többletterhelését is.

5. Hozzon létre egy második szabályzatalapú felügyeleti feltételt a következő specifikációk használatával:

   • név: RPO
   • Facet: Adatbázis-replika állapot
   • mező: @EstimatedDataLoss
   • operátor: <=
   • Érték: 3600

   Ez a feltétel meghiúsul, ha a lehetséges adatvesztés meghaladja az 1 órát.

6. Hozzon létre egy harmadik házirendalapú felügyeleti feltételt a következő specifikációk használatával:

   • név: IsPrimaryReplica
   • Facet: Rendelkezésre állási csoport
   • mező: @LocalReplicaRole
   • operátor: =
   • Érték: Primary

   Ez a feltétel ellenőrzi, hogy egy adott rendelkezésre állási csoport helyi rendelkezésre állási replikája-e az elsődleges replika.

7. Hozzon létre egy szabályzatalapú kezelés szabályzatot a következő specifikációk használatával:

   • Általános oldal:

     • név: CustomSecondaryDatabaseRTO

     • Feltétel ellenőrzése: RTO

     • A célpontok ellen: Minden DatabaseReplicaState az IsPrimaryReplica AvailabilityGroup-ben

       Ez a beállítás biztosítja, hogy a szabályzat csak olyan rendelkezésre állási csoportokon legyen kiértékelve, amelyeknél a helyi rendelkezésre állási replika az elsődleges replika.

       • Kiértékelési mód: Ütemezés szerint

       • Ütemezés: CollectorSchedule_Every_5min

       • Engedélyezett: kiválasztva

   • Leírás oldal:

     • kategória: rendelkezésre állási adatbázis figyelmeztetései

       Ez a beállítás lehetővé teszi, hogy a szabályzat kiértékelési eredményei megjelenjenek az Always On irányítópulton.

       • Leírás: Az aktuális replika RTO-ja meghaladja a 10 percet, feltételezve 1 perc többletterhelést a felderítéshez és a feladatátvételhez. Azonnal ki kell vizsgálni a megfelelő kiszolgálópéldány teljesítményproblémáit.

       • Kijelzendő szöveg: RTO túllépve!

8. Hozzon létre egy második szabályzatalapú felügyeleti szabályzatot a következő specifikációk használatával:

   • Általános oldal:

     • név: CustomAvailabilityDatabaseRPO
     • Feltétel ellenőrzése: RPO
     • A célpontok ellen: Minden DatabaseReplicaState az IsPrimaryReplica AvailabilityGroup-ben
     • Kiértékelési mód: Ütemezés szerint
     • Ütemezés: CollectorSchedule_Every_30min
     • Engedélyezett: kiválasztva

   • Leírás oldal:

     • kategória: rendelkezésre állási adatbázis figyelmeztetései

     • Leírás: A rendelkezésre állási adatbázis túllépte az 1 órás RPO-t. Azonnal meg kell vizsgálnia a rendelkezésre állási replikák teljesítményproblémáit.

     • Megjelenítendő szöveg: RPO túllépve!

Ha végzett, két új SQL Server Agent-feladat jön létre, egyet a szabályzatok kiértékelési ütemezéséhez. Ezeknek a feladatoknak olyan nevekkel kell rendelkezniük, amelyek syspolicy_check_schedule-tel kezdődnek.

A feladatelőzményeket megtekintheti a kiértékelési eredmények vizsgálatához. A kiértékelési hibák a Windows-alkalmazásnaplóban (az Eseménynaplóban) is rögzítésre kerülnek a 34052-s eseményazonosítóval. Az SQL Server Agentet úgy is konfigurálhatja, hogy riasztásokat küldjön a szabályzathibákról. További információ: Riasztások konfigurálása a házirend-rendszergazdák értesítésére a szabályzathibákról.

Teljesítménnyel kapcsolatos hibaelhárítási forgatókönyvek

Az alábbi táblázat a teljesítménnyel kapcsolatos gyakori hibaelhárítási forgatókönyveket sorolja fel.

Forgatókönyv	Leírás
Hibaelhárítás: A rendelkezésre állási csoport túllépte az RTO	Az automatikus feladatátvételt követően vagy az adatvesztés nélküli tervezett manuális feladatátvételt követően a feladatátvételi idő meghaladja az RTO-t. Vagy ha megbecsüli egy szinkron véglegesítésű másodlagos replika (például egy automatikus feladatátvételi partner) feladatátvételi idejét, azt tapasztalja, hogy az meghaladja az RTO-t.
Hibaelhárítás: A rendelkezésre állási csoport túllépte az RPO-t	Kényszerített manuális feladatátvétel után az adatvesztés mértéke nagyobb, mint az RPO. Vagy ha kiszámítja egy aszinkron véglegesítésű másodlagos replika lehetséges adatvesztését, azt tapasztalja, hogy az meghaladja az RPO-t.
Hibaelhárítás: Az elsődleges replika módosításai nem jelennek meg a másodlagos replikán	Az ügyfélalkalmazás sikeresen befejez egy frissítést az elsődleges replikán, de a másodlagos replika lekérdezése azt mutatja, hogy a módosítás nem jelenik meg.

Hasznos bővített események

Az alábbi bővített események hasznosak a replikák szinkronizálási állapotban történő hibaelhárítása során.

Esemény neve	Kategória	Csatorna	Rendelkezésre álló replika
redo_caught_up	Tranzakciók	Hibakeresés	Másodlagos
redo_worker_entry	Tranzakciók	Hibakeresés	Másodlagos
hadr_transport_dump_message	alwayson	Hibakeresés	Elsődleges
hadr_worker_pool_task	alwayson	Hibakeresés	Elsődleges
hadr_dump_primary_progress	alwayson	Hibakeresés	Elsődleges
hadr_dump_log_progress	alwayson	Hibakeresés	Elsődleges
hadr_undo_of_redo_log_scan	alwayson	Analitikus	Másodlagos