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

Видимо, по цих причинах, а також по причинах необхідного ускладнення системи синхронізації, описані засоби боротьби з фантом не були реалізовані в System R (принаймні, це виходить із заключних публікацій). Більш того внаслідок половинчатості цього рішення і дуже великого обмеження міри асинхронності розробники відмовилися і від неявних захоплень відношення в режимі S при скануванні без використання індексів. (Нагадаємо, що можливість явного захоплення цілком відносини залишилася). Тим самим, System R не гарантує відсутність фантом при повторному скануванні відношення.

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

На закінчення даного підрозділу стисло згадаємо про ще один рівень синхронізації, присутньому в RSS, - рівні фізичної синхронізації. Ми вже зазначали, що після виконання будь-якої операції RSS залишає базу даних в фізично узгодженому вигляді. Це означає, зокрема, коректність всіх міжсторінкових посилань. Прикладами таких посилань можуть бути посилання між станицями В-дерев індексів і т.д. Під час виконання операцій зміни (занесення, модифікації або видалення кортежу) може виникати тимчасова некоректність стану сторінок даних. Для того, щоб кожна операція при початку свого виконання мала коректну інформацію, необхідна додаткова короткочасна синхронізація на рівні сторінок. На час виконання операції всі необхідні сторінки захоплюються в режимі читання або зміни. Захоплення знімаються при закінченні виконання операції.

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

7.6. Журналізація і відновлення в System R

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

Ситуації, виникаючі при збоях кожного з відмічених класів, різні і, взагалі кажучи, вимагають різних підходів до організації відновлення баз даних. Індивідуальні збої транзакцій означають, що всі зміни, вироблені в базі даних деякою транзакцією, незаконні, і їх необхідно усунути. Для цього необхідно виконати індивідуальний відкат транзакції такого ж типу, як при виконанні RSS явної операції RESTORE.

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

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

Алгоритми відновлення System R засновані на двох базових засобах - веденні журналу і підтримці тіньових станів сегментів. Розглянемо спочатку механізм журналізації. Ми вже згадували про наявність журналу в попередніх підрозділах. Журнал - це окремий файл зовнішньої пам'яті, для якого для надійності звичайно підтримуються дві копії, і в який вміщується інформація про всі операції зміни стану бази даних. У попередньому підрозділі ми згадували про використання журналу для відкату транзакції по явній