що в будь-якому випадку для відновлення БД треба мати в своєму розпорядженні деяку додаткову інформацію. Іншими словами, підтримка надійності зберігання даних в БД вимагає надмірності зберігання даних, причому та частина даних, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримки такої надмірної інформації є ведення журналу змін БД.
Журнал - це особлива частина БД, недоступна користувачам СУБД і що підтримується з особливою ретельністю (іноді підтримуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку поступають записи про всі зміни основної частини БД. У різній СУБД зміни БД журналізуються на різних рівнях: іноді запис в журналі відповідає деякій логічній операції зміни БД (наприклад, операції видалення рядка з таблиці реляційної БД), іноді - мінімальної внутрішньої операції модифікації сторінки зовнішньої пам'яті; в деяких системах одночасно використовуються обидва підходи.
У всіх випадках дотримуються стратегії "попереджуючого" запису в журнал (так званого протоколу Write Ahead Log - WAL). Грубо кажучи, ця стратегія полягає в тому, що запис про зміну будь-якого об'єкта БД повинен попасти у зовнішню пам'ять журналу раніше, ніж змінений об'єкт попаде у зовнішню пам'ять основної частини БД. Відомо, що якщо в СУБД коректно дотримується протокол WAL, то за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.
Сама проста ситуація відновлення - індивідуальний відкат транзакції. Суворо кажучи, для цього не потрібний загальносистемний журнал змін БД. Досить для кожної транзакції підтримувати локальний журнал операцій модифікації БД, виконаних в цій транзакції, і проводити відкат транзакції шляхом виконання зворотних операцій, слідуючи від кінця локального журналу. У деякій СУБД так і роблять, але в більшості систем локальні журнали не підтримують, а індивідуальний відкат транзакції виконують за загальносистемним журналом, для чого всі записи від однієї транзакції зв'язують зворотним списком (від кінця до початку).
При м'якому збої у зовнішній пам'яті основної частини БД можуть знаходитися об'єкти, модифіковані транзакціями, що не закінчилися до моменту збою, і можуть бути відсутнім об'єкти, модифіковані транзакціями, які до моменту збою успішно завершилися (внаслідок використання буферів оперативної пам'яті, вміст яких при м'якому збої пропадає). При дотриманні протоколу WAL у зовнішній пам'яті журналу повинні гарантовано знаходитися запису, що відносяться до операцій модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою є стан зовнішньої пам'яті основної частини БД, який виник би при фіксації у зовнішній пам'яті змін всіх транзакцій, що завершилися і яке не містило б ніяких слідів незавершених транзакцій. Для того, щоб цього добитися, спочатку проводять відкат незавершених транзакцій (undo), а потім повторно відтворюють (redo) ті операції завершених транзакцій, результати яких не відображені у зовнішній пам'яті. Цей процес містить багато тонкості, пов'язаної із загальною організацією управління буферами і журналом. Більш детально ми розглянемо це у відповідній лекції.
Для відновлення БД після жорсткого збою використовують журнал і архівну копію БД. Грубо кажучи, архівна копія - це повна копія БД до моменту початку заповнення журналу (є багато варіантів більш гнучкого трактування значення архівної копії). Звичайно, для нормального відновлення БД після жорсткого збою необхідно, щоб журнал не пропав. Як вже відмічалося, до збереження журналу у зовнішній пам'яті в СУБД пред'являються особливо підвищені вимоги. Тоді відновлення БД полягає в тому, що виходячи з архівної копії по журналу відтворюється робота всіх транзакцій, які закінчилися до моменту збою. У принципі, можна навіть відтворити роботу незавершених транзакцій і продовжити їх роботу після завершення відновлення. Однак в реальних системах це звичайно не робиться, оскільки процес відновлення після жорсткого збою є досить тривалим.
2.1.5. Підтримка мов БД
Для роботи з базами даних використовуються спеціальні мови, загалом звані мовами баз даних. У ранній СУБД підтримувалося декілька спеціалізованих по своїх функціях мов. Частіше за все виділялися дві мови - мова визначення схеми БД (SDL - Schema Definition Language) і мова маніпулювання даними (DML - Data Manipulation Language). SDL служив головним чином для визначення логічної структури БД, тобто тієї структури БД, якої вона представляється користувачам. DML містив набір операторів маніпулювання даними, тобто операторів, що дозволяють занести дані в БД, видаляти, модифікувати або вибирати існуючі дані. Ми розглянемо більш детально мови ранньої СУБД в наступній лекції.
У сучасній СУБД звичайно підтримується єдина інтегрована мова, що містить всі необхідні засоби для роботи з БД, починаючи від її створення, і для забезпечення базового інтерфейсу користувача з базами даних. Стандартною мовою найбільш поширеної в цей час реляційних СУБД є мова SQL (Structured Query Language). У декількох лекціях цього курсу мова SQL буде розглядатися досить детально, а поки ми перерахуємо основні функції реляційної СУБД, що підтримуються на "мовному" рівні (тобто функції, що підтримуються при реалізації інтерфейсу SQL).
Передусім, мова SQL поєднує засоби SDL і DML, тобто дозволяє визначати схему реляційної БД і маніпулювати даними. При цьому іменування об'єктів БД (для реляційної БД - іменування таблиць і їх стовпців) підтримується на язиковому рівні в тому значенні, що компілятор мови SQL проводить перетворення імен об'єктів в їх внутрішні ідентифікатори на основі службових таблиць-каталогів, що спеціально підтримуються. Внутрішня частина СУБД (ядро) взагалі не працює з іменами таблиць і їх стовпців.
Мова SQL містить спеціальні засоби визначення обмежень цілісності БД. Знову ж, обмеження цілісності зберігаються в спеціальних таблицях-каталогах, і забезпечення контролю цілісності БД проводиться на язиковому рівні, тобто при компіляції