Durabilidad de las tablas optimizadas para memoria

Se aplica a:SQL Server

OLTP en memoria proporciona durabilidad total 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 (sobreviven a un reinicio de la base de datos), siempre que el almacenamiento subyacente esté disponible. Hay dos componentes clave de durabilidad: registro de transacciones y conservación de los cambios de los datos en el almacenamiento en disco.

Para obtener más información sobre las limitaciones de tamaño de las tablas duraderas, consulte Estimación de los requisitos de memoria para tablas optimizadas para memoria.

Registro de transacciones

Todos los cambios realizados en tablas basadas en disco o en tablas optimizadas para memoria se capturan en una o más entradas del registro de transacciones. Cuando se confirma una transacción, SQL Server escribe en el disco las entradas de registro asociadas a la transacción antes de comunicar a la aplicación o a la sesión de usuario que la transacción se ha confirmado. Esto garantiza que los cambios realizados por la transacción sean durables. El registro de transacciones para las tablas optimizadas para memoria está totalmente integrado con el mismo flujo de registro que emplean 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 su carga de trabajo, la E/S de log podría convertirse en un cuello de botella de rendimiento. Para dar cabida a este aumento del rendimiento, asegúrese de que el subsistema de E/S de registro puede hacerse cargo del incremento de la carga.

Archivos delta y de datos

Los datos de las tablas optimizadas para memoria se almacenan como filas de datos de forma libre en una estructura de datos del montón en memoria y se vinculan a través de uno o varios índices en memoria. No hay ninguna estructura de página para las filas de datos, como las empleadas para las tablas basadas en disco. Para la persistencia a largo plazo y para permitir el truncamiento del registro de transacciones, las operaciones en las tablas optimizadas para memoria se conservan en un conjunto de archivos delta y de datos. Estos archivos se generan según el registro de transacciones por medio de un proceso asincrónico en segundo plano. Los archivos de datos y delta se encuentran en uno o varios contenedores (con el mismo mecanismo empleado para los datos FILESTREAM). Estos contenedores forman parte de un grupo de archivos optimizados para memoria.

Los datos se escriben en estos archivos de un modo estrictamente secuencial, lo que reduce la latencia de disco para las unidades de disco. Puede utilizar varios contenedores en discos diferentes para distribuir la actividad de E/S. Los archivos de datos y de delta en múltiples contenedores en diferentes discos aumentan el rendimiento de la restauración o recuperación de la base de datos cuando los datos se leen desde los archivos de datos y de delta en disco, hasta la memoria.

Las transacciones de usuario no acceden directamente a los datos ni a los archivos delta. Todas las lecturas y escrituras de datos usan estructuras de datos en memoria.

El archivo de datos

Un archivo de datos contiene filas de una o más tablas optimizadas para memoria que se han insertado mediante varias transacciones como parte de las operaciones INSERT o UPDATE. Por ejemplo, una fila puede ser de una tabla T1 optimizada para memoria y la siguiente puede ser de una tabla T2 optimizada para memoria. Las filas se anexan al archivo de datos en el orden de las transacciones del registro de transacciones, con lo que el acceso a los datos es secuencial. Esto permite un mejor rendimiento de la E/S del orden de magnitud en comparación con la E/S aleatoria.

Una vez que el archivo de datos está lleno, las filas insertadas por las nuevas transacciones se almacenan en otro archivo de datos. Con el tiempo, las filas de las tablas optimizadas para memoria duraderas se almacenan en uno o más archivos de datos y cada archivo de datos contiene filas que forman un intervalo de transacciones separado pero contiguo. Por ejemplo, un archivo de datos con una marca de tiempo de confirmación de transacción en el intervalo de (100, 200) tiene todas las filas insertadas por transacciones cuya marca de tiempo de confirmación es 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 única de confirmación.

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. Se procesan las operaciones de actualización como una tupla de las operaciones de eliminación e inserción para cada fila. Esto elimina la E/S aleatoria en el archivo de datos.

Tamaño: cada archivo de datos tiene un tamaño aproximado de 128 MB en los equipos con más de 16 GB de memoria y de 16 MB en los equipos con 16 GB o menos. En SQL Server 2016 (13.x) puede usar el modo de punto de comprobación grande si considera que el subsistema de almacenamiento es lo suficientemente rápido. En el modo de punto de comprobación grande, los archivos de datos tienen un tamaño de 1 GB. Esto permite una mayor eficacia en el subsistema de almacenamiento para las cargas de trabajo de alto rendimiento.

El archivo delta

Cada archivo de datos está emparejado con un archivo delta que tiene el mismo intervalo de transacciones y hace un seguimiento de las filas eliminadas insertadas por transacciones en el intervalo de transacciones. Este archivo de datos y delta se conoce como par de archivos de punto de control (CFP) y es la unidad de asignación y desasignación, así como la unidad para las operaciones de combinación. Por ejemplo, un archivo delta correspondiente al intervalo de transacciones (100, 200) almacena filas eliminadas insertadas por transacciones en el intervalo (100, 200). Como los archivos de datos, se tiene acceso al archivo delta de forma secuencial.

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. Puesto que la fila que se va a eliminar ya existe en el archivo de datos, el archivo delta solo almacena la información de referencia {inserting_tx_id, row_id, deleting_tx_id} y sigue el orden del registro transaccional de las operaciones de eliminación o actualización de origen.

Tamaño: cada archivo delta tiene un tamaño aproximado de 16 MB en los equipos con más de 16 GB de memoria y de 1 MB en los equipos con 16 GB o menos. A partir de SQL Server 2016 (13.x) puede usar el modo de punto de comprobación grande si considera que el subsistema de almacenamiento es lo suficientemente rápido. En el modo de punto de comprobación grande, los archivos delta tienen un tamaño de 128 MB.

Rellenar datos y archivos delta

Los archivos delta y de datos se rellenan según los registros de transacciones generados por las transacciones confirmadas en las tablas optimizadas para memoria y se anexa información sobre las filas insertadas y eliminadas en los archivos de datos y delta correspondientes. A diferencia de las tablas basadas en disco donde las páginas de índice o datos se vacían con E/S aleatoria cuando se realiza el punto de comprobación, la persistencia de la tabla optimizada para memoria es una operación en segundo plano continua. Se obtiene acceso a varios archivos delta porque una transacción puede eliminar o actualizar cualquier fila que fuera insertada por alguna 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 cuatro 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 producen los siguientes eventos.

Trabajadores de puntos de control sin conexión

Este subproceso anexa las inserciones y eliminaciones para las filas de datos optimizadas para memoria a los pares correspondientes de archivos delta y de datos. SQL Server 2014 (12.x) tiene un trabajador de punto de control desconectado. SQL Server 2016 (13.x) y versiones posteriores tienen varios trabajos de punto de control.

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 archivos delta y de datos.

Durante la recuperación tras bloqueo

Cuando se reinicia SQL Server o la base de datos se pone en línea, los datos optimizados para memoria se rellenan con 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 de datos es independiente, estos archivos se cargan en paralelo para reducir el tiempo dedicado a rellenar los datos en la memoria. Una vez que los datos se cargan 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 los datos optimizados para memoria se completen.

Durante la operación de restauración

Los archivos de puntos de comprobación de OLTP en memoria se crean a partir de la copia de seguridad de la base de datos y, a continuación, se aplican una o más copias de seguridad del registro de transacciones. Al igual que con la recuperación de fallos, el motor In-Memory OLTP carga datos en paralelo en la memoria para reducir el impacto en el tiempo de recuperación.

Combinar datos y archivos delta

Los datos de las tablas con optimización para memoria se almacenan en uno o varios pares de archivos de datos y delta (también denominados pares de archivos de puntos de comprobación o CFP). Los archivos de datos almacenan las filas insertadas y los archivos delta hacen referencia a las filas eliminadas. Durante la ejecución de una carga de trabajo de OLTP como las operaciones DML de actualización, inserción y eliminación de filas, se crean nuevos CFP para conservar las filas nuevas y la referencia a las filas eliminadas se anexa a los archivos delta.

Con el tiempo, con las operaciones DML, el número de archivos de datos y delta crece, lo que provoca un mayor uso del espacio en disco y un mayor tiempo de recuperación.

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

La operación de combinación toma como entrada uno o varios pares de archivos de punto de control cerrado adyacentes (CFP), que son pares de archivos de datos y delta (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 CFP de origen se consolidan en un 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 de datos y delta en la marca de tiempo 500 que contienen datos de transacciones anteriores. Por ejemplo, las filas del primer archivo de datos corresponden a las transacciones con marca de tiempo mayor que 100 y menor o igual que 200; de forma alternativa, se representan como (100, 200]. Los archivos de datos segundo y tercero están completos menos de un 50 por ciento tras 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 las transacciones con marca de tiempo mayor que 200 y menor o igual que 400, que es el intervalo combinado de estos dos CFP. Puede ver otro CFP con intervalo (500, 600] y el archivo delta no vacío para el intervalo de transacción (200, 400] muestra que la operación de combinación se puede realizar de forma simultanea a la actividad transaccional que incluye la eliminación de varias filas de los CFP de origen.

Un subproceso en segundo plano evalúa todos los CFP cerrados mediante una directiva de combinación y después inicia una o varias solicitudes para los CFP aptos. Estas solicitudes de combinación se procesan mediante el subproceso de punto de comprobación sin conexión. La evaluación de la directiva de combinación se realiza periódicamente y también cuando se cierra un punto de comprobación.

Directiva de combinación de SQL Server

SQL Server implementa la directiva de combinación siguiente:

• Se planifica una combinación si se pueden consolidar dos o más CFP consecutivos, después de tener en cuenta las filas eliminadas, de modo que las filas resultantes puedan caber en un CFP de tamaño de destino. El tamaño de destino de los archivos de datos y delta corresponde al tamaño original, tal como se ha descrito anteriormente.

• Un único CFP se puede autocombinar si el archivo de datos supera el doble del tamaño de destino y se eliminan más de la mitad de las filas. Un archivo de datos puede aumentar más que el tamaño de destino 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 de destino, porque una transacción no puede abarcar varios CFP.

Estos son algunos ejemplos que muestran cómo los CFP se van a fusionar según la política de fusión.

Archivos de origen cfP adyacentes (% lleno)	Selección de mezcla
CFP0 (30 %), CFP1 (50 %), CFP2 (50 %), CFP3 (90 %)	(CFP0, CFP1) CFP2 no se elige porque hace que el archivo de datos resultante sea mayor que 100% del tamaño ideal.
CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%)	(CFP0, CFP1, CFP2). Los archivos se eligen empezando desde la izquierda. CFP3 no se elige porque hace que el archivo de datos resultante sea mayor que 100% del tamaño ideal.
CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%)	(CFP1, CFP2, CFP3). Los archivos se eligen empezando desde la izquierda. CFP0 se omite porque si se combina con CFP1, el archivo de datos resultante es mayor que 100% del tamaño ideal.

No todos los CFP con espacio disponible con aptos para la combinación. Por ejemplo, si dos CFP adyacentes están llenos al 60%, no califican para la combinación y cada uno de estos CFPs tiene un 40% de almacenamiento no utilizado. En el peor de los casos, todos los CFPs están al 50% de llenos, un aprovechamiento de almacenamiento de solo el 50%. Aunque es posible que las filas eliminadas existan en el almacenamiento porque las 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 de almacenamiento y de la memoria es independiente de la recolección de elementos no utilizados. El espacio de almacenamiento que ocupan los CFP activos (no todos los CFP se actualizan) puede ser hasta dos veces mayor que el tamaño de las tablas persistentes en la memoria.

Ciclo de vida de un CFP

Los CFP hacen una transición por varios estados antes de que se puedan desasignar. Es necesario que se produzcan puntos de comprobación de base de datos y copias de seguridad de registros para que los archivos vayan avanzado por cada fase y, en última instancia, se limpien aquellos archivos que ya no sean necesarios. Para obtener una descripción de estas fases, consulte sys.dm_db_xtp_checkpoint_files.

Puede forzar manualmente el punto de comprobación seguido de una copia de seguridad de registros para acelerar la recolección de elementos no utilizados. En escenarios de producción, los puntos de control automáticos y las copias de seguridad de registros tomadas como parte de la estrategia de copia de seguridad pasan sin inconvenientes los CFP a través de estas fases sin que sea necesaria intervención manual. El efecto del proceso de recolección de elementos no utilizados es que las bases de datos con tablas optimizadas para memoria podrían tener un tamaño de almacenamiento mayor en comparación con su tamaño en memoria. Si no se producen copias de seguridad de puntos de comprobación y registro, la superficie en disco de los archivos de punto de control sigue creciendo.

Contenido relacionado

• Creación y administración del almacenamiento para objetos optimizados para memoria