3.18Работа с SQL Server. Различия между полной (FULL) и простой (SIMPLE) моделями восстановления базы. Особенности сжатия журнала транзакций
SQL Server поддерживает 3 модели восстановления базы:
- полная (FULL). Требует резервного копирования журнала транзакций и обеспечивает возможности для этого;
- с дополнительным протоколированием (BULK_LOGGED). «Тяжелые» (BULK) операции протоколируются по минимуму, и поэтому под их логирование задействуется меньше места. «Обычные» операции протоколируются так же, как в полной модели;
- простая (SIMPLE). Резервных копий журналов транзакций нет, операции по управлению ими не поддерживаются.
Для каждой из этих моделей имеются доводы за и против, исходящие только из того, какие резервные копии возможны (или необходимы) и на какие моменты времени нужно иметь возможность восстановления.
Если вы не намерены использовать резервные копии журнала и вам не нужна возможность восстановления состояния базы данных на точно определенный момент времени, не следует использовать модель восстановления FULL.
На практике это в первую очередь относится к тестовым базам, а также (внимание!) к ЦУП. Это так, поскольку места под журналы транзакций там может требоваться очень много, но крайне малореальна ситуация, что кто-то станет пытаться восстанавливать базу ЦУП по журналу транзакций на момент середины анализа. Достаточно полных копий (или dt) на момент начала анализа (для ЦУП) или начала теста (для тестовых баз).
Для общего понимания, как работает журнал транзакций, надо представлять, что в действительности до тех пор, пока записи в его начале получается обрезать (или очищать), он является кольцевым файлом. Если это получается, то, когда процедура ведения журнала достигает конца журнала транзакций, она снова поворачивает в начало и начинает писать поверх того, что было там ранее. Запись перестает быть нужной, если для нее истинно все из нижеперечисленного:
- транзакция, к которой относится эта запись, зафиксирована;
- все измененные ею страницы базы записаны на диск;
- запись лога не нужна для бэкапа (полного, разностного или бэкапа журнала);
- запись лога не нужна компонентам, читающим журнал (таким как зеркалирование или репликация).
Третий пункт списка выше очень важен для понимания следующего:
- в полной модели записи журнала транзакций хранятся до тех пор, пока они нужны для бэкапа. Чтобы снять необходимость их хранения, нужно сделать бэкап журнала транзакций;
- в простой модели хранится только то, что нужно для текущей жизни, а не для бэкапа.
Также он подводит к пониманию, почему:
- интенсивность записи журнала на диск для моделей с неполным протоколированием (BULK_LOGGED) и модели простой (SIMPLE) не различается вообще;
- интенсивность записи журнала на диск для моделей полная (FULL) и простая (SIMPLE) (как и с дополнительным протоколированием (BULK_LOGGED)), различается только для «тяжелых» (BULK) операций, которые для большинства случаев в «1С» можно пересчитать по пальцам (загрузка из dt, реструктуризация таблиц, перестроение индекса).
Таким образом, переключение модели не прибавляет и не отнимает производительности, если речь идет об информационных системах на платформе «1С:Предприятие». Речь только о месте на диске.
И еще выходит, что оснований для использования модели с дополнительным протоколированием (BULK_LOGGED) в информационных системах на платформе «1С:Предприятие» почти нет, поэтому про нее далее не пишем. Нужно выбирать из полной (FULL) или простой (SIMPLE) моделей.
Модель восстановления можно указать в Management Studio, вызвав правой кнопкой мыши контекстное меню на имени нужной базы, выбрав Свойства (Properties) и перейдя на страницу Параметры (Options). Нужное значение задается в поле Модель восстановления (Recovery model), см. рис. 3.18.1. Обратите внимание также на поле Автоматическое сжатие (Auto shrink). MSDN рекомендует не трогать этот параметр, оставив его в False.
Рис. 3.18.1. Изменение модели восстановления базы
Модель восстановления базы данных можно в любой момент переключить с полной на простую и обратно. При этом надо придерживаться простых правил:
1. Перед переключением с модели полного восстановления создать резервную копию журнала транзакций.
2. После переключения с простой модели восстановления:
- сразу же после переключения на модель полного восстановления создать полную или разностную резервную копию базы данных, чтобы начать цепочку журналов. Переключение на модель полного восстановления вступает в силу только после создания первой резервной копии данных;
- создать в планах обслуживания регулярное резервное копирование журнала. Если резервные копии журнала создаются недостаточно часто, журнал транзакций может разрастаться до тех пор, пока не переполнит диск.
3. После переключения на простую модель восстановления:
- отменить все запланированные задания резервного копирования журнала транзакций;
- убедиться, что запланировано периодическое резервное копирование базы данных. Резервное копирование базы данных очень важно как для защиты данных, так и для усечения (truncation) неактивной части журнала транзакций.
Теперь рассмотрим сжатие журнала транзакций. Если вам известно, что файл журнала транзакции содержит неиспользуемое пространство, которое вам не нужно, можно освободить его, уменьшив размер журнала. Этот процесс называется сжатием (Shrink) файла журнала.
Выполнить его можно в Management Studio, вызвав правой кнопкой мыши контекстное меню на имени нужной базы: Задачи (Tasks) – Сжать (Shrink) – Файлы. Дальше в поле Тип файла (File type) выбрать Журнал (Log). Остальные настройки можно оставить по умолчанию, как на рис. 3.18.2, после чего нажать ОК.
Рис. 3.18.2. Настройки по умолчанию для сжатия журнала транзакций
Сжатие может производиться только в том случае, если база данных находится в оперативном режиме и пока свободен хотя бы один виртуальный файл журнала (что это такое, см. TechNet). Важно то, что в ряде случаев сжатие невозможно до тех пор, пока не выполнена следующая операция усечения (truncation) журнала. Принудительно усечение можно попробовать выполнить при использовании простой модели восстановления, создав резервную копию базы данных, при использовании модели полного восстановления – резервную копию журнала транзакции, потому что обычно усечение при выполнении этих действий происходит автоматически. Если же сжатие не выполнится с первого раза с нужным эффектом (сжатие ждет усечения, а усечение может быть отложено по ряду причин, см. TechNet), на практике достаточно немного подождать и повторить создание копии нужного вида и сжатие.
На практике различия можно увидеть следующим образом.
Для базы, использующей модель FULL, создадим полную резервную копию.
Размеры файлов показаны на рис. 3.18.3.
Рис. 3.18.3. Начальное состояние
Выполним перепроведение документов Расходный кассовый ордер с помощью групповой обработки справочников и документов, как показано на рис. 3.18.4.
Рис. 3.18.4. Выполнение групповой обработки
После ее выполнения свойства файлов будут выглядеть, как показано на рис. 3.18.5.
Рис. 3.18.5. Свойства файлов базы и журнала транзакций после выполнения действий в базе с полной моделью восстановления
Мы попытались создать резервную полную копию базы, но сжать журнал транзакций это почти не помогло (см. рис. 3.18.6).
Рис. 3.18.6. Размер журнала транзакций после сжатия без предшествующего ему создания резервной копии журнала транзакций
Если же создать резервную копию журнала транзакций и попытаться сжать журнал транзакций, размер его файла изменится значительно (см. рис. 3.18.7).
Рис. 3.18.7. Размер журнала транзакций после сжатия с предшествующим ему созданием резервной копии журнала транзакций
Восстановим базу на начало эксперимента, см. рис. 3.18.8 (сравните с рис. 3.18.3).
Рис. 3.18.8. Базу вернули в исходное состояние
Далее базу переведем на использование простой модели восстановления (см. рис. 3.18.1) и выполним в ней те же самые действия (см. рис. 3.18.4). Размер файла базы и дата его изменения изменятся, размер и дата изменения журнала транзакций – нет (см. рис. 3.18.9).
Рис. 3.18.9. Свойства файлов базы и журнала транзакций после выполнения действий в базе с простой моделью восстановления
