¿Qué sucede con las páginas sucias si el sistema falla antes del próximo punto de control?

Suponiendo que una base de datos use el modelo de recuperación completa, cuando se escribe un registro en SQL Server (por INSERT/ UPDATEetc), el registro de escritura anticipada garantizará que el cambio se escriba en el archivo de registro antes de modificar la página de datos.

Tanto las entradas de la página de registro como las de datos se realizan en RAM y un punto de control las confirma más tarde en el disco.

Si hay un bloqueo del sistema (pérdida de energía por el argumento), qué pasará con las páginas sucias (datos de IE que se cambian en la RAM pero no se comprometen en el disco) ya que el contenido de la RAM no sobrevive al reinicio del sistema, ¿se pierden estos datos ?

EDITAR

Después de algunas pruebas, puedo ver que las páginas sucias no se pierden, pero no estoy seguro de por qué:

usando este tutorial

crear una base de datos de prueba

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

desactivar los puntos de control automáticos

DBCC TRACEON(3505, -1);
DBCC TRACESTATUS();

crear una tabla, insertar algunos datos y emitir un punto de control:

CREATE TABLE t1 (Speaker_Bio CHAR(8000))
GO
INSERT INTO t1 VALUES ('SQL'),('Authority')
GO
CHECKPOINT

confirmar que no hay páginas sucias

-- Get the rows of dirtied pages
SELECT
database_name = d.name,
OBJECT_NAME =
CASE au.TYPE
WHEN 1 THEN o1.name
WHEN 2 THEN o2.name
WHEN 3 THEN o1.name
END,
OBJECT_ID =
CASE au.TYPE
WHEN 1 THEN p1.OBJECT_ID
WHEN 2 THEN p2.OBJECT_ID
WHEN 3 THEN p1.OBJECT_ID
END,
index_id =
CASE au.TYPE
WHEN 1 THEN p1.index_id
WHEN 2 THEN p2.index_id
WHEN 3 THEN p1.index_id
END,
bd.FILE_ID,
bd.page_id,
bd.page_type,
bd.page_level
FROM sys.dm_os_buffer_descriptors bd
INNER JOIN sys.databases d
ON bd.database_id = d.database_id
INNER JOIN sys.allocation_units au
ON bd.allocation_unit_id = au.allocation_unit_id
LEFT JOIN sys.partitions p1
ON au.container_id = p1.hobt_id
LEFT JOIN sys.partitions p2
ON au.container_id = p2.partition_id
LEFT JOIN sys.objects o1
ON p1.OBJECT_ID = o1.OBJECT_ID
LEFT JOIN sys.objects o2
ON p2.OBJECT_ID = o2.OBJECT_ID
WHERE is_modified = 1
AND d.name = 'DirtyPagesDB'
AND
(
o1.name = 't1'
OR o2.name = 't1'
);
GO

confirmar hora del último punto de control

SELECT  f1.[Checkpoint Begin], f2.[Checkpoint End]
FROM    fn_dblog(NULL, NULL) f1
        JOIN fn_dblog(NULL, NULL) f2
             On f1.[Current LSN] = f2.[Previous LSN]
WHERE   f2.Operation IN (N'LOP_BEGIN_CKPT', N'LOP_END_CKPT');

Agregar más filas

INSERT INTO t1 VALUES ('SQL'),('Authority')

Use la consulta anterior para confirmar que había páginas sucias

Elimine la tarea de SQL Server desde el administrador de tareas para simular un apagado.

Inicia el servicio

Vuelva a ejecutar el comando anterior para obtener el último tiempo de punto de control, fue el mismo (es decir, no se han ejecutado puntos de control que no sean los que hicimos manualmente)

SELECCIONADO de la tabla t1 y los cuatro registros estaban allí

Tanto las entradas de la página de registro como las de datos se realizan en RAM y un punto de control las confirma más tarde en el disco.

Esta afirmación no es completamente cierta. Es correcto que Checkpoint (y Lazy Writer) escriban páginas de datos en el disco. Sin embargo, los registros de anotaciones se escriben físicamente en el disco cuando la transacción se compromete a garantizar la durabilidad de la transacción. Los datos de transacción comprometidos nunca serán solo residentes de la memoria (salvo la durabilidad retrasada).

Todas las modificaciones de datos se escriben primero en el registro (registro de escritura anticipada ) y las páginas sucias se escriben después. Las páginas y los registros pueden incluir datos confirmados y no confirmados en el disco.

Independientemente del modelo de recuperación, SQL Server escanea el registro durante la recuperación del bloqueo al último punto de control, reenvía todas las modificaciones de datos desde ese punto hacia adelante y finalmente revierte las transacciones no confirmadas.