Supervisión del rendimiento para grupos de disponibilidad Always On

Se aplica a:SQL Server

El rendimiento de los grupos de disponibilidad Always On es vital para mantener el contrato de nivel de servicio (SLA) de las bases de datos de críticas. La comprensión de cómo envían los registros los grupos de disponibilidad a las réplicas secundarias puede ayudar a estimar el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) de la implementación de disponibilidad y a identificar cuellos de botella en grupos de disponibilidad o réplicas con un mal 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 de rendimiento puede estar en cualquier fase del proceso; su detección 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:

Secuencia	Descripción del paso	Comentarios	Métricas de utilidad
1	Generación de registro	Los datos del registro se vacían en el disco. Este registro se debe replicar en las réplicas secundarias. Las entradas del registro entran en la cola de envío.	SQL Server:Bytes del registro de la base de datos > liberados por segundo
2	Capturar	Los registros de cada base de datos se capturan y envían a la cola de asociados correspondiente (una por par de réplica de base de datos). Este proceso de captura se ejecuta de manera continua mientras la réplica de disponibilidad esté conectada y el movimiento de datos no se suspenda por ninguna razón, y el par réplica-base de datos se muestre como Sincronizando o Sincronizado. Si el proceso de captura no puede escanear y poner en cola los mensajes con la suficiente rapidez, la cola de envío de registros se acumula.	SQL Server: Réplica de Disponibilidad > Bytes enviados a réplica por segundo, que es el total agregado de todos los mensajes de base de datos en cola para esa réplica de disponibilidad. log_send_queue_size (KB) y log_bytes_send_rate (KB/s) en la réplica principal.
3	Envío	Los mensajes de cada cola de réplica de base de datos se desencolan y se envían a través del cable a la réplica secundaria correspondiente.	SQL Server:Bytes enviados al transporte por segundo desde la réplica de disponibilidad>
4	Recepción y almacenamiento en caché	Cada réplica secundaria recibe y almacena en caché el mensaje.	Contador de rendimiento SQL Server: Réplica de disponibilidad > Bytes de registro recibidos/s
5	Protección	El registro se vacía en la réplica secundaria para su protección. Tras el vaciado del registro, se envía una confirmación a la réplica principal. Una vez protegido el registro, se evita la pérdida de datos.	Contador de rendimiento SQL Server: Base de datos > Bytes de registro vaciados/s Tipo de espera HADR_LOGCAPTURE_SYNC
6	Rehacer	Las páginas vaciadas se ponen al día en la réplica secundaria. Las páginas se mantienen en la cola de puesta al día mientras esperan.	SQL Server: Réplica de base de datos > Bytes puestos al día/s redo_queue_size (KB) y redo_rate. Tipo de espera REDO_SYNC

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:

Nuevos límites

Para las versiones de SQL Server que habilitan la marca de seguimiento 12310, es decir, SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 y versiones posteriores, consulte los siguientes límites:

Nivel	Número de puertas	Número de mensajes	Métricas de utilidad
Transporte	1 por réplica de disponibilidad	16384	Evento extendido database_transport_flow_control_action
Base de datos	1 por base de datos de disponibilidad	7168	DBMIRROR_SEND Evento extendido hadron_database_flow_control_action

Límites anteriores

Para versiones de SQL Server no admitidas o versiones de SQL Server compatibles (a partir de SQL Server 2019 CU9, SQL Server 2017 CU18 y SQL Server 2016 SP1 CU16) que no tienen habilitada la marca de seguimiento 12310, consulte los límites siguientes:

Nivel	Número de puertas	Número de mensajes	Métricas de utilidad
Transporte	1 por réplica de disponibilidad	8192	Evento extendido database_transport_flow_control_action
Base de datos	1 por base de datos de disponibilidad	1792 (x64) 1600 (x86)	DBMIRROR_SEND Evento extendido hadron_database_flow_control_action

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 del SLA depende del tiempo de conmutación por error de la implementación de Always On en un momento dado, que se puede expresar en la siguiente fórmula:

Importante

Si un grupo de disponibilidad contiene más de una base de datos de disponibilidad, aquella con el valor Tfailover más alto se convierte en el valor límite para el cumplimiento del RTO.

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, vea Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server).

Lo único que la réplica secundaria tiene que hacer para prepararse para una conmutación por error es que la fase de puesta al día alcance el final del registro. El tiempo de fase de puesta al día, 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 conmutación por error, Toverhead, incluye el tiempo necesario para conmutar por error el 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 del SLA depende de la posible pérdida de datos de la implementación de Always On en un momento dado. 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 log generation rate es el valor de SQL Server: Base de datos > Bytes de registro vaciados/s.

Advertencia

Si un grupo de disponibilidad contiene más de una base de datos de disponibilidad, aquella con el valor Tdata_loss más alto se convierte en el valor límite para el cumplimiento del RPO.

La cola de envío de registro representa todos los datos que se pueden perder a causa de un error irrecuperable. 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 de la réplica principal notifica 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).

Estimación de RTO y RPO mediante 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.

Nota

Asegúrese de crear y ejecutar el procedimiento almacenado para estimar el RTO en primer lugar, ya que los valores que genera son necesarios para ejecutar el procedimiento almacenado para calcular el RPO.

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 da error cuando el tiempo estimado de conmutación por error supera los 10 minutos, evaluado 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 directivas tienen una configuración idéntica en todas las réplicas de disponibilidad

• Las directivas se evalúan en todos los servidores, pero solo en los grupos de disponibilidad cuya 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 las directivas se muestran en el panel Always On cuando se abre 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 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

     • Para destinos:Cada DatabaseReplicaState en IsPrimaryReplica AvailabilityGroup

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

       • Modo de evaluación:Al programar

       • 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
     • Para destinos:Cada DatabaseReplicaState en IsPrimaryReplica AvailabilityGroup
     • Modo de evaluación:Al programar
     • 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 el RPO de 1 hora. Debe investigar los problemas de rendimiento en las réplicas de disponibilidad inmediatamente.

     • 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.

Escenario	Descripción
Solución de problemas: el grupo de disponibilidad superó el RTO	Después de una conmutación por error automática o una manual planeada sin pérdida de datos, el tiempo de conmutación por error supera el RTO. O bien, al estimar el tiempo de conmutación por error de una réplica secundaria de confirmación sincrónica (por ejemplo, un asociado de conmutación automática por error), descubre que supera el RTO.
Solución de problemas: el grupo de disponibilidad superó el RPO	Después de realizar una conmutación por error manual forzada, la pérdida de datos supera la RPO. O bien, al calcular la posible pérdida de datos de una réplica secundaria de confirmación asincrónica, descubre que supera la RPO.
Solución de problemas: cambios en la réplica principal que no se reflejan en la réplica secundaria	La aplicación cliente completa correctamente una actualización en la réplica principal, pero la consulta de la réplica secundaria muestra que el cambio no se refleja.

Eventos extendidos de utilidad

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

Nombre del evento	Category	Canal	réplica de disponibilidad
redo_caught_up	transacciones	Depurar	Secundario
redo_worker_entry	transacciones	Depurar	Secundario
hadr_transport_dump_message	alwayson	Depurar	Principal
hadr_worker_pool_task	alwayson	Depurar	Principal
hadr_dump_primary_progress	alwayson	Depurar	Principal
hadr_dump_log_progress	alwayson	Depurar	Principal
hadr_undo_of_redo_log_scan	alwayson	Analíticos	Secundario