Журналізація змін функція СКБД яка зберігає інформацію необхідну для відновлення бази даних в попередній узгоджений стан

Журналізація змін — функція СКБД, яка зберігає інформацію, необхідну для відновлення бази даних в попередній узгоджений стан в разі збою в роботі СКБД (програмного чи апаратного), а також для забезпечення можливості скасування транзакцій.

У найпростішому випадку журналювання змін полягає в послідовному записі у зовнішню пам'ять всіх змін, які виконуються в базі даних. Записується наступна інформація:

Порядковий номер, тип і час зміни;
Ідентифікатор транзакції;
Об'єкт, що піддався зміні (номер зберігається файлу і номер блоку даних в ньому, номер рядка всередині блоку);
Попередній стан об'єкта і новий стан об'єкта.

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

В блоки даних зовнішньої пам'яті забезпечуються позначкою порядкового номера останньої зміни, яке було виконано над цим блоком даних. У разі збою системи ця позначка дозволяє дізнатися яка версія блоку даних встигла досягти зовнішньої пам'яті.

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

Журнал змін може не записуватися безпосередньо в зовнішню пам'ять, а акумулюватися в оперативній. У разі підтвердження транзакції СКБД очікує запису решти журналу на зовнішню пам'ять. Таким чином гарантується, що всі дані, внесені після сигналу підтвердження, будуть перенесені на зовнішній пам'ять, не чекаючи перепису всіх змінених блоків з . СКБД очікує запису решти журналу також і при виконанні контрольної точки.

'В разі логічної відмови' або сигналу відкату однієї транзакції журнал сканується в зворотному напрямку, і всі записи скасовуваної транзакції витягуються з журналу аж до позначки початку транзакції. Згідно витягнутої інформації виконуються дії, що скасовують дії транзакції, а в журнал записуються компенсувальні записи. Цей процес називається 'відкат' (rollback).

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

Типи записів журналу баз даних

Всі записи журналу містять загальні атрибути журналу вище, а також інші атрибути залежно від їх типу (який записується у атрибуті «Тип», як зазначено вище).

Запис про зміну даних відзначає оновлення (зміну) в базі даних. Вона включає в себе таку додаткову інформацію:
- PageID: посилання на ідентифікатор сторінки модифікованої сторінки.
- Довжина і зміщення: зазвичай входить довжина в байтах та зміщення сторінки.
- Before and After Images: Включає значення байтів сторінки до і після зміни сторінки. У деяких базах даних можуть бути журнали, які містять одне або обидва зображення.
Компенсувальний запис відзначає відкат певної зміни в базі даних. Кожна з них відповідає єдиному запису про зміну даних (хоча відповідний запис про зміну даних не зберігається в компенсувальному записі). Вона включає в себе таку додаткову інформацію:
- undoNextLSN: це поле містить LSN наступного запису журналу, який потрібно скасувати для транзакції, яка написала останній запис про зміну.
Запис про Commit відзначає рішення про завершення (commit) транзакції.
Запис про Abort відзначає рішення про перерву і, отже, відкат транзакції.
Запис про контрольну точку зазначає, що була виконана контрольна точка. Вони використовуються для прискорення відновлення. Вони записують інформацію, яка усуває необхідність прочитати багато минулих даних з журналу. Поведінка залежить від алгоритму контрольної точки. Якщо всі брудні (змінені) сторінки записуються на носій даних при створенні контрольної точки (як у PostgreSQL), цей запис може містити:
- redoLSN: посилання на перший запис журналу, який відповідає брудній сторінці. тобто перша зміна даних, яка не була записана на носій. Саме тут слід починати відновлення в процесі прогону.
- undoLSN: посилання на найстаріший запис журналу найстарішої транзакції, що ще виконується. Це найстаріший запис журналу, необхідний для скасування всіх поточних операцій.
Запис про завершення транзакції зазначає, що для цієї конкретної транзакції виконана уся робота. (Вона повністю підтверджена або відкочена)

Мультиплексування

Для збільшення відмовостійкості СКБД може записувати одночасно кілька ідентичних копій журналу змін. Якщо в разі відмови одна з копій журналу виявиться недоступною, СКБД відновить базу даних використовуючи будь-яку з доступних копій. Така стратегія називається мультиплексуванням журналу змін.

Архівування

Як правило, журнал змін перезаписується спочатку, як тільки закінчується простір зовнішньої пам'яті, виділений під нього. Це дозволяє відновити базу даних до актуального та узгодженого стану, але тільки в тому випадку, якщо сама база даних не втрачена, нехай навіть і не в актуальному стані.

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

Реалізації

Не всі реальні СКБД слідують класичній схемі реалізації журналу змін, зокрема з міркувань ефективності.

Oracle Database

В Oracle Database використовуються журнали змін двох видів: циклічний оперативний журнал повтору (redo log) і архівний журнал повтору (archive log), в якій переносяться записи з першого журналу при проходженні повного циклу першого. Обидва журнали записуються на постійний носій. В оперативний журнал дані про операції потрапляють в момент перед фіксацією даних на енергонезалежному носії, архівний журнал працює тільки в особливому режимі підтримки журнального архівування бази даних (archivelog). Інформація з журналів змін не використовується для відкоту транзакції, але застосовується для відновлення. Процес відновлення проводиться адміністратором з використанням резервної копії бази даних і послідовного застосування до неї архівних журналів і журналів повтору.

Інформація для відкату (журнал відкату,undo log) групується в сегменти відкату, які обслуговуються табличними просторами спеціального типу. Для цих даних також ведеться журнал повтору, тобто, вони захищені таким же чином, як інші дані в базі. У разі відкату журнал використовується для відновлення запису змінною транзакції. Крім того, інформація з журналу відкату використовується для підтримки для забезпечення доступу до знімка даних, зробленому в момент вибірки.

Informix

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

Для відновлення в разі відмови використовується т. Зв. 'Фізичний журнал' , в який копіюються образи сторінок перед їх зміною. У разі збою сервера непідтверджені дані будуть відновлені під час запуску.

Див. також

Примітки

Controlling Archiving

Література

Когаловский М. Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — .
Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — .
Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. — (рус.) 0-321-19784-4 (англ.).
Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1436 с. — .
Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. — .
C. J. Date. Date on Database: Writings 2000—2006. — Apress, 2006. — 566 с. — , 1-59059-746-X.

[oracle_archive-1] Controlling Archiving