Compartir vía

Administración de la recuperación de bases de datos acelerada

  • Artículo

se aplica a: SQL Server 2019 (15.x) y versiones posteriores

En este artículo se enseña a habilitar y deshabilitar la recuperación acelerada de bases de datos (ADR) con Transact-SQL (T-SQL) en SQL Server 2019 (15.x) y versiones posteriores, así como cómo cambiar el grupo de archivos del almacén de versiones persistente (PVS) usado por ADR.

Nota:

En Azure SQL Database, Azure SQL Managed Instance y SQL Database en Microsoft Fabric, la recuperación acelerada de bases de datos (ADR) siempre está habilitada. Si observa problemas, como un uso elevado de almacenamiento por parte de PVS o una limpieza lenta de ADR, consulte Solución de problemas de recuperación acelerada de bases de datos o póngase en contacto con el soporte técnico de Azure.

Quién debe considerar la recuperación de base de datos acelerada

Muchos clientes encuentran la recuperación acelerada de bases de datos (ADR) una tecnología valiosa para mejorar el tiempo de recuperación de la base de datos.

Si las cargas de trabajo de la base de datos suelen encontrarse con los siguientes escenarios, puede beneficiarse de ADR:

  • Transacciones de larga duración que no se pueden evitar. Por ejemplo, en los casos en los que las transacciones de larga duración corren el riesgo de revertirse, ADR puede ser de ayuda.
  • Transacciones activas que hacen que el registro de transacciones crezca significativamente.
  • Recuperación de bases de datos de larga duración que afecta a la disponibilidad de la base de datos (por ejemplo, después de un reinicio inesperado de SQL Server o reversión manual de transacciones).

No se recomienda ADR para los escenarios siguientes:

  • No se admiten las bases de datos que utilizan el espejo de bases de datos .
  • Si la aplicación usa un gran volumen de modificaciones de una sola fila en transacciones individuales, es posible que la carga de trabajo no sea óptima para ADR. Considere la posibilidad de realizar modificaciones por lotes en instrucciones de varias filas cuando sea posible y evite un gran número de pequeñas transacciones DML.

Habilitación de ADR

ADR está desactivada de forma predeterminada y está disponible a partir de SQL Server 2019 (15.x).

Use el siguiente comando Transact-SQL (T-SQL) para habilitar ADR:

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON;

Se necesita un bloqueo exclusivo de base de datos para habilitar o deshabilitar ADR. Esto significa que el comando ALTER DATABASE está bloqueado hasta que todas las sesiones activas se hayan ido y que las nuevas sesiones esperen detrás del comando ALTER DATABASE. Si es importante completar la operación y quitar el bloqueo, puede usar la cláusula de terminación, WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT] anular las sesiones activas de la base de datos. Para obtener más información, consulte Opciones de ALTER DATABASE SET.

Deshabilitar ADR

Use el siguiente comando de T-SQL para deshabilitar ADR:

ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

Incluso después de deshabilitar ADR, puede haber versiones almacenadas en PVS que el sistema todavía necesita para revertir lógicamente hasta que se completen todas las transacciones activas.

Cambiar el grupo de archivos PVS

De forma predeterminada, los datos del almacén de versiones persistentes (PVS) están en el grupo de archivos PRIMARY. Si es necesario, puede mover PVS a otro grupo de archivos. Por ejemplo, podría requerir más espacio o almacenamiento más rápido.

Para cambiar la ubicación del PVS a otro grupo de archivos, siga estos pasos:

  1. Cree el grupo de archivos para PVS y agregue al menos un archivo de datos a este grupo de archivos. Por ejemplo:

    ALTER DATABASE [<db_name>] ADD FILEGROUP [VersionStoreFG];
GO

ALTER DATABASE [<db_name>]
ADD FILE
(
   NAME = N'VersionStoreFG',
   FILENAME = N'E:\DATA\VersionStore.ndf',
   SIZE = 8192 MB,
   FILEGROWTH = 64 MB
)
TO FILEGROUP [VersionStoreFG];

  2. Deshabilite ADR con el siguiente comando de T-SQL:

    ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

  3. Espere hasta que se quiten todas las versiones almacenadas en PVS.

    Para habilitar ADR mediante una nueva ubicación de PVS, primero asegúrese de que se ha purgado toda la información de versión de la ubicación de PVS anterior. Puede forzar la ejecución de la limpieza con el procedimiento almacenado sys.sp_persistent_version_cleanup:

    EXEC sys.sp_persistent_version_cleanup [<db_name>];

    El procedimiento almacenado sys.sp_persistent_version_cleanup es sincrónico, lo que significa que no se completará hasta que toda la información de la versión se limpie del PVS actual. Una vez que se complete, puede comprobar que la información de la versión se elimina consultando sys.dm_tran_persistent_version_store_stats y examinando el valor de persistent_version_store_size_kb, como en el ejemplo siguiente:

    SELECT DB_NAME(database_id),
       persistent_version_store_size_kb
FROM sys.dm_tran_persistent_version_store_stats
WHERE database_id = [MyDatabaseID];

    Cuando el valor de persistent_version_store_size_kb es 0, puede volver a habilitar la función ADR, con el PVS en un nuevo conjunto de archivos.

  4. Habilite ADR y especifique la nueva ubicación de PVS con el siguiente comando de T-SQL:

    ALTER DATABASE [<db_name>] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

Supervisar el tamaño del PVS

Una vez que habilite ADR en una base de datos, supervise el tamaño del almacén de versiones persistente (PVS) y el rendimiento de limpieza de PVS. Puede supervisar el estado de PVS mediante los métodos que se encuentran en Solución de problemas de recuperación acelerada de bases de datos.

Si tiene una carga de trabajo con un gran volumen de instrucciones DML (INSERT, UPDATE, DELETE, MERGE), como es el caso de un OLTP de gran volumen, puede ser necesario un período de reposo o recuperación para que el proceso de limpieza del PVS pueda recuperar espacio. Normalmente, los ciclos de operación de negocio permiten este tiempo, pero en algunos escenarios es posible que quiera iniciar manualmente el proceso de limpieza de PVS para aprovechar los patrones de actividad de la aplicación.

  • Para activar el proceso de limpieza de PVS manualmente entre diferentes cargas de trabajo o durante las ventanas de mantenimiento, use el procedimiento almacenado sys.sp_persistent_version_cleanup.

  • Si el proceso de limpieza de PVS se está ejecutando durante un largo período de tiempo, es posible que el recuento de transacciones anuladas crezca, lo que también hace que el tamaño de PVS aumente. Use la DMV sys.dm_tran_aborted_transactions para notificar el recuento de transacciones anuladas y use sys.dm_tran_persistent_version_store_stats para notificar las horas de inicio y finalización de la limpieza junto con el tamaño de PVS.

  • Las cargas de trabajo que presentan consultas de larga duración mediante el aislamiento SNAPSHOT o READ COMMITTED, cuando la opción de base de datos READ_COMMITTED_SNAPSHOT (RCSI) está habilitada, podrían retrasar la limpieza de PVS para todas las bases de datos en una instancia de motor de base de datos, provocando que el tamaño de PVS crezca. Para obtener más información, consulte la sección sobre exploraciones de instantáneas activas prolongadas en Solución de problemas de recuperación acelerada de bases de datos.

Contenido relacionado