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

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

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

  • порядковый номер, тип и время изменения;
  • идентификатор транзакции;
  • объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока);
  • предыдущее состояние объекта и новое состояние объекта.

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

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

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

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

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

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

Мультиплексирование[править | править вики-текст]

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

Архивирование[править | править вики-текст]

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

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

Реализации[править | править вики-текст]

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

Oracle[править | править вики-текст]

В СУБД Oracle используются журналы изменений двух видов: журнал повтора («archive log») и журнал отката («redo log»). Журнал повтора работает только в т. н. режиме архивирования базы данных («archivelog») и записывается на диск, как правило в количестве двух или более копий. В этот журнал записывается информация о транзакции после её окончательного завершения и записи на диск. Информация из журнала повтора не может быть применена для отката транзакции, но применяется для её восстановления. Процесс восстановления производится администратором с использованием резервной копии базы данных и последовательного приложения к ней журналов повтора.

Информация для отката (журнал отката) группируется в сегменты отката и записывается в буферную память. В случае подтверждения транзакции информация о старых данных уничтожается (новые сегменты отката записываются в те же ячейки памяти), а в случае отката («rollback») — используется для восстановления записи изменяемой транзакции. Информация из журнала отката используется также для поддержания целостности по чтениюссылочная целостность»).[1]

Informix[править | править вики-текст]

В СУБД Informix журнал изменений представляет из себя дисковое пространство, разделенное на части называемые файлами журнала транзакций (эти файлы не имеют ничего общего с файлами на файловой системе) или логическим журналом. Запись изменений в этот журнал зависит от того в каком режиме находится база данных — без журналирования, с буферизованным журналированием или с небуферизованным. Все изменения сначала попадают в буфера логического журнала, а дальнейший сброс их в журнал транзакций зависит от режима журналирования базы данных.

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

См. также[править | править вики-текст]

Примечания[править | править вики-текст]

Литература[править | править вики-текст]

  • К. Дж. Дейт Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — С. 1328. ISBN 0-321-19784-4
  • Томас Коннолли, Каролин Бегг Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management Third Edition. — 3-е изд. — М.: «Вильямс», 2003. — С. 1436. ISBN 0-201-70857-4