Compartir vía

Recuperación acelerada de bases de datos.

  • Artículo

Se aplica a: SQL Server 2019 (15.x) y versiones posteriores de Azure SQL Database Azure SQL database Instancia administradaSQL Databaseen Microsoft Fabric

La recuperación acelerada de bases de datos (ADR) mejora la disponibilidad de la base de datos, especialmente en presencia de transacciones de larga duración, mediante el rediseño del proceso de recuperación del motor de base de datos.

ADR se introdujo en SQL Server 2019 (15.x) y se ha mejorado en SQL Server 2022 (16.x). ADR también está disponible en Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (solo grupo de SQL dedicado) y SQL Database en Microsoft Fabric.

Nota

ADR siempre está habilitado en Azure SQL Database, Azure SQL Managed Instance y SQL Database en Fabric.

En este artículo se proporciona información general sobre ADR. Para trabajar con ADR, consulte Administración de la recuperación de bases de datos acelerada.

Para obtener más información sobre el registro de transacciones y la recuperación de bases de datos, consulte guía de administración y arquitectura del registro de transacciones de SQL Server y información general sobre restauración y recuperación (SQL Server).

Información general

Las principales ventajas de ADR son:

  • Recuperación de base de datos rápida y coherente

    Las transacciones de larga duración no afectan al tiempo de recuperación general, lo que permite la recuperación rápida y coherente de la base de datos independientemente del número de transacciones activas en el sistema o su tamaño.

  • Reversión de transacción instantánea

    La reversión de transacciones es instantánea, independientemente del tiempo que la transacción haya estado activa o el número de actualizaciones realizadas.

  • Truncamiento de registro agresivo

    El registro de transacciones se trunca de forma agresiva, incluso en presencia de transacciones activas de larga duración, lo que impide que crezca fuera del control.

Proceso de recuperación de base de datos tradicional

Sin ADR, la recuperación de bases de datos sigue el modelo de recuperación de ARIES y consta de tres fases, que se ilustran y explican con más detalle en el diagrama siguiente:

Diagrama del proceso de recuperación actual.

  • Fase de análisis

    El motor de base de datos realiza un escaneo hacia adelante del registro de transacciones desde el principio del último punto de control exitoso (o el número de secuencia de registro de página sucia más antiguo (LSN)) hasta el final, para determinar el estado de cada transacción en el momento en que se detuvo el motor.

  • Fase de rehacer

    El motor de base de datos realiza un examen hacia delante del registro de transacciones desde la transacción sin confirmar más antigua hasta el final. Este proceso rehace de todas las operaciones confirmadas para restaurar la base de datos a su estado en el momento en que se produjo el fallo.

  • Fase de deshacer

    Para cada transacción que estaba activa en el momento del bloqueo, el motor de base de datos recorre el registro hacia atrás y deshace las operaciones que realizó esta transacción.

  • Con el proceso tradicional de recuperación de bases de datos, el restablecimiento tras un bloqueo puede llevar mucho tiempo si había una transacción de larga duración activa.

    El tiempo para que el motor de base de datos se recupere de un reinicio inesperado es (aproximadamente) proporcional al tamaño de la transacción activa más larga del sistema en el momento del bloqueo. La recuperación requiere la reversión de todas las transacciones incompletas. El período de tiempo necesario es proporcional al trabajo que ha realizado la transacción y el tiempo que ha estado activa.

  • La cancelación o reversión de una transacción grande puede tardar mucho tiempo, ya que usa la misma fase de deshacer que se ha descrito anteriormente.

  • El motor de base de datos no puede truncar el registro de transacciones cuando hay transacciones de ejecución prolongada porque se necesitan sus registros de registro correspondientes para los procesos de recuperación y reversión. Como resultado, el registro de transacciones puede crecer muy grande y consumir mucho espacio de almacenamiento.

Proceso de recuperación acelerada de bases de datos

ADR soluciona los problemas anteriores con el modelo de recuperación tradicional rediseñando completamente el proceso de recuperación del motor de base de datos para:

  • Haga constante el tiempo de recuperación, ya que ya no es necesario examinar el log de transacciones desde el inicio de la transacción activa más antigua. Con ADR, el registro de transacciones solo se procesa desde el último punto de control exitoso (o el LSN de la página sucia más antigua). Como resultado, el tiempo de recuperación no se ve afectado por las transacciones de larga duración y normalmente es instantáneo.

  • Minimice el espacio de registro de transacciones necesario, ya que ya no es necesario conservar el registro para toda la transacción. Como resultado, el registro de transacciones se puede truncar de manera agresiva a medida que se producen puntos de comprobación y copias de seguridad.

En un nivel alto, ADR logra una recuperación rápida de la base de datos mediante la versión de todas las modificaciones físicas de la base de datos y solo deshaciendo las operaciones no versionadas, que son limitadas y pueden deshacerse casi al instante. Las transacciones que estaban activas en el momento de un bloqueo se marcan como anuladas y, por lo tanto, las consultas de usuario simultáneas pueden omitir cualquier versión generada por estas transacciones.

El proceso de recuperación de ADR tiene las mismas tres fases que el proceso de recuperación tradicional. En el diagrama siguiente se ilustra cómo funcionan estas fases con ADR:

Diagrama del proceso de recuperación de ADR.

  • Fase de análisis

    El proceso sigue siendo el mismo que el modelo de recuperación tradicional con la adición de reconstruir la secuencia de registro secundaria (SLOG) y copiar registros de registro para operaciones noversionadas.

  • Fase de rehacer

    Se divide en dos subfases

    • Subfase 1

      Rehacer desde SLOG (las transacciones sin confirmar más antiguas hasta el último punto de control). Rehacer es una operación rápida, ya que puede que solo necesite procesar algunos registros del SLOG.

    • Subfase 2

      Rehacer desde el registro de transacciones comienza desde el último punto de control exitoso (en lugar de la transacción sin confirmar más antigua).

  • Fase de deshacer

    La fase de deshacer con ADR se completa casi instantáneamente utilizando SLOG para deshacer operaciones no versionadas y el almacén de versiones persistente (PVS) mediante la reversión lógica para realizar el deshacer a nivel de fila basado en versiones.

Para obtener una explicación de la recuperación acelerada de bases de datos, vea este vídeo de ocho minutos:

Componentes de recuperación de ADR

Estos son los cuatro componentes clave de ADR:

  • Almacén de versiones persistente (PVS)

    El almacén de versiones persistente (PVS) es un mecanismo del motor de base de datos para conservar las versiones de fila en la propia base de datos en lugar de en el almacén de versiones tradicional de la base de datos de tempdb. El PVS permite el aislamiento de recursos y mejora la disponibilidad de las secundarias legibles.

  • Reversión lógica

    La reversión lógica es el proceso asincrónico responsable de realizar la operación de deshacer en el nivel de fila y según la versión, proporcionando una reversión de transacción instantánea y deshacer todas las operaciones con versiones.

    • Realiza el seguimiento de todas las transacciones anuladas
    • Realiza una reversión mediante el PVS para todas las transacciones de usuario
    • Libera todos los bloqueos inmediatamente después de la anulación de la transacción

  • SLOG

    SLOG es una secuencia de registro en memoria secundaria que almacena entradas de registro para operaciones sin control de versiones (como la invalidación de la caché de metadatos, las adquisiciones de bloqueos, etc.). SLOG tiene estas características:

    • Es de bajo volumen y en memoria
    • Se conserva en el disco durante el proceso de punto de comprobación
    • Se trunca periódicamente a medida que se confirman las transacciones
    • Acelera el proceso de rehacer y deshacer procesando solo operaciones no versionadas.
    • Habilita el truncamiento del registro de transacciones agresivo conservando solo las entradas de registro necesarias

  • Limpiador

    El limpiador es el proceso asincrónico que se activa periódicamente y limpia las versiones de fila obsoletas en PVS.

Cargas de trabajo que se benefician de ADR

ADR es especialmente beneficioso para las cargas de trabajo que tienen:

  • Transacciones de larga duración.
  • Transacciones activas que hacen que el registro de transacciones crezca significativamente.
  • Largos períodos de falta de disponibilidad de la base de datos debido a la recuperación de larga duración (por ejemplo, desde el reinicio inesperado del servicio o la reversión manual de transacciones).

Procedimientos recomendados para ADR

  • Evite transacciones innecesarias de larga duración. Aunque ADR acelera la recuperación de bases de datos incluso con transacciones de larga duración, estas transacciones pueden retrasar la limpieza de versiones y aumentar el tamaño del PVS.

  • Evite transacciones grandes que incluyan operaciones DDL. ADR usa el mecanismo de flujo de registro secundario (SLOG) para realizar un seguimiento de las operaciones DDL usadas en la recuperación. SLOG solo se usa mientras la transacción está activa. SLOG se guarda en un punto de control, por lo que evitar transacciones grandes que usan SLOG puede mejorar el rendimiento global. Estos escenarios pueden hacer que el SLOG tome más espacio:

    • Muchas instrucciones DDL se ejecutan en una sola transacción. Por ejemplo, en una transacción, creando y eliminando rápidamente tablas temporales.
    • Una tabla tiene un gran número de particiones o índices que se modifican. Por ejemplo, una operación de DROP TABLE en dicha tabla requeriría una gran reserva de memoria SLOG, lo que retrasaría el truncamiento del registro de transacciones y retrasaría las operaciones de deshacer o rehacer. Como solución alternativa, quite los índices de forma individual y gradual y, a continuación, quite la tabla.

    Para obtener más información sobre SLOG, consulte Componentes de recuperación de ADR.

  • Evite o reduzca las transacciones anuladas innecesarias. Una alta tasa de anulación de transacciones pone presión sobre el limpiador PVS y reduce el rendimiento de ADR. Las anulaciones pueden provenir de una alta tasa de interbloqueos, claves duplicadas, infracciones de restricción o tiempos de espera de consulta. La DMV sys.dm_tran_aborted_transactions muestra todas las transacciones anuladas en la instancia del motor de base de datos. La columna nested_abort indica que la transacción se confirmó, pero hay partes que se anularon (puntos de guardado o transacciones anidadas), lo cual también puede retrasar el proceso de limpieza de PVS.

  • Asegúrese de que hay suficiente espacio en la base de datos para tener en cuenta el uso de PVS. Si la base de datos no tiene suficiente espacio para que PVS crezca, es posible que ADR no genere versiones, lo que provoca un error en las instrucciones DML.

  • Cuando ADR está habilitado con cargas de trabajo de escritura intensiva, la tasa de generación del registro de transacciones puede aumentar considerablemente porque se registran las versiones de fila escritas en PVS. Esto puede aumentar el tamaño de las copias de seguridad del registro de transacciones.

  • Cuando se usa replicación transaccional, replicación de instantáneaso captura de datos modificados (CDC), se deshabilita el comportamiento agresivo de truncamiento del registro de ADR para permitir que el lector de registros recopile cambios del registro de transacciones. Asegúrese de que el registro de transacciones es lo suficientemente grande.

    En Azure SQL Database, es posible que tenga que aumentar el nivel de servicio o el tamaño de proceso para asegurarse de que haya suficiente espacio de registro de transacciones disponible para las necesidades de todas las cargas de trabajo. Del mismo modo, en Instancia administrada de Azure SQL, es posible que tenga que aumentar el tamaño máximo de almacenamiento de la instancia.

  • Para SQL Server, aísle el almacén de versiones de PVS en un grupo de archivos en un almacenamiento de nivel superior, como SSD de gama alta o SSD avanzado o memoria persistente (PMEM), a veces denominado Memoria de clase de almacenamiento (SCM). Para obtener más información, consulte Cambiar la ubicación del PVS a un grupo de archivos diferente.

  • Para SQL Server, monitorea el registro de errores para las entradas PreallocatePVS. Si hay entradas PreallocatePVS presentes, es posible que tenga que aumentar la capacidad de ADR para preasignar páginas mediante una tarea en segundo plano. La asignación previa de páginas PVS en segundo plano mejora el rendimiento de ADR al reducir las asignaciones de PVS en primer plano más costosas. Puede usar la configuración del servidor ADR Preallocation Factor para aumentar esta cantidad. Para obtener más información, vea Configuración del servidor: Factor de Preasignación ADR.

  • Para SQL Server 2022 (16.x) y versiones posteriores, considere la posibilidad de habilitar la limpieza de PVS multiproceso si el rendimiento del limpiador de un solo subproceso no es suficiente. Para más información, consulte Configuración del servidor: recuento de subprocesos del limpiador de ADR.

  • Si observa problemas como el uso elevado del espacio de base de datos por PVS o la limpieza lenta de PVS, consulte Solución de problemas de recuperación acelerada de bases de datos.

Mejoras de ADR en SQL Server 2022

Hay varias mejoras que abordan el almacenamiento del almacén de versiones persistente (PVS) y optimizar la escalabilidad en general. Para obtener más información sobre las nuevas características de SQL Server 2022 (16.x), vea Novedades de SQL Server 2022.

Las mismas mejoras también están disponibles en Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics (solo grupo de SQL dedicado) y SQL Database en Microsoft Fabric.

  • Limpieza de transacciones de usuario

    Limpiar páginas que no se pueden limpiar mediante el proceso normal debido a un error de adquisición de bloqueo.

    Esta característica permite que las transacciones de usuario ejecuten la limpieza en páginas que no se pudieron solucionar mediante el proceso de limpieza normal debido a conflictos de bloqueo de nivel de tabla. Esta mejora ayuda a garantizar que el proceso de limpieza de ADR no produzca un error indefinidamente porque las cargas de trabajo de usuario no pueden adquirir bloqueos de nivel de tabla.

  • Reducir la huella de memoria para el seguimiento de páginas PVS

    Esta mejora realiza un seguimiento de las páginas PVS a nivel de fragmento, con el fin de reducir la huella de memoria necesaria para mantener páginas versionadas.

  • Mejoras en el limpiador de PVS

    El limpiador de PVS ha mejorado la eficiencia de limpieza de versiones para mejorar el modo en que el motor de base de datos realiza un seguimiento de las versiones de fila y registra las versiones de fila para las transacciones anuladas. Esto conduce a mejoras en el uso de memoria y almacenamiento.

  • Almacén persistente de versiones a nivel de transacción (PVS)

    Esta mejora permite a ADR limpiar las versiones que pertenecen a transacciones confirmadas independientemente de si hay transacciones anuladas en el sistema. Con esta mejora, las páginas de PVS se pueden desasignar, incluso si la limpieza no puede completar un barrido exitoso para recortar el mapa de transacciones abortadas.

    El resultado de esta mejora es que se reduce el crecimiento de PVS, incluso si la limpieza de PVS es lenta o falla.

  • Limpieza de versiones multiproceso

    En SQL Server 2019 (15.x), el proceso de limpieza es un único subproceso dentro de una instancia del motor de base de datos.

    A partir de SQL Server 2022 (16.x), se admite la limpieza de versiones multiproceso. Esto permite que varias bases de datos de la misma instancia del motor de base de datos se limpien en paralelo o una base de datos única se limpie más rápido. Para más información, consulte Configuración del servidor: recuento de subprocesos del limpiador de ADR.

    Se ha añadido un nuevo evento extendido, tx_mtvc2_sweep_stats, para la supervisión del limpiador de versiones con múltiples hilos de ADR PVS.

Contenido relacionado