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

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

Эта документация перемещена в архив и не поддерживается.

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

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

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

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

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

Дополнительные сведения об усечении журнала см. в подразделе «Как работает усечение журнала» далее в разделе.

В модели полного восстановления или модели восстановления с неполным протоколированием неактивную часть журнала нельзя усечь, пока в резервную копию не попали все записи журнала. Это необходимо, чтобы обеспечить наличие цепочки журналов — набора записей журнала с неразрывной последовательностью регистрационных номеров транзакций в журнале (номера LSN). Журнал усекается при создании резервной копии журналов, если выполняются следующие условия.

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

  Дополнительные сведения см. в разделе Контрольные точки и активная часть журнала.

• Никакие другие факторы не препятствуют усечению журнала.

  Обычно при систематическом резервном копировании занимаемое журналом место регулярно освобождается для повторного использования. Однако усечению журнала могут временно помешать различные факторы (например длительная транзакция). Дополнительные сведения см. в разделе Факторы, могущие вызвать задержку усечения журнала.

• В инструкции BACKUP LOG не указан параметр WITH COPY_ONLY.

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

Журнал транзакций является оборачиваемым файлом. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Журнал транзакций в базе данных сопоставляет один или несколько физических файлов. Компонент SQL Server Database Engine делит каждый физический файл журнала на несколько виртуальных файлов журнала. Процесс усечения журнала освобождает пространство в логическом журнале путем удаления неактивных виртуальных файлов журналов из начала логического журнала. Подробные сведения об архитектуре журнала транзакций см. в разделах Логическая архитектура журнала транзакций и Физическая архитектура журнала транзакций.

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

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

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

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

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

Справочник

Основные понятия

technet.microsoft.com

Сжатие журнала транзакций

при котором его физический размер уменьшается за счет удаления одного или более неактивных виртуальных файлов журнала. Единицей измерения при уменьшении размера всегда является виртуальный файл журнала. Например, если имеется файл журнала размером 600 мегабайт (МБ), разделенный на шесть виртуальных журналов по 100 МБ, размер файла журнала может уменьшаться на число, кратное 100 МБ. Размер файла может быть уменьшен до размера 500 МБ или 400 МБ, но не может быть уменьшен до размера 433 МБ или 525 МБ. Виртуальный файл журнала, хранящий какие-либо активные записи журнала, т.е. активный виртуальный файл журнала является частью логического журнала, и его нельзя удалить. Дополнительные сведения см. в разделе Физическая архитектура журнала транзакций.

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

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

При сжатии любого файла пространство освобождается в конце файла. При сжатии файла журнала транзакций в конце файла журнала освобождается достаточное количество виртуальных файлов журнала. Это происходит, чтобы журнал уменьшился до размера, заданного пользователем. Аргумент target_size, заданный пользователем, округляется до следующей самой большой границы виртуального файла. Например, если для файла в 600 МБ, который содержит шесть виртуальных файлов журнала размером по 100 МБ, пользователь указывает аргумент target_size, равный 325 МБ, последние два виртуальных файла журнала удаляются, и новый размер файла становится равным 400 МБ.

Операция DBCC SHRINKDATABASE или DBCC SHRINKFILE немедленно делает попытку сжать физический файл журнала до требуемого размера:

• Если ни одна из частей логического журнала виртуальных файлов журнала не расширяет отметку target_size, виртуальные файлы журнала, находящиеся после отметки target_size, освобождаются, и инструкция DBCC успешно выполняется без сообщений.

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

Предположим, что имеется файл журнала размером 600 МБ, который содержит шесть виртуальных файлов журнала, имеет логический журнал, начинающийся в виртуальном журнале 3 и заканчивающийся в виртуальном журнале 4. Выполняется инструкция DBCC SHRINKFILE с аргументом target_size, равным 275 МБ (т. е. три четверти виртуального журнала 3).

Виртуальные журналы 5 и 6 освобождаются немедленно, так как они не содержат части логического журнала. Однако для достижения указанного значения аргумента target_size виртуальный файл журнала 4 также должен быть освобожден, но это невозможно, так как он содержит конечную часть логического журнала. После освобождения виртуальных файлов журнала 5 и 6 компонент Database Engine заполняет оставшуюся часть виртуального файла журнала 4 фиктивными записями. Это приводит к смещению конца файла журнала в конец виртуального файла журнала 1. В большинстве систем все транзакции, начинающиеся в виртуальном файле журнала 4, будут зафиксированы за несколько секунд. Это значит, что вся активная часть журнала перемещается в виртуальный файл журнала 1. Теперь файл журнала выглядит примерно так:

Инструкция DBCC SHRINKFILE также выдает информационное сообщение, в котором говорится, что она не может освободить все необходимое пространство и для освобождения оставшегося пространства может быть выполнена инструкция BACKUP LOG. После перемещения активной части виртуального файла журнала 1 инструкция BACKUP LOG произведет усечение всего логического журнала, находящегося в виртуальном файле журнала 4:

Так как виртуальный файл журнала 4 больше не содержит части логического журнала, можно выполнить ту же инструкцию DBCC SHRINKFILE с аргументом target_size, равным 275 МБ. Виртуальный файл журнала 4 после этого освобождается, и размер физического файла журнала уменьшится до необходимого размера.

technet.microsoft.com

Факторы, могущие вызвать задержку усечения журнала

Эта документация перемещена в архив и не поддерживается.

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

Записи журнала могут оставаться активными по множеству причин, которые описываются в этом разделе. Чтобы определить, что препятствует усечению журнала транзакций в конкретном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.

В следующей таблице кратко описываются значения столбцов log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.

Значение столбца log_reuse_wait

Значение столбца log_reuse_wait_desc

Описание

0	NOTHING;	В данный момент существует один или более виртуальных файлов журнала, доступных для повторного использования.
1	CHECKPOINT	С момента последнего усечения журнала не было новых контрольных точек, либо заголовок журнала не перемещался за пределы виртуального файла журнала (для всех моделей восстановления). Это широко распространенная причина задержки усечения журнала. Дополнительные сведения см. в разделе Контрольные точки и активная часть журнала.
2	LOG_BACKUP.	Чтобы переместить заголовок журнала вперед, необходимо выполнить резервное копирование журнала (только для полной модели восстановления и модели восстановления с неполным протоколированием). Примечание Резервные копии журналов не препятствуют усечению. После завершения создания резервной копии журнала заголовок журнала перемещается вперед и некоторое пространство журнала может освободиться для повторного использования.
3	ACTIVE_BACKUP_OR_RESTORE	Выполняется резервное копирование или восстановление данных (для всех моделей восстановления). Резервное копирование данных работает аналогично активной транзакции, поэтому его выполнение предотвращает усечение. Дополнительные сведения см. ниже в подразделе «Операции резервного копирования и восстановления данных».
4	ACTIVE_TRANSACTION	Активна одна из транзакций (для всех моделей восстановления). Во время начала создания резервной копии журнала может существовать длительная транзакция. В этом случае, чтобы освободить пространство, может потребоваться создание другой резервной копии журнала. Дополнительные сведения см. ниже в разделе «Длительные активные транзакции». Транзакция отложена (только в SQL Server 2005 Enterprise Edition и более поздних версиях). Отложенная транзакция — это активная транзакция, откат которой был заблокирован по причине недоступности какого-либо ресурса. Дополнительные сведения о причинах, вызывающих появление отложенных транзакций, и о том, как их можно вывести из такого состояния, см. в разделе Отложенные транзакции.
5	DATABASE_MIRRORING	Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной (только для модели полного восстановления). Дополнительные сведения см. далее в разделе «Зеркальное отображение базы данных и журнал транзакций».
6	REPLICATION	Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям (только для модели полного восстановления). Дополнительные сведения см. далее в разделе «Репликации транзакций и журнал транзакций».
7	DATABASE_SNAPSHOT_CREATION	Создается моментальный снимок базы данных (для всех моделей восстановления). Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
8	LOG_SCAN	Производится просмотр журнала (для всех моделей восстановления). Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
9	OTHER_TRANSIENT	Эта значение сейчас не используется.

Усечение журнала во время операций резервного копирования или восстановления невозможно. В SQL Server 2005 и более поздних версиях резервное копирование журнала может выполняться во время резервного копирования данных. Однако усечение журнала во время такого резервного копирования журнала невозможно, поскольку журнал транзакций должен быть доступен для операции резервного копирования данных. Если усечению журнала препятствует резервное копирование данных, то проблему может решить отмена резервного копирования.

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

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

Для зеркального отображения базы необходимо, чтобы каждая запись журнала оставалась активной, пока экземпляр основного сервера получает уведомления от экземпляра зеркального сервера о записи на диск. Если экземпляр зеркального сервера начинает отставать от экземпляра основного сервера, то соответствующим образом увеличивается место на диске, занимаемое активным журналом. В этом случае может потребоваться остановка зеркального отображения базы данных, применение к зеркальной базе данных резервной копии журнала, усекающей журнал (с использованием параметра WITH NORECOVERY) и повторный запуск зеркального отображения.

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

Репликация слиянием и репликация моментальных снимков не влияют на размер журнала, в отличие от репликации транзакций. Если база данных содержит одну или несколько публикаций транзакций, журнал не может быть усечен, пока все транзакции, связанные с публикациями, не будут доставлены в базу данных распространителя. Если журнал транзакций становится слишком большим, а агент чтения журнала запускается по расписанию, необходимо рассмотреть возможность сокращения интервала между его запусками или возможность его установки в режим непрерывной работы. Если он установлен в режим непрерывной работы (по умолчанию), необходимо убедиться в том, что он запущен. Дополнительные сведения о проверке состояния агента чтения журнала см. в разделе Как просмотреть сведения и выполнить задачи для агентов, связанных с публикацией (монитор репликации).

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

Управление репликацией

Отслеживание репликации

Основные понятия

Другие ресурсы

technet.microsoft.com

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

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

Компонент Компонент 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).

technet.microsoft.com

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

Опубликовано: Ноябрь 2016

THIS TOPIC APPLIES TO:SQL Server (starting with 2008)Azure SQL DatabaseAzure SQL Data Warehouse Parallel Data Warehouse

Каждая база данных 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 пока не используется и не является частью текущего логического журнала.

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

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

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

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

В этом разделе описана роль, которую журнал транзакций с упреждающей записью играет в записи изменений данных на диск. SQL Server Использует журнал с упреждающей записью (WAL), который гарантирует, что до занесения на диск связанной с изменением записи журнала никакие изменения в данных записаны не будут. Таким образом обеспечиваются свойства 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)

technet.microsoft.com

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

Эта документация перемещена в архив и не поддерживается.

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

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

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

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

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

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

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

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

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

Важно регулярно создавать резервные копии журналов транзакций. Помимо возможности восстановления резервных копий транзакций, при этом производится усечение журнала: из него удаляются записи, помещенные в резервную копию. Если резервное копирование журнала производится недостаточно часто, файлы журнала могут заполниться. Сведения об обработке полного журнала транзакций см. в разделе Устранение неполадок при переполнении журнала транзакций (ошибка 9002).

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

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

Применение резервных копий журнала транзакций.

Основные понятия

Другие ресурсы

technet.microsoft.com

Смотрите также

• 
  Названия банковских журналов
• 
  Леди босс журнал
• 
  Конкурент журнала плейбой
• 
  Живой журнал гришковец
• 
  Журнал счастливая семья
• 
  Журнал сибирский уголь
• 
  Журнал про птиц
• 
  Журнал леди босс
• 
  Журнал добрые люди
• 
  Журнал бизнес логистика
• 
  Гришковец живой журнал