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

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

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

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

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

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

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

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

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

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

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

Мультиплексирование[править | править исходный текст]

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

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

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

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

Реализации[править | править исходный текст]

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

Oracle[править | править исходный текст]

В СУБД Oracle журнал изменений разделен на журнал повтора и журнал отката[источник не указан 1594 дня]. В журнал повтора записывается только информация, о том, в каком состоянии объект находился после выполнения изменения. Эта информация не может быть применена для отката отдельной транзакции[источник не указан 1594 дня].

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

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