Відкрити головне меню

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АрхивуванняРедагувати

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

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

РеалізаціїРедагувати

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

Oracle DatabaseРедагувати

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

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

InformixРедагувати

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

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

Див. такожРедагувати

ПриміткиРедагувати

ЛітератураРедагувати

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