Prestaties bewaken voor AlwaysOn-beschikbaarheidsgroepen

van toepassing op:SQL Server-

Het prestatieaspect van AlwaysOn-beschikbaarheidsgroepen is van cruciaal belang voor het onderhouden van de SLA (Service Level Agreement) voor uw bedrijfskritieke databases. Informatie over hoe beschikbaarheidsgroepen logboeken naar secundaire replica's verzenden, kan u helpen bij het schatten van de beoogde hersteltijd (RTO) en de RPO (Recovery Point Objective) van uw beschikbaarheids-implementatie en het identificeren van knelpunten in slecht presterende beschikbaarheidsgroepen of replica's. In dit artikel wordt het synchronisatieproces beschreven, wordt beschreven hoe u enkele van de belangrijkste metrische gegevens kunt berekenen en krijgt u de koppelingen naar enkele veelvoorkomende scenario's voor het oplossen van prestatieproblemen.

Proces voor gegevenssynchronisatie

Als u de tijd wilt schatten voor volledige synchronisatie en het knelpunt wilt identificeren, moet u het synchronisatieproces begrijpen. Prestatieknelpunten kunnen zich overal in het proces voordoen en het vinden van het knelpunt kunnen u helpen dieper in te gaan op de onderliggende problemen. In de volgende afbeelding en tabel ziet u het proces voor gegevenssynchronisatie:

Volgorde	Beschrijving van stap	Opmerkingen	Nuttige metrische gegevens
1	Logboekgeneratie	Logboekgegevens worden naar schijf leeggemaakt. Dit logboek moet worden gerepliceerd op de secundaire replica's. De logboekrecords voeren de verzendwachtrij in.	SQL Server:Databaselogboekbytes > leeggemaakt per seconde
2	Opnemen / Vastleggen	Logboeken voor elke database worden vastgelegd en verzonden naar de bijbehorende partnerwachtrij (één per databasereplicapaar). Dit opnameproces wordt continu uitgevoerd zolang de beschikbaarheidsreplica is verbonden en gegevensverplaatsing om welke reden dan ook niet is opgeschort en het databasereplicapaar wordt weergegeven als Synchroniseren of Gesynchroniseerd. Als het opnameproces de berichten niet snel kan scannen en in de wachtrij plaatsen, wordt de wachtrij voor het verzenden van logboeken opgebouwd.	SQL Server: Beschikbaarheidsreplica > Bytes verzonden naar replica per seconde, een aggregatie van de som van alle databaseberichten in de wachtrij voor die beschikbaarheidsreplica. log_send_queue_size (in KB) en log_bytes_send_rate (in KB/sec) op de primaire replica.
3	Verzenden	De berichten in elke databasereplicawachtrij worden uit de wachtrij gehaald en over het netwerk verzonden naar de respectieve secundaire replica.	SQL Server:Availability Replica > Bytes per seconde verzonden naar transport
4	Ontvangen en cachen	Elke secundaire replica ontvangt en slaat het bericht in de cache op.	Prestatiemeter SQL Server: Availability Replica > Logboekbytes ontvangen per seconde
5	Verharden	Het logbestand wordt weggeschreven op de secundaire replica voor verzegeling. Nadat de log flush is uitgevoerd, wordt een bevestiging teruggestuurd naar de primaire replica. Zodra het logboek is beveiligd, wordt gegevensverlies vermeden.	Prestatiemeter SQL Server:Database > bijgewerkte logbytes per seconde Wachttype HADR_LOGCAPTURE_SYNC
6	Opnieuw	Voer de leeggemaakte pagina's op de secundaire replica opnieuw uit. Pagina's worden bewaard in de redo-wachtrij terwijl ze wachten om opnieuw uitgevoerd te worden.	SQL Server:Database Replica > Opnieuw bytes/sec redo_queue_size (KB) en redo_rate. Wachttype REDO_SYNC

Stroomregelkleppen

Beschikbaarheidsgroepen zijn ontworpen met stroombeheerpoorten op de primaire replica om overmatig resourceverbruik, zoals netwerk- en geheugenresources, te voorkomen op alle beschikbaarheidsreplica's. Deze poorten voor stroombeheer hebben geen invloed op de synchronisatiestatus van de beschikbaarheidsreplica's, maar ze kunnen van invloed zijn op de algehele prestaties van uw beschikbaarheidsdatabases, waaronder RPO.

Nadat de logboeken zijn vastgelegd op de primaire replica, zijn ze onderworpen aan twee niveaus van stroombesturingselementen. Zodra de drempelwaarde voor het bericht van een poort is bereikt, worden logboekberichten niet meer verzonden naar een specifieke replica of voor een specifieke database. Berichten kunnen worden verzonden zodra bevestigingsberichten worden ontvangen om het aantal verzonden berichten onder de drempelwaarde te brengen.

Naast de poorten voor stroombesturing is er nog een factor die kan voorkomen dat de logboekberichten worden verzonden. De synchronisatie van replica's zorgt ervoor dat de berichten worden verzonden en toegepast in de volgorde van de logboekreeksnummers (LSN). Voordat een logboekbericht wordt verzonden, wordt het LSN van het bericht gecontroleerd op het laagste erkende LSN-nummer om ervoor te zorgen dat het lager is dan een van de drempelwaarden (afhankelijk van het berichttype). Als de kloof tussen de twee LSN-getallen groter is dan de drempelwaarde, worden de berichten niet verzonden. Zodra de kloof weer onder de drempelwaarde ligt, worden de berichten verzonden.

SQL Server 2022 (16.x) verhoogt de limieten voor het aantal berichten dat elke poort toestaat. Met traceringsvlag 12310 is de verhoogde limiet ook beschikbaar voor de volgende versies van SQL Server: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.

In de volgende tabel worden berichtlimieten vergeleken:

nieuwe limieten

Zie de volgende limieten voor versies van SQL Server die Trace Flag 12310 inschakelen, namelijk SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 en latere versies:

Niveau	Aantal poorten	Aantal berichten	Nuttige metrische gegevens
Vervoer	1 per replica van beschikbaarheid	16384	Uitgebreide gebeurtenis database_transport_flow_control_action
Databank	1 per beschikbaarheidsdatabase	7168	DBMIRROR_SEND Uitgebreide gebeurtenis hadron_database_flow_control_action

oude limieten

Zie de volgende limieten voor niet-ondersteunde SQL Server-versies of ondersteunde SQL Server-versies (te beginnen met SQL Server 2019 CU9, SQL Server 2017 CU18 en SQL Server 2016 SP1 CU16) waarvoor traceringsvlag 12310 niet is ingeschakeld:

Niveau	Aantal poorten	Aantal berichten	Nuttige metrische gegevens
Vervoer	1 per replica van beschikbaarheid	8192	Uitgebreide gebeurtenis database_transport_flow_control_action
Databank	1 per beschikbaarheidsdatabase	1792 (x64) 1600 (x86)	DBMIRROR_SEND Uitgebreide gebeurtenis hadron_database_flow_control_action

Twee handige prestatiemeteritems, SQL Server: Availability Replica > Flow control/sec en SQL Server: Availability Replica > Flow Control Time (ms/sec), laten u zien hoe vaak flow control in de afgelopen seconde is geactiveerd en hoeveel tijd is besteed aan wachten op flow control. Een langere wachttijd bij de regeling van de doorstroming leidt tot een hogere RPO. Zie Troubleshoot: Potential data loss with asynchronous-commit availability-group replica's (Mogelijke gegevensverlies met asynchrone beschikbaarheidsgroepreplica's) voor meer informatie over de typen problemen die een hoge wachttijd kunnen veroorzaken voor het stroombeheer.

Een schatting maken van de failovertijd (RTO)

De RTO in uw SLA is afhankelijk van de failovertijd van uw AlwaysOn-implementatie op elk gewenst moment, wat kan worden uitgedrukt in de volgende formule:

Belangrijk

Als een beschikbaarheidsgroep meer dan één beschikbaarheidsdatabase bevat, wordt de beschikbaarheidsdatabase met de hoogste Tfailover de beperkende waarde voor RTO-naleving.

De foutdetectietijd, Tdetection, is de tijd die het systeem nodig heeft om de fout te detecteren. Deze tijd is afhankelijk van instellingen op clusterniveau en niet van de afzonderlijke beschikbaarheidsreplica's. Afhankelijk van de automatische failovervoorwaarde die is geconfigureerd, kan een failover worden geactiveerd als een directe reactie op een kritieke interne SQL Server-fout, zoals zwevende spinlocks. In dit geval kan detectie zo snel zijn als het sp_server_diagnostics foutenrapport wordt verzonden naar het Windows Server Failover Cluster (WSFC). Het standaardinterval is 1/3 van de time-out van de statuscontrole. Een failover kan ook worden geactiveerd vanwege een time-out, zoals de time-out van de clusterstatuscontrole is verlopen (standaard 30 seconden) of de lease tussen de resource-DLL en het SQL Server-exemplaar is verlopen (standaard 20 seconden). In dit geval is de detectietijd zo lang als het time-outinterval. Zie Flexibele failoverbeleid voor automatische failover van een beschikbaarheidsgroep (SQL Server)voor meer informatie.

Het enige dat de secundaire replica moet doen om klaar te zijn voor een failover, is ervoor zorgen dat de redo het einde van het logboek inhaalt. De hersteltijd, Tredo, wordt berekend met de volgende formule:

waarbij redo_queue de waarde in redo_queue_size is en redo_rate de waarde in redo_rateis.

De failover-overheadtijd, Toverhead, omvat de tijd die nodig is om een failover te realiseren voor het WSFC-cluster en om de databases online te brengen. Deze tijd is meestal kort en constant.

Schatting maken van mogelijk gegevensverlies (RPO)

De RPO in uw SLA is afhankelijk van het mogelijke gegevensverlies van uw AlwaysOn-implementatie op elk gewenst moment. Dit mogelijke gegevensverlies kan worden uitgedrukt in de volgende formule:

waarbij log_send_queue de waarde is van log_send_queue_size en loggeneratiesnelheid de waarde is van SQL Server:Database > Logboekbytes weggeschreven per seconde.

Waarschuwing

Als een beschikbaarheidsgroep meer dan één beschikbaarheidsdatabase bevat, wordt de beschikbaarheidsdatabase met de hoogste Tdata_loss de beperkende waarde voor RPO-naleving.

De wachtrij voor het verzenden van logboeken vertegenwoordigt alle gegevens die verloren kunnen gaan na een onherstelbare fout. Op het eerste gezicht is het nieuwsgierig dat de snelheid voor het genereren van logboeken wordt gebruikt in plaats van de verzendsnelheid voor logboeken (zie log_send_rate). Houd er echter rekening mee dat het gebruik van de frequentie voor het verzenden van logboeken u alleen de tijd geeft om te synchroniseren, terwijl RPO gegevensverlies meet op basis van hoe snel deze wordt gegenereerd, niet hoe snel het wordt gesynchroniseerd.

Een eenvoudigere manier om Tdata_loss te schatten is door last_commit_timete gebruiken. De DMV op de primaire replica rapporteert deze waarde voor alle replica's. U kunt het verschil berekenen tussen de waarde voor de primaire replica en de waarde voor de secundaire replica om in te schatten hoe snel het logboek op de secundaire replica bij de primaire replica komt te staan. Zoals eerder vermeld, vertelt deze berekening u niet het potentiële gegevensverlies op basis van hoe snel het logboek wordt gegenereerd, maar dit moet een nauwe benadering zijn.

RTO en RPO schatten met het SSMS-dashboard

In AlwaysOn-beschikbaarheidsgroepen worden de RTO en RPO berekend en weergegeven voor de databases die worden gehost op de secundaire replica's. In het SSMS-dashboard (SQL Server Management Studio) op de primaire replica worden de RTO en RPO gegroepeerd door de secundaire replica.

Voer de volgende stappen uit om de RTO en RPO in het dashboard weer te geven:

1. Vouw in SQL Server Management Studio het AlwaysOn High Availability-knooppunt uit, klik met de rechtermuisknop op de naam van uw beschikbaarheidsgroep en selecteer Dashboard weergeven.

2. Selecteer Kolommen toevoegen/verwijderen onder het tabblad Groeperen op. Controleer zowel Geschatte hersteltijd (seconden) [RTO] als Geschatte gegevensverlies (tijd) [RPO].

   

Berekening van secundaire database RTO

De berekening van de hersteltijd bepaalt hoeveel tijd er nodig is om de secundaire database te herstellen nadat een failover is uitgevoerd. De failovertijd is meestal kort en constant. De detectietijd is afhankelijk van de instellingen op clusterniveau en niet van de afzonderlijke beschikbaarheidsreplica's.

Voor een secundaire database (DB_sec) is de berekening en weergave van de RTO gebaseerd op de redo_queue_size en redo_rate:

Met uitzondering van randgevallen is de formule voor het berekenen van de RTO van een secundaire database:

Berekening van secundaire database-RPO

Voor een secundaire database (DB_sec) is berekening en weergave van de RPO gebaseerd op is_failover_readyde bijbehorende , last_commit_timeen de gecorreleerde primaire database (DB_pri)- last_commit_time waarden. Wanneer de waarde DB_sec.is_failover_ready is 1, worden gegevens tussen de primaire en secundaire bestanden gesynchroniseerd en treedt er geen gegevensverlies op bij een failover. Als deze waarde echter is 0, is er een kloof tussen de last_commit_time primaire database en de last_commit_time secundaire database.

Voor de primaire database is het last_commit_time tijdstip waarop de meest recente transactie is doorgevoerd. Voor de secundaire database is de last_commit_time laatste doorvoertijd voor de transactie van de primaire database die ook is beveiligd op de secundaire database. Dit getal is hetzelfde voor zowel de primaire als de secundaire database. Een tussenruimte tussen deze twee waarden is echter de duur waarin in behandeling zijnde transacties niet zijn beveiligd op de secundaire database en mogelijk verloren gaan in het geval van een failover.

Metrische gegevens over prestaties die worden gebruikt in RTO-/RPO-formules

• redo_queue_size (KB): De grootte van de redo-wachtrij, die wordt gebruikt in RTO, is de grootte van transactielogboeken tussen zijn last_received_lsn en last_redone_lsn. De last_received_lsn waarde is de logboekblok-id die het punt aangeeft waartoe alle logboekblokken zijn ontvangen door de secundaire replica die als host fungeert voor deze secundaire database. De waarde van last_redone_lsn is het logvolgnummer van het laatste logbestand dat is heruitgevoerd op de secundaire database. Op basis van deze twee waarden kunnen we id's vinden van het beginlogboekblok (last_received_lsn) en het eindlogboekblok (last_redone_lsn). De ruimte tussen deze twee logboekblokken kan dan weergeven hoeveel transactielogboekblokken nog niet opnieuw worden uitgevoerd. Dit wordt gemeten in Kilobytes (KB).

• redo_rate (KB/sec): Wordt gebruikt in de RTO-berekening, dit is een cumulatieve waarde die aangeeft hoeveel kilobytes van het transactielogboek (KB) opnieuw is uitgevoerd of gerepliceerd op de secundaire database per seconde.

• last_commit_time (datum/tijd): Deze waarde wordt gebruikt in RPO en heeft een andere betekenis tussen de primaire en secundaire database. Voor de primaire database last_commit_time is het tijdstip waarop de laatste transactie is doorgevoerd. Voor de secundaire database is de last_commit_time de meest recente commit voor de transactie op de primaire database, die ook succesvol is gehard op de secundaire database. Aangezien deze waarde op de secundaire waarde moet worden gesynchroniseerd met dezelfde waarde op de primaire, is elke kloof tussen deze twee waarden de schatting van gegevensverlies (RPO).

RTO en RPO schatten met DMV's

Het is mogelijk om query's uit te voeren op de DMV's sys.dm_hadr_database_replica_states en sys.dm_hadr_database_replica_cluster_states om de RPO en RTO van een database te schatten. Met de onderstaande query's worden opgeslagen procedures gemaakt waarmee beide dingen worden uitgevoerd.

Notitie

Zorg ervoor dat u eerst de opgeslagen procedure maakt en uitvoert om de RTO te schatten, aangezien de waarden die het oplevert noodzakelijk zijn om de opgeslagen procedure voor het schatten van de RPO uit te voeren.

Een opgeslagen procedure maken om een schatting te maken van RTO

1. Maak opgeslagen procedure proc_calculate_RTOop de secundaire doelreplica. Als deze opgeslagen procedure al bestaat, verwijdert u deze eerst en maakt u deze opnieuw.

   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. Voer de volgende opdracht uit proc_calculate_RTO met de naam van de secundaire doeldatabase:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. In de uitvoer wordt de RTO-waarde van de secundaire doelreplicadatabase weergegeven. Sla de group_id, replica_iden group_database_id op voor gebruik met de opgeslagen procedure voor RPO-schattingen.

   Voorbeelduitvoer:

   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
   

Een opgeslagen procedure maken om een schatting te maken van de RPO

1. Maak opgeslagen procedure proc_calculate_RPOop de primaire replica. Als deze al bestaat, verwijder het eerst en recreëer het daarna.

   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. Voer proc_calculate_RPO uit met de group_id, replica_id en group_database_id van de doeldatabase.

   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. In de uitvoer wordt de RPO-waarde van de secundaire doelreplicadatabase weergegeven.

Bewaken voor RTO en RPO

In deze sectie ziet u hoe u uw beschikbaarheidsgroepen kunt bewaken voor metrische RTO- en RPO-gegevens. Deze demonstratie is vergelijkbaar met de GUI-zelfstudie in Het AlwaysOn-statusmodel, deel 2: het statusmodel uitbreiden.

Elementen van de failovertijd en mogelijke berekeningen voor gegevensverlies bij het schatten van de failovertijd (RTO) en het schatten van potentieel gegevensverlies (RPO) zijn handig als prestatiegegevens in de facet databasereplicastatus van beleidsbeheer. Zie Op beleid gebaseerde beheer facets weergeven in een SQL Server-object voor meer informatie. U kunt deze twee metrische gegevens controleren volgens een schema en worden gewaarschuwd wanneer de metrische gegevens respectievelijk uw RTO en RPO overschrijden.

De gedemonstreerde scripts maken twee systeembeleidsregels die volgens hun respectieve planningen worden uitgevoerd, met de volgende kenmerken:

• Een RTO-beleid dat mislukt wanneer de geschatte failovertijd langer is dan 10 minuten, geëvalueerd om de 5 minuten

• Een RPO-beleid dat mislukt wanneer geschatte gegevensverlies groter is dan 1 uur, geëvalueerd om de 30 minuten

• De twee beleidsregels hebben een identieke configuratie voor alle beschikbaarheidsreplica's

• Beleidsregels worden geëvalueerd op alle servers, maar alleen op de beschikbaarheidsgroepen waarvoor de lokale beschikbaarheidsreplica de primaire replica is. Als de lokale beschikbaarheidsreplica niet de primaire replica is, worden de beleidsregels niet geëvalueerd.

• Beleidsfouten worden gemakkelijk weergegeven in het Always On Dashboard wanneer u het op de primaire replica bekijkt.

Volg deze instructies op alle serverexemplaren die deelnemen aan de beschikbaarheidsgroep om het beleid op te stellen.

1. Start de SQL Server Agent-service als deze nog niet is gestart.

2. In SQL Server Management Studio, selecteer je vanuit het menu Extra de optie Opties.

3. Selecteer op het tabblad AlwaysOn van SQL Server het door de gebruiker gedefinieerde AlwaysOn-beleid inschakelen en selecteer OK.

   Met deze instelling kunt u correct geconfigureerde aangepaste beleidsregels weergeven in het AlwaysOn-dashboard.

4. Maak een op beleid gebaseerde beheervoorwaarde met behulp van de volgende specificaties:

   • Naam: RTO
   • Facet-: databasereplicastatus
   • veld: Add(@EstimatedRecoveryTime, 60)
   • Operator: <=
   • waarde: 600

   Deze voorwaarde mislukt wanneer de mogelijke failovertijd langer is dan 10 minuten, inclusief een overhead van 60 seconden voor zowel foutdetectie als failover.

5. Maak een tweede op beleid gebaseerde beheervoorwaarde aan de hand van de volgende specificaties:

   • Naam: RPO
   • Facet: Database-Replica-Status
   • veld: @EstimatedDataLoss
   • Operator: <=
   • waarde: 3600

   Deze voorwaarde mislukt wanneer mogelijk gegevensverlies langer is dan 1 uur.

6. Maak een derde op beleid gebaseerde beheervoorwaarde met behulp van de volgende specificaties:

   • Naam: IsPrimaryReplica
   • Facet-: Beschikbaarheidsgroep
   • veld: @LocalReplicaRole
   • Operator: =
   • waarde: Primary

   Met deze voorwaarde wordt gecontroleerd of de lokale beschikbaarheidsreplica voor een bepaalde beschikbaarheidsgroep de primaire replica is.

7. Maak een op beleid gebaseerd beheerbeleid aan de hand van de volgende specificaties:

   • Algemeen pagina:

     • Naam: CustomSecondaryDatabaseRTO

     • Voorwaarde controleren: RTO

     • Tegen doelen: Elke DatabaseReplicaState in IsPrimaryReplica AvailabilityGroup

       Deze instelling zorgt ervoor dat het beleid alleen wordt geëvalueerd voor beschikbaarheidsgroepen waarvoor de lokale beschikbaarheidsreplica de primaire replica is.

       • Evaluatiemodus: Volgens planning

       • Schema: CollectorSchedule_Every_5min

       • ingeschakeld: geselecteerd

   • Beschrijving pagina

     • Categorie: waarschuwingen voor beschikbaarheidsdatabase

       Met deze instelling kunnen de resultaten van de beleidsevaluatie worden weergegeven in het AlwaysOn-dashboard.

       • Beschrijving: De huidige replica heeft een RTO die langer is dan 10 minuten, uitgaande van een overhead van 1 minuut voor detectie en failover. U moet prestatieproblemen op de desbetreffende serverinstantie onmiddellijk onderzoeken.

       • Tekst om weer te geven: RTO overschreden!

8. Maak een tweede beleid-gebaseerd beheerbeleid met behulp van de volgende specificaties:

   • Algemeen pagina:

     • Naam: CustomAvailabilityDatabaseRPO
     • Voorwaarde controleren: RPO
     • Tegen doelen: Elke DatabaseReplicaState in IsPrimaryReplica AvailabilityGroup
     • Evaluatiemodus: Volgens planning
     • Schema: Verzamelingsschema_elke_30_min
     • ingeschakeld: geselecteerd

   • Beschrijving pagina

     • Categorie: databasebeschikbaarheidswaarschuwingen

     • nl-NL: Beschrijving: De beschikbaarheidsdatabase heeft uw RPO van 1 uur overschreden. U moet onmiddellijk prestatieproblemen op de beschikbaarheidsreplica's onderzoeken.

     • Tekst omweer te geven: RPO overschreden!

Wanneer u klaar bent, worden er twee nieuwe SQL Server Agent-taken gemaakt, één voor elk van de planning voor beleidsevaluatie. Deze taken moeten namen hebben die beginnen met syspolicy_check_schedule.

U kunt de taakgeschiedenis bekijken om evaluatieresultaten te controleren. Evaluatiefouten worden ook vastgelegd in het Windows-toepassingslogboek (in de Logboeken) met de Event-ID 34052. U kunt SQL Server Agent ook configureren om waarschuwingen te verzenden over de beleidsfouten. Zie Waarschuwingen configureren om beleidsbeheerders op de hoogte te stellen van beleidsfouten voor meer informatie.

Scenario's voor het oplossen van prestatieproblemen

De volgende tabel bevat de veelvoorkomende scenario's voor het oplossen van problemen met betrekking tot prestaties.

Scenario	Beschrijving
Probleemoplossing: beschikbaarheidsgroep heeft de RTO overschreden	Na een automatische failover of een geplande handmatige failover zonder gegevensverlies overschrijdt de failovertijd uw RTO. Als u een schatting maakt van de failovertijd van een secundaire replica met synchrone confirmatie (zoals een automatische failoverpartner), merkt u dat deze uw RTO overschrijdt.
Problemen oplossen: Beschikbaarheidsgroep heeft de herstelpuntdoelstelling overschreden	Nadat u een geforceerde handmatige failover hebt uitgevoerd, is uw gegevensverlies meer dan uw RPO. Of wanneer u het potentiële gegevensverlies van een secundaire replica met asynchrone doorvoer berekent, merkt u dat deze de RPO overschrijdt.
Problemen oplossen: wijzigingen op de primaire replica worden niet weergegeven op de secundaire replica	De clienttoepassing voltooit een update op de primaire replica, maar bij het uitvoeren van een query op de secundaire replica ziet u dat de wijziging niet wordt weerspiegeld.

Nuttige uitgebreide gebeurtenissen

De volgende uitgebreide gebeurtenissen zijn handig bij het oplossen van problemen met replica's in de status Synchroniseren.

Gebeurtenisnaam	Categorie	Kanaal	Beschikbaarheidsreplica
redo_caught_up	Transacties	Fouten opsporen	Secundair
redo_worker_entry	Transacties	Debuggen	Secundair
hadr_transport_dump_message	alwayson	Debuggen	Primair
hadr_worker_pool_task	alwayson	Debuggen	Primair
hadr_dump_primary_progress	alwayson	Debuggen	Primair
hadr_dump_log_progress	alwayson	Fouten opsporen	Primair
hadr_undo_of_redo_log_scan	alwayson	Analytisch	Secundair