Supervisar el rendimiento de los grupos de disponibilidad Always On

Se aplica a:SQL Server

El aspecto del rendimiento de los grupos de disponibilidad Always On es fundamental para mantener el acuerdo de nivel de servicio (SLA) de sus bases de datos de misión crítica. Comprender cómo los grupos de disponibilidad envían los registros a las réplicas secundarias puede ayudarle a estimar el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) de su implementación de disponibilidad, así como a identificar cuellos de botella en grupos de disponibilidad o réplicas con bajo rendimiento. En este artículo se explica el proceso de sincronización, se muestra cómo calcular algunas de las métricas clave y se proporcionan vínculos a algunos de los escenarios de solución de problemas de rendimiento comunes.

Proceso de sincronización de datos

Para estimar el tiempo necesario para una sincronización completa e identificar el cuello de botella, debe comprender el proceso de sincronización. Un cuello de botella del rendimiento puede estar en cualquier punto del proceso, y localizarlo puede ayudar a profundizar en los problemas subyacentes. En la ilustración y la tabla siguientes se muestra el proceso de sincronización de datos:

Puertas de control de flujo

Los grupos de disponibilidad se diseñan con puertas de control de flujo en la réplica principal para evitar un uso excesivo de recursos, por ejemplo de red y memoria, en todas las réplicas de disponibilidad. Estas compuertas de control de flujo no afectan al estado de sincronización de las réplicas de disponibilidad, pero pueden afectar al rendimiento general de las bases de datos de disponibilidad, incluido el RPO.

Una vez capturados los registros en la réplica principal, están sujetos a dos niveles de control de flujo. Una vez que se alcanza el umbral de mensajes de cualquier puerta, los mensajes de registro ya no se envían a una réplica determinada ni para una base de datos concreta. Los mensajes pueden enviarse una vez que se reciben los mensajes de confirmación de los mensajes enviados, a fin de reducir el número de mensajes enviados por debajo del umbral.

Además de las puertas de control de flujo, hay otro factor que puede impedir que se envíen los mensajes de registro. La sincronización de réplicas garantiza que los mensajes se envíen y se apliquen en el orden de los números de secuencia de registro (LSN). Antes de que se envíe un mensaje de registro, el LSN del mensaje se comprueba en relación con el número de LSN más bajo confirmado, para verificar que es más bajo que uno de los umbrales (según el tipo de mensaje). Si la diferencia entre los dos números LSN es mayor que el umbral, los mensajes no se envían. Una vez que la diferencia vuelve a estar por debajo del umbral, se envían los mensajes.

SQL Server 2022 (16.x) aumenta los límites al número de mensajes que permite cada puerta. A partir de las siguientes versiones, use la marca de seguimiento 12310 al inicio para aumentar el límite: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18 y SQL Server 2016 (13.x) SP1 CU16. Esta marca de seguimiento no se puede usar con DBCC TRACEON.

En la tabla siguiente se comparan los límites de mensajes:

Dos útiles contadores de rendimiento, SQL Server: Réplica de disponibilidad > Control de flujo/s y SQL Server: Réplica de disponibilidad > Tiempo de control de flujo (ms/s), muestran, durante el último segundo, cuántas veces se ha activado el control de flujo y cuánto tiempo se ha esperado en el control de flujo. Un mayor tiempo de espera en el control de flujo se traduce en un RPO superior. Para obtener más información sobre los tipos de problemas que pueden provocar un tiempo de espera elevado en el control de flujo, consulte Solución de problemas: Posible pérdida de datos con réplicas de grupo de disponibilidad de confirmación asincrónica.

Estimación del tiempo de conmutación por error (RTO)

El RTO de su SLA depende del tiempo de conmutación por error de su implementación de Always On en un momento dado, lo que puede expresarse mediante la siguiente fórmula:

El tiempo de detección de errores, Tdetection, es el tiempo que tarda el sistema en detectar el error. Este tiempo depende de la configuración del clúster y no de las réplicas de disponibilidad individuales. Según la condición de conmutación automática por error configurada, una conmutación por error se puede desencadenar como una respuesta inmediata a un error interno de SQL Server crítico, como un bloqueo por subproceso huérfano. En este caso, la detección puede ser tan rápida como cuando se envía el informe de errores de sp_server_diagnostics al clúster de conmutación por error de Windows Server (WSFC). El intervalo predeterminado es 1/3 del tiempo de espera de la comprobación de estado. También se puede desencadenar una conmutación por error debido a un tiempo de espera, como el tiempo de espera de comprobación de estado del clúster ha expirado (30 segundos de forma predeterminada) o la concesión entre el archivo DLL de recursos y la instancia de SQL Server ha expirado (20 segundos de forma predeterminada). En este caso, el tiempo de detección dura tanto como el tiempo de espera. Para obtener más información, consulte Directiva de conmutación por error flexible para la conmutación automática por error de un grupo de disponibilidad (SQL Server).

Lo único que la réplica secundaria necesita hacer para estar lista para una conmutación por error es que el redo se ponga al día hasta el final del registro. El tiempo de rehacer, Tredo, se calcula mediante la siguiente fórmula:

donde redo_queue es el valor de redo_queue_size y redo_rate es el valor de redo_rate.

El tiempo de sobrecarga de la conmutación por error, Toverhead, incluye el tiempo necesario para realizar la conmutación por error del clúster WSFC y poner en línea las bases de datos. Este tiempo suele ser breve y constante.

Estimación de la posible pérdida de datos (RPO)

El RPO de su SLA depende de la posible pérdida de datos que pueda producirse en su implementación de Always On en cualquier momento. Esta posible pérdida de datos se puede expresar en la siguiente fórmula:

donde log_send_queue es el valor de log_send_queue_size y tasa de generación de registros es el valor de SQL Server:Database > Log Bytes Flushed/sec.

La cola de envío del registro representa todos los datos que pueden perderse en caso de un fallo catastrófico. A primera vista, es curioso que se use la tasa de generación de registros en lugar de la velocidad de envío de registros (consulte log_send_rate). Sin embargo, recuerde que el uso de la velocidad de envío del registro solo proporciona el tiempo de sincronización, mientras que el RPO mide la pérdida de datos en función de la rapidez con la que se genera, no en la rapidez con la que se sincroniza.

Una manera más sencilla de estimar Tdata_loss es usar last_commit_time. La DMV en la réplica principal informa de este valor para todas las réplicas. Puede calcular la diferencia entre el valor de la réplica principal y el de la réplica secundaria para estimar la velocidad con que el registro de la réplica secundaria alcanza a la réplica principal. Como se indicó anteriormente, este cálculo no indica la posible pérdida de datos en función de la rapidez con la que se genera el registro, pero debe ser una aproximación cercana.

Estimación del RTO y el RPO con el panel de SSMS

En los Grupos de Disponibilidad Always On, el RTO y el RPO se calculan y muestran para las bases de datos alojadas en las réplicas secundarias. En el panel de administración de SQL Server Management Studio (SSMS), en la réplica principal, el RTO y el RPO se agrupan por la réplica secundaria.

Para ver el RTO y el RPO en el panel, siga estos pasos:

1. En SQL Server Management Studio, expanda el nodo Alta disponibilidad de Always On, haga clic con el botón derecho en el nombre del grupo de disponibilidad y seleccione Mostrar panel.

2. Seleccione Agregar o quitar columnas en la pestaña Agrupar por. Active Tiempo de recuperación calculado (segundos) [RTO] y Pérdida de datos calculada (tiempo) [RPO].

   

Cálculo del RTO de la base de datos secundaria

El cálculo del tiempo de recuperación determina cuánto tiempo se necesita para recuperar la base de datos secundaria después de que s e produzca una conmutación por error. El tiempo de conmutación por error suele ser breve y constante. El tiempo de detección depende de la configuración del clúster y no de las réplicas de disponibilidad individuales.

Para una base de datos secundaria (DB_sec), el cálculo y la presentación de su RTO se basa en sus redo_queue_size y redo_rate:

Salvo en casos excepcionales, la fórmula para calcular el RTO de la base de datos secundaria es la siguiente:

Cálculo del RPO de la base de datos secundaria

Para una base de datos secundaria (DB_sec), el cálculo y la presentación de su RPO se basan en sus is_failover_ready, last_commit_time y los valores DB_pri de su base de datos principal correlacionada (last_commit_time). Cuando el valor de DB_sec.is_failover_ready es 1, se sincronizan los datos entre las secundarias y principales y no se produce ninguna pérdida de datos tras la conmutación por error. Sin embargo, si este valor es 0, hay un intervalo entre en la last_commit_time base de datos principal y en la last_commit_time base de datos secundaria.

Para la base de datos principal, last_commit_time es la hora en que se ha confirmado la transacción más reciente. Para la base de datos secundaria, last_commit_time es la hora de confirmación más reciente de la transacción de la base de datos principal que también se ha protegido correctamente en la base de datos secundaria. Este número es el mismo para la base de datos principal y secundaria. Sin embargo, una diferencia entre estos dos valores es la duración durante la cual las transacciones pendientes no se han confirmado en la base de datos secundaria y podrían perderse en caso de un error.

Métricas de rendimiento usadas en fórmulas RTO/RPO

• redo_queue_size (KB): El tamaño de la cola de repetición, utilizada en RTO, es el tamaño de los registros de transacciones entre sus last_received_lsn y last_redone_lsn. El last_received_lsn valor es el identificador de bloque de registro que identifica hasta el punto en el que todos los bloques de registro han sido recibidos por la réplica secundaria que hospeda esta base de datos secundaria. El valor de last_redone_lsn es el número de secuencia de registro del último registro que se rehizo en la base de datos secundaria. En función de estos dos valores, podemos encontrar identificadores del bloque de registro de inicio (last_received_lsn) y el bloque de registro final (last_redone_lsn). El espacio entre estos dos bloques de registro puede representar el número de bloques de registro de transacciones que aún no se rehacen. Esto se mide en kilobytes (KB).

• redo_rate (KB/s): Este valor acumulativo, utilizado en el cálculo de RTO, muestra cuánta parte del registro de transacciones (en KB) se ha rehecho o reproducido en la base de datos secundaria por segundo.

• last_commit_time (datetime): se usa en RPO, este valor tiene un significado diferente entre la base de datos principal y secundaria. Para la base de datos principal, last_commit_time es la hora en que se confirmó la transacción más reciente. Para la base de datos secundaria, last_commit_time es la confirmación más reciente de la transacción en la base de datos principal, la cual ha sido correctamente consolidada en la base de datos secundaria. Como en la base de datos secundaria este valor se debe sincronizar con el mismo valor de la principal, cualquier diferencia entre estos dos valores es la estimación de la pérdida de datos (RPO).

Estimar el RTO y el RPO mediante las DMV

Es posible consultar las DMV sys.dm_hadr_database_replica_states y sys.dm_hadr_database_replica_cluster_states para calcular el RPO y el RTO de una base de datos. Las consultas siguientes crean procedimientos almacenados que realizan las dos operaciones.

Creación de un procedimiento almacenado para calcular el RTO

1. En la réplica secundaria de destino, cree el procedimiento almacenado proc_calculate_RTO. Si este procedimiento almacenado ya existe, primero debe eliminarlo y después volver a crearlo.

   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. Ejecute proc_calculate_RTO con el nombre de la base de datos secundaria de destino:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

3. En la salida se muestra el valor de RTO de la base de datos de réplica secundaria de destino. Guarde los valores group_id, replica_id y group_database_id para usarlos con el procedimiento almacenado de estimación del RPO.

   Salida de ejemplo:

   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
   

Creación de un procedimiento almacenado para calcular el RPO

1. En la réplica principal, cree el procedimiento almacenado proc_calculate_RPO. Si ya existe, primero debe eliminarlo y, después, volver a crearlo.

   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. Ejecute proc_calculate_RPO con la group_id, replica_id y group_database_id de la base de datos secundaria de destino.

   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. En la salida se muestra el valor de RPO de la base de datos de réplica secundaria de destino.

Supervisión de RTO y RPO

En esta sección se muestra cómo supervisar las métricas RTO y RPO de los grupos de disponibilidad. Esta demostración es similar al tutorial de GUI proporcionado en The Always On health model, part 2: Extending the health model (El modelo de estado de Always On, parte 2: extensión del modelo de estado).

Los elementos del tiempo de conmutación por error y los posibles cálculos de pérdida de datos en Estimación del tiempo de conmutación por error (RTO) y Estimación de la posible pérdida de datos (RPO) se proporcionan convenientemente como métricas de rendimiento en la faceta de administración de directivas Estado de réplica de base de datos. Para obtener más información, vea Ver facetas de administración basada en directivas en un objeto de SQL Server. Puede supervisar estas dos métricas según una programación y recibir alertas cuando superen el RTO y el RPO, respectivamente.

Los scripts que se muestran crean dos directivas del sistema que se ejecutan según sus respectivas programaciones, con las siguientes características:

• Una directiva de RTO que falla cuando el tiempo estimado de conmutación por error supera 10 minutos, evaluada cada 5 minutos

• Una directiva de RPO que da error cuando la pérdida de datos estimada supera 1 hora, evaluada cada 30 minutos

• Las dos políticas tienen la misma configuración en todas las réplicas de disponibilidad

• Las directivas se evalúan en todos los servidores, pero solo en los grupos de disponibilidad en los que la réplica de disponibilidad local es la réplica principal. Si la réplica de disponibilidad local no es la réplica principal, las políticas no se evalúan.

• Los errores de directiva se muestran de forma práctica en el panel de Always On al visualizarlo en la réplica principal.

Para crear las directivas, siga estas instrucciones en todas las instancias de servidor que participan en el grupo de disponibilidad:

1. Inicie el servicio agente SQL Server si aún no se ha iniciado.

2. En SQL Server Management Studio, en el menú Herramientas , seleccione Opciones.

3. En la pestaña AlwaysOn de SQL Server , seleccione Habilitar directiva AlwaysOn definida por el usuario y seleccione Aceptar.

   Esta configuración permite mostrar las directivas personalizadas configuradas correctamente en el panel Always On.

4. Cree una condición de administración basada en directivas con las especificaciones siguientes:

   • Nombre: RTO
   • Faceta: Estado de la réplica de base de datos
   • Campo: Add(@EstimatedRecoveryTime, 60)
   • Operador: <=
   • Valor: 600

   Esta condición produce un error cuando el tiempo de conmutación por error potencial supera los 10 minutos, incluida una sobrecarga de 60 segundos para la detección de errores y la conmutación por error.

5. Cree una segunda condición de administración basada en directivas con las especificaciones siguientes:

   • Nombre: RPO
   • Faceta: Estado de la réplica de la base de datos
   • Campo: @EstimatedDataLoss
   • Operador: <=
   • Valor: 3600

   Se produce un error en esta condición cuando la posible pérdida de datos supera 1 hora.

6. Cree una tercera condición de administración basada en directivas con las especificaciones siguientes:

   • Nombre: IsPrimaryReplica
   • Faceta: Grupo de disponibilidad
   • Campo: @LocalReplicaRole
   • Operador: =
   • Valor: Primary

   Esta condición comprueba si la réplica de disponibilidad local de un grupo de disponibilidad determinado es la réplica principal.

7. Cree una directiva de administración basada en directivas con las especificaciones siguientes:

   • Página General:

     • Nombre: CustomSecondaryDatabaseRTO

     • Condición de comprobación: RTO

     • En comparación con los destinos: Cada DatabaseReplicaState en IsPrimaryReplica AvailabilityGroup

       Esta configuración garantiza que la directiva se evalúe solo en los grupos de disponibilidad en los que la réplica de disponibilidad local es la réplica principal.

       • Modo de evaluación: Según lo programado

       • Programación: CollectorSchedule_Every_5min

       • Habilitado: seleccionado

   • Página Descripción:

     • Categoría: Advertencias de base de datos de disponibilidad

       Esta configuración permite que los resultados de evaluación de directivas se muestren en el panel Always On.

       • Descripción: La réplica actual tiene un RTO que supera los 10 minutos, asumiendo una sobrecarga de 1 minuto para la detección y la conmutación por error. Debe investigar los problemas de rendimiento en la instancia de servidor respectiva inmediatamente.

       • Texto para mostrar: RTO Superado!

8. Cree una segunda directiva de administración basada en directivas con las especificaciones siguientes:

   • Página General:

     • Nombre: CustomAvailabilityDatabaseRPO
     • Condición de comprobación: RPO
     • Con respecto a los destinos: Cada DatabaseReplicaState en IsPrimaryReplica AvailabilityGroup
     • Modo de evaluación: Según lo previsto
     • Programación: CollectorSchedule_Every_30min
     • Habilitado: seleccionado

   • Página Descripción:

     • Categoría: Advertencias de base de datos de disponibilidad

     • Descripción: La base de datos de disponibilidad ha superado su RPO de 1 hora. Debe investigar de inmediato los problemas de rendimiento de las réplicas de disponibilidad.

     • Texto para mostrar: RPO superado

Cuando haya terminado, se crean dos nuevos trabajos del Agente SQL Server, uno para cada una de las programaciones de evaluación de directivas. Estos trabajos deben tener nombres que comiencen por syspolicy_check_schedule.

Puede ver el historial de trabajos para inspeccionar los resultados de la evaluación. Los errores de evaluación también se registran en el registro de aplicaciones de Windows (en el Visor de eventos) con el Id. de evento 34052. También puede configurar el Agente SQL Server para enviar alertas sobre los errores de directiva. Para obtener más información, vea Configurar alertas para notificar a los administradores de directivas los errores de directiva.

Escenarios de solución de problemas de rendimiento

En la tabla siguiente se enumeran los escenarios de solución de problemas relacionados con el rendimiento comunes.

Eventos extendidos útiles

Los siguientes eventos extendidos son útiles para solucionar problemas de réplicas en el estado Sincronizando.