воно може бути реалізовано в рамках додатків.
Тиражування. Основний сервер доступний на читання і запис, вторинний - тільки на читання. p> Коли основний сервер виходить з ладу, вторинний переводиться в режим доступу на читання, і на запис. p> Oracle 7 для використання DR необхідно придбати додатково до Oracle7 DBMS опцію Replication Option. p> Специфіка механізмів DR залежить від використовуваної СУБД. Найпростіший варіант DR - використання "моментальних знімків" (Snapshot). Розглянемо приклад з Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE ('DD-MON-YY HH23: MI: 55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer @ paris, order @ london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = "N";
В«Моментальний знімокВ» у вигляді горизонтальної проекції об'єднання таблиць customer і order буде виконаний в 23:55 і буде повторяться кожні 7 днів. Щоразу будуть вибиратися тільки завершені замовлення.
Реальні схеми тиражування, зрозуміло, влаштовані більш складно. В якості базису для тиражування виступає транзакція до бази даних. У той же час можливе перенесення змін групами транзакцій, періодично або в деякий момент часу, що дає можливість досліджувати стан приймаючої бази на певний момент часу.
Деталі тиражування даних повністю приховані від прикладної програми; її функціонування ніяк не залежать від роботи реплікатора, який цілком знаходиться у віданні адміністратора бази даних. Отже, для перенесення програми в розподілену середу з тиражованими даними не потрібно її модифікації. У цьому, власне, полягає якість 6 в визначенні Дейта.
Синхронне оновлення DDB і DR-технологія - в певному сенсі антиподи. Наріжний камінь першої - синхронне завершення транзакцій одночасно на кількох вузлах розподіленої системи, тобто синхронна фіксація змін до DDB. Ee "Ахіллесова п'ята" - жорсткі вимоги до продуктивності і надійності каналів зв'язку. Якщо база даних розподілена по декількох територіально віддалених вузлів, об'єднаним повільними і ненадійними каналами зв'язку, а число одночасно працюючих користувачів становить сотні і вище, то ймовірність того, що розподілена транзакція буде зафіксована в осяжному часовому інтервалі, стає надзвичайно малою. У таких умовах (характерних, до речі, для більшості вітчизняних організацій) обробка розподілених даних практично неможлива.
DR-технологія не вимагає синхронної фіксації змін, і в цьому її сильна сторона. Насправді далеко не у всіх завданнях потрібно забезпечення ідентичності БД на різних вузлах у будь-який час. Досить підтримувати тотожність даних лише в певні критичні моменти часу. Можна накопичувати зміни в даних у вигляді транзакцій в одному вузлі і періодично копіювати ці зміни на інші вузли.
У наявності переваги DR-технології. По-перше, дані завжди розташовані там, де вони обробляються - отже, швидкість доступу до них істотно збільшується. По-друге, передача лише операцій, змінюють дані (а не всіх операцій доступу до віддалених даних), і до того ж в асинхронному режимі дозволяє значно зменшити трафік. По-третє, зі боку вихідної бази для приймаючих баз реплікатор виступає як процес, ініційований одним користувачем, в той час як в фізично розподіленої середовищі з кожним локальним сервером працюють всі користувачі розподіленої системи, конкуруючі за ресурси один з одним. Нарешті, по-четверте, ніякої тривалий збій зв'язку неспроможна порушити передачу змін. Справа в тім, що тиражування передбачає буферизацію потоку змін (транзакцій); після відновлення зв'язку передача поновлюється з тієї транзакції, на якій тиражування було перервано.
DR-технологія даних не позбавлена ​​недоліків. Наприклад, неможливо повністю виключити конфлікти між двома версіями однієї і тієї ж записи. Він може виникнути, коли внаслідок все тієї ж асинхронности два користувача на різних вузлах виправлять одну і ту ж запис в той момент, поки зміни до даних з першої бази даних ще не були перенесені в другу. При проектуванні розподіленої середовища з використанням DR-технології необхідно передбачити конфліктні ситуації та запрограмувати репликатор на небудь варіант їх дозволу. У цьому сенсі застосування DR-технології - найбільш сильна загроза цілісності DDB. На мій погляд, DR-технологію потрібно застосовувати вкрай обережно, тільки для вирішення завдань з жорстко обмеженими умовами і за ретельно продуманою схемою, що включає осмислений алгоритм вирішення конфліктів.
5 Багатоланкова архітектура
Архітектура клієнт-сервер
Розподілені системи - це системи клієнт-сервер. Існує, щонайменше, три моделі клієнт-сервер:
* модель доступу до віддалених даних (RDA-модель);
* модель сервера бази даних (DBS-модель);
* модель серв...
