Övervaka prestanda för AlwaysOn-tillgänglighetsgrupper

gäller för:SQL Server

Prestandaaspekten för AlwaysOn-tillgänglighetsgrupper är avgörande för att upprätthålla serviceavtalet (SLA) för dina verksamhetskritiska databaser. Att förstå hur tillgänglighetsgrupper skickar loggar till sekundära repliker kan hjälpa dig att beräkna mål för återställningstid (RTO) och mål för återställningspunkt (RPO) för tillgänglighetsimplementeringen och identifiera flaskhalsar i tillgänglighetsgrupper eller repliker med dåliga prestanda. Den här artikeln beskriver synkroniseringsprocessen, visar hur du beräknar några av nyckelmåtten och ger dig länkarna till några av de vanliga scenarierna för prestandafelsökning.

Datasynkroniseringsprocess

För att uppskatta tiden till fullständig synkronisering och identifiera flaskhalsen måste du förstå synkroniseringsprocessen. Prestandaflaskhalsen kan finnas var som helst i processen, och att hitta flaskhalsen kan hjälpa dig att fördjupa dig i de underliggande problemen. Följande bild och tabell illustrerar datasynkroniseringsprocessen:

Sekvens	Stegbeskrivning	Kommentarer	Användbara mått
1	Logggenerering	Loggdata rensas till disk. Den här loggen måste replikeras till de sekundära replikerna. Loggposterna går in i utskickskön.	SQL Server:Databasloggbyte > skrivna per sekund
2	Fånga	Loggar för varje databas registreras och skickas till motsvarande partnerkö (en per databasreplikpar). Den här infångningsprocessen körs kontinuerligt så länge som tillgänglighetsrepliken är ansluten och dataflytten inte avbryts av någon anledning samt om databasreplikparet visas antingen som synkroniserande eller synkroniserat. Om avbildningsprocessen inte kan skanna och skicka meddelanden tillräckligt snabbt byggs loggens sändningskö upp.	SQL Server:Availability Replica > Byte som skickas till replik/s, vilket är en aggregering av summan av alla databasmeddelanden i kö för den tillgänglighetsrepliken. log_send_queue_size (KB) och log_bytes_send_rate (KB/s) på den primära repliken.
3	Sända	Meddelandena i varje databasreplikkö tas ur kö och skickas över nätverket till respektive sekundär replik.	SQL Server:Availability Replica > Bytes skickade till transport per sekund
4	Ta emot och cachelagra	Varje sekundär replik tar emot och cachelagrar meddelandet.	PrestandaRäknare SQL Server:Tillgänglighetsreplik > Loggbyte mottagna per sekund
5	Hårdna	Loggen skrivs på den sekundära repliken för säkerställande. När loggen har tömts skickas en bekräftelse tillbaka till den primära repliken. När loggen är härdad undviks dataförlust.	Prestandaräknare SQL Server:Database > Loggbytes spolade/sek Väntetyp HADR_LOGCAPTURE_SYNC
6	Gör om	Återskapa de spolade sidorna på den sekundära repliken. Sidor sparas i redo-kön medan de väntar på att göras om.	SQL Server:Database Replica > Omgjorda byte/sekund redo_queue_size (KB) och redo_rate. Väntetyp REDO_SYNC

Flödeskontrollgrindar

Tillgänglighetsgrupper är utformade med flödeskontrollgrindar på den primära repliken för att undvika överdriven resursförbrukning, till exempel nätverks- och minnesresurser, på alla tillgänglighetsrepliker. Dessa flödeskontrollportar påverkar inte hälsotillståndet för synkroniseringen av tillgänglighetsreplikerna, men de kan påverka den övergripande prestandan för dina tillgänglighetsdatabaser, inklusive RPO.

När loggarna har registrerats på den primära repliken omfattas de av två nivåer av flödeskontroller. När meddelandetröskelvärdet för någon av portarna har nåtts skickas inte längre loggmeddelanden till en specifik replik eller för en specifik databas. Meddelanden kan skickas när bekräftelsemeddelanden tas emot för de skickade meddelandena för att få antalet skickade meddelanden under tröskelvärdet.

Förutom flödeskontrollgrindarna finns det en annan faktor som kan förhindra att loggmeddelandena skickas. Synkroniseringen av kopior säkerställer att meddelandena skickas och tillämpas i ordningen av loggsekvensnummer (LSN). Innan ett loggmeddelande skickas kontrolleras även LSN mot det lägsta bekräftade LSN-numret för att se till att det är mindre än ett tröskelvärde (beroende på meddelandetyp). Om klyftan mellan de två LSN-talen är större än tröskelvärdet skickas inte meddelandena. När klyftan är under tröskelvärdet igen skickas meddelandena.

SQL Server 2022 (16.x) ökar gränserna för antalet meddelanden som varje grind tillåter. Med hjälp av spårningsflagga 12310 är den ökade gränsen också tillgänglig för följande versioner av SQL Server: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.

I följande tabell jämförs meddelandegränser:

Nya gränser

För versioner av SQL Server som aktiverar Spårningsflagga 12310, nämligen SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 och senare versioner, se följande gränser:

Nivå	Antal portar	Antal meddelanden	Användbara mått
Transport	1 per tillgänglighetskopie	16384	Utökad händelse database_transport_flow_control_action
Databas	1 per tillgänglighetsdatabas	7168	DBMIRROR_SEND Utökad händelse hadron_database_flow_control_action

Gamla gränser

För SQL Server-versioner som inte stöds eller stödjda SQL Server-versioner (från och med SQL Server 2019 CU9, SQL Server 2017 CU18 och SQL Server 2016 SP1 CU16) som inte har spårningsflagga 12310 aktiverad, se följande begränsningar:

Nivå	Antal portar	Antal meddelanden	Användbara mått
Transport	1 per tillgänglighetskopie	8192	Utökad händelse database_transport_flow_control_action
Databas	1 per tillgänglighetsdatabas	1792 (x64) 1600 (x86)	DBMIRROR_SEND Utökad händelse hadron_database_flow_control_action

Två användbara prestandaräknare, SQL Server:Availability Replica > Flow control/sec och SQL Server:Availability Replica > Flow Control Time (ms/sec), visar inom den senaste sekunden hur många gånger flödeskontroll aktiverades och hur mycket tid som spenderades på att vänta på flödeskontroll. Högre väntetid på flödeskontrollen översätts till högre RPO. Mer information om vilka typer av problem som kan orsaka hög väntetid i flödeskontrollen finns i Felsöka: Potentiell dataförlust med asynkron-kommitterade tillgänglighetsgrupprepliker.

Beräkna redundanstid (RTO)

RtO i ditt serviceavtal beror på redundanstiden för din AlwaysOn-implementering vid en viss tidpunkt, vilket kan uttryckas i följande formel:

Viktig

Om en tillgänglighetsgrupp innehåller mer än en tillgänglighetsdatabas blir tillgänglighetsdatabasen med den högsta Tfailover det begränsande värdet för RTO-efterlevnad.

Felidentifieringstiden, Tdetection, är den tid det tar för systemet att identifiera felet. Detta beror på inställningar på klusternivå och inte på enskilda tillgänglighetsrepliker. Beroende på det automatiska växlingsvillkor som har konfigurerats kan en växling utlösas som ett omedelbart svar på ett kritiskt internt SQL Server-fel, till exempel spinlocks som har blivit överflödiga. I det här fallet kan upptäckten ske så snart sp_server_diagnostics felrapport har skickats till Failover-klustret för Windows Server (WSFC). Standardintervallet är 1/3 av tidsgränsen för hälsokontrollen. En redundansväxling kan också utlösas på grund av en timeout, till exempel att tidsgränsen för klusterhälsokontrollen har upphört att gälla (30 sekunder som standard) eller att lånet mellan resurs-DLL och SQL Server-instansen har upphört att gälla (20 sekunder som standard). I det här fallet är identifieringstiden lika lång som tidsgränsintervallet. Mer information finns i Flexibel redundansprincip för automatisk redundans för en tillgänglighetsgrupp (SQL Server).

Det enda som den sekundära repliken behöver göra för att bli redo för en växling är att låta återställningsprocessen hinna ikapp så den når slutet av loggen. Omgörningstiden, Tredo, beräknas med hjälp av följande formel:

där redo_queue är värdet i redo_queue_size och redo_rate är värdet i redo_rate.

Övergångens extra tid, Toverhead, inkluderar den tid det tar att övergå WSFC-klustret och att starta databaserna. Den här tiden är vanligtvis kort och konstant.

Uppskatta potentiell dataförlust (RPO)

RPO i ditt serviceavtal beror på den möjliga dataförlusten av din Always On-implementering vid en viss tidpunkt. Den här möjliga dataförlusten kan uttryckas i följande formel:

där log_send_queue är värdet för log_send_queue_size och logggenereringshastighet är värdet för SQL Server:Database > Log Bytes Flushed/sec.

Varning

Om en tillgänglighetsgrupp innehåller mer än en tillgänglighetsdatabas blir tillgänglighetsdatabasen med högst Tdata_loss det begränsande värdet för RPO-efterlevnad.

Sändningskön för loggar representerar alla data som kan gå förlorade vid ett katastrofalt fel. Vid första anblicken är det märkligt att logggenereringsfrekvensen används i stället för loggöverföringshastigheten (se log_send_rate). Kom dock ihåg att användning av loggöverföringsfrekvensen bara ger dig tid att synkronisera, medan RPO mäter dataförlust baserat på hur snabbt det genereras, inte på hur snabbt det synkroniseras.

Ett enklare sätt att uppskatta Tdata_loss är att använda last_commit_time. DMV på den primära repliken rapporterar detta värde för alla repliker. Du kan beräkna skillnaden mellan värdet för den primära repliken och värdet för den sekundära repliken för att uppskatta hur snabbt loggen på den sekundära repliken kommer ikapp den primära repliken. Som tidigare nämnts visar den här beräkningen inte den potentiella dataförlusten baserat på hur snabbt loggen genereras, men det bör vara en nära uppskattning.

Beräkna RTO och RPO med SSMS-instrumentpanelen

I AlwaysOn-tillgänglighetsgrupper beräknas och visas RTO och RPO för de databaser som finns på de sekundära replikerna. På instrumentpanelen för SQL Server Management Studio (SSMS) grupperas RTO och RPO på den primära repliken av den sekundära repliken.

Gör följande för att visa RTO och RPO på instrumentpanelen:

1. I SQL Server Management Studio expanderar du noden Always On High Availability, högerklickar på namnet på tillgänglighetsgruppen och väljer Visa instrumentpanel.

2. Välj Lägg till/ta bort kolumner under fliken Gruppera efter. Kontrollera både Beräknad återställningstid (sekunder) [RTO] och Uppskattad dataförlust (tid i sekunder) [RPO].

   

Beräkning av den sekundära databasens RTO

Beräkningen av återställningstid avgör hur lång tid som krävs för att återställa den sekundära databasen efter en övergång. Redundanstiden är vanligtvis kort och konstant. Identifieringstiden beror på inställningar på klusternivå och inte på enskilda tillgänglighetsrepliker.

För en sekundär databas (DB_sec) baseras beräkningen och visningen av dess RTO på dess redo_queue_size och redo_rate:

Förutom undantagsfall är formeln för att beräkna en sekundär databas RTO:

Beräkning av RPO för sekundär databas

För en sekundär databas (DB_sec) baseras beräkningen och visningen av dess RPO på dess is_failover_ready, last_commit_timeoch dess korrelerade primära databasvärden (DB_pri).last_commit_time När värdet på DB_sec.is_failover_ready är 1 synkroniseras data mellan de primära och sekundärerna och ingen dataförlust sker vid övergång till sekundären. Men om det här värdet är 0finns det en lucka mellan last_commit_time den primära databasen och den last_commit_time sekundära databasen.

För den primära databasen är last_commit_time den tid då den senaste transaktionen har bekräftats. För den sekundära databasen last_commit_time är den senaste bekräftelsetiden för transaktionen från den primära databasen som har bekräftats på den sekundära databasen. Det här talet är detsamma för både den primära och sekundära databasen. Det finns dock en skillnad mellan dessa två värden som är varaktigheten under vilken väntande transaktioner inte har skrivits in på den sekundära databasen och kan gå förlorade vid en felövergång.

Prestandamått som används i RTO/RPO-formler

• redo_queue_size (KB): Den omgjorda köstorleken, som används i RTO, är storleken på transaktionsloggarna mellan dess last_received_lsn och last_redone_lsn. Värdet last_received_lsn är loggblocks-ID:t som identifierar den punkt upp till vilken alla loggblock har tagits emot av den sekundära repliken som är värd för den sekundära databasen. Värdet last_redone_lsn för är loggsekvensnumret för den senaste loggposten som gjordes om på den sekundära databasen. Baserat på dessa två värden kan vi hitta ID:t för startloggblocket (last_received_lsn) och slutloggblocket (last_redone_lsn). Utrymmet mellan dessa två loggblock kan sedan representera hur många transaktionsloggblock som ännu inte har gjorts om. Detta mäts i Kilobyte (KB).

• redo_rate (KB/s): Används i RTO-beräkningen, det här är ett kumulativt värde som visar hur mycket av transaktionsloggen (KB) som har gjorts om eller spelas upp på den sekundära databasen per sekund.

• last_commit_time (datetime): Det här värdet används i RPO och har en annan betydelse mellan den primära och sekundära databasen. För den primära databasen last_commit_time är den tid då den senaste transaktionen bekräftades. För den sekundära databasen är last_commit_time det senaste kommandot för transaktionen på den primära databasen som också har framgångsrikt härdats på den sekundära databasen. Eftersom det här värdet på den sekundära ska synkroniseras med samma värde på den primära, är varje mellanrum mellan dessa två värden uppskattningen av dataförlust (RPO).

Uppskatta RTO och RPO med användning av DMVs

Man kan köra frågor mot DMV:erna sys.dm_hadr_database_replica_states och sys.dm_hadr_database_replica_cluster_states för att uppskatta RPO och RTO för en databas. Frågorna nedan skapar lagrade procedurer som åstadkommer båda sakerna.

Anteckning

Se till att skapa och köra den lagrade proceduren för att beräkna RTO först, eftersom de värden som genereras är nödvändiga för att köra den lagrade proceduren för att uppskatta RPO.

Skapa en lagrad procedur för att uppskatta RTO

1. På den sekundära målrepliken skapar du en lagrad procedur proc_calculate_RTO. Om den här lagrade proceduren redan finns släpper du den först och återskapar den sedan.

   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. Kör proc_calculate_RTO med det sekundära måldatabasnamnet:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. Utdata visar RTO-värdet för den sekundära målreplikdatabasen. Spara group_id, replica_idoch group_database_id som ska användas med den lagrade proceduren för RPO-uppskattning.

   Exempelutdata:

   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
   

Skapa en lagrad procedur för att uppskatta RPO

1. På den primära repliken skapar du den lagrade proceduren proc_calculate_RPO. Om den redan finns, ta bort den först och återskapa den sedan.

   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. Kör proc_calculate_RPO med måldatabasens group_id, replica_id och group_database_id.

   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. Utdata visar RPO-värdet för den sekundära målreplikdatabasen.

Övervaka för RTO och RPO

Det här avsnittet visar hur du övervakar dina tillgänglighetsgrupper för RTO- och RPO-mått. Den här demonstrationen liknar GUI-självstudien som ges i AlwaysOn-hälsomodellen, del 2: Utöka hälsomodellen.

sv-SE: Element av redundanstiden och potentiella dataförlustberäkningar i estimera redundanstid (RTO) och uppskatta potentiell dataförlust (RPO) tillhandahålls bekvämt som prestandamått i principhanteringens aspekten Databasreplikastatus. Mer information finns i Visa principbaserade hanteringsfasetter på ett SQL Server-objekt. Du kan övervaka dessa två mått enligt ett schema och aviseras när måtten överskrider din RTO respektive RPO.

De demonstrerade skripten skapar två systemprinciper som körs enligt respektive schema, med följande egenskaper:

• En RTO-policy som misslyckas när den uppskattade omställningstiden överskrider 10 minuter, utvärderas var femte minut

• En RPO-princip som misslyckas när den uppskattade dataförlusten överskrider 1 timme, utvärderas var 30:e minut

• De två policyerna har identiska konfigurationer på alla tillgänglighetsrepliker

• Policyer bedöms på alla servrar, men bara på de tillgänglighetsgrupper för vilka den lokala tillgänglighetsrepliken är den primära repliken. Om den lokala tillgänglighetsrepliken inte är den primära repliken utvärderas inte principerna.

• Policyfel visas bekvämt på Alltid på-instrumentpanelen när du visar den i den primära replikan.

Följ dessa instruktioner för alla serverinstanser som deltar i tillgänglighetsgruppen för att skapa principerna:

1. Starta SQL Server Agent-tjänsten om den inte redan har startats.

2. I SQL Server Management Studio går du till menyn Tools och väljer Alternativ.

3. På fliken SQL Server AlwaysOn väljer du Aktivera användardefinierad AlwaysOn-princip och väljer OK.

   Med den här inställningen kan du visa anpassade principer som är korrekt konfigurerade på "Alltid På-instrumentpanelen".

4. Skapa ett principbaserat hanteringsvillkor med hjälp av följande specifikationer:

   • Namn: RTO
   • Facet: Databasreplikatets tillstånd
   • Field: Add(@EstimatedRecoveryTime, 60)
   • Operator: <=
   • Värde: 600

   Det här villkoret misslyckas när den potentiella redundanstiden överskrider 10 minuter, inklusive en 60-sekunders overhead för både felidentifiering och redundans.

5. Skapa ett andra principbaserat hanteringsvillkor med hjälp av följande specifikationer:

   • Namn: RPO
   • Facet: Databasreplikatets tillstånd
   • Field: @EstimatedDataLoss
   • Operator: <=
   • Värde: 3600

   Det här villkoret misslyckas när potentiell dataförlust överskrider 1 timme.

6. Skapa ett tredje principbaserat hanteringsvillkor med hjälp av följande specifikationer:

   • Namn: IsPrimaryReplica
   • Facet: tillgänglighetsgrupp
   • Field: @LocalReplicaRole
   • Operator: =
   • Värde: Primary

   Det här villkoret kontrollerar om den lokala tillgänglighetsrepliken för en viss tillgänglighetsgrupp är den primära repliken.

7. Skapa en principbaserad hanteringsprincip med hjälp av följande specifikationer:

   • Allmänt sida

     • Namn: CustomSecondaryDatabaseRTO

     • Kontrollera villkoret: RTO

     • Mot mål: Varje DatabaseReplicaState i IsPrimaryReplica AvailabilityGroup

       Den här inställningen säkerställer att principen endast utvärderas för tillgänglighetsgrupper där den lokala tillgänglighetsrepliken är den primära repliken.

       • utvärderingsläge: Enligt schema

       • Schema: CollectorSchedule_Every_5min

       • Aktiverad: valt

   • sidan Beskrivning:

     • Kategori: Tillgänglighetsdatabasvarningar

       Med den här inställningen kan resultaten av principutvärderingen visas på Always On-instrumentpanelen.

       • Beskrivning: Den aktuella repliken har en RTO som överskrider 10 minuter, förutsatt en omkostnad på 1 minut för identifiering och redundans. Du bör undersöka prestandaproblem på respektive serverinstans omedelbart.

       • Text för att visa: RTO har överskridits!

8. Skapa en andra principbaserad hanteringsprincip med hjälp av följande specifikationer:

   • Allmänt sida

     • Namn: CustomAvailabilityDatabaseRPO
     • Kontrollera villkoret: RPO
     • Mot mål: Varje DatabaseReplicaState i IsPrimaryReplica AvailabilityGroup
     • utvärderingsläge: Enligt schema
     • Schema: CollectorSchedule_Every_30min
     • Aktiverad: valt

   • Beskrivning sidan:

     • Kategori: Tillgänglighetsdatabasvarningar

     • Beskrivning: Tillgänglighetsdatabasen har överskridit ditt RPO på 1 timme. Du bör undersöka problem med prestanda på tillgänglighetsreplikerna omedelbart.

     • Text för att visa: RPO har överskridits!

När du är klar skapas två nya SQL Server Agent-jobb, ett för varje principutvärderingsschema. De här jobben bör ha namn som börjar med syspolicy_check_schedule.

Du kan visa jobbhistoriken för att granska utvärderingsresultat. Utvärderingsfel registreras också i Windows-programloggen (i Loggboken) med händelse-ID 34052. Du kan också konfigurera SQL Server-agenten för att skicka aviseringar om principfelen. Mer information finns i Konfigurera aviseringar för att meddela principadministratörer om principfel.

Scenarier för prestandafelsökning

I följande tabell visas de vanliga prestandarelaterade felsökningsscenarierna.

Scenario	Beskrivning
Felsökning: Tillgänglighetsgrupp överskred RTO	Efter en automatisk failover eller en planerad manuell failover utan dataförlust överskrider failovertiden din RTO. Eller när du beräknar växlingstiden för en sekundär replik med synkron inlämning (som en automatisk växlingspartner) upptäcker du att den överskrider din RTO.
Felsökning: Tillgänglighetsgruppen överskred RPO-	När du har gjort en manuell tvingad överflyttning är dataförlusten större än vad ditt RPO tillåter. Eller när du beräknar den potentiella dataförlusten för en sekundär replik med asynkron incheckning upptäcker du att den överskrider ditt RPO.
Felsökning: Ändringar på den primära repliken återspeglas inte på den sekundära repliken	Klientprogrammet slutför en uppdatering av den primära repliken, men vid förfrågan mot den sekundära repliken visar det att ändringen inte återspeglas.

Nyttiga utökade händelser

Följande utökade händelsetyper är användbara när du felsöker repliker i tillståndet synkroniserar.

Händelsenamn	Kategori	Kanal	Tillgänglighetsreplika
redo_caught_up	Transaktioner	Felsöka	Sekundär
redo_worker_entry	Transaktioner	Felsöka	Sekundär
hadr_transport_dump_message	alwayson	Felsöka	Primär
hadr_worker_pool_task	alwayson	Felsöka	Primär
hadr_dump_primary_progress	alwayson	Felsöka	Primär
hadr_dump_log_progress	alwayson	Felsöka	Primär
hadr_undo_of_redo_log_scan	alwayson	Analytisk	Sekundär