лювання: в промисловій системі завжди можна дати однозначну відповідь на питання А що буде, якщо.? Raquo ;. Іншими словами, промислова система повинна забезпечувати своїми внутрішніми засобами передбачуваність свого стану незалежно від зовнішніх умов. Безумовно, будь-яке загальне визначення страждає неповнотою (справді, формально найбільш передбачуваним є стан системи, яка взагалі ніколи не працює), проте, на думку автора, воно все-таки дає ідею, необхідну для розуміння суті твердження про те, що Oracle надає технологію для створення саме промислових систем.
В якості поясняющего прикладу повернемося до проблеми синхронізації тиражованих даних. Розглянемо питання про організацію зв'язку між серверами в розподіленої БД. Дуже спокусливою є ідея: якщо вже ми не вимагаємо, щоб цілісність даних забезпечувалася в будь-який момент часу, чи не можна організувати зазначену зв'язок на основі електронної пошти? На перший погляд, нічого небезпечного в цьому немає, але згадаємо, що електронна пошта не гарантує, що листи будуть отримані адресатом в тій же послідовності, в якій вони були послані і навіть що всі вони взагалі будуть отримані. Навіть якщо за допомогою спеціального контролю на прийомі наслідки даної неоднозначності зводяться до мінімуму, все одно виявляється неможливим передбачити, скажімо, момент часу, коли інформація про зміну однієї з копій об'єкта дійде до інших його копій, і в якому стані до цього моменту ця змінилася копія знаходитиметься. Чи означає це, що електронною поштою в розподіленої БД користуватися взагалі не можна? І так і ні. Все залежить від вимог до системи. Якщо свіжість тиражованих даних потрібно, припустимо, в межах доби, а наслідки непередбачуваності системи і втрати її цілісності не надто руйнівні, то чому б і ні? Але якщо все-таки потрібно дійсно промислова система, то необхідно дуже ретельно оцінити всі можливі наслідки застосування обраного механізму взаємодії і ввести у використання того ж тиражування такі обмеження, які забезпечили б необхідний рівень цілісності системи.
2.5 Варіанти тиражування даних в Oracle
Найпростішим (і історично реалізованим перше) варіантом тиражування в Oracle є механізм так званих незмінних знімків (read-only snapshots). Він передбачає створення видаленої копії таблиці (або її підмножини), яка доступна тільки на читання і оновлюється за заданим сценарієм і розкладом. Точніше, знімок визначається так само, як уявлення - view, тобто він може бути заснований і на кількох таблицях.
Наступним за своєю логічною складності варіантом є організація змінюваних знімків, що надає можливість модифікації віддалених копій. Однак, як і в попередньому випадку, відносини серверів при цьому асиметричні (один з них є власником оригіналу даних, хоча і схильного віддаленим змінам).
Останнім атомарним варіантом тиражування в Oracle (бо можливі також будь-які комбінації) є тиражування з множинними господарями (multi-master site replication). При даному варіанті повністю тиражуються цілі набори об'єктів БД (в них крім таблиць можуть входити індекси, уявлення, тригери, пакети збережених процедур, синоніми, генератори послідовностей). При цьому тиражуються всі визначення і атрибути об'єктів, так що в результаті все господарі їх копій стають рівноправними. Будь-які зміни тиражованих даних безпосередньо передаються ( поширюються ) всім господарям (на відміну від варіанту змінюваних знімків, де кілька знімків одного об'єкта можуть обмінятися змінами тільки за посередництвом господаря цього об'єкта). Таке рішення, зокрема, призводить до того, що в системі не буде ні одного сервера, одиничний вихід з ладу якого означав би неможливість продовження роботи з набором тиражованих об'єктів.
Механізм розповсюдження змін в Oracle вбудований в ядро ??системи і не вимагає використання ніяких додаткових програмних продуктів. Будь-яка зміна тиражованого об'єкта приводить в дію спеціальний тригер, який формує виклик віддаленої процедури, необхідний для відтворення зміни в усіх залишилися копіях об'єкта. Далі в разі використання синхронного тиражування сформований виклик негайно починає виконуватися, у випадку ж асинхронного тиражування він поміщається в спеціальну чергу відкладених викликів, чекаючи настання моменту своєї передачі.
Черга відкладених викликів є об'єктом БД, а стало бути, нею можна управляти поряд з іншими об'єктами, після збоїв сервера вона відновлюється також разом з іншими.
Тепер, коли загальний механізм тиражування ясний, спробуємо розібратися в деяких аспектах його застосування.
Як уже згадувалося, можливі два режими тиражування: синхронний, коли всі зміни даних поширюються негайно, і асинхронний, коли по відношенню до цих змін застосовується алгоритм запам'ятати і передати (stor...
