Журнал транзакций (SQL Server)

Статья
10/01/2013

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

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

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

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

В этом разделе:

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

Преимущества Операции, поддерживаемые журналом транзакций

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

восстановление отдельных транзакций;
восстановление всех незавершенных транзакций при запуске SQL Server;
накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
поддержка репликации транзакций;
Поддержка решений высокого уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

Значок стрелки, используемый со ссылкой «В начало» [В начало]

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

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

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

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

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

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

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

Значок стрелки, используемый со ссылкой «В начало» [В начало]

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

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

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

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

NOTHING;

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

CHECKPOINT

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

Это широко распространенная причина задержки усечения журнала. Дополнительные сведения см. в разделе Контрольные точки базы данных (SQL Server).

LOG_BACKUP

Требуется выполнить резервное копирование журналов, поскольку лишь после этого журнал транзакций может быть усечен. (Только для моделей полного восстановления и моделей восстановления с неполным протоколированием)

После завершения создания следующей резервной копии журнала некоторое пространство журнала может освободиться для повторного использования.

ACTIVE_BACKUP_OR_RESTORE

Выполняется резервное копирование или восстановление данных (для всех моделей восстановления).

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

ACTIVE_TRANSACTION

Активна одна из транзакций (для всех моделей восстановления).

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

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

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

DATABASE_MIRRORING

Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной. (Только для модели полного восстановления)

Дополнительные сведения см. в разделе Зеркальное отображение базы данных (SQL Server).

REPLICATION

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

Дополнительные сведения о репликации транзакций см. в разделе Репликация SQL Server.

DATABASE_SNAPSHOT_CREATION

Создается моментальный снимок базы данных. (Все модели восстановления)

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

LOG_SCAN

Производится просмотр журнала. (Все модели восстановления)

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

AVAILABILITY_REPLICA

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

Дополнительные сведения см. в разделе Обзор групп доступности AlwaysOn (SQL Server).

—

Только для внутреннего использования

—

Только для внутреннего использования

—

Только для внутреннего использования

OLDEST_PAGE

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

Дополнительные сведения о косвенных контрольных точках см. в разделе Контрольные точки базы данных (SQL Server).

OTHER_TRANSIENT

Эта значение сейчас не используется.

Значок стрелки, используемый со ссылкой «В начало» [В начало]

Операции, для которых возможно минимальное протоколирование

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

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

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

Следующие операции, выполняемые с полным протоколированием в модели полного восстановления, осуществляются с минимальным протоколированием в простой модели восстановления и модели восстановления с неполным протоколированием:

Операции массового импорта (bcp, BULK INSERT и INSERT... SELECT). Дополнительные сведения о том, когда массовый импорт в таблицу подлежит минимальному протоколированию, см. в разделе Предварительные условия для минимального ведения журнала массового импорта данных.

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

Операции SELECT INTO.

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

Частичные обновления типов данных с большими значениями с помощью предложений .WRITE инструкции UPDATE при вставке или добавлении новых данных. Обратите внимание, что минимальное протоколирование не используется при обновлении существующих значений. Дополнительные сведения о больших типах-значениях см. в разделе Типы данных (Transact-SQL).

Инструкции WRITETEXT и UPDATETEXT при вставке или добавлении новых данных в столбцы с типом данных text, ntext и image. Обратите внимание, что минимальное протоколирование не используется при обновлении существующих значений.

Примечание
Инструкции WRITETEXT и UPDATETEXT являются устаревшими, поэтому следует избегать их использования в новых приложениях.

Если в базе данных используется простая модель восстановления или модель восстановления с неполным протоколированием, некоторые DDL-операции с индексом протоколируются в минимальном объеме при их выполнении как режиме «вне сети», так и в режиме «в сети». Минимально протоколируются следующие операции с индексами.

Операции CREATE INDEX (включая индексированные представления).

Операции ALTER INDEX REBUILD или DBCC DBREINDEX.

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

Перестроение новой кучи DROP INDEX (если применимо).

Примечание
Освобождение страниц индекса в ходе выполнения операции DROP INDEX всегда протоколируется полностью.