Durabilidad para tablas de Memory-Optimized

In-Memory OLTP proporciona una durabilidad completa para las tablas optimizadas para memoria. Cuando se confirma una transacción que cambió una tabla optimizada para memoria, SQL Server (como lo hace para las tablas basadas en disco), garantiza que los cambios son permanentes (sobrevivirán a un reinicio de la base de datos), siempre que el almacenamiento subyacente esté disponible. Hay dos componentes clave de durabilidad: el registro de transacciones y la conservación de los cambios de datos en el almacenamiento en disco.

Registro de transacciones

Todos los cambios realizados en tablas basadas en disco o en tablas optimizadas para memoria duradera se capturan en uno o varios registros de registro de transacciones. Cuando se confirma una transacción, SQL Server escribe los registros de registro asociados a la transacción en el disco antes de comunicarse con la aplicación o sesión de usuario que la transacción ha confirmado. Esto garantiza que los cambios realizados por la transacción sean duraderos. El registro de transacciones de las tablas optimizadas para memoria está totalmente integrado con el mismo flujo de registro que usan las tablas basadas en disco. Esta integración permite que las operaciones de copia de seguridad, recuperación y restauración del registro de transacciones existentes sigan funcionando sin necesidad de pasos adicionales. Sin embargo, dado que In-Memory OLTP puede aumentar significativamente el rendimiento de las transacciones de la carga de trabajo, debe asegurarse de que el almacenamiento del registro de transacciones esté configurado correctamente para manejar los mayores requisitos de E/S.

Archivos delta y de datos

Los datos de las tablas optimizadas para memoria se almacenan como filas de datos en formato libre, vinculadas a través de uno o varios índices en memoria. No hay estructuras de página para las filas de datos, como las que se usan para las tablas basadas en disco. Cuando la aplicación esté lista para confirmar la transacción, el In-Memory OLTP genera los registros de registro para la transacción. La persistencia de las tablas optimizadas para memoria se realiza con un conjunto de datos y archivos delta mediante un subproceso en segundo plano. Los archivos delta y de datos se encuentran en uno o varios contenedores (mediante el mismo mecanismo que se usa para los datos FILESTREAM). Estos contenedores se asignan a un nuevo tipo de grupo de archivos, denominado grupo de archivos optimizado para memoria.

Los datos se escriben en estos archivos de forma estrictamente secuencial, lo que minimiza la latencia del disco para los medios giratorios. Puede usar varios contenedores en discos diferentes para distribuir la actividad de E/S. Los archivos de datos y delta de varios contenedores en discos diferentes aumentarán el rendimiento de recuperación cuando los datos se leen de los archivos de datos y delta en el disco, en memoria.

Una aplicación no accede directamente a los datos ni a los archivos delta. Todas las lecturas y escrituras de datos usan datos en memoria.

El archivo de datos

Un archivo de datos contiene filas de una o varias tablas optimizadas para memoria insertadas por varias transacciones como parte de las operaciones INSERT o UPDATE. Por ejemplo, una fila puede ser de la tabla optimizada para memoria T1 y la siguiente fila puede ser de la tabla optimizada para memoria T2. Las filas se anexan al archivo de datos en el orden de las transacciones del registro de transacciones, lo que hace que el acceso a los datos sea secuencial. Esto permite un orden de magnitud mejor rendimiento de E/S en comparación con la E/S aleatoria. Cada archivo de datos tiene un tamaño aproximado de 128 MB para equipos con memoria superior a 16 GB y 16 MB para equipos con menos o igual que 16 GB. Una vez que el archivo de datos está lleno, las filas insertadas por nuevas transacciones se almacenan en otro archivo de datos. Con el tiempo, las filas de las tablas optimizadas para memoria duradera se almacenan en uno o más archivos de datos, y cada archivo de datos contiene filas de un intervalo de transacciones que es separado pero contiguo. Por ejemplo, un archivo de datos con marca de tiempo de confirmación de transacción en el intervalo de (100, 200) tiene todas las filas insertadas por transacciones que tienen marca de tiempo de confirmación mayor que 100 y menor o igual que 200. La marca de tiempo de confirmación es un número que aumenta de forma monotónica asignado a una transacción cuando está listo para confirmarse. Cada transacción tiene una marca de tiempo de confirmación única.

Cuando se elimina o actualiza una fila, la fila no se quita ni cambia en contexto en el archivo de datos, pero se realiza un seguimiento de las filas eliminadas en otro tipo de archivo: el archivo delta. Las operaciones de actualización se procesan como una tupla de operaciones de eliminación e inserción para cada fila. Esto elimina la E/S aleatoria en el archivo de datos.

El archivo Delta

Cada archivo de datos se empareja con un archivo delta que tiene el mismo intervalo de transacciones y realiza un seguimiento de las filas eliminadas insertadas por transacciones en el intervalo de transacciones. Este archivo de datos y archivo delta se conoce como par de archivos de punto de control (CFP) y es la unidad de asignación y desasignación, y para las operaciones de combinación. Por ejemplo, un archivo delta correspondiente al intervalo de transacciones (100, 200) almacenará filas eliminadas insertadas por transacciones en el intervalo (100, 200). Al igual que los archivos de datos, se accede secuencialmente al archivo delta.

Cuando se elimina una fila, la fila no se quita del archivo de datos, pero se anexa una referencia a la fila al archivo delta asociado al intervalo de transacciones donde se insertó esta fila de datos. Dado que la fila que se va a eliminar ya existe en el archivo de datos, el archivo delta solo almacena la información {inserting_tx_id, row_id, deleting_tx_id } de referencia y sigue el orden del registro transaccional de las operaciones de eliminación o actualización de origen.

Población de datos y archivos delta

Los datos y el archivo delta se rellenan mediante un subproceso en segundo plano denominado punto de control sin conexión. Este subproceso lee los registros de registro de transacciones generados por transacciones confirmadas en tablas optimizadas para memoria y anexa información sobre las filas insertadas y eliminadas en los archivos delta y de datos adecuados. A diferencia de las tablas basadas en disco, en las que las páginas de datos o de índices se descargan mediante operaciones de entrada/salida aleatorias al realizar un punto de control, la persistencia de una tabla optimizada para memoria es una operación continua en segundo plano. Se accede a varios archivos delta porque una transacción puede eliminar o actualizar cualquier fila insertada por cualquier transacción anterior. La información de eliminación siempre se anexa al final del archivo delta. Por ejemplo, una transacción con una marca de tiempo de confirmación de 600 inserta una nueva fila y elimina las filas insertadas por transacciones con una marca de tiempo de confirmación de 150, 250 y 450, como se muestra en la siguiente imagen. Las 4 operaciones de E/S de archivos (tres para las filas eliminadas y 1 para las filas recién insertadas), son operaciones de solo anexión a los archivos delta y de datos correspondientes.

Acceso a datos y archivos delta

Se accede a los pares de archivos delta y de datos cuando se produce lo siguiente.

Subproceso de punto de control sin conexión Este subproceso anexa inserciones y eliminaciones a las filas de datos optimizadas para memoria, a los pares de archivos delta y de datos correspondientes.

Operación de combinación La operación combina uno o varios pares de archivos delta y de datos y crea un nuevo par de datos y archivos delta.

Durante la recuperación tras fallos, cuando se reinicia SQL Server o se vuelve a conectar la base de datos a la red, los datos optimizados para memoria se rellenan mediante los pares de archivos delta y de datos. El archivo delta actúa como filtro para las filas eliminadas al leer las filas del archivo de datos correspondiente. Dado que cada par de archivos delta y datos es independiente, estos archivos se cargan en paralelo para reducir el tiempo necesario para rellenar los datos en la memoria. Una vez cargados los datos en la memoria, el motor de In-Memory OLTP aplica los registros de registro de transacciones activos que aún no están cubiertos por los archivos de punto de comprobación para que se completen los datos optimizados para memoria.

Durante la operación de restauración Se crean los archivos de punto de comprobación de In-Memory OLTP a partir de la copia de seguridad de la base de datos y, a continuación, se aplican una o varias copias de seguridad del registro de transacciones. Al igual que con la recuperación ante fallos, el motor de In-Memory OLTP carga datos en memoria en paralelo para minimizar el impacto en el tiempo de recuperación.

Combinar datos y archivos delta

Los datos de las tablas optimizadas para memoria se almacenan en uno o varios pares de archivos delta y de datos (también denominado par de archivos de punto de control o CFP). Los archivos de datos almacenan filas insertadas y archivos delta hacen referencia a filas eliminadas. Durante la ejecución de una carga de trabajo OLTP, a medida que las operaciones DML actualizan, insertan y eliminan filas, se crean nuevos CFP para conservar las nuevas filas y la referencia a las filas eliminadas se anexa a los archivos delta.

Los metadatos de todos los CFP previamente cerrados y activos actualmente se almacenan en una estructura de matriz interna denominada matriz de almacenamiento. Es una matriz finita (8.192 entradas) de CFP. Las entradas de la matriz de almacenamiento se ordenan por intervalo de transacciones. Los CFP de la matriz de almacenamiento (junto con el final del registro) representan todo el estado en disco necesario para recuperar una base de datos con tablas optimizadas para memoria.

Con el tiempo, con las operaciones DML, el número de CFP crece, lo que hace que la matriz de almacenamiento alcance la capacidad, lo que presenta los siguientes desafíos:

• Filas eliminadas. Las filas eliminadas permanecen en el archivo de datos, pero se marcan como eliminadas en el archivo delta correspondiente. Estas filas ya no son necesarias y se quitarán del almacenamiento. Si las filas eliminadas no se quitaron de cfP, usarían espacio innecesariamente y ralentizarían el tiempo de recuperación.

• Matriz de almacenamiento llena. Cuando se asignan 8000 entradas en la matriz de almacenamiento (192 entradas de la matriz están reservadas para las combinaciones existentes para competir o para permitirle realizar combinaciones manuales), no se pueden ejecutar nuevas transacciones DML en tablas optimizadas para memoria duraderas. Solo se permiten las operaciones de punto de control y combinación para consumir las entradas restantes. Esto garantiza que las transacciones DML no rellenen la matriz y que algunas entradas de la matriz estén reservadas para combinar archivos existentes y recuperar espacio en la matriz.

• Sobrecarga de manipulación de matrices de almacenamiento. Los procesos internos buscan en la matriz de almacenamiento operaciones como buscar el archivo delta para anexar información sobre una fila eliminada. El costo de estas operaciones aumenta con el número de entradas.

Para ayudar a evitar estas ineficiencias, los CFP cerrados más antiguos se combinan, en función de una directiva de combinación descrita a continuación, por lo que la matriz de almacenamiento se compacta para representar el mismo conjunto de datos, con un número reducido de CFP.

El tamaño total en memoria de todas las tablas duraderas de una base de datos no debe superar los 250 GB. Las tablas duraderas que usan hasta 250 GB de memoria requerirán, suponiendo que las operaciones de inserción, eliminación y actualización requieran un promedio de 500 GB de espacio de almacenamiento. Se necesitan 4000 pares de archivos delta y de datos en el grupo de archivos optimizados para memoria para admitir los 500 GB de espacio de almacenamiento.

Los aumentos a corto plazo en la actividad de la base de datos pueden provocar retrasos en las operaciones de punto de control y combinación, lo que aumentará el número de pares de archivos de datos y delta necesarios. Para dar cabida a picos de actividad a corto plazo en la actividad de la base de datos, el sistema de almacenamiento puede asignar hasta 8,000 pares de archivos de datos y delta hasta un total de 1 TB de almacenamiento. Cuando se alcance ese límite, no habrá nuevas transacciones permitidas en la base de datos hasta que las operaciones de punto de control se ponga al día. Si el tamaño de las tablas persistentes en memoria supera los 250 GB durante largos períodos de tiempo, existe la posibilidad de llegar al límite de 8,000 pares de archivos.

La operación de combinación toma como entrada uno o varios CFP cerrados adyacentes (denominados origen de mezcla) en función de una directiva de combinación definida internamente y genera un CFP resultante, denominado destino de combinación. Las entradas de cada archivo delta de los CFP de origen se usan para filtrar las filas del archivo de datos correspondiente para quitar las filas de datos que no son necesarias. Las filas restantes de los CFPs de origen se consolidan en un único CFP de destino. Una vez completada la combinación, el CFP resultante de destino de combinación reemplaza los CFP de origen (orígenes de mezcla). Los CFP de origen de mezcla pasan por una fase de transición antes de quitarlas del almacenamiento.

En el ejemplo siguiente, el grupo de archivos de tabla optimizada para memoria tiene cuatro pares de archivos delta y de datos en la marca de tiempo 500 que contienen datos de transacciones anteriores. Por ejemplo, las filas del primer archivo de datos corresponden a transacciones con marca de tiempo mayor que 100 y menor o igual que 200; también representado como (100, 200]. Los archivos de datos segundo y tercero se muestran como inferiores al 50 % completos después de tener en cuenta las filas marcadas como eliminadas. La operación de combinación combina estos dos CFP y crea un nuevo CFP que contiene transacciones con marca de tiempo mayor que 200 y menor o igual que 400, que es el intervalo combinado de estos dos CFP. Verá otro CFP con intervalo (500, 600] y un archivo delta no vacío para el intervalo de transacciones (200, 400] que muestra que la operación de combinación se puede realizar simultáneamente con la actividad de transacciones, incluyendo la eliminación de más filas de los archivos CFP de origen.

Un subproceso en segundo plano evalúa todos los CFP cerrados usando una política de combinación y luego inicia una o varias solicitudes de combinación para los CFP aptos. El subproceso de punto de control sin conexión procesa estas solicitudes de combinación. La evaluación de la directiva de combinación se realiza periódicamente y también cuando se cierra un punto de control.

Directiva de combinación de SQL Server 2014 (12.x)

SQL Server 2014 (12.x) implementa la siguiente directiva de combinación:

• Se planifica una combinación si se pueden consolidar 2 o más CFP consecutivos, después de tener en cuenta las filas eliminadas, de modo que las filas resultantes puedan ajustarse a 1 CFP de tamaño ideal. El tamaño ideal de CFP se determina de la siguiente manera:

  • Si un equipo tiene menos o igual que 16 GB de memoria, el archivo de datos es de 16 MB y el archivo delta es de 1 MB.

  • Si un equipo tiene más de 16 GB de memoria, el archivo de datos es de 128 MB y el archivo delta es de 16 MB.

• Un único CFP se puede combinar automáticamente si el archivo de datos supera los 256 MB y se eliminan más de la mitad de las filas. Un archivo de datos puede crecer más de 128 MB si, por ejemplo, una sola transacción o varias transacciones simultáneas inserta o actualiza una gran cantidad de datos, lo que obliga al archivo de datos a crecer más allá de su tamaño ideal porque una transacción no puede abarcar varios CFP.

Estos son algunos ejemplos que ilustran los CFP que se combinarán bajo la política de combinación.

No todos los CFP con espacio disponible califican para la combinación. Por ejemplo, si dos CFP adyacentes están 60% llenos, no calificarán para la combinación y cada uno de estos CFPs tendrá 40% de almacenamiento no utilizado. En el peor de los casos, todos los CFP serán 50% completos, un uso del almacenamiento de solo 50%. Aunque las filas eliminadas pueden existir en el almacenamiento porque los CFP no cumplen los requisitos para la combinación, es posible que las filas eliminadas ya se hayan quitado de la memoria mediante la recolección de elementos no utilizados en memoria. La administración del almacenamiento y la memoria es independiente de la recolección de elementos no utilizados. El espacio de almacenamiento consumido por los CFP activos (no todos los CFP se están actualizando) puede llegar a ser hasta 2 veces más grande que el tamaño de las tablas duraderas en la memoria.

Si es necesario, se puede realizar explícitamente una combinación manual llamando a sys.sp_xtp_merge_checkpoint_files (Transact-SQL).

Ciclo de vida de un CFP

Las CPF pasan por varios estados antes de que se puedan desasignar. En cualquier momento, los CFP se encuentran en una de las siguientes fases: PRECREADO, EN CONSTRUCCIÓN, ACTIVO, OBJETIVO DE FUSIÓN, ORIGEN FUSIONADO, NECESARIO PARA RESPALDO/HA, EN TRANSICIÓN A TOMBSTONE y TOMBSTONE. Para obtener una descripción de estas fases, consulte sys.dm_db_xtp_checkpoint_files (Transact-SQL).

Después de tener en cuenta el almacenamiento utilizado por los CFP en varios estados, el almacenamiento total requerido por las tablas optimizadas para memoria duradera puede ser mucho mayor que el doble del tamaño de las tablas en memoria. El DMV sys.dm_db_xtp_checkpoint_files (Transact-SQL) se puede consultar para enumerar todos los CFP del grupo de archivos optimizados para memoria, incluidas sus fases. La transición de los CFP del estado MERGE SOURCE a TOMBSTONE y, finalmente, a la recolección de basura, puede ocupar hasta cinco puntos de control, con cada punto de control seguido de una copia de seguridad del registro de transacciones, si la base de datos está configurada para el modelo de recuperación completo o de carga masiva.

Puede forzar manualmente el punto de control seguido de la copia de seguridad del log para acelerar la recolección de basura, pero esto agregará 5 CFP vacíos (5 pares de archivos de datos o delta, cada uno con un archivo de datos de tamaño 128 MB). En escenarios de producción, los checkpoints automáticos y las copias de seguridad de los registros, tomadas como parte de la estrategia de copias de seguridad, permitirán que los CFP pasen sin problemas a través de estas fases sin necesidad de intervención manual. El impacto del proceso de recolección de elementos no utilizados es que las bases de datos con tablas optimizadas para memoria pueden tener un tamaño de almacenamiento mayor en comparación con su tamaño en memoria. No es raro que los CFP sean hasta cuatro veces más grandes que las tablas duraderas optimizadas para memoria.

Véase también

Creación y administración del almacenamiento para objetos de Memory-Optimized