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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристики журнала транзакций компонента Database Engine SQL Server:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• операции SELECT - INTO.

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

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

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

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

  Операторы WRITETEXT и UPDATETEXT являются устаревшими. Избегайте их использования в новых приложениях.

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

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

  • ALTER INDEX ПЕРЕСТРОИТЬ или DBCC DBREINDEX выполнить операцию.

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

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

    Инструкция DBCC DBREINDEX устарела. Избегайте его использования в новых приложениях.

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

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

Связанный контент

• Руководство по архитектуре журнала транзакций 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)