Qu'arrive-t-il aux pages sales si le système tombe en panne avant le prochain point de contrôle?

En supposant qu'une base de données utilise un modèle de récupération complète, lorsqu'un enregistrement est écrit dans SQL Server (par INSERT/ UPDATEetc), la journalisation en écriture anticipée garantira que la modification est écrite dans le fichier journal avant de modifier la page de données.

Les entrées du journal et de la page de données sont effectuées dans la RAM et validées sur le disque ultérieurement par un point de contrôle.

S'il y a un plantage du système (perte de puissance pour les besoins de l'argument), qu'arrivera-t-il aux pages sales (données IE modifiées dans la RAM mais non validées sur le disque) car le contenu de la RAM ne survit pas au redémarrage du système, ces données sont-elles perdues ?

ÉDITER

Après quelques tests, je peux voir que les pages sales ne sont pas perdues, mais je ne sais pas pourquoi:

en utilisant ce tutoriel

créer une base de données de test

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

désactiver les points de contrôle automatiques

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

créer une table, insérer des données et émettre un point de contrôle:

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

confirmer aucune page sale

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

confirmer l'heure du dernier point de contrôle

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

Ajouter plus de lignes

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

Utilisez la requête ci-dessus pour confirmer qu'il y avait des pages sales

Tuez la tâche SQL Server à partir du gestionnaire de tâches pour simuler une mise hors tension.

Démarrez le service

Réexécutez la commande ci-dessus pour obtenir l'heure du dernier point de contrôle, c'était la même chose (IE aucun point de contrôle n'a été exécuté autre que celui que nous avons fait manuellement)

SÉLECTIONNÉ dans le tableau t1 et les quatre enregistrements étaient là

Les entrées du journal et de la page de données sont effectuées dans la RAM et validées sur le disque ultérieurement par un point de contrôle.

Cette affirmation n'est pas complètement vraie. Il est exact que les pages de données sont écrites sur le disque par Checkpoint (et Lazy Writer). Cependant, les enregistrements du journal sont physiquement écrits sur le disque lorsque la transaction est validée pour garantir la durabilité de la transaction. Une donnée de transaction validée ne sera jamais uniquement résidente en mémoire (sauf durabilité retardée).

Toutes les modifications de données sont d'abord écrites dans le journal (journalisation en écriture anticipée ) et les pages sales écrites par la suite. Les pages et les enregistrements de journal peuvent inclure à la fois des données validées et non validées sur le disque.

Quel que soit le modèle de récupération, SQL Server analyse le journal pendant la récupération après incident jusqu'au dernier point de contrôle, annule toutes les modifications de données à partir de ce point et annule finalement les transactions non validées.