Архитектура журнала транзакций и управление им

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

В этом руководстве

Логическая архитектура журнала транзакций

Физическая архитектура журнала транзакций

Журнал транзакций с упреждающей записью

Резервные копии журналов транзакций

Логическая архитектура журнала транзакций

Логически журнал транзакций SQL Server работает так, как если бы он являлся последовательностью записей в журнале. Каждая запись журнала идентифицируется регистрационным номером транзакции (номер LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи. Записи журнала хранятся в той последовательности, в которой они были созданы. Каждая запись журнала содержит идентификатор транзакции, к которой она относится. Все записи журнала, связанные с определенной транзакцией, с помощью обратных указателей связаны в цепочку, которая предназначена для ускорения отката транзакции.

Записи журнала для изменения данных содержат либо выполненную логическую операцию, либо исходный и результирующий образ измененных данных. Исходный образ записи — это копия данных до выполнения операции, а результирующий образ — копия данных после ее выполнения.

Действия, которые необходимо выполнить для восстановления операции, зависят от типа журнальной записи:

• Зарегистрирована логическая операция.

  • Для наката логической операции выполняется эта операция.

  • Для отката логической операции выполняется логическая операция, обратная зарегистрированной.

• Зарегистрированы исходный и результирующий образы записи.

  • Для наката операции применяется результирующий образ.

  • Для отката операции применяется исходный образ.

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

• начало и конец каждой транзакции;

• любые изменения данных (вставка, обновление или удаление), включая изменения в любой таблице (в том числе и в системных таблицах), производимые системными хранимыми процедурами или инструкциями языка DDL;

• любое выделение и освобождение страниц и экстентов;

• создание и удаление таблиц и индексов.

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

Раздел журнального файла, который начинается от первой записи, необходимой для успешного отката на уровне базы данных, до последней зарегистрированной записи называется активной частью журнала, или активным журналом. Этот раздел журнала необходим для выполнения полного восстановления базы данных. Ни одна часть активного журнала не может быть усечена. Регистрационный номер транзакции в журнале LSN этой первой записи журнала называется минимальным номером LSN восстановления (MinLSN).

Физическая архитектура журнала транзакций

Журнал транзакций в базе данных сопоставляет один или несколько физических файлов. По сути, файл журнала представляет собой строку записей журнала. Физически последовательность записей журнала эффективно хранится в наборе физических файлов, которые образуют журнал транзакций. Для каждой базы данных должен существовать хотя бы один файл журнала.

Компонент Компонент SQL Server Database Engine делит каждый физический файл журнала на несколько виртуальных файлов журнала. Виртуальные файлы журнала не имеют фиксированных размеров. Не существует также и определенного числа виртуальных файлов журнала, приходящихся на один физический файл журнала. Компонент Компонент Database Engine динамически определяет размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Компонент Database Engine стремится обслуживать небольшое число виртуальных файлов. После расширения файла журнала размер виртуальных файлов определяется как сумма размера существующего журнала и размера нового приращения файла. Администраторы не могут настраивать или устанавливать размеры и число виртуальных файлов журнала.

Виртуальные файлы журнала влияют на производительность системы лишь в том случае, если физические файлы журнала определяются малыми значениями size и growth_increment. Значение size является первоначальным размером для файла журнала, а значение growth_increment ― это объем пространства, добавляемого к файлу каждый раз, когда это требуется. Если файлы журнала в результате большого числа малых приращений будут разрастаться до крупных размеров, они будут иметь множество виртуальных файлов журнала. В итоге может увеличиться время запуска базы данных, а также снизиться скорость операций резервного копирования и восстановления. Рекомендуется выбирать для файлов журнала значение параметра size, близкое к окончательному требуемому размеру, а также задавать относительно большое значение growth_increment. Дополнительные сведения об этих параметрах см. в разделе Параметры инструкции ALTER DATABASE для файлов и файловых групп (Transact-SQL).

Журнал транзакций является оборачиваемым файлом. Рассмотрим пример. Пусть база данных имеет один физический файл журнала, разделенный на четыре виртуальных файла журнала. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых находятся перед минимальным регистрационным номером восстановления в журнале транзакций (MinLSN). MinLSN является в журнале транзакций регистрационным номером самой старой записи, которая необходима для успешного отката на уровне всей базы данных. Журнал транзакций рассматриваемой в данном примере базы данных будет выглядеть примерно так же, как на следующей иллюстрации.

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

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

• Если для данного журнала применена установка FILEGROWTH и на диске имеется свободное место, файл расширяется на величину, указанную в параметре growth_increment, и новые записи журнала добавляются к этому расширению. Дополнительные сведения о настройке FILEGROWTH см. в разделе Параметры инструкции ALTER DATABASE для файлов и файловых групп (Transact-SQL).

• Если параметр FILEGROWTH не применяется или диск, на котором размещается файл журнала, имеет меньше свободного места, чем это указано в growth_increment, формируется ошибка 9002.

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

Усечение журнала

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

На следующем рисунке показан журнал транзакций до усечения и после. На первом рисунке показан журнал транзакций, который никогда не усекался. В настоящий момент логический журнал состоит из четырех виртуальных файлов. Логический журнал начинается с первого файла виртуального журнала и заканчивается виртуальным файлом журнала 4. Запись MinLSN находится в виртуальном журнале 3. Виртуальные журналы 1 и 2 содержат только неактивные записи журнала. Эти записи можно усечь. Виртуальный журнал 5 пока не используется и не является частью текущего логического журнала.

На втором рисунке показан журнал после усечения. Виртуальные журналы 1 и 2 усечены и могут использоваться повторно. Логический журнал теперь начинается с виртуального журнала 3. Виртуальный журнал 5 пока не используется и не является частью текущего логического журнала.

За исключением тех случаев, когда усечение журнала по каким-то причинам задерживается, оно выполняется автоматически после наступления следующих событий.

• В простой модели восстановления — после достижения контрольной точки.

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

Усечение журнала может быть задержано из-за множества факторов. В случае большой задержки усечения журнала возможно заполнение журнала транзакций. Дополнительные сведения см. в разделах Факторы, которые могут вызвать задержку усечения журнала и Устранение неполадок при переполнении журнала транзакций (ошибка SLQ Server 9002).

Журнал транзакций с упреждающей записью

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

Для понимания принципов работы упреждающего ведения журнала важно знать, как измененные данные записываются на диск. SQL Server имеет кэш буфера, в который считываются страницы данных, когда требуется получить данные. Если какая-либо из страницы в буферном кэше изменилась, она не записывается сразу на диск, а помечается как грязная. До момента ее физической записи на диск к странице могла быть применена одна или несколько операций логической записи. При каждой логической операции записи в кэш журнала, который записывает изменения, добавляется запись журнала транзакций. Записи журнала должны быть перенесены на диск до того, как соответствующая «грязная» страница будет удалена из буферного кэша и записана на диск. Заключается в том, что процесс контрольных точек производит периодический просмотр буферного кэша на наличие буферов со страницами определенной базы данных и запись всех «грязных» страниц на диск. Контрольные точки экономят время во время последующего восстановления при помощи создания точки, в которой все «грязные» страницы гарантированно записываются на диск.

Запись измененной страницы данных из буферного кэша на диск называется сбросом страницы на диск. SQL Server имеет логику, которая предотвращает удаление «грязной» страницы до сохранения соответствующей записи журнала. Содержимое журнала запишется на диск после того, как будут зафиксированы транзакции.

Резервные копии журналов транзакций

Этот раздел содержит основные понятия о создании резервной копии и восстановлении журналов транзакций. В рамках модели полного восстановления или восстановления с неполным протоколированием для восстановления данных важно регулярно создавать резервные копии журнала транзакций (резервные копии журнала). Можно создать резервную копию журнала во время выполнения полного резервного копирования. Дополнительные сведения о моделях восстановления см. в разделе Резервное копирование и восстановление баз данных SQL Server.

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

Рекомендуется производить создание резервных копий журналов достаточно часто в соответствии с требованиями предприятия, а особенно со степенью толерантности к потерям данных, например из-за повреждения диска с журналами. Частота создания резервных копий журнала зависит от степени толерантности к возможности потери данных и от того, какое количество резервных копий журнала получится хранить и в потенциале восстанавливать, а также каким количеством управлять. Возможно, создания резервных копий журналов один раз в 15-30 минут может оказаться достаточно. Если предприятию необходимо минимизировать вероятность потери данных, следует увеличить частоту создания резервных копий журнала. Более частое создание резервных копий журнала предоставляет преимущество за счет более частого усечения журнала, результатом которого является меньший размер файлов журнала.

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

Цепочка журналов

Непрерывная последовательность резервных копий журнала называется цепочкой журналов. Цепочка журналов начинается с полной резервной копии базы данных. Обычно новая цепочка журналов начинается, только когда создается первая резервная копия базы данных или после переключения модели восстановления с простой на полную или на модель с неполным протоколированием. Существующая цепочка журналов остается без изменений, если не выбрана перезапись существующих наборов резервных копий при создании резервной копии базы данных целиком. Сохраняя неизменность цепочки журналов, базу данных можно восстановить из любой резервной копии полной базы данных в любом наборе носителей и из всех последующих резервных копий журналов до точки восстановления. Точка восстановления может быть концом последней резервной копии журналов или определенной точкой восстановления в любой из резервных копий журналов. Дополнительные сведения см. в разделе Резервные копии журналов транзакций (SQL Server).

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

Восстановление резервных копий журнала

Восстановление резервной копии журналов выполняет накат изменения, которые записаны в журнале транзакций, для воссоздания точного состояния базы данных на момент начала операции резервного копирования журнала. При восстановлении базы данных необходимо восстанавливать резервные копии журналов, которые были созданы после создания восстановленной полной резервной копии или с начала первой восстановленной резервной копии файлов. Обычно после восстановления последней резервной копии данных или разностной резервной копии необходимо произвести восстановление серии резервных копий журналов до точки восстановления. Затем производится восстановление базы данных. При этом откатываются все незавершенные на момент восстановления транзакции, и база данных переводится в режим «в сети». После восстановления базы данных нельзя более восстанавливать резервные копии. Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).

Дополнительные материалы

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

Основные сведения о ведении журнала и восстановлении из резервных копий в SQL Server. Автор: Пол Ренделл (Paul Randall)

Управление журналом транзакций SQL Server. Авторы: Тони Дэвис (Tony Davis) и Гейл Шоу (Gail Shaw)