Поделиться через

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

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

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

Замечание

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

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

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

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

  • Восстановление отдельных транзакций.

  • Восстановление всех неполных транзакций при запуске SQL Server.

  • накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;

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

  • Поддержка решений высокого уровня доступности и аварийного восстановления: группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

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

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

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

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

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

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

Замечание

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

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

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

Это важно

Сведения о том, как реагировать на полный журнал транзакций, см. в разделе "Устранение неполадок с полным журналом транзакций" (ошибка SQL Server 9002).

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

Значение столбца log_reuse_wait Значение столбца log_reuse_wait_desc Описание
0 НИЧТО В настоящее время существует один или несколько повторно используемых виртуальных файлов журналов.
1 Контрольный пункт С момента последней усечения журнала контрольная точка не произошла, или голова журнала еще не перемещена за пределы виртуального файла журнала. (Все модели восстановления)

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

После завершения создания следующей резервной копии журнала некоторое пространство журнала может освободиться для повторного использования.
3 АКТИВНОЕ СОЗДАНИЕ РЕЗЕРВНОЙ КОПИИ ИЛИ ВОССТАНОВЛЕНИЕ Выполняется резервное копирование данных или восстановление (все модели восстановления).

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

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

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

Длительные транзакции также могут заполнить журнал транзакций tempdb. Tempdb используется неявно транзакциями пользователей для внутренних объектов, таких как рабочие таблицы для сортировки, рабочих файлов для хэширования, рабочих таблиц курсоров и управления версиями строк. Даже если транзакция пользователя включает только данные чтения (запросы SELECT), внутренние объекты могут быть созданы и использованы при транзакциях пользователей. Затем можно заполнить журнал транзакций tempdb.
5 ЗЕРКАЛИРОВАНИЕ БАЗЫ ДАННЫХ Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной. (Только для модели полного восстановления)

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

Дополнительные сведения о репликации транзакций см. в разделе SQL Server Replication.
7 СОЗДАНИЕ СНИМКОВ БАЗЫ ДАННЫХ Создается моментальный снимок базы данных. (Все модели восстановления)

Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
8 ЛОГ_СКАН Выполняется проверка журнала. (Все модели восстановления)

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

Дополнительные сведения см. в разделе "Общие сведения о группах доступности AlwaysOn" (SQL Server).
10 - Только для внутреннего использования
11 - Только для внутреннего использования
12 - Только для внутреннего использования
13 (тринадцать) СТАРЕЙШАЯ_СТРАНИЦА Если база данных настроена для использования косвенных контрольных точек, старейшая страница базы данных может быть старше LSN контрольной точки. В этом случае самая старая страница может задержать усечение журнала. (Все модели восстановления)

Сведения о косвенных контрольных точках см. в разделе "Контрольные точки базы данных" (SQL Server).
14 ДРУГОЕ_ПРОХОДЯЩЕЕ Это значение в настоящее время не используется.
16 XTP_CHECKPOINT Если база данных имеет файловую группу, оптимизированную для работы в памяти, журнал транзакций может не быть усечён до тех пор, пока не будет запущена автоматическая контрольная точка In-Memory OLTP (что происходит при каждых 512 МБ роста журнала).

Примечание: Чтобы усечь журнал транзакций до размера, меньшего чем 512 МБ, выполните команду "Checkpoint" вручную для рассматриваемой базы данных.

Операции, которые могут быть зарегистрированы с минимальной записью

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

Замечание

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

Замечание

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

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

  • Операции массового импорта (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 new heap rebuild (если применимо).

      Замечание

      Размещение сделки на странице индекса во время операции DROP INDEX всегда полностью регистрируется.

Связанные задачи

Managing the transaction log

Резервное копирование журнала транзакций (модель полного восстановления)

Восстановление журнала транзакций (модель полного восстановления)

См. также

Управление устойчивостью транзакций
Предварительные требования для минимального протоколирования при пакетном импорте
Резервное копирование и восстановление баз данных SQL Server
Контрольные точки базы данных (SQL Server)
Просмотр или изменение свойств базы данных
Модели восстановления (SQL Server)

  • Last updated on