• Статья
  • Чтение занимает 11 мин

Применимо к: даSQL Server (все поддерживаемые версии)

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

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

Сведения об архитектуре и внутренних компонентах журнала транзакций см. в разделе Руководство по архитектуре журнала транзакций SQL Server и управлению им.

Предупреждение

Удаляя или перемещая этот журнал, вы должны понимать все последствия этого действия.

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка решений высокого уровня доступности и аварийного восстановления

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

В сценарии «Группы доступности AlwaysOn» каждое изменение в базе данных (первичной реплике) немедленно воспроизводится в ее полных автономных копиях (вторичных репликах). Первичная реплика немедленно отсылает каждую запись журнала во вторичные реплики, которые применяют входящие записи к базам данных групп доступности, производя непрерывный накат. Дополнительные сведения см. в разделе Экземпляры отказоустойчивого кластера AlwaysOn.

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

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

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

Ниже приведены характеристики журнала транзакций Компонент SQL Server Database Engine.

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

  • Формат записей журнала и страниц не обязан следовать формату страниц данных.

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

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

Сведения об архитектуре и внутренних компонентах журнала транзакций см. в разделе Руководство по архитектуре журнала транзакций SQL Server и управлению им.

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 РЕПЛИКАЦИЯ Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям. (Только для модели полного восстановления)

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

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

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

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

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

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

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

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

Сведения о косвенных контрольных точках см. в статье Database Checkpoints (SQL Server).

14 OTHER_TRANSIENT Эта значение сейчас не используется.
16 XTP_CHECKPOINT Необходимо реализовать контрольную точку выполняющейся в памяти OLTP. Для таблиц, оптимизированных для памяти, автоматическая контрольная точка используется, когда размер файла журнала транзакций превышает 1,5 ГБ с момента последней контрольной точки (включая таблицы на основе дисков и оптимизированные для памяти).
Дополнительные сведения см. в разделе Работа контрольной точки для оптимизированных для памяти таблиц и [Процесс ведения журналов и создания контрольных точек для оптимизированных для памяти таблиц] (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

Операции, допускающие минимальное протоколирование

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

Примечание

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

Примечание

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

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

  • Операции массового импорта (bcp, BULK INSERT и INSERT… SELECT). Дополнительные сведения о том, когда массовый импорт в таблицу подлежит минимальному протоколированию, см. в разделе Prerequisites for Minimal Logging in Bulk Import.

Если включена репликация транзакций, операции 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всегда протоколируется полностью.

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

  • Управление размером файла журнала транзакций

  • Устранение неполадок при переполнении журнала транзакций (ошибка SQL Server 9002)

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

  • Создание резервной копии журнала транзакций (SQL Server)

  • Создание резервной копии журнала транзакций при повреждении базы данных (SQL Server)

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

  • Восстановление резервной копии журнала транзакций (SQL Server)

См. также раздел

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