Recuperación acelerada de bases de datos

Se aplica a: SQL Server 2019 (15.x) y versiones posteriores Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics

La recuperación de bases de datos acelerada (ADR) mejora considerablemente la disponibilidad de la base de datos, especialmente en presencia de transacciones de larga duración, al volver a diseñar el proceso de recuperación del motor de base de datos de SQL.

ADR se introdujo en SQL Server 2019 (15.x) y se ha mejorado en SQL Server 2022 (16.x). ADR también está disponible para las bases de datos en Azure SQL Database, Azure SQL Managed Instance y Azure Synapse SQL. ADR está habilitado de forma predeterminada en SQL Database y SQL Managed Instance y no se puede deshabilitar. Para más información sobre ADR en Azure SQL, consulte Recuperación acelerada de la base de datos en Azure SQL.

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

Información general

Las principales ventajas de ADR son:

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

  Con ADR, las transacciones de larga duración no afectan al tiempo de recuperación total, lo que permite una recuperación de base de datos rápida y coherente, con independencia del número de transacciones activas en el sistema o de sus tamaños.

• Reversión de transacción instantánea

  Con ADR, la reversión de la transacción es instantánea, independientemente del momento en que la transacción haya estado activa o del número de actualizaciones que haya realizado.

• Truncamiento de registro agresivo

  Con ADR, el registro de transacciones se trunca de manera agresiva, incluso en presencia de transacciones activas de larga duración, lo que evita que crezca fuera de control.

Proceso de recuperación de la base de datos actual

Sin ADR, la recuperación de la base de datos en SQL Server sigue el modelo de recuperación ARIES y consta de tres fases, que se muestran en el diagrama siguiente y se explican con más detalle después del diagrama.

• Fase de análisis

  SQL Server realiza un examen hacia delante del registro de transacciones desde el principio del último punto de control correcto (o el LSN de página desfasada más antiguo) hasta el final, para determinar el estado de cada transacción en el momento en que la detuvo SQL Server.

• Fase de rehacer

  SQL Server realiza el examen hacia delante del registro de transacciones desde la transacción sin confirmar más antigua hasta el final, para poner la base de datos en el estado en que se encontraba en el momento del bloqueo rehaciendo todas las operaciones confirmadas.

• Fase de deshacer

  Para cada transacción que estaba activa en el momento del bloqueo, SQL Server recorre el registro hacia atrás, deshaciendo las operaciones realizadas por esta transacción.

En función de este diseño, el tiempo necesario 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. Por lo tanto, el proceso de recuperación de SQL Server puede tardar mucho tiempo en la presencia de transacciones de larga duración (como operaciones de inserción masiva grandes u operaciones de generación de índice en una tabla grande).

Además, si se cancela o se revierte, una transacción grande basada en este diseño también puede tardar mucho tiempo, ya que se usa la misma fase de recuperación de deshacer, tal y como se ha descrito antes.

Además, el motor de base de datos no puede truncar el registro de transacciones cuando hay transacciones de larga duración, porque sus entradas de registro correspondientes son necesarias para los procesos de recuperación y reversión. Como resultado, algunos registros de transacciones crecen mucho y consumen grandes cantidades de espacio en la unidad.

Proceso de recuperación acelerada de bases de datos

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

• Sea constante/instantáneo, ya que evita tener que examinar el registro desde/hasta el principio de la transacción activa más antigua. Con ADR, el registro de transacciones solo se procesa desde el último punto de control correcto (o el número de secuencia de registro de la página desfasada más antigua). Como resultado, el tiempo de recuperación no se ve afectado por las transacciones de larga duración.
• Minimice el espacio del registro de transacciones necesario, ya que ya no es necesario procesar 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 líneas generales, ADR consigue una recuperación de base de datos rápida mediante la creación de versiones de todas las modificaciones físicas de la base de datos y solo se deshacen las operaciones lógicas, que son limitadas y se pueden deshacer 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 actual. En este diagrama siguiente se muestra cómo funcionan estas fases con ADR.

• Fase de análisis

  El proceso sigue siendo el mismo que hoy con la adición de la reconstrucción de SLOG (secuencia de registro del sistema) y la copia de entradas de registro para las operaciones sin control de versiones.

• Fase de rehacer

  Se divide en dos subfases

  • Subfase 1

    Rehacer desde SLOG (transacción sin confirmar más antigua hasta el último punto de control). La operación de rehacer es rápida, ya que solo necesita procesar algunos registros de SLOG.

  • Subfase 2

    La operación de rehacer desde el registro de transacciones empieza a partir del último punto de control (en lugar de la transacción sin confirmar más antigua).

• Fase de deshacer

  La fase de deshacer con ADR se completa de forma casi instantánea mediante el uso de SLOG para deshacer las operaciones sin control de versiones y el almacén de versiones persistente (PVS) con reversión lógica para realizar la operación de deshacer basada en versiones de nivel de fila.

También puede ver este vídeo de 8 minutos en el que se explica la recuperación acelerada de bases de datos:

Componentes de recuperación de ADR

Estos son los cuatro componentes clave de ADR:

• Almacén de versiones persistentes (PVS)

  El almacén de versiones persistentes es un mecanismo del motor de base de datos para conservar las versiones de fila generadas en la propia base de datos en lugar del almacén de versiones tempdb tradicional. El PVS permite el aislamiento de recursos y mejora la disponibilidad de las secundarias legibles. Hay un subproceso PVS por instancia en SQL Server 2019 (15.x). A partir de SQL Server 2022 (16.x), SQL Server tiene un subproceso PVS más limpio por base de datos.

• 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 mediante su serialización durante el proceso de punto de comprobación
  • Se trunca periódicamente a medida que se confirman las transacciones
  • Acelera las operaciones de rehacer y deshacer procesando solo las operaciones sin control de versiones
  • 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.

Mejoras de ADR en SQL Server 2022 (16.x)

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), consulte Novedades de SQL Server 2022 (16.x).

• Limpieza de transacciones de usuario

  Borrar páginas que no se pudieron limpiar por el proceso normal debido a un error 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.

• Reducción de la superficie de memoria para el seguimiento de páginas PVS

  Esta mejora realiza un seguimiento de las páginas del almacén de versiones persistentes (PVS) en el nivel de extensión, con el fin de reducir la superficie de memoria necesaria para mantener las páginas con versiones.

• Mejoras del limpiador de recuperación de datos aceleradas (ADR)

  El limpiador de recuperación de datos acelerada (ADR) ha mejorado las eficiencias de limpieza de versiones para mejorar la forma en que SQL Server realiza un seguimiento y registra las versiones anuladas de una página que conduce a mejoras en la memoria y la capacidad.

• Almacén de versiones persistente de 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, se pueden desasignar páginas de almacén de versiones persistentes (PVS), incluso si la limpieza no puede completar un barrido correcto para recortar el mapa de transacciones anulado.

  El resultado de esta mejora se reduce el crecimiento del almacén de versiones persistente (PVS), incluso si la limpieza de ADR 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 de SQL Server.

  A partir de SQL Server 2022 (16.x), este proceso usa la limpieza de versiones multiproceso. Esto permite limpiar varias bases de datos de la misma instancia de SQL Server en paralelo. Esta mejora es útil cuando tiene varias bases de datos grandes.

  Para ajustar el número de subprocesos para la escalabilidad de limpieza de versiones, establezca ADR Cleaner Thread Count con sp_configure. El número de subprocesos está limitado en el número de núcleos de la instancia.

  Como procedimiento recomendado, se recomienda usar el mismo número de subprocesos de limpieza de ADR que el número de bases de datos. Por ejemplo, si configura ADR Cleaner Thread Count para que sea 4 en una instancia de SQL Server con dos bases de datos, el limpiador de ADR seguirá asignando solo un subproceso por base de datos, dejando inactivos los dos subprocesos restantes.

  En el ejemplo siguiente se cambia el número de subprocesos a 4:

  EXEC sp_configure 'ADR Cleaner Thread Count', '4';
  RECONFIGURE WITH OVERRIDE; 
  

• Nuevos eventos extendidos

  Se ha agregado un nuevo evento extendido, tx_mtvc2_sweep_stats, para la telemetría en el limpiador de versiones multiproceso de PVS de ADR.

Procedimientos recomendados y guía

Para obtener instrucciones sobre las cargas de trabajo que sí y no se recomiendan para ADR, consulte Administración de la recuperación de bases de datos acelerada.

Importante

En base de datos de Azure SQL, las transacciones inactivas (transacciones que no se han escrito en el registro de transacciones durante seis horas) se finalizan automáticamente para liberar recursos.

Contenido relacionado

• Administración de la recuperación de bases de datos acelerada
• Solución de problemas de la recuperación de bases de datos acelerada
• Recuperación de base de datos acelerada en Azure SQL