Cosa succede alle pagine sporche se il sistema si guasta prima del prossimo checkpoint?

Supponendo che un database utilizzi il modello di recupero completo, quando un record viene scritto in SQL Server (da INSERT/ UPDATEetc), la registrazione anticipata assicurerà che la modifica venga scritta nel file di registro prima di modificare la pagina di dati.

Entrambe le voci della pagina di registro e dei dati vengono create nella RAM e sottoposte a commit sul disco in seguito da un Checkpoint.

Se si verifica un arresto anomalo del sistema (interruzione dell'alimentazione per motivi di argomento) cosa accadrà alle pagine sporche (dati IE che vengono modificati nella RAM ma non impegnati sul disco) poiché il contenuto della RAM non sopravvive al riavvio del sistema, questi dati vengono persi? ?

MODIFICARE

Dopo alcuni test, vedo che le pagine sporche non vengono perse, ma non sono sicuro del perché:

usando questo tutorial

creare un database di test

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

disattiva i checkpoint automatici

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

creare una tabella, inserire alcuni dati ed emettere un checkpoint:

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

confermare senza pagine sporche

-- 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

confermare l'ora dell'ultimo checkpoint

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

Aggiungi più righe

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

Usa la query sopra per confermare che c'erano pagine sporche

Uccidere l'attività di SQL Server dal Task Manager per simulare uno spegnimento.

Avvia il servizio

Rieseguire il comando sopra per ottenere l'ultimo orario del checkpoint, era lo stesso (IE nessun checkpoint è stato eseguito diverso da quello che abbiamo fatto manualmente)

SELEZIONATO dalla tabella t1 e tutti e quattro i record erano lì

Entrambe le voci della pagina di registro e dei dati vengono create nella RAM e sottoposte a commit sul disco in seguito da un Checkpoint.

Questa affermazione non è completamente vera. È corretto che le pagine di dati siano scritte su disco da Checkpoint (e Lazy Writer). I record di registro, tuttavia, vengono scritti fisicamente su disco quando la transazione viene impegnata per garantire la durata della transazione. I dati di una transazione impegnata non saranno mai solo residenti in memoria (salvo la durata ritardata).

Tutte le modifiche ai dati vengono prima scritte nel registro ( registrazione in anticipo ) e pagine sporche scritte successivamente. Le pagine e i registri possono includere sia dati impegnati che non impegnati sul disco.

Indipendentemente dal modello di recupero, SQL Server esegue la scansione del registro durante il ripristino di emergenza fino all'ultimo checkpoint, esegue il roll forward di tutte le modifiche dei dati da quel punto in avanti e infine ripristina le transazioni senza commit.