Для чего используется журнал транзакций базы данных
Журнал транзакций
Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций.
Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД.
А это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддерживается в виде журнала изменений базы данных, чаще всего называемого журналом транзакций.
Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общими принципами восстановления являются следующие:
— результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;
— результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.
Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.
Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:
— индивидуальный откат транзакции. Этот откат должен быть применен в следующих случаях:
— стандартной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK;
— аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения;
— принудительный откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций. В подобном случае для выхода из тупика данная транзакция может быть выбрана в качестве «жертвы» и принудительно прекращено ее выполнение ядром СУБД.
— восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть в следующих случаях:
— при аварийном выключении электрического питания;
— при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т. д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти;
— восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.
Для восстановления согласованного состояния базы данных при индивидуальном откате тран-закции нужно устранить последствия операторов модификации базы данных, которые выполня-лись в этой транзакции. Для восстановления непротиворечивого состояния БД при мягком сбое необходимо восстановить содержимое БД по содержимому журналов транзакций, хранящихся на дисках. Для восстановления согласованного состояния БД при жестком сбое надо восстановить содержимое БД по архивным копиям и журналам транзакций, которые хранятся на неповреж-денных внешних носителях.
Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.
Возможны два основных варианта ведения журнальной информации. В первом варианте для каждой транзакции поддерживается отдельный локальный журнал изменений базы данных этой транзакцией. Такие журналы называются локальными журналами. Они используются для индивидуальных откатов транзакций и могут поддерживаться в оперативной (правильнее сказать, в виртуальной) памяти. Кроме того, поддерживается общий журнал изменений базы данных, используемый для восстановления состояния базы данных после мягких и жестких сбоев.
Этот подход позволяет быстро выполнять индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще используется второй вариант – поддержание только общего журнала изменений базы данных, который используется и при выполнении индивидуальных откатов. Далее мы рассматриваем именно этот вариант.
Общая структура журнала условно может быть представлена в виде некоторого последовательного файла, в котором фиксируется каждое изменение БД, которое происходит в ходе выполнения транзакции. Все транзакции имеют свои внутренние номера, поэтому в едином журнале транзакций фиксируются все изменения, проводимые всеми транзакциями.
Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет. Кроме того, для каждой транзакции в журнале фиксируется команда начала и завершения транзакции (рис. 6.7).
Рис. 6.7. Журнал транзакций
Для большей надежности журнал транзакций часто дублируется системными средствами коммерческих СУБД, именно поэтому объем внешней памяти во много раз превышает реальный объем данных, которые хранятся в хранилище.
Имеются два альтернативных варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями.
Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:
1. Когда транзакция Т1 начинается, в протокол заносится запись
4. После того как транзакция фиксирована, записи протокола, относящиеся к Т1, используются для внесения соответствующих изменений в БД.
6. Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.
При откате транзакции выполняется системная процедура UNOOO, которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.
Для восстановления при сбое используется следующий механизм:
1. Если транзакция содержит команду начала транзакции, но не содержит команды фиксации с подтверждением ее выполнения, то выполняется последовательность действий как при откате транзакции, то есть восстанавливаются старые значения.
2. Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.
Однако следует отметить, что проблемы восстановления выглядят гораздо сложнее приведенных ранее алгоритмов, с учетом того, что изменения как в журнал, так и в БД заносятся не сразу, а буферируются. Этому посвящен следующий раздел.
Журнал транзакций
Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций.
Однако назначение журнала транзакций гораздо шире. Он предназначен для обеспечения надежного хранения данных в БД.
А это требование предполагает, в частности, возможность восстановления согласованного состояния базы данных после любого рода аппаратных и программных сбоев. Очевидно, что для выполнения, восстановлений необходима некоторая дополнительная информация. В подавляющем большинстве современных реляционных СУБД такая избыточная дополнительная информация поддержи вается в виде журнала изменений базы данных, чаще всего называемого Журналом транзакций.
Итак, общей целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общими принципами восстановления являются следующие:
Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.
Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных.
Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции. Для восстановления непротиворечивого состояния БД при мягком сбое необходимо восстановить содержимое БД по содержимому журналов транзакций, хранящихся на дисках. Для восстановления согласованного состояния БД при жестком сбое надо восстановить содержимое БД по архивным копиям и журналам транзакций, которые хранятся на неповрежденных внешних носителях.
Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.
Возможны два основных варианта ведения журнальной информации. В первом варианте для каждой транзакции поддерживается отдельный локальный журнал изменений базы данных этой транзакцией. Такие журналы называются локальными журналами. Они используются для индивидуальных откатов транзакций и могут поддерживаться в оперативной (правильнее сказать, в виртуальной) памяти. Кроме того, поддерживается общий журнал изменений базы данных, используемый для восстановления состояния базы данных после мягких и жестких сбоев.
Этот подход позволяет быстро выполнять индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще используется второй вариант — поддержание только общего журнала изменений базы данных, который используется и при выполнении индивидуальных откатов. Далее мы рассматриваем именно этот вариант.
Общая структура журнала условно может быть представлена в виде некоторого последовательного файла, в котором фиксируется каждое изменение БД, которое происходит в ходе выполнения транзакции. Все транзакции имеют свои внутренние номера, поэтому в едином журнале транзакций фиксируются все изменения, проводимые всеми транзакциями.
Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет. Кроме того, для каждой транзакции в журнале фиксируется команда начала и завершения транзакции (см. рис. 11.3).
Для большей надежности журнал транзакций часто дублируется системными средствами коммерческих СУБД, именно поэтому объем внешней памяти во много раз превышает реальный объем данных, которые хранятся в хранилище.
Имеются два альтернативных варианта ведения журнала транзакций: протокол с отложенными обновлениями и протокол с немедленными обновлениями.
Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:
Рис. 11.3. Журнал транзакций
При откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции, последовательно проходя по протоколу начиная с команды BEGIN TRANSACTION.
Для восстановления при сбое используется следующий механизм:
Резервное копирование Microsoft SQL Server
Отказы системы
Некоторые из отказов могут носить умеренный характер; некоторые могут оказаться разрушительными. Чтобы понять важность резервного копирования, вы должны знать о трех основных категориях отказов: отказы оборудования, отказы программного обеспечения и человеческие ошибки.
Отказы оборудования
Отказы оборудования – это, видимо, наиболее распространенный тип отказов, с которыми вы будете сталкиваться. Хотя эти отказы возникают менее часто по мере роста надежности компьютерного оборудования, но компоненты компьютеров все равно со временем становятся подвержены износу. Вот следующие типичные отказы оборудования.
Отказы программного обеспечения
Человеческие ошибки
Третьей основной категорией отказа является человеческая ошибка. Человеческие ошибки могут возникать в любой момент и без предупреждения. Они могут быть умеренными и серьезными. К сожалению ошибки этого типа могут оставаться незамеченными в течение дней или даже недель, что затрудняет процесс восстановления. Поддерживая хорошие взаимоотношения с вашими пользователями (включая средства связи), вы можете быстрее и проще выполнять восстановление после ошибок пользователей. Пользователи не должны опасаться вашей реакции и сразу сообщать вам об ошибке. Чем раньше вы узнаете об ошибке, тем лучше. Следующие отказы могут быть вызваны человеческой ошибкой:
Журнальное протоколирование в SQL Server
Журнал транзакций
Журнал транзакций используется для записи всех транзакций и модификаций, которые вносятся в базу данных этими транзакциями. Именно эта запись позволяет выполнять воспроизведение. При фиксировании транзакции операция фиксирования не завершается, пока в журнал транзакций не будет внесена запись о фиксировании данной транзакции. Поскольку изменения, которые вносятся в базу данных, не сразу записываются на диск, журнал транзакций является единственным средством, с помощью которого можно воспроизвести транзакции в случае отказа системы.
Поток откладываемой записи (Lazywriter Thread)
Кроме потока откладываемой записи, поток контрольной точки а также выполняет запись ожидающих страниц на диск. (Мы рассмотрим более подробно поток контрольной точки ниже в этом разделе.)
Последовательная запись в журнал
Размер журнала транзакций
В зависимости от числа изменений, вносимых в базу данных, журнал транзакций может увеличиваться до больших размеров. Поскольку журнал транзакций состоит из одного или нескольких файлов, размер которых ограничен, этот журнал будет заполняться до конца, и поэтому его приходится время от времени укорачивать (усекать). Автоматическое усечение журнала выполняется по завершении его резервного копирования, как мы увидим ниже в этой лекции.
Воспроизведение с помощью журнала транзакций
В случае отказа системы, при котором не повреждены файлы данных, текущий журнал транзакций используется для воспроизведения базы данных, поскольку это требуется для повторного исполнения транзакций, которые еще не были записаны на диск. Количество требующих воспроизведения страниц зависит от количества ожидающих записи (черновых) страниц в базе данных, которое, в свою очередь, определяется интервалом между контрольными точками. При создании очередной контрольной точки происходит запись всех черновых страниц на диск, что позволяет уменьшить время, необходимое для воспроизведения. Контрольные точки и интервал между контрольными точками подробно описываются в разделе «Контрольные точки» ниже в этой лекции.
Руководство по архитектуре журнала транзакций SQL Server и управлению им
Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все изменения данных, произведенные в каждой из транзакций. Журнал транзакций является критическим компонентом базы данных и в случае системного сбоя может потребоваться для приведения базы данных в согласованное состояние. В этом руководстве приводятся сведения о физической и логической архитектуре журнала транзакций. Понимание архитектуры может помочь в повышении эффективности работы с журналами транзакций.
Логическая архитектура журнала транзакций
Логически журнал транзакций SQL Server работает так, как если бы он являлся последовательностью записей в журнале. Каждая запись журнала идентифицируется регистрационным номером транзакции (номер LSN). Каждая новая запись добавляется в логический конец журнала с номером LSN, который больше номера LSN предыдущей записи. Записи журнала сохраняются в серийной последовательности по мере их создания, таким образом если LSN2 больше, чем LSN1, то изменение, описанное записью журнала, на которую ссылается LSN2, произошло после изменения, описанного записью журнала LSN1. Каждая запись журнала содержит идентификатор транзакции, к которой она относится. Все записи журнала, связанные с определенной транзакцией, с помощью обратных указателей связаны в цепочку, которая предназначена для ускорения отката транзакции.
Записи журнала для изменения данных содержат либо выполненную логическую операцию, либо исходный и результирующий образ измененных данных. Исходный образ записи — это копия данных до выполнения операции, а результирующий образ — копия данных после ее выполнения.
Действия, которые необходимо выполнить для восстановления операции, зависят от типа журнальной записи:
Зарегистрирована логическая операция.
Для наката логической операции выполняется эта операция.
Для отката логической операции выполняется логическая операция, обратная зарегистрированной.
Зарегистрированы исходный и результирующий образы записи.
Для наката операции применяется результирующий образ.
Для отката операции применяется исходный образ.
В журнал транзакций записываются различные типы операций, например:
начало и конец каждой транзакции;
любые изменения данных (вставка, обновление или удаление), включая изменения в любой таблице (в том числе и в системных таблицах), производимые системными хранимыми процедурами или инструкциями языка DDL;
любое выделение и освобождение страниц и экстентов;
создание и удаление таблиц и индексов.
Кроме того, регистрируются операции отката. Каждая транзакция резервирует в журнале транзакций место, чтобы при выполнении инструкции отката или возникновения ошибки в журнале было достаточно места для регистрации отката. Объем резервируемого пространства зависит от выполняемых в транзакции операций, но обычно он равен объему, необходимому для регистрации каждой из операций. Все это пространство после завершения транзакции освобождается.
Разностные резервные копии и резервные копии журналов продвигают восстанавливаемую базу данных к более позднему моменту, которому соответствует больший регистрационный номер транзакции в журнале.
Физическая архитектура журнала транзакций
Журнал транзакций в базе данных сопоставляет один или несколько физических файлов. По сути, файл журнала представляет собой строку записей журнала. Физически последовательность записей журнала эффективно хранится в наборе физических файлов, которые образуют журнал транзакций. Для каждой базы данных должен существовать хотя бы один файл журнала.
Виртуальные файлы журнала (VLF)
Внутри системы компонент Компонент SQL Server Database Engine делит каждый физический файл журнала на несколько виртуальных файлов журнала. Виртуальные файлы журнала не имеют фиксированных размеров. Не существует также и определенного числа виртуальных файлов журнала, приходящихся на один физический файл журнала. Компонент Компонент Database Engine динамически определяет размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Компонент Database Engine стремится обслуживать небольшое число виртуальных файлов. После расширения файла журнала размер виртуальных файлов определяется как сумма размера существующего журнала и размера нового приращения файла. Администраторы не могут настраивать или устанавливать размеры и число виртуальных файлов журнала.
Для создания виртуального файла журнала (VLF) используется следующий метод.
Если в результате большого числа малых приращений файлы журнала разрастаются до крупных размеров, они будут иметь множество виртуальных файлов журнала. Это может замедлить запуск базы данных, а также операции резервного копирования и восстановления журналов. И наоборот, если файлы журнала разрастаются до крупных размеров в результате всего нескольких или даже одного приращения, они будут иметь очень мало виртуальных файлов журнала. Дополнительные сведения о правильной оценке параметра требуемого размера и автоувеличения для журнала транзакций см. в разделе Рекомендации статьи Управление размером файла журнала транзакций.
Рекомендуется назначать файлам журнала значение size, которое было бы максимально близким к окончательному требуемому размеру, используя требуемые приращения для обеспечения оптимального распределения VLF, а также задавать относительно большое значение growth_increment. Воспользуйтесь советом ниже, чтобы определить оптимальное распределение VLF для текущего размера журнала транзакций.
Дополнительные сведения об аргументах FILEGROWTH и SIZE для ALTER DATABASE см. в разделе Параметры инструкции ALTER DATABASE (Transact-SQL) для файлов и файловых групп.
Чтобы определить оптимальное распределение виртуальных файлов журнала для текущего размера журнала транзакций всех баз данных в определенном экземпляре, а также требуемые приращения для достижения нужного размера, см. следующий скрипт.
Циклическая природа журнала транзакций
Журнал транзакций является оборачиваемым файлом. Рассмотрим пример. Пусть база данных имеет один физический файл журнала, разделенный на четыре виртуальных файла журнала. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых находятся перед минимальным регистрационным номером восстановления в журнале транзакций (MinLSN). MinLSN — это регистрационный номер транзакции самой старой записи в журнале, которая необходима для успешного отката на уровне всей базы данных. Журнал транзакций рассматриваемой в данном примере базы данных будет выглядеть примерно так же, как на следующей иллюстрации.
Когда конец логического журнала достигнет конца физического файла журнала, новые записи журнала будут размещаться в начале физического файла журнала.
Этот цикл повторяется бесконечно, пока конец логического журнала не совмещается с началом этого логического журнала. Если старые записи журнала усекаются достаточно часто, так что при этом всегда остается место для новых записей журнала, созданных с новой контрольной точки, журнал постоянно остается незаполненным. Однако, если конец логического журнала совмещается с началом этого логического журнала, происходит одно из двух событий, перечисленных ниже.
Если для журнала включен параметр FILEGROWTH и на диске имеется свободное место, файл расширяется на величину, указанную в параметре growth_increment, и новые записи журнала будут добавляться в это расширение. Дополнительные сведения о параметре FILEGROWTH см. в статье Параметры инструкции ALTER DATABASE (Transact-SQL) для файлов и файловых групп.
Если параметр FILEGROWTH не включен или диск, на котором размещается файл журнала, имеет меньше свободного места, чем указано в параметре growth_increment, выдается ошибка 9002. Дополнительные сведения см. в разделе Устранение неполадок при переполнении журнала транзакций.
Если в журнале содержится несколько физических файлов журнала, логический журнал будет продвигаться по всем физическим файлам журнала до тех пор, пока он не вернется на начало первого физического файла журнала.
Дополнительные сведения об управлении размером журнала транзакций см. в разделе Управление размером файла журнала транзакций.
Усечение журнала
На следующем рисунке показан журнал транзакций до усечения и после. На первом рисунке показан журнал транзакций, который никогда не усекался. В настоящий момент логический журнал состоит из четырех виртуальных файлов. Логический журнал начинается с первого файла виртуального журнала и заканчивается виртуальным файлом журнала 4. Запись MinLSN находится в виртуальном журнале 3. Виртуальные журналы 1 и 2 содержат только неактивные записи журнала. Эти записи можно усечь. Виртуальный журнал 5 пока не используется и не является частью текущего логического журнала.
На втором рисунке показан журнал после усечения. Виртуальные журналы 1 и 2 усечены и могут использоваться повторно. Логический журнал теперь начинается с виртуального журнала 3. Виртуальный журнал 5 пока не используется и не является частью текущего логического журнала.
За исключением тех случаев, когда усечение журнала по каким-то причинам задерживается, оно выполняется автоматически после наступления следующих событий.
Усечение журнала может быть задержано из-за множества факторов. В случае большой задержки усечения журнала возможно заполнение журнала транзакций. См. сведения в разделах Факторы, которые могут вызвать задержку усечения журнала и Устранение неполадок при переполнении журнала транзакций (ошибка SQL Server 9002).
Журнал транзакций с упреждающей записью
В этом разделе описана роль, которую журнал транзакций с упреждающей записью играет в записи изменений данных на диск. SQL Server использует алгоритм с упреждающей записью журнала (WAL), который гарантирует, что сначала на диск будет записана соответствующая запись журнала, и только после этого изменения данных будут записаны на диск. Таким образом обеспечиваются свойства ACID для транзакции.
Для понимания принципов работы упреждающего ведения журнала важно знать, как измененные данные записываются на диск. SQL Server Имеет буферный кэш, в который считываются страницы данных, когда требуется получить данные. Если какая-либо из страниц в буферном кэше изменилась, она не записывается сразу на диск, а помечается грязной. До момента ее физической записи на диск к странице могла быть применена одна или несколько операций логической записи. При каждой логической операции записи в кэш журнала, который записывает изменения, добавляется запись журнала транзакций. Записи журнала должны быть перенесены на диск до того, как соответствующая «грязная» страница будет удалена из буферного кэша и записана на диск. Заключается в том, что процесс контрольных точек производит периодический просмотр буферного кэша на наличие буферов со страницами определенной базы данных и запись всех «грязных» страниц на диск. Контрольные точки экономят время во время последующего восстановления при помощи создания точки, в которой все «грязные» страницы гарантированно записываются на диск.
Запись измененной страницы данных из буферного кэша на диск называется сбросом страницы на диск. SQL Server Имеет логику, которая предотвращает запись на диск «грязной» страницы до записи на него связанной записи журнала. Содержимое журнала записывается на диск при сбросе буферов журнала. Это происходит при фиксации транзакции или заполнении буферов журнала.
Резервные копии журналов транзакций
Этот раздел содержит основные понятия о создании резервной копии и восстановлении журналов транзакций. В рамках модели полного восстановления или восстановления с неполным протоколированием для восстановления данных важно регулярно создавать резервные копии журнала транзакций (резервные копии журнала). Можно создать резервную копию журнала во время выполнения полного резервного копирования. Дополнительные сведения о моделях восстановления см. в статье Резервное копирование и восстановление баз данных SQL Server.
Перед созданием первой резервной копии журнала необходимо создать полную резервную копию данных, например резервную копию базы данных или первую в наборе резервную копию файлов. Восстановить базу данных исключительно из резервных копий файлов может оказаться довольно сложно. Поэтому рекомендуется начинать резервирование с создания полной резервной копии базы данных. После этого необходимо регулярное создание резервных копий журнала транзакций. Это не только уменьшит вероятность потери данных, но и даст возможность производить усечение журнала транзакций. Обычно он усекается после каждого обычного резервного копирования журналов,
Рекомендуем создавать резервные копии журналов с достаточной периодичностью в соответствии с вашими бизнес-требованиями, в особенности касающимися устойчивости к потере данных, что может произойти из-за повреждения хранилища журналов. Частота создания резервных копий журнала зависит от степени толерантности к возможности потери данных и от того, какое количество резервных копий журнала получится хранить и в потенциале восстанавливать, а также каким количеством управлять. При реализации стратегии восстановления и, в частности, периодичности резервного копирования журнала, определите необходимое целевое время и целевую точку восстановления. Возможно, создания резервных копий журналов один раз в 15-30 минут может оказаться достаточно. Если предприятию необходимо минимизировать вероятность потери данных, следует увеличить частоту создания резервных копий журнала. Более частое создание резервных копий журнала предоставляет преимущество за счет более частого усечения журнала, результатом которого является меньший размер файлов журнала.
Чтобы ограничить число резервных копий журналов, которые требуется восстановить, важно периодически создавать резервные копии данных. Например, можно запланировать еженедельное создание полной резервной копии базы данных и ежедневное создание разностных резервных копий.
Опять же, при реализации стратегии восстановления и, в частности, периодичности полного и разностного резервного копирования базы данных, определите необходимое целевое время и целевую точку восстановления.
Дополнительные сведения о создании резервных копий журналов транзакций см. в разделе Резервные копии журналов транзакций (SQL Server).
Цепочка журналов
Непрерывная последовательность резервных копий журналов называется цепочкой журналов. Цепочка журналов начинается с полной резервной копии базы данных. Обычно новая цепочка журналов начинается, только когда создается первая резервная копия базы данных или после переключения модели восстановления с простой на полную или на модель с неполным протоколированием. Существующая цепочка журналов остается без изменений, если не выбрана перезапись существующих наборов резервных копий при создании резервной копии базы данных целиком. Сохраняя неизменность цепочки журналов, базу данных можно восстановить из любой резервной копии полной базы данных в любом наборе носителей и из всех последующих резервных копий журналов до точки восстановления. Точка восстановления может быть концом последней резервной копии журналов или определенной точкой восстановления в любой из резервных копий журналов. Дополнительные сведения см. в разделе Резервные копии журналов транзакций (SQL Server).
Чтобы восстановить базу данных на момент точки сбоя, нужна неповрежденная цепочка журналов. Непрерывная последовательность резервных копий журналов должна следовать до точки сбоя. Точка начала этой последовательности зависит от типа восстанавливаемой резервной копии: резервная копия базы данных, частичная резервная копия или резервная копия файлов. В случае резервной копии базы данных или частичной резервной копии последовательность резервных копий журнала должна начинаться от конца резервной копии базы данных или частичной резервной копии. В наборе резервных копий файлов последовательность резервных копий журналов должна следовать от начала полного набора резервных копий файлов. Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).
Восстановление резервных копий журнала
Восстановление резервной копии журналов выполняет накат изменения, которые записаны в журнале транзакций, для воссоздания точного состояния базы данных на момент начала операции резервного копирования журнала. При восстановлении базы данных необходимо восстанавливать резервные копии журналов, которые были созданы после создания восстановленной полной резервной копии или с начала первой восстановленной резервной копии файлов. Обычно после восстановления последней резервной копии данных или разностной резервной копии необходимо произвести восстановление серии резервных копий журналов до точки восстановления. Затем производится восстановление базы данных. При этом откатываются все незавершенные на момент восстановления транзакции, и база данных переводится в режим «в сети». После восстановления базы данных нельзя более восстанавливать резервные копии. Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).
Контрольные точки и активная часть журнала
При достижении контрольных точек измененные страницы данных записываются из буферного кэша текущей базы данных на диск. Это сводит к минимуму активную часть журнала, которую приходится обрабатывать при полном восстановлении базы данных. Во время полного восстановления базы данных выполняются следующие действия.
Функционирование контрольной точки
Контрольная точка выполняет в базе данных следующее.
Записывает в файл журнала запись, отмечающую начало контрольной точки.
Сохраняет данные, записанные для контрольной точки в цепи записей журнала контрольной точки.
Одним из элементов данных, регистрируемых в записях контрольной точки, является номер LSN первой записи журнала, при отсутствии которой успешный откат в масштабе всей базы данных невозможен. Такой номер LSN называется минимальным номером LSN восстановления (MinLSN). Номер MinLSN является наименьшим значением из:
Записи контрольной точки содержат также список активных транзакций, изменивших базу данных.
Если база данных использует простую модель восстановления, помечает для повторного использования пространство, предшествующее номеру MinLSN.
Записывает все измененные страницы журналов и данных на диск.
Записывает в файл журнала запись, отмечающую конец контрольной точки.
Записывает в страницу загрузки базы данных номер LSN начала соответствующей цепи.
Действия, приводящие к срабатыванию контрольных точек
Контрольные точки срабатывают в следующих ситуациях.
Автоматические контрольные точки
Ядро СУБД SQL Server создает автоматические контрольные точки. Интервал между автоматическими контрольными точками определяется на основе использованного места в журнале и времени, прошедшего с момента создания последней контрольной точки. Интервал времени между автоматическими контрольными точками колеблется в широких пределах и может быть довольно длительным, если база данных изменяется редко. При крупномасштабных изменениях данных частота автоматических контрольных точек может быть гораздо выше.
Кроме того, интервал между автоматическими контрольными точками зависит от модели восстановления, как показано ниже.
Если применяется полная модель восстановления или модель восстановления с неполным протоколированием, то автоматическая контрольная точка создается каждый раз, когда число записей в журнале достигает значения, определенного ядром СУБД в качестве предельного количества записей, которое оно может обработать за время, заданное параметром recovery interval.
Если используется простая модель восстановления базы данных, автоматическая контрольная точка создается каждый раз, когда число записей в журнале достигает меньшего из двух предельных условий:
Информацию о настройке интервала восстановления см. в статье Настройка параметра конфигурации сервера recovery interval.
Если используется простая модель восстановления базы данных, то при срабатывании автоматических контрольных точек неиспользуемая часть журнала транзакций удаляется. Однако при использовании модели полного восстановления или модели восстановления с неполным протоколированием журнал в результате срабатывания автоматических контрольных точек не усекается. Дополнительные сведения см. в статье Журнал транзакций.
Инструкция CHECKPOINT теперь поддерживает необязательный аргумент checkpoint_duration, определяющий время (в секундах), отводимое контрольным точкам на завершение. Дополнительные сведения см. в статье CHECKPOINT.
активным журналом
Часть файла журнала, начинающаяся с номера MinLSN и заканчивающаяся последней зафиксированной записью, называется активной частью журнала или «активным журналом». Этот раздел журнала необходим для выполнения полного восстановления базы данных. Ни одна часть активного журнала не может быть усечена. Все записи журнала до номера MinLSN должны быть удалены из частей журнала.
На следующем рисунке изображена упрощенная схема журнала завершения транзакций, содержащего две активные транзакции. Записи контрольных точек были сжаты в одну запись.
Последней записью в журнале транзакций является запись с номером LSN, равным 148. На момент обработки записанной контрольной точки с номером LSN 147 транзакция 1 уже зафиксирована и единственной активной транзакцией является транзакция 2. В результате первая запись журнала, созданная для транзакции 2, становится старейшей записью активной транзакции на момент последней контрольной точки. Таким образом, номером MinLSN становится номер LSN, равный 142 и соответствующий записи начала транзакции 2.
Продолжительные транзакции
Активный журнал должен включать в себя все элементы всех незафиксированных транзакций. Приложение, инициирующее транзакцию и не выполняющее ее фиксацию или откат, препятствует Компонент Database Engine продвигать MinLSN. Это может привести к проблемам двух типов.
Начиная с SQL Server 2019 (15.x) и в База данных SQL Azure, восстановления длительных транзакций и описанных выше проблем можно избежать с помощью ускоренного восстановления базы данных.
Транзакции репликации
Агент чтения журнала следит за журналом транзакций всех баз данных, на которых настроена репликация транзакций, и копирует отмеченные для репликации транзакции из журнала транзакций в базу данных распространителя. Активный журнал должен содержать все транзакции, отмеченные для репликации, но еще не доставленные базе данных распространителя. Если эти транзакции не реплицировать в допустимый срок, усечение журнала может оказаться невозможным. Дополнительные сведения см. в статье Репликация транзакций.
См. также раздел
Мы рекомендуем следующие статьи и книги, которые содержат дополнительные сведения о журнале транзакций и рекомендации по управлению журналами.