e and forward), а момент передачі вибирається по заданому правилу (або явно ініціюється, наприклад, після відновлення зв'язку).
Синхронний варіант виправданий, мабуть, у прикладі з банком та його філіями, наведеному в самому початку розділу (у разі асинхронного тиражування з'являється небезпека, що нечистий на руку клієнт банку може, приміром, кілька разів закрити свій рахунок, швидко переміщаючись з філії у філію, - втім, як показано нижче, дана проблема може бути дозволена і інакше). У порівнянні з варіантом використання синхронного зв'язку без тиражування, переваги полягають у тому, що, по-перше, запити виконуються на локальному сервері і не вимагають передачі даних між серверами, по-друге, транзакції, хоча і вимагають поширення змін, що все ж виконуються для клієнтів швидше, оскільки це розповсюдження відбувається асинхронно по відношенню до транзакцій (клієнт не чекає закінчення обміну даними між серверами).
Інший важливий приклад використання синхронного тиражування - підтримка дзеркальної БД на резервному сервері, причому обидва сервера (основний і резервний) в цьому випадку можуть працювати паралельно.
Що стосується асинхронного тиражування, то воно застосовується тоді, коли немає можливості підтримувати постійний зв'язок між серверами, а тимчасовим неузгодженістю даних можна поступитися (знову-таки в припущенні, що стан БД в часі передбачувано). Якщо на Заході як приклад найчастіше призводять торгового агента, що роз'їжджає зі своїм ноутбуком і має можливість лише час від часу підключатися до мережі, то в російських умовах, на жаль, аналогічна ситуація досить типова. У тих регіонах нашої могутньої країни, де досі найнадійніший засіб зв'язку - це трактор, реалізація навіть передбачувано працюючого тиражування даних представляється нелегким завданням.
Втім, завдання це непроста і у випадку, коли зі зв'язком все гаразд. Серйозною проблемою при проектуванні системи є забезпечення її коректного функціонування в умовах можливих конфліктів з оновлення різних копій одних і тих же даних на різних серверах. Тут ми стикаємося з ситуацією, коли універсального рішення просто не існує, тому все, що може надати СУБД, - це кошти для реалізації різних варіантів рішень і рекомендації щодо їх використання.
Насамперед, необхідно вибрати загальну архітектуру системи, точніше, той її аспект, який відноситься до дисципліни доступу до даних. Можна, звичайно, ніякої дисципліни не встановлювати, але в цьому випадку завдання проектувальника стає найбільш складною, та й стовідсоткова гарантія коректності роботи не завжди досягається. Втім, давайте по порядку.
Найпростіший варіант архітектури, свідомо гарантує відсутність конфліктів, припускає, що для будь-якого тиражованого елемента даних серед усіх рівноправних зберігачів його копій вибирається один, так би мовити, самий рівноправний. Йому одному дозволяється цей елемент даних змінювати, всім іншим дозволяется тільки спостерігати за цим. Варіантів реалізації такої схеми може бути безліч: від найпростішого - звездообразного (філіям банку дозволяється бачити дані центрального відділення, але не змінювати їх) до набагато більш витончених зі складною мережею незмінних знімків.
Більш розвинений варіант архітектури, також дає гарантію відсутності конфліктів, дозволяє динамічну передачу права модифікації (в англомовних матеріалах зазвичай вживається термін, буквально перекладається як документообіг ) від сервера до сервера. Кожен елемент даних забезпечується спеціальним атрибутом дозволена запис raquo ;, і вводиться процедура передачі цього атрибута. Варіанти реалізації знову-таки можуть бути різними. Характерним прикладом може служити інформаційна система торгової фірми, де для кожного замовлення естафета послідовно передається від відділу продажів до управління складом і далі до відділу доставки. Аналогічна схема в принципі вирішує згадану вище проблему багаторазового закриття рахунку в банку.
Будь-які інші організації архітектури тиражування допускають виникнення конфліктів, отже, не залишається нічого іншого, як намагатися їх вирішувати. Від СУБД тут в першу чергу потрібно забезпечити автоматичне виявлення конфліктів і можливість повідомлення про них (напевно, зайве згадувати, що Oracle робить це), бо момент виникнення конфлікту залежить від механізму поширення змін. Але просто сповіщати про проблему і чекати її ручного дозволу (по всій видимості, крайнім, як завжди, виявиться адміністратор БД) - ймовірно, не найкращий вихід. По можливості потрібно прагнути вирішувати конфлікти автоматіческі.предлагает для цієї мети набір процедур вирішення конфліктів, які можна асоціювати з групами стовпців таблиці. Керуватися при цьому найкраще здоровим глуздом: скажімо, якщо мова йде про описових даних клієнта, в якості роздільної функції розумно вибрати ос...
