Что происходит с грязными страницами, если система выходит из строя до следующей контрольной точки?

Предполагая, что база данных использует модель полного восстановления, когда запись записывается в SQL Server (с помощью INSERT/ UPDATEetc), запись в журнал с опережением записи гарантирует, что изменение будет записано в файл журнала перед изменением страницы данных.

Записи журнала и страницы данных создаются в оперативной памяти и записываются на диск позже контрольной точкой.

Если происходит сбой системы (потеря мощности ради аргумента), что произойдет с грязными страницами (данные IE, которые изменяются в ОЗУ, но не записываются на диск), поскольку содержимое ОЗУ не сохраняется после перезапуска системы, если эти данные будут потеряны ?

РЕДАКТИРОВАТЬ

После некоторого тестирования я вижу, что грязные страницы не потеряны, но я не уверен, почему:

используя этот учебник

создать тестовую базу данных

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

отключить автоматические контрольные точки

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

создайте таблицу, вставьте некоторые данные и введите контрольную точку:

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

не подтверждать грязные страницы

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

подтвердить время последней контрольной точки

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

Добавить больше строк

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

Используйте запрос выше, чтобы подтвердить, что были грязные страницы

Убейте задачу SQL Server из диспетчера задач, чтобы имитировать отключение питания.

Запустить сервис

Повторите команду выше, чтобы получить время последней контрольной точки, оно было таким же (т.е. никакие контрольные точки не выполнялись, кроме той, которую мы сделали вручную)

ВЫБРАН из таблицы t1 и все четыре записи были там

Записи журнала и страницы данных создаются в оперативной памяти и записываются на диск позже контрольной точкой.

Это утверждение не совсем верно. Это верно, что страницы данных записываются на диск Checkpoint (и Lazy Writer). Журнальные записи, однако, физически записываются на диск, когда транзакция совершается, чтобы гарантировать долговечность транзакции. Данные совершенной транзакции никогда не будут только резидентными (исключая отсроченный срок службы).

Все изменения данных сначала записываются в журнал ( запись с опережением записи ), а грязные страницы записываются позже. Страницы и записи журнала могут содержать как зафиксированные, так и незафиксированные данные на диске.

Независимо от модели восстановления, SQL Server сканирует журнал во время восстановления после сбоя до последней контрольной точки, откатывает все изменения данных с этого момента и, наконец, откатывает незафиксированные транзакции.