O que acontece com as páginas sujas se o sistema falhar antes do próximo ponto de verificação?

Supondo que um banco de dados usando o modelo de recuperação completa, quando um registro é gravado no SQL Server (por INSERT/ UPDATEetc), o log de gravação antecipada garantirá que a alteração seja gravada no arquivo de log antes de modificar a página de dados.

As entradas da página de log e de dados são feitas na RAM e confirmadas no disco posteriormente por um ponto de verificação.

Se houver uma falha no sistema (perda de energia por uma questão de argumento), o que acontecerá com páginas sujas (dados do IE que são alterados na RAM, mas não confirmados no disco), pois o conteúdo da RAM não sobrevive à reinicialização do sistema, esses dados são perdidos ?

EDITAR

Após alguns testes, vejo que as páginas sujas não estão perdidas, mas não sei por que:

usando este tutorial

criar um banco de dados de teste

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

desativar pontos de verificação automáticos

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

crie uma tabela, insira alguns dados e emita um ponto de verificação:

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

confirme se não há páginas sujas

-- 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 a hora do último ponto de verificação

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');

Adicione mais linhas

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

Use a consulta acima para confirmar que havia páginas sujas

Mate a tarefa do SQL Server do gerenciador de tarefas para simular um desligamento.

Iniciar o serviço

Execute novamente o comando acima para obter o último horário do ponto de verificação; era o mesmo (no IE, nenhum ponto de verificação foi executado além do que fizemos manualmente)

SELECT da tabela t1 e todos os quatro registros estavam lá

As entradas da página de log e de dados são feitas na RAM e confirmadas no disco posteriormente por um ponto de verificação.

Esta afirmação não é completamente verdadeira. É correto que as páginas de dados sejam gravadas no disco pelo Checkpoint (e Lazy Writer). Os registros de log, no entanto, são gravados fisicamente no disco quando a transação é confirmada para garantir a durabilidade da transação. Um dado de transação confirmado nunca será apenas residente na memória (com exceção da durabilidade atrasada).

Todas as modificações de dados são primeiro gravadas no log (registro write-ahead ) e as páginas sujas gravadas posteriormente. As páginas e os registros de log podem incluir dados confirmados e não confirmados no disco.

Independentemente do modelo de recuperação, o SQL Server verifica o log durante a recuperação de falhas até o último ponto de verificação, encaminha todas as modificações de dados desse ponto em diante e, finalmente, reverte as transações não confirmadas.