З управлінням транзакціями в багатокористувацької СУБД пов'язані важливі поняття сериализации транзакцій і серіального плану виконання суміші транзакцій. Під сериализацией паралельно виконуються транзакцій розуміється такий порядок планування їх роботи, при якому сумарний ефект суміші транзакцій еквівалентний ефекту їх деякого послідовного виконання. Серіальний план виконання суміші транзакцій - це такий план, який призводить до серіалізациі транзакцій. Зрозуміло, що якщо вдається домогтися дійсно серіального виконання суміші транзакцій, то для кожного користувача, з ініціативи якого утворена транзакція, присутність інших транзакцій буде непомітно (якщо не вважати деякого уповільнення роботи в порівнянні з однокористувацький режимом). p align="justify">. Журналізація
Одним з основних вимог до СУБД є надійність зберігання даних у зовнішній пам'яті. Під надійністю зберігання розуміється те, що СУБД повинна бути в змозі відновити останній узгоджений стан БД після будь-якого апаратного або програмного збою. Звичайно розглядаються два можливі види апаратних збоїв: так звані м'які збої, які можна трактувати як раптову зупинку роботи комп'ютера (наприклад, аварійне вимкнення живлення), і жорсткі збої, що характеризуються втратою інформації на носіях зовнішньої пам'яті. p align="justify"> Прикладами програмних збоїв можуть бути: аварійне завершення роботи СУБД (з причини помилки в програмі або в результаті деякого апаратного збою) або аварійне завершення користувальницької програми, в результаті чого деяка транзакція залишається незавершеною. Першу ситуацію можна розглядати - як особливий вид м'якого апаратного збою; при виникненні останній потрібна ліквідувати наслідки тільки однієї транзакції. Зрозуміло, що в будь-якому випадку для відновлення БД потрібно розташовувати деякою додатковою інформацією. p align="justify"> Іншими словами, підтримку надійності зберігання даних в БД вимагає надмірності зберігання даних, причому та частина даних, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримання такої надмірної інформації є ведення журналу змін БД. p align="justify"> Журнал - це особлива частина БД, недоступна користувачам СУБД і підтримувана з особливою ретельністю (іноді підтримуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку надходять записи про всі зміни основної частини БД. У різних СУБД зміни БД журналізіруются на різних рівнях: іноді запис у журналі відповідає деякої логічної операції зміни БД (наприклад, операції видалення рядка з таблиці реляційної БД), іноді - мінімальної внутрішньої операції модифікації сторінки зовнішньої пам'яті; в деяких системах одночасно використовуються обидва підходи. У всіх випадках дотримуються стратегії "попереджуючої" записи до журналу (так званого протоколу Write Ahead Log - WAL). Грубо кажучи, ця стратегія полягає в тому, що запис про зміну будь-якого об'єкта...
