Сайт Игоря Гаршина Главная страница
Письмо автору сайта garchine@mail.ru
Опыт орадмина: 1. Инсталляция 2. Генерация 3. Миграция 4. ODBC 5. Администрация 6. Утилиты 7. Netware 8. RedHat 9. NT
Синхронизация: 1. Механизмы 2. Архитектуры 3а. Снапшоты 3б. Мастер-сайт 4. Сравнение ОС 5. RepMan Пр1. Файлы ORA Пр2. CONFIG.ORA Пр3. API Пр4. Словарь данных
Практика работы с Oracle - книга о репликации распределенной базы данных Oracle 8
Вся книга: Практика работы с Oracle: генерация, администрирование, репликация. И.К.Гаршин.
ISBN 5-901314-02-6 (рус.). УДК 004.42Oracle. ББК 32.973.26-018.2. Г21.

В 1999-2000 г. программисты «Нефтегазсистемы» разработали и внедрили в большинство ОАО МН «Транснефти Информационную систему паспортизации магистральных нефтепроводов «СКУТОР». Сначала он был создан на базе MS Access, затем переведен на Oracle 8 с поддкржкой асинхронной репликации с помощью программы Oracle Multimaster. В книге подробно описан авторский опыт перевода и внедрения этой базы данных.

Автор признателен руководителям и сотрудникам ЗАО «Нефтегазсистемы», начальникам и персоналу вычислительных центров региональных управлений ОАО «Транснефть», c чьей помощью был разработан и внедрен данный Oracle-проект.

Глава 2

Виды репликационных архитектур

 

В этой главе…

 

·        Единая БД с удаленным доступом на рабочих местах

·        Единая БД с обновляемыми копиями на других серверах

·        Распределенная БД

 

 

Единая БД с удаленным доступом на рабочих местах

            Это наиболее простой вид архитектуры для установки и администрирования. Работа осуществляется прямым доступом в удаленную БД через механизм Net8 и какой-либо протокол (в большинстве случаев TCP/IP). Поэтому необходимость в репликации отсутствует и проблем с несоответсвием данных на различных рабочих местах быть не может.

Главный недостаток – низкая производительность (в среднем) для используемых в России сетей. Смена экранных форм, информации на экране, реакция от управляющих элементов происходят крайне медленно, делая работу приложения практически малоприемлемой. Проблема решается, главным образом, техническим путем (смена маршрутизаторов и каналов связи), а также настройкой приоритетов на процессах в сети. Главный враг для работы с Oracle в этом режиме – Интернет и пересылки больших файлов по почте.

Тем не менее, этот режим работы применяется (либо применялся) в ряде Предприятий (без видимой разницы по сравнению с локальной сетью Объединения).

 

Единая БД с обновляемыми копиями на других серверах

            В этом виде архитектуры существует основная БД и базы данных, чьи репликационные таблицы (используемые в приложении, но не относящиеся к административным схемам SYS, SYSTEM и др.) регулярно обновляются как копии основной БД (снимки) или как копии друг друга под управлением процессов в основной БД (мастер-таблицы). При этом обновление может осуществляться как автоматически через указанный интервал времени, так и вручную (по мере необходимости) путем репликации изменений или полного пересоздания.

            Достоинство этой архитектуры – в ее высокой производительности и малой зависимости от наличия и производительности каналов связи. Репликацию можно настроить на ночное время или на время, когда отсутствует интенсивный почтовый обмен или работа в Интернете. Неисправности в сети или на серверах реплицируемых БД не мешают продолжать работу, а после восстановления связи все накопившиеся изменения (ссылки на которые копятся в журналах снимков или транзакционных таблицах) поступают в БД-копию.

Тем не менее, в случае длительной потери связи и интенсивных транзакциях накопившиеся изменения могут после восстановления связи либо «хлынуть» в БД-приемник  и «смыть» ее вместе с сервером (причем, такой же ущерб может принести БД-источнику обратная «волна» подтверждений), либо их выполнение «подвесит» систему на длительное и, возможно, неограниченное, время. В это время не исключены также зацикливания процессов («дедлоки», «смертельные объятия», «мертвые петли»). Кроме того, при возникновении сбоя или ошибки выполнения транзакции (что, несмотря на их «чистую» работу в БД-источнике, может быть связано с БД-приемником – например, изменение структуры таблиц или ее ограничений, удаление родительской записи…), ошибки могут нарастать каскадно, и их затем будет очень сложно анализировать. Особенно неустойчива для таких ситуаций ОС Novell Netware (см. Часть 2, Глава 4: ОС Novell Netware 5.0).

По указанной выше причине таблицы, регулярно участвующие в интенсивных транзакциях (десятки и сотни тысяч добавлений, изменений и удалений записей), необходимо, по мере возможностей, исключать из репликации и периодически обновлять в БД путем экспорта-импорта.

Недостатком данного вида архитектуры является необходимость и сложность ее регулярного администрирования (при ежедневных операциях с БД – ежедневного просмотра и устранения возможных ошибок), а также сложность установки (особенно это касается механизма Мультимастер) и настройки (в т.ч. привязывания клиентской части). Кроме того, какие-либо изменения свойств объектов механизма Мультимастер требуют перевода групп реплицируемых таблиц в состояние QUIESCED (молчащая), при которой запись в БД из клиентской части невозможна.

 

Распределенная БД

            Распределенная БД является более сложным видом вышеописанной архитектуры с обновляемыми БД. В этом виде вся БД разделена на секторы, каждый из которых расположен на удаленном сервере, и таблицы которого реплицируются на другие серверы (или, иначе: общая БД состоит из таблиц удаленных баз данных).

            Применение такой архитектуры может быть целесообразно, например, в следующих ситуациях:

·         Когда в главном офисе возникает необходимость объединения в общую БД  независимых прежде БД (или частей БД) филиалов.

·         Когда правка классификаторов осуществляется централизованно (при этом они находятся на сервере головной организации), а правка рабочих таблиц – в дочерних организациях (эти таблицы находятся на их серверах).

·         Когда БД состоит из общего ядра (которое целесообразно держать на одном сервере) и независимых частей (даже структурно различных таблиц), располагающихся на серверах эксплуатирующих эти БД предприятиях.

            В этом случае общая часть БД реплицируется на серверы филиалов (если были изменения – а они в ядре могут быть очень редкими), а таблицы, принадлежащие филиалам (или только их часть)  более-менее регулярно реплицируются на общий сервер. Вариантом является репликация этих таблиц (в т.ч. различающейся структуры) в отдельные схемы и затем из объединение в общее представление.

            Такая архитектура удобна возможностью существования разнородных БД и низкой загрузкой сети. Неудобство – в установке и развитии (детальное предоставление прав на таблицы и другие объекты различным пользователям и др.).


Игорь Гаршин, E-mail: garchine@mail.ru, URL: garshin.ru.

Страницы со статьей: Репликация Oracle | Все статьи
Я.Метрика: просмотры, визиты и хиты сегодня
На правах рекламы (см. условия):