зпечення унікальності імен серверів ( сервісів в термінології Oracle ) в мережі, що досягається за допомогою ієрархічної організації доменів, подібної існуючої в Internet.
Оскільки замість справжніх імен об'єктів можна використовувати їх синоніми (також у свою чергу є об'єктами БД), то додаток клієнта може просто не знати, чи є даний об'єкт локальним для сервера, з яким встановлено зв'язок, чи ні. Звичайно, механізм каналів зв'язку і синонімів - лише зовнішня сторона тієї системи, яка дозволяє зробити структуру розподіленої БД Oracle абсолютно прозорою для додатків незалежно від розміщення даних і режиму взаємодії серверів. А таких варіантів організації Oracle пропонує безліч - як кажуть, на будь-який смак, хоча точніше було б сказати, для будь-якої ситуації.
2.2 Синхронна зв'язок без тиражування даних
Розглянемо спочатку найпростіший, з логічної точки зору, варіант, при якому будь-який об'єкт розподіленої БД зберігається тільки в одному екземплярі (Не тиражується). Це неминуче означає, що якщо яка-небудь транзакція (або запит) користувальницького додатка включає в себе звернення до віддаленим (розташованим не на тому сервері, з яким встановлено зв'язок) об'єктам, ця транзакція (запит) не може бути завершена, поки всі задіяні сервери НЕ обміняються необхідною інформацією (тобто вони взаємодіють в синхронному режимі).
Найбільш складні проблеми при цьому виникають при виконанні транзакцій, одночасно змінюють дані, що зберігаються на декількох серверах (такі транзакції називаються розподіленими на відміну від віддалених, які хоч і змінюють видалені дані, але тільки на одному сервері). Суть проблеми в тому, що при будь-яких обставин треба забезпечити, аби транзакція або завершилася, або відкотилася на всіх порушених нею серверах (в іншому випадку виникне неузгодженість даних у розподіленої БД). Ось чому при роботі розподіленої БД потрібно використовувати двофазну фіксацію транзакцій.
Схема алгоритму двофазної фіксації спрощено зводиться до того, що на першій фазі (підготовці до фіксації) сервер-ініціатор транзакції розсилає відповідний запит інших серверів (що знаходиться для нього в безпосередній видимості ) і чекає відповіді. Кожен з цих серверів може в разі необхідності повторити те ж дію рекурсивно. Якщо всі порушені транзакцією сервери інформують про готовність до її завершення у своїх відповідях, ініціюється друга фаза - власне завершення транзакції.
Описана схема дійсно сильно спрощена, оскільки основні складності при двофазної фіксації транзакцій починаються тоді, коли постає питання про забезпечення коректного і передбачуваного поведінки системи в разі виходу з ладу окремих серверів або тимчасових розривів ліній зв'язку. Найпростіше - перекласти вирішення даної проблеми на прикладного програміста (що фактично і робиться в ряді СУБД), але, навіть якщо це потрібно в обмеженому наборі ситуацій, говорити про прозорість структури розподіленої БД для додатків в такому випадку вже не можна. Реалізація двофазного завершення в Oracle така, що всі проблеми вирішуються автоматично, хоча можливість втручання адміністратора передбачена.
Як неважко здогадатися, організація розподіленої БД в даному варіанті вимагає наявності надійних, постійно доступних і досить швидких ліній зв'язку між серверами.
2.3 Тиражування даних
Припустимо, що банк крім центрального офісу має ряд філій, пов'язаних з ним виділеними лініями зв'язку, що не володіють, однак, достатньою пропускною здатністю для підключення робочих місць у філіях до центральної БД в режимі клієнтів. Напрошується рішення з використанням розподіленої БД, організованої так, щоб дані, найчастіше вимагаються у філії, фізично розташовувалися на його локальному сервері. При цьому виникає питання: як забезпечити можливість доступу з філій до центральної БД і з центрального офісу до даних у філіях?
Якщо організувати розподілене зберігання?? даних, як в попередньому варіанті, будь такий запит (або транзакція) може виконуватися з великою затримкою. Як вихід можна запропонувати зберігати об'єкти даних в розподіленої БД не в єдиному екземплярі, а тиражувати їх на всіх серверах, де до них може знадобитися швидкий доступ. Природно при цьому виникає необхідність якимось чином забезпечити синхронізацію різних копій одних і тих же даних, інакше розподілена БД втратить свою цілісність і перетвориться на хаос.
2.4 Промислові системи
Методика забезпечення цілісності розподіленої БД - лише один з аспектів, що визначають згадане відмінність. Якщо спробувати сформулювати основний його критерій в загальному вигляді, то, мабуть, можна запропонувати наступне форму...
