Superviser les performances des groupes de disponibilité Always On

S'applique à :SQL Server

La partie performance des groupes de disponibilité Always On est essentielle au respect du SLA (contrat de niveau de service) pour vos bases de données critiques. Le fait de comprendre comment les groupes de disponibilité envoient les journaux aux réplicas secondaires peut vous aider à estimer le RTO (objectif de temps de récupération) et le RPO (objectif de point de récupération) de votre implémentation de disponibilité et à identifier les goulots d’étranglement dans les groupes ou réplicas de disponibilité peu performants. Cet article décrit le processus de synchronisation, montre comment calculer certaines métriques clés et fournit des liens vers des scénarios courants de résolution de problèmes de performances.

Processus de synchronisation des données

Pour estimer le temps nécessaire à la synchronisation complète et identifier le goulot d’étranglement, vous devez comprendre le processus de synchronisation. Un goulot d’étranglement des performances peut se trouver n’importe où dans le processus, et sa localisation peut vous aider à explorer plus en détail les problèmes sous-jacents. La figure et le tableau suivants illustrent le processus de synchronisation de données :

Portes de contrôle de flux

Les groupes de disponibilité sont conçus avec des portes de contrôle de flux sur le réplica principal pour éviter toute consommation excessive des ressources, notamment les ressources réseau et mémoire, sur tous les réplicas de disponibilité. Ces portes de contrôle de flux n’affectent pas l’état d’intégrité de synchronisation des réplicas de disponibilité, mais elles peuvent affecter les performances globales de vos bases de données de disponibilité, y compris le RPO.

Une fois capturés sur le réplica principal, les journaux sont soumis à deux niveaux de contrôles de flux. Une fois le seuil de messages atteint sur l’une des portes, les messages de journal ne sont plus envoyés à un réplica spécifique ou pour une base de données spécifique. Les messages peuvent être envoyés après l’obtention des accusés de réception des messages envoyés afin de faire passer le nombre de messages envoyés sous le seuil.

En plus des portes de contrôle de flux, il existe un autre facteur qui pourrait empêcher l’envoi des messages de log. La synchronisation des réplicas garantit que les messages sont envoyés et appliqués dans l’ordre des LSN (numéros séquentiels dans le journal). Avant d’envoyer un message de journal, son numéro LSN est également vérifié par rapport au numéro LSN reconnu le plus bas pour vous assurer qu’il est inférieur à l’un des seuils (en fonction du type de message). Si l’écart entre les deux numéros LSN est supérieur au seuil, les messages ne sont pas envoyés. Quand l’intervalle est à nouveau sous le seuil, les messages sont envoyés.

SQL Server 2022 (16.x) augmente les limites du nombre de messages que chaque porte autorise. À compter des versions suivantes, utilisez l’indicateur de trace 12310 au démarrage pour augmenter la limite : SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18 et SQL Server 2016 (13.x) SP1 CU16. Cet indicateur de trace ne peut pas être utilisé avec DBCC TRACEON.

Le tableau suivant compare les nombres limites de messages :

Deux compteurs de performances utiles, SQL Server:Réplica de disponibilité > Contrôle de flux/s et SQL Server:Réplica de disponibilité > Durée du contrôle de flux (ms/s), vous montrent dans la dernière seconde écoulée le nombre de fois que le contrôle de flux a été activé et le temps passé à attendre le contrôle de flux. Plus le temps d’attente est élevé sur le contrôle de flux, plus le RPO est élevé. Pour plus d’informations sur les types de problèmes qui peuvent entraîner un temps d’attente élevé sur le contrôle de flux, consultez Résoudre les problèmes : Perte de données potentielle avec des réplicas de groupe de disponibilité à engagement asynchrone.

Estimer le temps de basculement (RTO)

Le RTO dans votre SLA dépend du temps de basculement de votre implémentation Always On à un moment donné. Il peut être calculé à l’aide de la formule suivante :

Le temps de détection d’échec (Tdetection) est le temps qu’il faut au système pour détecter la défaillance. Ce temps dépend des paramètres au niveau du cluster et non des réplicas de disponibilité individuels. En fonction de la condition de basculement automatique configurée, un basculement peut être déclenché comme réponse instantanée à une erreur interne SQL Server critique (par exemple, des verrouillages spinlock orphelins). Dans ce cas, la détection peut être aussi rapide que le rapport d’erreurs sp_server_diagnostics est envoyé au Cluster de basculement de Windows Server (WSFC). L’intervalle par défaut est 1/3 du délai d’expiration du contrôle d’intégrité. Un basculement peut également être déclenché en raison d’un délai d’attente, par exemple le délai d’expiration du contrôle d’intégrité du cluster a expiré (30 secondes par défaut) ou le bail entre la DLL de ressource et l’instance SQL Server a expiré (20 secondes par défaut). Dans ce cas, le temps de détection est aussi long que l’intervalle de délai d’attente. Pour plus d’informations, consultez Stratégie de basculement flexible pour le basculement automatique d’un groupe de disponibilité (SQL Server).

Pour que le réplica secondaire soit prêt pour le basculement, il suffit que la restauration par progression rattrape son retard et arrive à la fin du journal. Le temps de restauration par progression, Tredo, est calculé à l’aide de la formule suivante :

où redo_queue est la valeur dans redo_queue_size et redo_rate la valeur dans redo_rate.

La surcharge de temps de basculement, Toverhead, comprend le temps nécessaire pour basculer le cluster WSFC et placer les bases de données en ligne. Ce temps est généralement court et constant.

Estimer la perte de données potentielle (RPO)

Le RPO dans votre SLA dépend du risque de perte de données de votre implémentation Always On à un moment donné. Ce risque de perte de données peut être calculé à l’aide de la formule suivante :

où log_send_queue est la valeur de log_send_queue_size et log generation rate la valeur de SQL Server:Base de données > Octets de journal vidés/s.

La file d’attente d’envoi du journal représente toutes les données pouvant être perdues en raison d’une défaillance catastrophique. À première vue, il est curieux que le taux de génération du journal soit utilisé au lieu du taux d’envoi du journal (voir log_send_rate). Toutefois, n'oubliez pas que l'utilisation du taux de transmission du journal vous donne uniquement le temps de synchronisation, tandis que le RPO mesure la perte de données en fonction de la vitesse à laquelle elles sont générées, et non de la vitesse à laquelle elles sont synchronisées.

Un moyen plus simple d’estimer Tdata_loss consiste à utiliser last_commit_time. La DMV sur le réplica principal fournit cette valeur pour tous les réplicas. Vous pouvez calculer la différence entre la valeur du réplica principal et celle du réplica secondaire pour estimer la vitesse à laquelle le journal sur le réplica secondaire rattrape son retard par rapport au réplica principal. Comme indiqué précédemment, ce calcul ne vous indique pas la perte de données potentielle en fonction de la vitesse à laquelle le journal est généré, mais il doit s’agir d’une approximation étroite.

Estimer le RTO et le RPO avec le tableau de bord SSMS

Dans les groupes de disponibilité Always On, le RTO et le RPO sont calculés et affichés pour les bases de données hébergées sur les réplicas secondaires. Dans le tableau de bord SSMS (SQL Server Management Studio), sur le réplica principal, le RTO et le RPO sont associés au réplica secondaire.

Pour afficher le RTO et le RPO dans le tableau de bord, procédez comme suit :

1. Dans SQL Server Management Studio, développez le nœud Haute disponibilité Always On, cliquez avec le bouton droit sur le nom de votre groupe de disponibilité et sélectionnez Afficher le tableau de bord.

2. Sélectionnez Ajouter/Supprimer des colonnes sous l’onglet Regrouper par. Cochez à la fois Temps de récupération estimé (en secondes) [RTO] et Perte de données estimée (temps) [RPO].

   

Calcul du RTO de base de données secondaire

Le calcul du temps de récupération détermine la durée nécessaire pour récupérer la base de données secondaire après un basculement. Ce temps de basculement est généralement court et constant. Le temps de détection dépend des paramètres au niveau du cluster et non des réplicas de disponibilité individuels.

Pour une base de données secondaire (DB_sec), le calcul et l’affichage de son RTO sont basés sur son redo_queue_size et redo_rate:

À l’exception des cas extrêmes, la formule pour calculer le RTO d’une base de données secondaire est :

Calcul du RPO d’une base de données secondaire

Pour une base de données secondaire (DB_sec), le calcul et l'affichage de son RPO sont basés sur ses valeurs de is_failover_ready, et sur celles de la base de données primaire corrélée (last_commit_time), DB_pri. Lorsque la valeur est DB_sec.is_failover_ready1, les données entre les fichiers principaux et secondaires sont synchronisées et aucune perte de données ne se produit lors du basculement. Toutefois, si cette valeur est 0, il existe un écart entre la last_commit_time base de données primaire et la last_commit_time base de données secondaire.

Pour la base de données primaire, il last_commit_time s’agit de l’heure à laquelle la dernière transaction a été validée. Pour la base de données secondaire, le last_commit_time correspond à l'heure de la dernière validation de la transaction provenant de la base de données primaire, qui a également été finalisée sur la base de données secondaire. Ce nombre est identique pour la base de données primaire et secondaire. Toutefois, un écart entre ces deux valeurs est la durée pendant laquelle les transactions en attente n’ont pas été renforcées sur la base de données secondaire et peuvent être perdues en cas de basculement.

Métriques de performances utilisées dans les formules RTO/RPO

• redo_queue_size (Ko) : la taille de file d'attente de redo, utilisée dans le Recovery Time Objective (RTO), correspond à la taille des journaux de transaction entre son last_received_lsn et last_redone_lsn. La last_received_lsn valeur est l’ID de bloc de journal identifiant le point jusqu’à lequel tous les blocs de journal ont été reçus par le réplica secondaire qui héberge cette base de données secondaire. La valeur de last_redone_lsn est le numéro de séquence du journal associé au dernier enregistrement de journal qui a été réappliqué sur la base de données secondaire. En fonction de ces deux valeurs, nous pouvons trouver les ID du bloc de journal de démarrage (last_received_lsn) et le bloc de journal final (last_redone_lsn). L’espace entre ces deux blocs de journal peut ensuite représenter le nombre de blocs de journal des transactions qui ne sont pas encore restaurés. C’est mesuré en kilo-octets (Ko).

• redo_rate (Ko/s) : Utilisé dans le calcul du RTO, il s'agit d'une valeur cumulative qui montre combien du journal des transactions (Ko) a été refait ou réappliqué sur la base de données secondaire par seconde.

• last_commit_time (datetime) : utilisée dans le RPO, cette valeur a une signification différente entre la base de données primaire et secondaire. Pour la base de données primaire, last_commit_time est l’heure à laquelle la dernière transaction a été validée. Pour la base de données secondaire, last_commit_time représente la dernière validation de la transaction effectuée sur la base de données primaire, qui a également été écrite de manière durable sur la base de données secondaire. Étant donné que cette valeur sur la base de données secondaire doit être synchronisée avec la même valeur que celle sur la base de données primaire, tout écart entre ces deux valeurs est l’estimation de la perte de données (RPO).

Estimer le RTO et le RPO à l’aide de vues DMV

Il est possible d’interroger les DMV sys.dm_hadr_database_replica_states et sys.dm_hadr_database_replica_cluster_states pour estimer le RPO et le RTO d’une base de données. Les requêtes ci-dessous créent les procédures stockées qui accomplissent les deux choses.

Créer une procédure stockée pour estimer le RTO

1. Sur le réplica secondaire cible, créez une procédure stockée proc_calculate_RTO. Si cette procédure stockée existe déjà, commencez par la supprimer, puis recréez-la.

   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. Exécutez proc_calculate_RTO avec le nom de la base de données secondaire cible :

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. La sortie affiche la valeur RTO de la base de données du réplica secondaire cible. Enregistrez les group_id, replica_id et group_database_id pour les utiliser avec la procédure stockée d’estimation de RPO.

   Exemple de sortie :

   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
   

Créer une procédure stockée pour estimer le RPO

1. Sur le réplica principal, créez une procédure stockée proc_calculate_RPO. Si elle existe déjà, commencez par la supprimer, puis recréez-la.

   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. Exécutez proc_calculate_RPO avec les group_id, replica_id et group_database_id de la base de données secondaire cible.

   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. La sortie affiche la valeur RPO de la base de données du réplica secondaire cible.

Surveiller le RTO et le RPO

Cette section montre comment monitorer les métriques RTO et RPO des groupes de disponibilité. Cette démonstration est similaire au tutoriel de l’interface graphique utilisateur présenté dans The Always On health model, part 2: Extending the health model (Modèle d’intégrité Always On Partie 2 : Extension du modèle d’intégrité).

Les éléments relatifs au temps de basculement et aux calculs de perte de données potentielle dans l’estimation du temps de basculement (RTO) et l’estimation de la perte de données potentielle (RPO) sont commodément fournis sous forme de métrique de performance dans la facette de gestion des stratégies de l'état du réplica de base de données. Pour plus d’informations, consultez Afficher les facettes de gestion basée sur des stratégies sur un objet SQL Server. Vous pouvez monitorer ces deux métriques selon une planification et recevoir une alerte quand elles dépassent le RTO et le RPO, respectivement.

Les scripts présentés créent deux stratégies système qui sont exécutées selon leur planification respective, avec les caractéristiques suivantes :

• Une stratégie RTO échoue quand le temps de basculement estimé est supérieur à 10 minutes (évaluation toutes les 5 minutes)

• Une stratégie RPO échoue quand la perte de données estimée est supérieure à 1 heure (évaluation toutes les 30 minutes)

• Les deux stratégies ont la même configuration sur tous les réplicas de disponibilité

• Les stratégies sont évaluées sur tous les serveurs, mais uniquement sur les groupes de disponibilité pour lesquels le réplica de disponibilité local est le réplica principal. Si le réplica de disponibilité local n’est pas le réplica principal, les stratégies ne sont pas évaluées.

• Les échecs de stratégies sont clairement présentés dans le tableau de bord Always On affiché sur le réplica principal.

Pour créer les stratégies, suivez ces instructions sur toutes les instances de serveur qui participent au groupe de disponibilité :

1. Démarrez le service SQL Server Agent s’il n’est pas déjà démarré.

2. Dans SQL Server Management Studio, dans le menu Outils , sélectionnez Options.

3. Sous l’onglet Always On SQL Server , sélectionnez Activer la stratégie Always On définie par l’utilisateur et sélectionnez OK.

   Ce paramètre vous permet d’afficher les stratégies personnalisées correctement configurées dans le tableau de bord Always On.

4. Créez une condition de gestion basée sur la stratégie à l’aide des spécifications suivantes :

   • Nom : RTO
   • Facette : État du réplica de base de données
   • Champ : Add(@EstimatedRecoveryTime, 60)
   • Opérateur : <=
   • Valeur : 600

   Cette condition échoue lorsque le temps de basculement potentiel dépasse 10 minutes, y compris une surcharge de 60 secondes pour la détection des défaillances et le basculement.

5. Créez une deuxième condition de gestion basée sur la stratégie à l’aide des spécifications suivantes :

   • Nom : RPO
   • Facette : État du réplica de base de données
   • Champ : @EstimatedDataLoss
   • Opérateur : <=
   • Valeur : 3600

   Cette condition échoue quand la perte de données potentielle est supérieure à 1 heure.

6. Créez une troisième condition de gestion basée sur la stratégie à l’aide des spécifications suivantes :

   • Nom : IsPrimaryReplica
   • Facette : Groupe de disponibilité
   • Champ : @LocalReplicaRole
   • Opérateur : =
   • Valeur : Primary

   Cette condition vérifie si le réplica de disponibilité local pour un groupe de disponibilité donné est le réplica principal.

7. Créez une stratégie de gestion basée sur la stratégie à l’aide des spécifications suivantes :

   • Page Général :

     • Nom : CustomSecondaryDatabaseRTO

     • Vérifier la condition : RTO

     • Par rapport aux cibles : Chaque DatabaseReplicaState dans IsPrimaryReplica AvailabilityGroup

       Ce paramètre garantit que la stratégie est évaluée uniquement sur les groupes de disponibilité pour lesquels le réplica de disponibilité local est le réplica principal.

       • Mode d’évaluation : Selon planification

       • Planification : CollectorSchedule_Every_5min

       • Activé : Sélectionné

   • Page Description :

     • Catégorie : Avertissements de base de données de disponibilité

       Ce paramètre permet d’afficher les résultats de l’évaluation de la stratégie dans le tableau de bord Always On.

       • Description : Le réplica actuel a un RTO supérieur à 10 minutes, avec pour hypothèse une surcharge de 1 minute pour la détection et le basculement. Vous devez examiner immédiatement les problèmes de performances sur l’instance de serveur respective.

       • Texte à afficher : RTO dépassé !

8. Créez une deuxième stratégie de gestion basée sur la stratégie à l’aide des spécifications suivantes :

   • Page Général :

     • Nom : CustomAvailabilityDatabaseRPO
     • Vérifier la condition : RPO
     • Par rapport aux cibles : Chaque DatabaseReplicaState dans IsPrimaryReplica AvailabilityGroup
     • Mode d’évaluation : Selon planification
     • Planification : CollectorSchedule_Every_30min
     • Activé : Sélectionné

   • Page Description :

     • Catégorie : Avertissements de base de données de disponibilité

     • Description : La base de données de disponibilité a dépassé votre RPO de 1 heure. Vous devez immédiatement examiner les problèmes de performances sur les réplicas de disponibilité.

     • Texte à afficher : RPO dépassé !

Lorsque vous avez terminé, deux nouvelles tâches SQL Server Agent sont créées, une pour chaque planification d'évaluation de la stratégie. Ces travaux doivent avoir des noms qui commencent par syspolicy_check_schedule.

Vous pouvez afficher l’historique des travaux pour examiner les résultats de l’évaluation. Les échecs d’évaluation sont également enregistrés dans le journal des applications Windows (dans l’observateur d’événements) avec l’ID d’événement 34052. Vous pouvez également configurer SQL Server Agent de manière à ce qu’il envoie des alertes en cas d’échec de stratégie. Pour plus d’informations, consultez Configurer des alertes pour avertir les administrateurs de stratégie des échecs de stratégie.

Scénarios de résolution des problèmes de performances

Le tableau suivant répertorie les scénarios courants de résolution des problèmes liés aux performances.

Événements étendus utiles

Les événements étendus suivants sont utiles dans le cadre de la résolution des problèmes liés aux réplicas dans l’état Synchronisation.