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

Применимо к: SQL Server Azure SQL DatabaseУправляемый экземпляр SQL AzureAzure Synapse AnalyticsAnalytics Platform System (PDW)

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

Логическая архитектура журнала транзакций

Логически журнал транзакций SQL Server работает так, как если бы он являлся последовательностью записей в журнале. Каждая запись журнала идентифицируется по номеру последовательности журнала (LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи. Записи журнала сохраняются в серийной последовательности по мере их создания, таким образом если LSN2 больше, чем LSN1, то изменение, описанное записью журнала, на которую ссылается LSN2, произошло после изменения, описанного записью журнала LSN1. Каждая запись журнала содержит идентификатор транзакции, к которой она относится. Все записи журнала, связанные с определенной транзакцией, с помощью обратных указателей связаны в цепочку, которая предназначена для ускорения отката транзакции.

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

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

  • Зарегистрирована логическая операция.

    • Для наката логической операции выполняется снова.
    • Для отката логической операции выполняется обратная логическая операция.
  • Зарегистрированы исходный и результирующий образы записи.

    • Для наката операции применяется образ после.
    • Для отката операции применяется образ до.

В журнал транзакций записываются различные типы операций, например:

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

  • любые изменения данных (вставка, обновление или удаление), включая изменения в любой таблице (в том числе и в системных таблицах), производимые системными хранимыми процедурами или инструкциями языка DDL;

  • любое выделение и освобождение страниц и экстентов;

  • создание и удаление таблиц и индексов.

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

Раздел файла журнала из первой записи, который должен присутствовать для успешного отката всей базы данных к последней зарегистрированной записи называется активной частью журнала, активным журналом или заключительным фрагментом журнала. Этот раздел журнала необходим для полного восстановления базы данных. Ни одна часть активного журнала не может быть усечена. Номер последовательности журнала (LSN) этой первой записи журнала называется минимальным номером LSN восстановления (MinLSN). Дополнительные сведения об операциях, поддерживаемых журналом транзакций, см. в разделе Журнал транзакций (SQL Server).

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

Физическая архитектура журнала транзакций

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

Виртуальные файлы журнала (VLF)

Ядро СУБД SQL Server делит каждый физический файл журнала на несколько виртуальных файлов журналов (VLF). Файлы виртуальных журналов не имеют фиксированного размера и не имеют фиксированного количества виртуальных файлов журнала для физического файла журнала. Ядро СУБД динамически выбирает размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Database Engine пытается сохранить несколько виртуальных файлов. После расширения файла журнала размер виртуальных файлов определяется как сумма размера существующего журнала и размера нового приращения файла. Размер или количество виртуальных файлов журнала не могут быть настроены или заданы администраторами.

Для создания виртуального файла журнала (VLF) используется следующий метод.

  • В SQL Server 2014 (12.x) и более поздних версиях, если следующий рост меньше 1/8 текущего физического размера журнала, создайте 1 VLF, который охватывает размер увеличения.
  • Если следующее увеличение превышает 1/8 текущего размера журнала, используйте метод до 2014 года:
    • Если размер не превышает 64 МБ, создайте 4 VLF, которые охватывают размер увеличения (например, для увеличения 1 МБ создайте 4 VVL размером 256 КБ).
      • В Azure SQL Database и начиная с SQL Server 2022 (16.x) (все выпуски) это немного отличается. Если рост меньше или равен 64 МБ, компонент Компонент Database Engine создает только 1 виртуальный файл для покрытия размера увеличения.
    • Если рост составляет от 64 МБ до 1 ГБ, создайте 8 VVL, которые охватывают размер увеличения (например, для увеличения 512 МБ создайте 8 VVL размером 64 МБ).
    • Если увеличение превышает 1 ГБ, создайте 16 VVL, которые охватывают размер увеличения, например для увеличения 8 ГБ создайте 16 VVL размером 512 МБ).

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

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

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

  • Значение размера , заданное аргументом SIZE , ALTER DATABASE является начальным размером файла журнала.
  • Значение growth_increment (также известное как значение автоувеличений), которое задается аргументом FILEGROWTHALTER DATABASE, — это объем пространства, добавляемого в файл каждый раз, когда требуется новое пространство.

Дополнительные сведения о FILEGROWTH аргументах ALTER DATABASEи SIZE см. в разделе Параметры файла и файловой группы ALTER DATABASE (Transact-SQL).

Совет

Чтобы определить оптимальное распределение VLF для текущего размера журнала транзакций всех баз данных в данном экземпляре и требуемые приращения для достижения требуемого размера, см. этот сценарий Fixing-VLFs на GitHub.

Что происходит, если у вас слишком много VLF?

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

  • Восстановление одной или нескольких баз данных занимает очень много времени во время запуска SQL Server.
  • Восстановление базы данных занимает очень много времени.
  • Попытки подключения базы данных занимают очень много времени.
  • При попытке настроить зеркальное отображение базы данных отображаются сообщения об ошибках 1413, 1443 и 1479, указывающие на истечение времени ожидания.
  • При попытке восстановления базы данных возникают ошибки, связанные с памятью, например 701.

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

2022-05-08 14:42:38.65 spid22s Starting up database 'lot_of_vlfs'.
2022-05-08 14:46:04.76 spid22s Analysis of database 'lot_of_vlfs' (16) is 0% complete (approximately 0 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

Кроме того, SQL Server может регистрировать ошибку 9017 при восстановлении базы данных с большим количеством VLF:

Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

Дополнительные сведения см. в разделе MSSQLSERVER_9017.

Исправление баз данных с большим количеством VLF

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

  1. Сожмите файлы журнала транзакций вручную.

  2. Выравывайте файлы до требуемого размера вручную за один шаг с помощью следующего скрипта T-SQL:

    ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

    Примечание

    Этот шаг также возможен в SQL Server Management Studio, используя страницу свойств базы данных.

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

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

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

Циклическая природа журнала транзакций

Журнал транзакций является оборачиваемым файлом. Рассмотрим пример. Пусть база данных имеет один физический файл журнала, разделенный на четыре виртуальных файла журнала. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых находятся перед минимальным регистрационным номером восстановления в журнале транзакций (MinLSN). MinLSN — это регистрационный номер транзакции самой старой записи в журнале, которая необходима для успешного отката на уровне всей базы данных. Журнал транзакций рассматриваемой в данном примере базы данных будет выглядеть примерно так же, как на следующей иллюстрации.

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

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

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

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

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

Важно!

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

Усечение журнала

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

На следующем рисунке показан журнал транзакций до усечения и после. На первом рисунке показан журнал транзакций, который никогда не усекался. В настоящий момент логический журнал состоит из четырех виртуальных файлов. Логический журнал начинается с первого файла виртуального журнала и заканчивается виртуальным файлом журнала 4. Запись MinLSN находится в виртуальном журнале 3. Виртуальные журналы 1 и 2 содержат только неактивные записи журнала. Эти записи можно усечь. Виртуальный журнал 5 по-прежнему не используется и не является частью текущего логического журнала.

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

На втором рисунке показан журнал после усечения. Виртуальные журналы 1 и 2 усечены и могут использоваться повторно. Логический журнал теперь начинается с виртуального журнала 3. Виртуальный журнал 5 по-прежнему не используется и не является частью текущего логического журнала.

Иллюстрация, показывающая, как журнал транзакций отображается после его усечения.

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

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

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

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

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

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

Запись измененной страницы данных из буферного кэша на диск называется сбросом страницы на диск. SQL Server Имеет логику, которая предотвращает запись на диск "грязной" страницы до записи на него связанной записи журнала. Содержимое журнала записывается на диск при сбросе буферов журнала. Это происходит при фиксации транзакции или заполнении буферов журнала.

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

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

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

Важно!

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

Частота создания резервных копий журнала зависит от степени толерантности к возможности потери данных и от того, какое количество резервных копий журнала получится хранить и в потенциале восстанавливать, а также каким количеством управлять. При реализации стратегии восстановления подумайте о требуемом целевом времени восстановления (RTO) и целевой точке восстановления (RPO) и, в частности, о частоте резервного копирования журналов. Возможно, создания резервных копий журналов один раз в 15-30 минут может оказаться достаточно. Если предприятию необходимо минимизировать вероятность потери данных, следует увеличить частоту создания резервных копий журнала. Более частое создание резервных копий журнала предоставляет преимущество за счет более частого усечения журнала, результатом которого является меньший размер файлов журнала.

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

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

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

Цепочка журналов

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

Чтобы восстановить базу данных на момент точки сбоя, нужна неповрежденная цепочка журналов. Непрерывная последовательность резервных копий журналов должна следовать до точки сбоя. Где должна начинаться эта последовательность журналов, зависит от типа восстанавливаемых резервных копий данных: базы данных, частичной или файловой копии. В случае резервной копии базы данных или частичной резервной копии последовательность резервных копий журнала должна начинаться от конца резервной копии базы данных или частичной резервной копии. В наборе резервных копий файлов последовательность резервных копий журналов должна следовать от начала полного набора резервных копий файлов. Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).

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

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

Контрольные точки и активная часть журнала

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

  • Накат записанных в журнал изменений, не записанных на диск до остановки системы.
  • Выполняется откат всех изменений, связанных с неполными транзакциями, например транзакций, для которых нет записей журнала COMMIT или ROLLBACK.

Операция контрольной точки

Контрольная точка выполняет в базе данных следующее.

  • Записывает в файл журнала запись, отмечающую начало контрольной точки.

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

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

    • номера LSN начала контрольной точки;
    • номера LSN начала старейшей активной транзакции;
    • Номер LSN начала самой старой транзакции репликации, которая еще не была доставлена в базу данных распространителя.

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

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

  • Записывает все измененные страницы журналов и данных на диск.

  • Записывает в файл журнала запись, отмечающую конец контрольной точки.

  • Записывает в страницу загрузки базы данных номер LSN начала соответствующей цепи.

Действия, вызывающие контрольную точку

Контрольные точки срабатывают в следующих ситуациях.

  • При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
  • При выполнении в базе данных операции с минимальной регистрацией, например при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
  • При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
  • При остановке экземпляра SQL Server инструкцией SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка для каждой базы данных на экземпляре SQL Server.
  • Экземпляр SQL Server периодически создает для каждой базы данных автоматические контрольные точки с целью сократить время восстановления базы данных.
  • При создании резервной копии базы данных.
  • При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.

Автоматические контрольные точки

Ядро СУБД SQL Server создает автоматические контрольные точки. Интервал между автоматическими контрольными точками определяется на основе использованного места в журнале и времени, прошедшего с момента создания последней контрольной точки. Интервал времени между автоматическими контрольными точками колеблется в широких пределах и может быть довольно длительным, если база данных изменяется редко. При крупномасштабных изменениях данных частота автоматических контрольных точек может быть гораздо выше.

Используйте параметр конфигурации сервера recovery interval , чтобы вычислить интервал между автоматическими контрольными точками для всех баз данных на экземпляре сервера. Значение этого параметра определяет максимальное время, отводимое ядру СУБД на восстановление базы данных при перезапуске системы. Ядро СУБД оценивает число записей журнала, которые оно может обработать за время recovery interval в ходе операции восстановления.

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

  • Если применяется полная модель восстановления или модель восстановления с неполным протоколированием, то автоматическая контрольная точка создается каждый раз, когда число записей в журнале достигает значения, определенного ядром СУБД в качестве предельного количества записей, которое оно может обработать за время, заданное параметром recovery interval.

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

    • журнал заполняется на 70 процентов;
    • число записей в журнале достигает значения, определенного ядром СУБД в качестве количества записей, которое оно может обработать за время, заданное параметром recovery interval.

Информацию о настройке интервала восстановления см. в статье Настройка параметра конфигурации сервера recovery interval.

Совет

Параметр -k расширенной настройки SQL Server позволяет администратору базы данных регулировать поведение ввода-вывода контрольных точек на основе пропускной способности подсистемы ввода-вывода для некоторых типов контрольных точек. Параметр -k настройки применяется к автоматическим контрольным точкам и любым другим некоротким контрольным точкам.

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

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

Активный журнал

Часть файла журнала, начинающаяся с номера MinLSN и заканчивающаяся последней зафиксированной записью, называется активной частью журнала или "активным журналом". Этот раздел журнала необходим для выполнения полного восстановления базы данных. Ни одна часть активного журнала не может быть усечена. Все записи журнала до номера MinLSN должны быть удалены из частей журнала.

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

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

Последней записью в журнале транзакций является запись с номером LSN, равным 148. На момент обработки записанной контрольной точки с номером LSN 147 транзакция 1 уже зафиксирована и единственной активной транзакцией является транзакция 2. В результате первая запись журнала, созданная для транзакции 2, становится старейшей записью активной транзакции на момент последней контрольной точки. Таким образом, номером MinLSN становится номер LSN, равный 142 и соответствующий записи начала транзакции 2.

Продолжительные транзакции

Активный журнал должен включать в себя все элементы всех незафиксированных транзакций. Приложение, которое запускает транзакцию и не фиксирует ее или не выполняет откат, не позволяет компоненту Компонент Database Engine перейти к MinLSN. Это может привести к проблемам двух типов.

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

Начиная с SQL Server 2019 (15.x) и в База данных SQL Azure, восстановления длительных транзакций и описанных выше проблем можно избежать с помощью ускоренного восстановления базы данных.

Транзакции репликации

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

Дальнейшие действия

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