ькох територіально віддалених вузлів, об'єднаним повільними і ненадійними каналами зв'язку, а число одночасно працюючих користувачів становить сотні і вище, то ймовірність того, що розподілена транзакція буде зафіксована в осяжному часовому інтервалі, стає надзвичайно малою. У таких умовах (характерних, до речі, для більшості вітчизняних організацій) обробка розподілених даних практично неможлива.
Технологія реплікації даних не вимагає синхронної фіксації змін, що є, безсумнівно, її сильною стороною. Насправді далеко не у всіх завданнях потрібно забезпечення ідентичності БД на різних вузлах у будь-який час. Досить підтримувати тотожність даних лише в певні критичні моменти часу (генерація добового, тижневого, місячного, річного звіту). Можна накопичувати зміни в даних у вигляді транзакцій в одному вузлі і періодично копіювати ці зміни на інші вузли.
У наявності переваги розподіленої технології. По-перше, дані завжди розташовані там, де вони обробляються - отже, швидкість доступу до них істотно збільшується. По-друге, передача тільки операцій, що змінюють дані (а не всіх операцій доступу до віддалених даних), та ще до того ж в асинхронному режимі дозволяє значно зменшити трафік. По-третє, з боку вихідної бази для приймаючих баз реплікатор виступає як процес, ініційований одним користувачем, в той час як в фізично розподіленої середовищі з кожним локальним сервером працюють всі користувачі розподіленої системи, конкуруючі за ресурси один з одним. Нарешті, по-четверте, ніякої тривалий збій зв'язку неспроможна порушити передачу змін. Справа в тім, що тиражування передбачає буферизацію потоку змін (транзакцій); тому після відновлення зв'язку передача поновлюється з тієї транзакції, на якої тиражування було перервано.
У той же час технологія реплікації даних не позбавлена ​​недоліків. Наприклад, неможливо повністю виключити конфлікти між двома версіями однієї і тієї ж записи. Такий конфлікт може виникнути, коли, внаслідок все тієї ж асинхронности, два користувача на різних вузлах виправлять одну і ту ж запис в той момент, поки зміни до даних з першої бази ще не були перенесені в другу. При проектуванні розподіленої середовища з використанням реплікації даних необхідно передбачити можливість виникнення конфліктних ситуацій та запрограмувати реплікатор на який-небудь варіант їх дозволу. У цьому сенсі застосування DR-технології - найбільш сильна загроза цілісності розподілених баз даних.
При використанні механізмів реплікації даних також гостро стоїть питання сумісності різнорідних локальних баз даних, що становлять вихідну БД. Найчастіше штатні засоби тиражування в складі даної конкретної БД дозволяють переносити дані в однорідну базу. Відповіддю стала поява продуктів, виконують тиражування між різнорідними базами даних. Тут розвиток технологій пішло по двох шляхах. Перший - створення засобів уніфікованого доступу до даних (стандарт ODBC - Open DataBase Connectivity). Очевидний недолік ODBC - недоступність для програми багатьох корисних механізмів кожної конкретної СУБД, оскільки вони можуть бути використані в більшості випадків тільки через розширення SQL в діалекті мови даної СУБД, але в стандарті ODBC ці розширення можуть не підтримуватись. Інший підхід - це створення шлюзів, що дозволяють додаткам оперувати над базами даних в іншому форматі так, як ніби це власні бази даних. Завдання шлюзу - організація доступу до успадкованим БД і служить для вирішення завдань узгодження форматів баз даних при переході до якої-небудь однієї СУБД. Шлюзи можна розглядати як засіб, що полегшує міграцію, але не як універсальний засіб межоперабельності в розподіленої системі. Взагалі, універсального рецепта вирішення завдання межоперабельності в цьому контексті не існує - всі визначається конкретною ситуацією, історією інформаційної системи і масою інших факторів.
Обробка розподілених запитів
Це властивість розподіленої БД трактується як можливість виконання операцій вибірки, сформульованих в рамках звичайного запиту на мові SQL. To є операцію вибірки з розподіленої бази даних можна сформулювати за допомогою тих же мовних коштів, що і операцію над локальною базою даних.
Обробка розподілених запитів - завдання, складніша, ніж обробка локальних запитів, і вона вимагає інтелектуального рішення за допомогою особливого компонента - Оптимізатора розподілених запитів. Припустимо, у нас є розподілена база даних, розміщена на двох вузлах. Нехай, таблиця detail зберігається на одному вузлі, а таблиця main - на іншому. Розмір першої таблиці - 2000 рядків, розмір другої - 200 рядків (безліч товарів поставляється невеликим числом постачальників). Припустимо, що виконується запит:
SELECT detail_name, main_name, main _address
FROM detail, main WHERE detail, main _number = main, main _number;
Тоді результуюча таблиця являє собою об'єднання таблиць
detail і main, викона...
