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