Режим простого восстановления

Режим простого восстановления — это модель восстановления базы данных в системах управления базами данных (СУБД), в частности в Microsoft SQL Server, которая характеризуется минимальным ведением журнала транзакций и автоматическим освобождением пространства журнала после каждой завершённой транзакции. Данный режим предназначен для баз данных, где допустима потеря данных с момента последнего полного или дифференциального резервного копирования, и не требуется восстановление на момент времени (Point-in-Time Recovery, PITR). Режим простого восстановления является одним из трёх стандартных режимов восстановления в SQL Server, наряду с полным режимом и режимом с неполным протоколированием.

Общие сведения

Режим простого восстановления (Simple Recovery Model) управляет тем, как SQL Server обрабатывает журнал транзакций (log file). В этом режиме журнал транзакций автоматически усекается (truncated) после каждой завершённой контрольной точки (checkpoint), что означает, что записи о завершённых транзакциях удаляются из журнала, освобождая место для новых операций. Это резко снижает требования к дисковому пространству для файла журнала и упрощает администрирование, так как не требуется управлять резервными копиями журнала транзакций.

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

История

Режим простого восстановления был введён в Microsoft SQL Server 7.0 (1998 год) как часть трёхуровневой модели восстановления, пришедшей на смену более простым механизмам в ранних версиях (SQL Server 6.5 и ранее). До этого существовала только одна модель, которая требовала обязательного резервного копирования журнала транзакций для восстановления после сбоя. С введением режимов восстановления администраторы получили возможность выбирать баланс между производительностью, надёжностью и объёмом хранимых данных журнала. Режим простого восстановления стал стандартным выбором для тестовых, учебных и некритичных баз данных, где потеря данных за короткий промежуток времени приемлема.

Характеристики и принцип работы

Усечение журнала транзакций

Основной механизм, отличающий режим простого восстановления, — автоматическое усечение журнала транзакций. После каждой контрольной точки (checkpoint) SQL Server помечает неактивные части журнала как доступные для повторного использования. Контрольная точка — это операция, которая записывает все «грязные» страницы (изменённые в памяти) на диск и фиксирует точку согласованности данных. В режиме простого восстановления контрольная точка происходит автоматически с определённой периодичностью, а также принудительно при выполнении команд CHECKPOINT или при переполнении журнала.

Отсутствие резервного копирования журнала

В режиме простого восстановления резервное копирование журнала транзакций (BACKUP LOG) не поддерживается. Попытка выполнить такую команду приведёт к ошибке. Вся защита данных сводится к полным и дифференциальным резервным копиям базы данных. Это означает, что восстановление возможно только до момента последнего полного или дифференциального резервного копирования.

Восстановление после сбоя

При аварийном завершении работы SQL Server (например, из-за сбоя питания или отказа диска) база данных в режиме простого восстановления может быть восстановлена только до последней контрольной точки. Все транзакции, завершённые после последней контрольной точки, но ещё не записанные в файлы данных, будут потеряны. Восстановление на момент времени (Point-in-Time) невозможно, так как журнал не содержит достаточной истории для этого.

Применение

Режим простого восстановления рекомендуется использовать в следующих сценариях:

• Тестовые и разработческие базы данных: где потеря данных за короткий промежуток времени (например, до последнего полного резервного копирования) не является критичной, а производительность и простота администрирования важнее.
• Базы данных с низкой интенсивностью изменений: например, справочные или архивные базы данных, которые обновляются редко (например, раз в сутки).
• Системы, где допустима потеря данных за последние несколько минут: например, некоторые системы мониторинга, где данные могут быть восстановлены из других источников.
• Базы данных, которые не требуют восстановления на момент времени: например, базы данных для отчётов, которые перезагружаются из внешних источников.

Ограничения и недостатки

• Потеря данных: при сбое теряются все изменения, сделанные после последнего полного или дифференциального резервного копирования. Время восстановления ограничено точкой последнего резервного копирования, а не моментом сбоя.
• Невозможность восстановления на момент времени: нельзя восстановить базу данных на состояние до определённой транзакции (например, до случайного удаления данных).
• Непригодность для критически важных систем: для систем с высокими требованиями к надёжности (например, банковские, медицинские) режим простого восстановления не подходит.
• Ручное управление резервными копиями: администратор должен самостоятельно планировать и выполнять полные и дифференциальные резервные копии, так как автоматическое резервное копирование журнала отсутствует.

Сравнение с другими режимами восстановления

Переключение между режимами

Администратор базы данных может изменить режим восстановления с помощью команды ALTER DATABASE. Переключение с полного режима на простой возможно в любой момент, но при этом теряется возможность восстановления на момент времени, а журнал транзакций будет усечён при следующей контрольной точке. Переключение с простого режима на полный требует немедленного выполнения полного резервного копирования базы данных, чтобы журнал транзакций начал записываться с полным протоколированием.

Влияние на производительность

Режим простого восстановления снижает нагрузку на подсистему ввода-вывода, так как журнал транзакций не растёт бесконтрольно и не требует частого резервного копирования. Это может улучшить производительность операций записи, особенно в системах с высокой транзакционной нагрузкой. Однако, при большом объёме изменений между контрольными точками производительность может снизиться из-за необходимости выполнения полной контрольной точки.

Примеры использования

• База данных для интернет-магазина на этапе разработки: разработчики могут тестировать новые функции, не беспокоясь о росте журнала, и выполнять резервное копирование раз в сутки.
• База данных для учёта посещаемости сайта: данные обновляются каждые 5 минут, и потеря данных за последние 5 минут считается допустимой.
• База данных для хранения конфигураций системы: изменения вносятся редко, и резервное копирование выполняется после каждого изменения.

Источники

1. Microsoft Learn. Документация по режимам восстановления SQL Server.
2. Itzik Ben-Gan, Dejan Sarka, Ron Talmage. "Inside Microsoft SQL Server 2008: T-SQL Programming".
3. Kalen Delaney. "SQL Server 2008 Internals".
4. Microsoft SQL Server Books Online (BOL).