Solución de problemas de bases de datos de disponibilidad Always On en estado Recovery Pending o Suspect en SQL Server

Artículo
06/27/2023

En este artículo se describen los errores y limitaciones de una base de datos de disponibilidad en Microsoft SQL Server que se encuentra en un Recovery Pending estado o Suspect y cómo restaurar la base de datos a una funcionalidad completa en un grupo de disponibilidad.

Versión original del producto: SQL Server 2012
Número de KB original: 2857849

Resumen

Supongamos que una base de datos de disponibilidad definida en un grupo de disponibilidad AlwaysOn realiza la transición a un Recovery Pending estado o Suspect en SQL Server. Si esto ocurre en la réplica principal del grupo de disponibilidad, la disponibilidad de la base de datos se ve afectada. En esta situación, no se puede acceder a la base de datos a través de las aplicaciones cliente. Además, no se puede quitar ni quitar la base de datos del grupo de disponibilidad.

Por ejemplo, suponga que SQL Server se está ejecutando y que una base de datos de disponibilidad está establecida en el Recovery Pending estado o Suspect . Al consultar las vistas de administración dinámica (DMV) en la réplica principal mediante el siguiente script SQL, es posible que la base de datos se notifique en un NOT_HEALTHY estado y RECOVERY_PENDING o en un SUSPECT estado como se indica a continuación:

SELECT
    dc.database_name,
    d.synchronization_health_desc,
    d.synchronization_state_desc,
    d.database_state_desc
FROM
    sys.dm_hadr_database_replica_states d
    JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id
    AND d.is_local = 1

database_name          synchronization_health_desc     synchronization_state_desc   database_state_desc
-------------------- ------------------------------ ------------------------------ ---------------------
<DatabaseName>                         NOT_HEALTHY              NOT SYNCHRONIZING      RECOVERY_PENDING
(1 row(s) affected)

Captura de pantalla del resultado de ejecución del script para comprobar el estado de la base de datos y el estado de sincronización.

Además, esta base de datos se puede notificar como en el estado Not Synchronizing /Recovery Pending (No sincronizando o pendiente de recuperación) o Suspect (Pendiente de recuperación) en SQL Server Management Studio.

Captura de pantalla de la base de datos que está en estado Not Synchronizing /Recovery Pending (Sincronización/ Pendiente de recuperación).

Cuando la base de datos se define en un grupo de disponibilidad, la base de datos no se puede quitar ni restaurar. Por lo tanto, debe realizar pasos específicos para recuperar la base de datos y devolverla al uso de producción.

Más información

En el siguiente contenido se describen los errores y limitaciones de una base de datos de disponibilidad que se encuentra en estado Pendiente de recuperación en varias situaciones.

El estado de la base de datos impide la restauración de la base de datos

Intente ejecutar el siguiente script SQL para restaurar la base de datos que tiene el RECOVERY parámetro :
```
RESTORE DATABASE <DatabaseName> WITH RECOVERY
```
Al ejecutar este script, recibirá el siguiente mensaje de error porque la base de datos se define en un grupo de disponibilidad:

Mensaje 3104, nivel 16, estado 1, línea 1
RESTORE no puede funcionar en database <DatabaseName> porque está configurado para la creación de reflejo de la base de datos o se ha unido a un grupo de disponibilidad. Si piensa restaurar la base de datos, use ALTER DATABASE para quitar la creación de reflejo o para quitar la base de datos de su grupo de disponibilidad.

Mensaje 3013, nivel 16, estado 1, línea 1
RESTORE DATABASE termina anómalamente.
El estado de la base de datos impide la eliminación de la base de datos

Intente ejecutar el siguiente script SQL para quitar la base de datos:
```
DROP DATABASE <DatabaseName>
```
Al ejecutar este script, recibirá el siguiente mensaje de error porque la base de datos se define en un grupo de disponibilidad:

Mensaje 3752, nivel 16, estado 1, línea 1
<DatabaseName> está unido actualmente a un grupo de disponibilidad. Para poder quitar la base de datos, debe quitarla del grupo de disponibilidad.
El estado de la base de datos impide quitar la base de datos del grupo de disponibilidad

Intente ejecutar el siguiente script SQL para quitar la base de datos del grupo de disponibilidad:
```
ALTER DATABASE <DatabaseName> SET hadr OFF
```
Al intentar ejecutar este script, recibirá el siguiente mensaje de error porque la base de datos de disponibilidad pertenece a la réplica principal:

Mensaje 35240, nivel 16, estado 14, línea 1
Database <DatabaseName> no se puede unir ni separar del grupo <de disponibilidad AvailabilityGroupName>. Esta operación no se admite en la réplica principal del grupo de disponibilidad.

Debido a este mensaje de error, es posible que se le obligue a conmutar por error la base de datos. Una vez conmutada por error la base de datos, la réplica propietaria de la base de datos pendiente de recuperación se encuentra en el rol secundario. En esta situación, intentará ejecutar de nuevo el siguiente script SQL para quitar la base de datos del grupo de disponibilidad en la réplica secundaria:
```
ALTER DATABASE <DatabaseName> SET hadr OFF
```
Sin embargo, todavía no puede quitar la base de datos del grupo de disponibilidad y recibe el siguiente mensaje de error porque la base de datos sigue en estado Pendiente de recuperación:

Mensaje 921, nivel 16, estado 112, línea 1
Database <DatabaseName> aún no se ha recuperado. Espere unos momentos e inténtelo de nuevo.

Resolución cuando la base de datos está en el rol secundario

Para resolver este problema, realice las siguientes acciones generales:

Quite del grupo de disponibilidad la réplica que hospeda la base de datos dañada cuando la base de datos esté en el rol secundario.
Resuelva los problemas que afecten al sistema y que puedan haber contribuido al error de la base de datos.
Restaure la réplica en el grupo de disponibilidad.

Para realizar estas acciones, conéctese a la nueva réplica principal y, a continuación, ejecute el ALTER AVAILABILITY GROUP script SQL para quitar la réplica que hospeda la base de datos de disponibilidad con errores. Para hacerlo, siga estos pasos.

En estos pasos se supone que la réplica principal hospeda primero la base de datos dañada. Por lo tanto, primero se debe producir una conmutación por error para realizar la transición de la réplica que hospeda la base de datos dañada a un rol secundario.

Conéctese al servidor que ejecuta SQL Server y que hospeda la réplica secundaria.

Ejecute el siguiente script SQL:

ALTER AVAILABILITY GROUP <AvailabilityGroupName> FAILOVER

Ejecute el siguiente script SQL para quitar la réplica que hospeda la base de datos dañada del grupo de disponibilidad:
```
ALTER AVAILABILITY GROUP <AvailabilityGroupName> REMOVE REPLICA ON '<SQLServerNodeName>'
```
Resuelva cualquier problema en el servidor que ejecuta SQL Server y que pueda contribuir al error de la base de datos.
Vuelva a agregar la réplica al grupo de disponibilidad.

Resolución cuando la réplica principal es la única réplica del grupo de disponibilidad

Si la réplica principal hospeda la base de datos dañada y es la única réplica de trabajo en el grupo de disponibilidad, se debe quitar el grupo de disponibilidad. Una vez eliminado el grupo de disponibilidad, la base de datos se puede recuperar de una copia de seguridad u otros esfuerzos de recuperación de emergencia se pueden aplicar para restaurar las bases de datos y reanudar la producción.

Para quitar el grupo de disponibilidad, use el siguiente script SQL:

DROP AVAILABILITY GROUP <AvailabilityGroupName>

En este momento, puede intentar recuperar la base de datos problemática. O bien, puede restaurar la base de datos a partir de la última copia de seguridad correcta conocida.

Resolución al quitar el grupo de disponibilidad

Al quitar un grupo de disponibilidad, el recurso del agente de escucha también se quita e interrumpe la conectividad de la aplicación a las bases de datos de disponibilidad.

Para minimizar el tiempo de inactividad de la aplicación, use uno de los métodos siguientes para mantener la conectividad de la aplicación a través del agente de escucha y quite el grupo de disponibilidad:

Método 1: Asociar el agente de escucha a un nuevo grupo de disponibilidad (rol) en el Administrador de clústeres de conmutación por error

Este método le permite mantener el agente de escucha al quitar y volver a crear el grupo de disponibilidad.

En la instancia de SQL Server a la que el agente de escucha del grupo de disponibilidad existente dirige las conexiones, cree un nuevo grupo de disponibilidad vacío. Para simplificar este proceso, use el comando Transact-SQL para crear un grupo de disponibilidad que no tenga ninguna réplica secundaria o base de datos:
```
USE master
GO
CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
    ENDPOINT_URL = 'tcp://sqlnode1:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL
)
```
Inicie el Administrador de clústeres de conmutación por error y, a continuación, seleccione Roles en el panel izquierdo. En el panel que muestra los roles, seleccione el grupo de disponibilidad original.
En el panel inferior central de la pestaña Recursos , haga clic con el botón derecho en el recurso del grupo de disponibilidad y, a continuación, seleccione Propiedades. Seleccione la pestaña Dependencias , elimine la dependencia al agente de escucha y, a continuación, seleccione Aceptar.
En los recursos, haga clic con el botón derecho en el agente de escucha, seleccione Más acciones y, a continuación, seleccione Asignar a otro rol.
En el cuadro de diálogo Asignar origen a rol , seleccione el nuevo grupo de disponibilidad y, a continuación, seleccione Aceptar.
En el panel Roles , seleccione el nuevo grupo de disponibilidad. En el panel inferior central, en la pestaña Recursos , ahora debería ver el nuevo grupo de disponibilidad y el recurso del agente de escucha. Haga clic con el botón derecho en el nuevo recurso del grupo de disponibilidad y seleccione Propiedades.
Haga clic en la pestaña Dependencias , seleccione el recurso del agente de escucha en el cuadro desplegable y, a continuación, seleccione Aceptar.
En SQL Server Management Studio, use Explorador de objetos para conectarse a la instancia de SQL Server que hospeda la réplica principal del nuevo grupo de disponibilidad. Seleccione Alta disponibilidad AlwaysOn, haga clic en el nuevo grupo de disponibilidad y, a continuación, seleccione Agentes de escucha de grupo de disponibilidad. Debe encontrar el agente de escucha.
Haga clic con el botón derecho en el agente de escucha, seleccione Propiedades, escriba el número de puerto adecuado para el agente de escucha y, a continuación, seleccione Aceptar.

Esto garantiza que las aplicaciones que usan el agente de escucha puedan seguir utilizándola para conectarse a la instancia de SQL Server que hospeda las bases de datos de producción sin interrupción. El grupo de disponibilidad original ahora se puede quitar y volver a crear. O bien, las bases de datos y réplicas se pueden agregar al nuevo grupo de disponibilidad.

Si vuelve a crear el grupo de disponibilidad original, debe reasignar el agente de escucha al rol de grupo de disponibilidad, configurar la dependencia entre el nuevo recurso del grupo de disponibilidad y el agente de escucha y, a continuación, reasignar el puerto al agente de escucha. Para ello, siga estos pasos:

Inicie el Administrador de clústeres de conmutación por error y, a continuación, seleccione Roles en el panel izquierdo. En el panel que muestra los roles, haga clic en el nuevo grupo de disponibilidad que hospeda el agente de escucha.
En el panel central inferior de la pestaña Recursos , haga clic con el botón derecho en el agente de escucha, seleccione Más acciones y, a continuación, seleccione Asignar a otro rol. En el cuadro de diálogo, elija el grupo de disponibilidad que se ha vuelto a crear y, a continuación, seleccione Aceptar.
En el panel Roles , haga clic en el grupo de disponibilidad que se ha vuelto a crear. En el panel central inferior, en la pestaña Recursos , ahora debería ver el grupo de disponibilidad vuelto a crear y el recurso del agente de escucha. Haga clic con el botón derecho en el recurso del grupo de disponibilidad que se ha vuelto a crear y, a continuación, seleccione Propiedades.
Seleccione la pestaña Dependencias , seleccione el recurso del agente de escucha en el cuadro desplegable y, a continuación, seleccione Aceptar.
En SQL Server Management Studio, use Explorador de objetos para conectarse a la instancia de SQL Server que hospeda la réplica principal del grupo de disponibilidad vuelto a crear. Seleccione Alta disponibilidad AlwaysOn, haga clic en el nuevo grupo de disponibilidad y, a continuación, seleccione Agentes de escucha de grupo de disponibilidad. Debe encontrar el agente de escucha.
Haga clic con el botón derecho en el agente de escucha, seleccione Propiedades, escriba el número de puerto adecuado para el agente de escucha y, a continuación, seleccione Aceptar.

Método 2: Asociar el agente de escucha a una instancia en clúster de conmutación por error de SQL Server existente (SQLFCI)

Si hospeda el grupo de disponibilidad en una instancia en clúster de conmutación por error de SQL Server (SQLFCI), puede asociar el recurso en clúster del agente de escucha al grupo de recursos en clúster de SQLFCI mientras quita y vuelve a crear el grupo de disponibilidad.

Inicie el Administrador de clústeres de conmutación por error y, a continuación, seleccione Roles en el panel izquierdo.
En el panel que muestra los roles, seleccione el grupo de disponibilidad original.
En el panel central inferior de la pestaña Recursos , haga clic con el botón derecho en el recurso del grupo de disponibilidad y, a continuación, seleccione Propiedades.
Seleccione la pestaña Dependencias , elimine la dependencia al agente de escucha y, a continuación, seleccione Aceptar.
En el panel central inferior de la pestaña Recursos , haga clic con el botón derecho en el agente de escucha, seleccione Más acciones y, a continuación, seleccione Asignar a otro rol.
En el cuadro de diálogo Asignar recurso a rol , haga clic en la instancia de FCI de SQL Server y seleccione Aceptar.
En el panel Roles , seleccione el grupo SQLFCI. En el panel central inferior, en la pestaña Recursos , ahora debería ver el nuevo recurso del agente de escucha.

Después de volver a crear el grupo de disponibilidad, vuelva a asignar el agente de escucha al rol de grupo de disponibilidad. A continuación, configure la dependencia entre el nuevo recurso del grupo de disponibilidad y el agente de escucha y vuelva a asignar el puerto al agente de escucha:

Inicie el Administrador de clústeres de conmutación por error y, a continuación, seleccione Roles en el panel izquierdo.
En el panel que muestra los roles, haga clic en el rol SQLFCI original.
En el panel central inferior, en la pestaña Recursos , haga clic con el botón derecho en el agente de escucha, seleccione Más acciones y, a continuación, seleccione Asignar a otro rol.
En el cuadro de diálogo, haga clic en el grupo de disponibilidad que se ha vuelto a crear y, a continuación, seleccione Aceptar.
En el panel Roles , seleccione el nuevo grupo de disponibilidad.
En la pestaña Recursos , debería ver el nuevo grupo de disponibilidad y el recurso del agente de escucha. Haga clic con el botón derecho en el nuevo recurso del grupo de disponibilidad y seleccione Propiedades.
Seleccione la pestaña Dependencias , seleccione el recurso del agente de escucha en el cuadro desplegable y, a continuación, seleccione Aceptar.
En SQL Server Management Studio, use Explorador de objetos para conectarse a la instancia de SQL Server que hospeda la réplica principal del nuevo grupo de disponibilidad.
Seleccione Alta disponibilidad AlwaysOn, haga clic en el nuevo grupo de disponibilidad y, a continuación, seleccione Agentes de escucha de grupo de disponibilidad. Debe encontrar el agente de escucha.
Haga clic con el botón derecho en el agente de escucha, seleccione Propiedades, escriba el número de puerto adecuado para el agente de escucha y, a continuación, seleccione Aceptar.

Método 3: Quite el grupo de disponibilidad y vuelva a crear el grupo de disponibilidad y el agente de escucha con el mismo nombre de agente de escucha.

Este método producirá una pequeña interrupción para las aplicaciones que están conectadas actualmente porque se quita el grupo de disponibilidad y el agente de escucha y, a continuación, se vuelven a crear:

Quite el grupo de disponibilidad.

Nota:

Esto también quitará el agente de escucha.
Cree inmediatamente un nuevo grupo de disponibilidad vacío que incluya la definición del agente de escucha, en el mismo servidor que hospeda las bases de datos de producción.

Por ejemplo, supongamos que el agente de escucha del grupo de disponibilidad es aglisten. La siguiente instrucción Transact-SQL crea un grupo de disponibilidad sin ninguna base de datos principal o secundaria, pero también crea un agente de escucha denominado aglisten. Las aplicaciones pueden usar este agente de escucha para conectarse.
```
USE master
GO
    CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH (
        ENDPOINT_URL = 'tcp://sqlnode1:5022',
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        FAILOVER_MODE = MANUAL
    ) LISTENER 'aglisten' (
        WITH IP ((N'11.0.0.25', N'255.0.0.0')),
        PORT = 1433
    )
GO
```
Recupere la base de datos dañada. A continuación, vuelva a agregarla y la réplica secundaria al grupo de disponibilidad.

Compartir a través de