Журнал транзакций

Область применения: SQL Server

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристики журнала транзакций SQL Server ядро СУБД:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

Значение столбца log_reuse_wait	Значение столбца log_reuse_wait_desc	Description
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	REPLICATION	Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям. (Только для модели полного восстановления) Дополнительные сведения о репликации транзакций см. в разделе SQL Server Replication.
7	DATABASE_SNAPSHOT_CREATION	Создается моментальный снимок базы данных (все модели восстановления). Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
8	LOG_SCAN	Выполняется сканирование журнала (все модели восстановления). Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций.
9	AVAILABILITY_REPLICA	Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей базе данных-получателю. (Только модель полного восстановления). Дополнительные сведения см. в разделе "Что такое группа доступности AlwaysOn?".
10	-	Только для внутреннего использования
11	-	Только для внутреннего использования
12	-	Только для внутреннего использования
13	OLDEST_PAGE	Если в базе данных настроено использование косвенных контрольных точек, самая старая страница в базе может быть старше регистрационного номера транзакции в журнале (LSN) для контрольной точки. В этом случае самая старая страница может отложить усечение журнала (все модели восстановления). Сведения о косвенных контрольных точках см. в разделе "Контрольные точки базы данных" (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). Дополнительные сведения о том, когда массовый импорт в таблицу минимально регистрируется, см. в разделе "Предварительные требования для минимального ведения журнала в массовом импорте".

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

• SELECT — операции предложения INTO.

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

• Частичные изменения типов данных с большими значениями с помощью предложения .WRITE инструкции UPDATE при вставке или добавлении новых данных. Минимальное ведение журнала не используется при обновлении существующих значений. Дополнительные сведения о типах данных больших значений см. в разделе "Типы данных".

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

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

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

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

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

  • ALTER INDEX REBUILD или DBCC DBREINDEX operation.

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

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

    Инструкция 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)
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)