танню за часом модифікацію, зміни кількості товару на складі має сенс підсумувати і т.д.
Крім значного набору стандартних функцій вирішення конфліктів можна використовувати і свої власні. Однак не все так просто. Далеко не всі функції здатні забезпечити стовідсоткову конвергенцію (неодмінну установку в одне і те ж значення) даних, особливо у випадку, коли в конфлікті бере участь більше двох серверів. Якщо застосовується нестандартна функція, для визначення її властивостей може знадобитися вельми тонкий аналіз (для стандартних він вже проведено). Як би там не було, в системі необхідно передбачати або вибір лише тих функцій, які забезпечують конвергенцію даних при прийнятій дисципліні доступу до них, або використовувати сповіщення адміністратора, коли функція не здатна впоратися з ситуацією самостійно.
Як резюме відзначимо ще раз, що тиражування дає надзвичайно широкі можливості, але ставитися до нього необхідно з великою обережністю і ретельно аналізувати всі аспекти можливої ??поведінки системи при її проектуванні.
2.6 Підтримка резервної копії БД
пропонує ще один механізм, що нагадує тиражування. Це призначена підвищення стійкості системи до збоїв підтримка резервної копії БД (standby database). Змішувати даний механізм з тиражуванням, мабуть, не варто, бо резервна БД недоступна для користувачів одночасно з основною. Зате відсутня додаткове навантаження на ядро ??основного сервера, пов'язана з поширенням змін. Справа в тому, що для підтримки відповідності резервної та основної баз даних використовуються журнальні файли змін, взагалі кажучи, призначені для відновлення БД після збоїв. Власне, резервна БД якраз і функціонує в режимі перманентного відновлення, зчитуючи журнальні файли основний БД, передані тим чи іншим способом на резервний сервер.
Вибір варіанта рішення задачі багато в чому залежить від складових гетерогенну систему СУБД.
Якщо це реляційні СУБД (MS SQL Server, Informix, Sybase, DB2, CA Ingres), можна використовувати так звані прозорі шлюзи для об'єднання їх з Oracle. Для користувача такого шлюзу повністю імітується функціональна середу сервера Oracle при доступі до даних, що зберігаються в чужих СУБД.
Для реалізації шлюзу використовується проміжний сервер Oracle (найчастіше він функціонує на тому ж комп'ютері, що і чужий сервер), за рахунок якого і досягається ефект ораклізаціі даних. Наприклад, якщо користувач викликає збережену процедуру на PL/SQL, то вона фактично виконується північчю-шлюзом (СУБД інших виробників з PL/SQL не працюють), а чужому сервера передаються тільки SQL-пропозиції, що містяться або сформовані у процедурі.
Складніше йде справа, якщо необхідно отримати доступ до даних, що зберігаються в нереляційних СУБД (ADABAS, VSAM та ін.). У такому випадку, як правило, неможливо формально однозначно відобразити ці дані в реляційні структури Oracle, тому підхід прозорих шлюзів не застосовують. Проте Oracle пропонує рішення для таких ситуацій у вигляді процедурних шлюзів. У них замість стандартного SQL для взаємодії з чужими даними надається бібліотека процедур, за допомогою яких розробник реалізує необхідне відображення даних.
Другий варіант вирішення проблеми в разі звернення до екзотичних системам зберігання даних - використання моніторів транзакцій.
Треба відзначити, що при роботі зі шлюзами дані інших СУБД органічно включаються в середу розподілених БД Oracle: реалізується повнофункціональна підтримка синхронного зв'язку між серверами без тиражування і навіть деякі варіанти тиражування даних.
2.7 Адміністрування розподілених систем на прикладі Oracle
Трохи поговоримо про ті засоби, які Oracle пропонує в допомогу адміністратору розподіленої інформаційної системи.
В принципі, така система може мати (і зазвичай має) більше одного адміністратора. Однак подібна організація має багато недоліків. Не кажучи вже про необхідність знайти потрібну кількість висококваліфікованих фахівців, їхня діяльність потрібно тісно координувати, наприклад, для забезпечення єдиної політики захисту даних. Зрозумілі незручності користувача, який повинен пам'ятати безліч паролів для доступу до різних серверів. Якщо ж паролі скрізь однакові, то збільшується ймовірність втрати їх секретності.
Корисність централізації хоча б частини адміністративних функцій очевидна. На ринку програмних продуктів існує досить багато коштів, спрямованих на вирішення саме цього завдання. Приміром, є системи, що реалізують централізовану ідентифікацію користувачів. Для деяких з них (Kerberos, Sesame) Oracle надає інтерфейси, що дозволяє ввести їх функціональність в розподілену БД на...
