Глава 3

Создание репликации БД по архитектуре с обновляемыми копиями

 

В этой главе…

 

·        Некорректируемые (read only) снимки

·        Корректируемые (updatable) снимки

·        Мультимастер

 

 

Некорректируемые (READ ONLY) снимки

Создание снимков

Механизм репликации с некорректируемыми снимками создается по следующей схеме:

1. На БД-приемнике следует удалить все объекты:

1)   удалить таблицы (каскадно) и последовательности (DTabSeq.sql)

2)   удалить функции (DFunc.sql) и процедуры

2.      На БД-приемнике следует создать dblink в PLIPEKN на PLIPEKN

3.      Создать и дать права REPADMIN (роли CONNECT, RESOURCE, DBA)

4.      Создать на БД-источнике журналы снимков (MLOG$) на каждую реплицируемую таблицу   (CLog.sql)

5.      Войти в БД Oracle как REPADMIN и создать refresh-группы.

6.      Создать таблицы-журналы EDITIONS и др. и импортировать нереплицируемые таблицы BOOK, FEATURES; создать последовательности, функции и триггеры на них; проверить включение ограничений (или добавить ограничения, если импорт    проводился до создания снимков)

7.      Дать права для ролей:

·         PLIREAD  (GRead.sql)  - чтение всех снимков СИСТЕМЫ

12.  Дать пользователям Предприятия права на роль PLIREAD.

Решение проблем при создании снимков

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

1.      Предварительное создание снимка на пустую таблицу:

·         Создать в основной БД копию большой таблицы в другой схеме или под другим именем, но без ограничений (create table TABLE2 as select * from TABLE1), отключить ограничения в таблице-источнике и удалить из нее все записи;

·         Создать в БД-копии снимок на пустую таблицу;

·         Добавить в пустую таблицу ранее удаленные записи (insert into TABLE1 select * from TABLE2), восстановить ограничения и удалить копию таблицы;

·         Обновить снимок.

2.      Предварительное создание снимка на таблицу в своей БД:

·         Экспортировать большую таблицу из основной БД

·         Импортировать таблицу в БД-копию

·         Изменить в файле TNSNAMES.ORA TCP/IP-адрес основной БД на адрес БД-копии

·         Создать журнал снимка

·         Создать снимок

·         Изменить в файле TNSNAMES.ORA TCP/IP-адрес БД-копии на адрес основной БД

Администрирование снимков

            Если регенерация снимков осуществляется при потере связи (или если снимки были созданы с ошибками), то неудачные попытки постоянно возобновляются через удвоенный интервал, а в протокол %RDBMS%\TRACE\ пишутся сообщения об ошибках. В этом случае сервер будет перегружен (ORACLE80 может занимать 95-98% ресурсов ЦПУ), а файл трассировки разрастись до многих Мбайт.

            Рекомендуется регулярно просматривать процент загрузки Oracle ЦПУ и файлы трассировки. Особенно это необходимо делать в первое время, после создания снимков и при неполадках на серверах или в сети между ними.

 

Корректируемые (UPDATABLE) снимки

Создание snapshot-сайта

Механизм репликации с корректируемыми снимками создается по следующей схеме:

1. На БД-приемнике следует удалить все объекты:

3)      удалить таблицы (каскадно) и последовательности (DTabSeq.sql)

4)      удалить функции (DFunc.sql) и процедуры

2.      На БД-приемнике следует создать dblink в PLIPEKN на PLIPEKN

3.      Создать snapshot-сайт на БД-приемнике и мастер-сайт на БД-источнике: создать,   зарегистрировать и дать права REPADMIN (CSnS.sql)

4.      Создать на БД-источнике журналы снимков (MLOG$) на каждую реплицируемую таблицу   (CLog.sql)

5.      Войти в БД Oracle как REPADMIN и создать refresh-группы и snapshot-группы;   включить в snapshot-группы таблицы; создать последовательности для генерации ключей на снимки (CUpSn.sql), установив для DBMS_REFRESH.MAKE нужное значение ROLLBACK_SEG (например, R10) и исправив список полей в create snapshot для таблиц с измененной структурой (COUNTRY из 0-вой мастер-группы, WORKS из 3-ей мастер-группы) - иначе впоследствие триггеры на SNAP$-ы не создадутся

6.      Поправить последовательности после генерации снимков (CorSeq7.sql)

7.      Создать функции выборки значений из последовательностей и триггеры на снимки (CTrgSnp.sql)

8.      Добавить первичные ключи

9.      Добавить ссылки

10.  Создать таблицы-журналы EDITIONS и др. и импортировать нереплицируемые таблицы BOOK, FEATURES; создать последовательности, функции и триггеры на них; проверить включение ограничений (или добавить ограничения, если импорт    проводился до создания снимков)

11.  Дать права для ролей:

·         PLIREAD  (GRead.sql)  - чтение всех снимков СИСТЕМЫ;

·         PLIWRITE (GWrite.sql) - правка всех снимков СИСТЕМЫ;

·         PLIWRUSR (GWrUsr.sql) - правка только рабочих снимков СИСТЕМЫ;

·         PLIWRADM (GWrAdm.sql) - правка только снимков кодификаторов СИСТЕМЫ.

12.  Дать пользователям Предприятия права только на роли PLIREAD и PLIWRUSR, чем частично разрешатся конфликты на удаление

 

Мультимастер

Создание механизма с распространением репликации из основной БД

Механизм репликации Мультимастер создается по нижеприведенным схемам.

Подготовительные работы

1.      Выполнить экспорт основной схемы (ExpUsUl.bat) на случай удаления таблиц по невнимательности при выгрузке их из мастер-группы !

2.      Создать во всех БД (обычно уже создается при генерации БД - в CUser.sql):

1)      пользователя REPADMIN (администратор репликаций)

2)      пользователя PLIPEKN (основной пользователь)

3)      dblink в схеме REPADMIN на пользователя REPADMIN

3.      Удалить в основной БД MLOG$ (DLog.sql), если есть

4.      Выправить структуру БД:

·         Проверить, нет ли в таблицах одновременно primery key и unique key на одно поле или группу полей (ShwPkUk.sql). Удалить в таблицах unique key по полям, на которые имеется primary key. Если этого не сделать, то при добавлении в мастер-группу мастер-БД на деф-сайте таблицы будут иметь статус Error и административные запросы на их добавление и репликационную поддержку не смогут выполниться.

·         Также проверить, есть ли во всех таблицах primery key и включены ли они.

·         Проверить, не присутствуют ли в таблицах ссылки на саму себя (как, например, в таблице PART: CLAST, CNEXT - идентификаторы предыдущего и следующего участка, ссылающееся раньше на ключевое поле ID этой таблицы).

·         Если для разрешения конфликтов на изменение применяется метод Latest Timestamp (по последнему времени), то во всех таблицах должно быть соответствующее поле (CORDATE) с типом данных date (не было в COUNTRY - см. Country.sql).

·         Нужно не только наличие такого поля, но и включенный триггер, который бы его обновлял. Например, автору пришлось потратить ночь, чтобы найти причину возвращаемой встречными транзакциями ошибки, а просто для таблицы DFEA отсутствовал триггер.

·         Проверьте на всякий случай все:

·         Есть ли на включенных ссылках (foreign key) родительские таблицы с       включенными primary key

·         Есть ли для каждой таблицы оба триггера (_COR и _LOG), а также функция _ID и последовательность _SEQ

·         Обновите структуру БД.

5.      Проверьте, что тела репликационных модулей не нарушены (PliInvPb.sql). В противном случае перегенерите их (RDBMS80\ADMIN\CatRep8m.sql). А если не поможет - запустите генерацию всего Словаря БД: СATALOG.SQL, CATPROC.SQL, CATHS.SQL, PUPBLD.SQL.

6.      Подготовка скриптов:

1)      Таблицы необходимо разделить на группы, в которой бы они объединялись по приоритетам с тем, чтобы формировать добавления таблиц в мастер-группы от родительских к дочерним (иначе возникает ошибка). При этом в каждой мастер-группе ни одна таблица не ссылается на другую. Другой метод - деление по «объектам» с ссылками внутри мастер-группы - не испытывался. В мастер-группы не следует включать очень большие таблицы (более 100000 записей), которые  участвуют в интенсивных транзакциях. Если в мастер-группе находится много больших таблиц (более 10000 записей - обычно это таблицы из средних мастер-групп, хотя могут быть и большие справочники), то мастер-группу можно разделить на несколько мастер-групп для облегчения их распространения на дест-сайт после добавления к мастер-группе мастер-БД. По данной СИСТЕМЕ (на примере одного Объединения) имелась следующая статистика:

·         таблица BOOK              - 550 000 записей;

·         таблица FEATURES       - 350 000 записей;

·         таблица KMCOL               -   80 000 записей;

·         таблица PROFILES   -   80 000 записей;

·         таблица WORKS               -   20 000 записей;

·         таблица PAREQUIP       -   10 000 записей;

·         остальные таблицы         -   40 000 записей.

Первые 2 таблицы занимают 77% объема и не включены в репликацию.

Другие большие таблицы составляют 17% объема и принадлежат к одной мастер-группе, которую можно разделить (она большая также по кол-ву таблиц).

Остальные таблицы занимают лишь 6% всего объема.

Можно также привести следующую статистику по общему кол-ву записей для каждой мастер-группы (на примере одного Объединения):

·   PLIPEKN0    –     4640 записей по 57 таблицам;

·   PLIPEKN1    –       663 записей по 30 таблицам;

·   PLIPEKN2    –     1571 записей по 25 таблицам;

·   PLIPEKN3    – 198008 записей по 39 таблицам;

·   PLIPEKN4    –   11390 записей по 42 таблицам;

·   PLIPEKN5    –   25304 записей по 29 таблицам;

·   PLIPEKN6    –     3936 записей по   8 таблицам;

·   PLIPEKN7    –           1 запись   по   1 таблице.

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

2)      Исключить или закомментировать в скриптах на добавление таблиц (CMg__.sql)      таблицы, в которых бывают транзакции сразу по большому кол-ву записей (несколько 100000 записей и более). Эти таблицы должны периодически импортироваться (неисключена также репликация вручную в Oracle Replication Manager).

 

Работа с API и Oracle Replication Manager

1.      Создать основной (definition) мастер-сайт (CMs.sql) с регистрацией Распространителя и созданием sheduled purge и sheduled link (перед  этим проверить и перекомпилировать Invalid Package Bodies в SYS)

2.      Создать другие (destination) мастер-сайты (CMsANTA.sql, …).

3.      Последовательно выполнить следующие шаги:

1)      Создать мастер-группу на основном мастер-сайте с выполнением добавления таблиц (CMg__.sql). Дождаться окончания добавления таблиц. Если возникли ошибки, то выгрузите таблицу из группы (без удаления ее из БД - для чего нажать Нет), исправьте ошибку, загрузите вновь (отключив опции Generate и Resume), затем сделайте Support Generation. Добавьте метод разрешения конфликтов и опять сделайте Support Generation. Декларируется, что для этого можно также запустить DDL-операцию внутри Oracle Replication Manager (Alter Replication Object), только при этом всегда выдается ошибка.

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

3)      Добавить для каждой таблицы метод разрешения конфликтов на изменение      (UpdRes.sql). Обязательно сделать COMMIT (при этом все таблицы изменят статус на NeedsGen). Сделать Support Generate на все таблицы. Дождаться окончания выполнения административных запросов.

4)      Активизировать (Resume) деф-сайт. Дождаться окончания выполнения административных запросов (при этом на деф-сайте и затем на дест-сайте статус группы становится NORMAL).

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

4.      Приступить к следующей группе. После создания и распространения на 1 дест-сайт всех групп - начать для каждой группы последовательно добавлять новую мастер-базу (в режиме QUIESCED).

 

Заключительные работы

1.    После реплицирования данных и генерации репликационной поддержки настоятельно рекомендуется проверить правильность созданных объектов на деф-сайте и дест-сайтах. Можно это осуществить визуально: проверить статус созданных объектов на дест-сайте (не должно быть Error),  статус объектов на деф-сайте (не должно быть NeedsGen), статус модулей ТАБЛИЦА$RP и ТАБЛИЦА$RR в БД (не должно быть Invalid) и перегенерить репликационную поддержку, либо удалить-и-добавить объект. Можно, на всякий случай, перегенерить репликационную поддержку для объектов, административные запросы на которые имели статус ERROR. Очень удобен и стандартный механизм проверки «валидности». Для этого откройте окно свойств мастер-группы деф-сайта (правой кнопкой), выберите вкладку Validation (последняя), установите все опции (Generation, Validity, Existence, Sheduling) и нажмите кл. Validate. Если имеются ошибки по установленным опциям, они будут показаны в окне. При отсутсствии указанных ошибок будет выдано сообщение <No errors found>.

 

ПРИМЕЧАНИЕ 1.

Операцию Validate не рекомендуется проводить при выполняющихся административных запросах, т.к. это может привести к зависанию.

 

ПРИМЕЧАНИЕ 2.

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

 

ПРИМЕЧАНИЕ 3.

Для проверки наличия Error-объектов на каждом сайте следует выполнить запрос:

 

select GNAME, ONAME from ALL_REPOBJECT

where STATUS=’ERROR’ and TYPE=’TABLE’ order by GNAME;

 

Также можно сделать сверку кол-ва модулей (см. Часть 2, Глава 3: Анализ объектов в мастер-группе):

 

select GNAME, count(*) from ALL_REPOBJECT

where TYPE=’TABLE’ group by GNAME order by GNAME;

 

 

 

2.      После начального реплицирования данных на дест-сайт, а также некоторое время в период эксплуатации рекомендуется осуществлять проверку общего кол-ва записей на деф-сайте и дест-сайтах (RowCount.sql, RowCntMg.sql, RwCntMg0.sql, …, RwCntMg7.sql – см. Часть 2, Глава 3: Анализ объектов в мастер-группе). Если в БД дест-сайта после начальной репликации обнаружены недосозданные таблицы (с меньшим кол-вом записей), то их необходимо пересоздать одним из следующих способов:

·         Удалить таблицу из мастер-группы деф-сайта без опции Drop (т.е., не удаляя таблицу в БД физически), дождаться окончания выполнения административных запросов, включить таблицу в мастер-группу деф-сайта с опцией Copy Rows, но без активизации репликационной поддержки (и тем более без Resume), дождаться окончания выполнения административных запросов, запустить перегенерацию репликационной поддержки.

·         Удалить таблицу из БД дест-сайта физически и создать заново (либо с помощью create … as select …, - но для этого нужно сперва создать dblink, и это очень долгая операция для больших таблиц; либо импортировать ее из дампа, полученного из БД деф-сайта, - что намного быстрее), предварительно отключив связи с дочерними таблицами, а после созания включив их. Затем просто перегенерить репликационную поддержку, либо (если все равно остались объекты со статусом Error) выполнить предыдущий способ (только без опции Copy Rows).

 

ПРИМЕЧАНИЕ 1.

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

 

ПРИМЕЧАНИЕ 2.

Для отключения связей с таблицами-потомками, нужно их найти из представления USER_CONSTRAINTS (см. ShwRef.sql), затем выполнить команду alter table …, например (для таблицы WORKS):

 

select

  substr(TABLE_NAME,1,12) TN,

  substr(CONSTRAINT_NAME,1,17) CN,

  CONSTRAINT_TYPE CT,

  substr(R_CONSTRAINT_NAME,1,17) RCN,

  DELETE_RULE DR,

  STATUS

from

  USER_CONSTRAINTS

where

  R_CONSTRAINT_NAME='WORKS_PK'

order by

  TABLE_NAME;

 

alter table CDOCWORKS disable constraint CDOCWORKS_FK1;

alter table MEMWORKS  disable constraint MEMWORKS_FK1;

alter table PARWORKS   disable constraint PRWORKS_FK1;

 

 

3.      Перевести мастер-группы в режим NORMAL.

4.      Сгенерить на дест-сайтах недостающие объекты:

1)  последовательности (CSeq.sql);

2)  таблицы-журналы EDITIONS – см. CAlEd.sql или AdObj.sql;

3)  триггеры и функции (CTrigFunc.sql);

4)  индексы (CInd.sql).

5.      Поправить последовательности на каждом дест-сайте (CorSeq7B.sql…) для разрешения конфликтов на вставку

6.      Включить нереплицируемые объекты (FEATURES, BOOK и, возможно, KMCOL, PROFILES, WORKS, PAREQUIP):

1)  Экспорт из деф-сайта (ExpBigTb.bat)

2)  Отключение ограничений и триггеров на эти т-цы (BigTbOff.sql)

3)  Удаление таблиц (DBigTab.sql)

4)  Импорт в дест-сайт (ImpBigTb.bat)

5)  Правка последовательностей (CrSqBgTb.sql или BigSqSet.sql)

6)  Включение ограничений и триггеров (BigTbOn.sql)

7)  Права на таблицы для ролей PLIREAD, PLIWRITE

7.      Если импорт нереплицируемых объектов выполнялся до репликации других таблиц, то необходимо затем добавить ограничения, т.к. из-за отсутствия родительских таблиц они не были созданы.

8.      Решедулинг транзакций

9.      Дать права для ролей:

·         PLIREAD  (GRead.sql)  - чтение всех таблиц СИСТЕМЫ;

·         PLIWRITE (GWrite.sql) - правка всех таблиц СИСТЕМЫ;

·         PLIWRUSR (GWrUsr.sql) - правка только рабочих таблиц СИСТЕМЫ;

·         PLIWRADM (GWrAdm.sql) - правка только кодификаторов СИСТЕМЫ.

10.  Дать пользователям Предприятия права только на роли PLIREAD и PLIWRUSR, чем частично разрешатся конфликты на удаление

 

Установка на предварительно собранных жестких дисках

            Собрать со всех Предприятий диски, установить на них Oracle-сервер, БД и мастер-сайты, импортировать нереплицируемые объекты, отправить обратно, и после их установки в Предприятиях исправить TNS-адреса – решение логичное и рациональное. Но оно возможно только при следующих условиях:

·         Собранные диски устанавливаются на серверах сразу все и на этапе внедрения все БД должны быть запущены;

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

Создание сразу всех сайтов, имея все диски, но меньшее кол-во серверов, невозможно по следующим причинам:

·         При удалении диска с готовым сайтом и установкой другого новый сайт в группу добавить нельзя, т.к. возникает ошибка, что не найден имеющийся на группе старый сайт.

·         Чтобы в этой ситуации добавить новый сайт, приходится удалить старый сайт из группы. Но после установки предыдущего диска этот сайт в группу уже добавить нельзя, т.к. возникает ошибка, что данная группа в этом сайте уже существует. Т.о. приходится удалять и пересоздавать всю группу.

·         Если старый сайт не удалять из группы, а соответствующую задачу PUSH сделать Broken, то новый сайт создать можно, но после попытки сделать Resume опять возникает ошибка, что не найден старый сайт.

 

РЕКОМЕНДАЦИЯ.

Наиболее оптимальным из реальных решений является предварительный сбор дисков в кол-ве имеющихся серверов, установка на дисках Oracle, БД и мастер-сайтов, далее установка этих дисков на «родные» сервера, запуск этих БД, и только затем перевод мастер-групп на деф-сайте в состояние NORMAL. Если необходимо установить репликацию сразу на всех серверах, то лучше не переводить в NORMAL, а обработать следующую партию дисков и т.д., пока не будут созданы все сайты.

 

Создание механизма с предварительным импортом дампа в БД-копиях

1.      Создание мастер-сайтов и связей

1)      Запустите Setup Wizard для создания основного (definition) мастер-сайта и на запросы введите следующее:

·         Администратор/Распространитель/Получатель – REPADMIN, пароль …

·         Владелец объектов репликации - владелец таблиц СИСТЕМЫ (PLIPEKN, пароль …)

·         Остальное - по умолчанию

·         Установите для параметра RollBack Segment значение R10, далее с помощью Oracle Storage Manager увеличьте Optimal Size до 30 M, а также в файл INITsid.ORA добавьте параметр rollback_segments = (R01, R02, R03, R04, R05, R06, R07, R08, R09, R10)

2)      Создайте dblink в схеме REPADMIN в БД деф-сайта

3)      Запустите Setup Wizard для создания дополнительного (destination) мастер-сайта и на запросы введите следующее:

·         Администратор/Распространитель/Получатель – REPADMIN, пароль …

·         Владелец объектов репликации - владелец таблиц СИСТЕМЫ (PLIPEKN, пароль …)

·         Остальное - по умолчанию

·         Установите для параметра RollBack Segment значение R10, далее с помощью Oracle Storage Manager увеличьте Optimal Size до 30 M, а также в файл INITsid.ORA добавьте параметр ROLLBACK_SEGMENTS = (R01, R02, R03, R04, R05, R06, R07, R08, R09, R10)

4)      Создайте dblink в схеме REPADMIN в БД дест-сайта

2.      Перенос данных

1)      Экспорт основной схемы (PLIPEKN) (с предварительным экспортом и очисткой      таблицы-журнала EDITIONS, а также удалением мастер-групп, если были) - ExpUsPek.ncf с сервера (желательно уточнить этот файл, чтобы не экспортировались снапшот-логи)

2)      Импорт дампа в БД Предприятия (с предварительной чисткой схемы, если там уже есть      объекты скриптами DTabSeq.sql и DFunc.sql, и с помощью Schema Mansger - лишние объекты (временные таблицы, остатки старых MLOG$_ и т.д.)) - ImpUsBer.ncf с сервера

3)      Исправление ошибок импорта (замена уникальных ключей на первичные или      отключение первых и создание вторых)

4)      Удаление снапшот-логов и процедуры CorSeq6U (или CorSeq6)

5)      Исправить параметры nCode и nCodeAO в CorSeq7B.sql и запустить процедуру (execute CORSEQ7)

6)      Назначить права на роли PLIREAD и PLIWRITE (GRead.sql, GWrite.sql)

3.      Создание и активизация мастер-групп

1)      Подсоединиться к БД Объединения как REPADMIN и запустить CMGr__.sql

2)      Настроить интервалы JOB'ов (задач): для групп - 5 мин, для связи (Sheduled Link) - 10 мин, для очистки (Sheduled Purge) оставить 1 день

3)      Если группы молчат (состояние QUIESCIED) - перевести их в состояние NORMAL кн. Resume на вкладке Operation (если не переводятся - нажать кн. Apply Now)

 

Разрешение конфликтов

Виды конфликтов и стандартные методы их разрешения

            Мультимастер репликация включает возможности для обнаружения и разрешения трех типов конфликтов: конфликтов изменения, конфликтов уникальности и конфликтов удаления. Ниже приведены их краткое описание и способы разрешения:

1.      Конфликты изменения (Update Conflicts).

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

·         Конфликты изменения полностью избежать нельзя, но их можно минимизировать, насколько возможно. Существуют следующие стандартные методы разрешения конфликтов изменения (подробности см. в [8] гл.5: Conflict Resolution):

·         Additive and average (добавление разницы и замена на среднее значение).

·         Minimum and maximum (замена на минимальное или максимальное значение).

·         Earliest and latest timestamp (приоритет первого или последнего изменения).

·         Overwrite and discard (перезапись или отмена записи).

·         Priority groups and site priority (приоритет группы или приоритет сайта).

2.      Конфликты уникальности (Uniqueness Conflicts).

·         Конфликт уникальности возникает когда репликация записи пытается нарушить сущностную целостность (ограничение  primary key или unique). Например, посмотрите, что случиться, когда каждая из двух транзакций, происходящих из двух различных сайтов, добавляет запись в таблицу-реплику с одинаковым значением первичного ключа. В этом случае, репликация транзакций породит конфликт уникальности.

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

3.      Конфликты удаления (Delete Conflicts).

·         Конфликт удаления возникает когда две транзакции происходят из различных сайтов и одна транзакция удаляет запись, которую другая транзакция изменяет или удаляет.

·         Нужно всегда избегать конфликты удаления. Для этого предлагается в клиентской части при удалении записи не удалять ее в Oracle физически, а помечать как удаленную. Т.о. конфликты удаления преобразовываются в конфликты изменения и разрешаются одним из стандартных способов (или способом, запрограммированным разработчиком).

 

Вариант практического разрешения конфликтов

            В описываемой СИСТЕМЕ использовались следующие способы для разрешения конфликтов:

1.       Конфликты изменения. Используется стандартный метод Latest Timestamp (приоритет по последнему времени изменения). Поле, по которому определяется время изменения – например, CORDATE. Данные заносятся в это поле перед добавлением или изменением записи триггером ТАБЛИЦА_COR.

2.       Конфликты уникальности.  Минимизируются с помощью стандартного метода: генерация первичных ключей таблиц для каждого сайта происходит в разных диапазонах.

3.       Конфликты удаления. Могут разрешаться различными методами:

·         Административными. Изменения в справочники вносит только администратор СИСТЕМЫ в Объединении по просьбе других пользователей Предприятия. Либо такие изменения разрешается вносить на местах, но в различное время (например, для каждого Предприятия можно определить свои часы для изменения справочников либо для ввода данных  вообще). Конфликтов в других таблицах быть, в принципе, не должно, поскольку в клиентской части СИСТЕМЫ записи этих таблиц для каждого Предприятия фильтруются и защищены от исправлений другими пользователями (если, конечно, они специально не выберут для работы другое Предприятие).

·         Эмулированием разнесения ввода по времени. Можно для каждого сайта либо для отдельного пользователя внести изменение в триггеры ТАБЛИЦА_COR так, чтобы в поле CORDATE заносились сдвинутые по времени значения, имитируя разнесение сайтов или пользователей по приоритетам. Очевидно, при этом также нужно увеличить интервалы срабатывания задач (job'ов). Метод «Latest Timestamp», как из этого видно, является более гибким и может позволить разрешать не только конфликты изменения, но и конфликты удаления.

·         Разграничением прав в Oracle на рабочие таблицы и справочники. Создаются роли PLIWRITEADM на изменение справочников и PLIWRITEUSER на изменение рабочих таблиц. Роль PLIWRITEADM дается ограниченному кругу лиц, которые согласовывают между собой время правок справочников (или роль дается одному администратору СИСТЕМЫ в Объединении).

 

 Удаление механизма Мультимастер репликации

·         Вариант 1.

1.      Удалите объекты из мастер-групп.

2.      Удалите мастер-группы (DMGr.sql). После удаления мастер-групп удаляются также пакеты $RP (удаленные процедуры при транзакциях) и $RR (удаленные процедуры разрешения конфликтов).

·         Вариант 2.

1.      Удалите мастер-группы вместе с объектами (DMGr__.sql – со всех сайтов, DMGr_.sql – с одного сайта).

 

ВНИМАНИЕ !

Не в коем случае не удаляйте перед этим самих таблиц, таблиц SNAP$_ и модулей $RP и $RR на них.

 

 

Поддержка механизма Мультимастер репликации

Общие рекомендации

·         Не забывайте, что все DBMS-процедуры для Мультмастера необходимо выполнять, присоединившись к Oracle пользователем REPADMIN.

·         Чтобы узнать какая DBMS-процедура выполняет диалоговую операцию в ORM, перед ее началом нужно (как во многих утилитах OEM) нажать кн. Start Recording (с зеленым шариком), а по окончании – на соседнюю кн. Stop Recording (красный кубик).

·         Перед большинством работ по настройке механизма Мультимастер необходимо переводить мастер-группу в состояние QUIESCED (молчащая), т.е. делать Suspend (приостановку) – см. SAct.sql:

 

 

Ниже перечислены работы, требующие состояние QUIESCED:

·         Добавление объекта в мастер-группу.

·         Изменение свойств объекта в мастер-группе.

·         Перегенерация репликационной поддержки объекта.

·         Добавление метода разрешения конфликтов для таблицы.

·         Добавление к мастер-группе дест-сайта (master site destination) или, по-другому, мастер-БД (master database).

·         Изменение метода распространения между сайтами.

 

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

·         Настоятельно рекомендуется делать все «мелкими шагами»:

·         Не запускать одновременно процессов по разным группам и разным сайтам ! Если Вы решили ускорить работу, добавляя для каждой мастер-группы деф-сайта по 2 дест-сайта и видя в диалоге в ORM, что все мастер-группы успешно обработаны, то, посмотрев в административные запросы каждой группы каждого сайта, Вы увидите их длинный список без видимости его сокращения во времени. Вы обязательно получите (хотя бы по нескольким адмюзапросам) замкнутые петли и «ускорение» оборачивается значительной потерей времени (пол-дня для локальной сети, несколько дней для удаленных сайтов), т.к. необходимо не только грамотно выйти из этого состояния, но и начать все снова, предварительно ликвидировав последствия неполного выполнения административных запросов (такой «гордиев узел» часто приходится не распутывать, а разрубать: «убить» все сессии REPADMIN и/или перестартовать БД в режиме ABORT, удалить мастер-группы с дест-сайтов и «оборвать» дест-сайты с мастер-групп деф-сайта, что, впрочем, тоже может не помочь, поскольку сессии REPADMIN очень «живучи»).

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

·         Не делать Suspend или Resume, пока идут другие административные запросы.

·         Отвечать отрицательно (No) на вопрос Would you like to resume replication activity ? после завершения сообщений о происходящей перегенерации репликационной поддержки для каждого объекта. На самом деле административные запросы еще не выполнены и надо дождаться их окончания, прежде чем переводить мастер-группу в состояние NORMAL.

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

·         По окончании включения объекта в мастер-группу необходимо чтобы его состояние было правильным (в разделе Generate Objects значение в колонке Status должно быть Valid  (Error – если объект включен в мастер-группу некорректно или еще включается).

ВНИМАНИЕ !

При ускорении выполнения административных запросов (Apply all requests now) не нажмите на соседний пункт, по которому удаляются все административные запросы (Purge all requests), а при удалении объекта из мастер-группы на вопрос Drop the … also ? подтвердите, что сам объект из БД удалять не надо (по умолчанию Нет), и не нажмите на соседнюю Да (!!!). Ввиду особой опсности последней операции рекомендуется предварительно делать экспорт основной схемы либо отдельных объектов деф-сайта.

·         Во время внедрения механизма ММ не исключены ситуации, когда нужно срочно остановить сервер (БД запустилась неудачно, нельзя подсоединиться обычным пользователем, нужно удалить большой пакет транзакций и т.д.) и не помогает команда SHUTDOWN IMMEDIATE. В этом случае воспользуйтесь командой SHUTDOWN ABORT (предварительно «убив» зависшие сессии с помощью Oracle Instance Manager).

·         Если возникают ошибки, причина которых неясна, просмотрите трассировочные файлы в каталоге %RDBMS80%\TRACE.

·         Если во время работы в ORM произошел останов БД, пропала связь с сервером или были сделаны некорректные действия, в результате которых в ORM возникли сообщения об ошибках, то рекомендуется выйти из ORM и запустить его снова.

 

Работа с административными запросами

 Ускорение выполнения

            Для ускорения прохождения административных запросов (что особенно важно, если они относятся ко всем таблицам мастер-группы – например, при создании мастер-группы в новом дест-сайте), рекомендуется открыть 2 окна Oracle Replication Manager. В одном нужно открыть раздел Административных запросов деф-сайта, в другом – дест-сайта. Перейдите в окно, где у большинства административных запросов есть статус Ready и через контекстное меню (по правой кн.мыши) укажите пункт Apply all requests. Перейдите во второе окно (у этого сайта у большинства административных запросов будет при этом статус Await) и время от времени обновляйте экран. Вы увидите, что список ждущих административных запросов будет постепенно «таять». Если в этом окне есть немного административных запросов со статусом Ready, то можно их «проталкивать» таким же способом. В этом окне Вы также можете просматривать оставшееся кол-во административных запросов другого сайта (в первом окне это не удастся, поскольку там будет «висеть» сообщение о выполнении всех административных запросов).

            Если во втором окне много административных запросов со статусом Ready, то можно тоже указать Apply all requests и открыть третье окно для попеременного просмотра оставшегося кол-ва административных запросов в обоих сайтах, поскольку в этом окне тоже «зависнет» сообщение о выполнении всех административных запросов.

Будьте крайне осторожны и не укажите пункт чуть выше, который удаляет все административные запросы – Purge all requests, - в этом случае Вам придется повторять свою операцию, предварительно дождавшись удаления административных запросов в другом сайте, или также их удалив самим. При этом теряется минут 40 Вашего времени.

Административные запросы по таблицам: добавление в мастер-группу дест-сайта (ADD_MASTER_DATABASE),  объекта (CREATE_MASTER_REPOBJECT), генерация репликационной поддержки (GENERATE_REPLICATION_SUPPORT), - выполняются в 2 фазы: сначала у административных запросов статус READY (выполняется) в дест-сайте и AWAIT_CALLBACK (ожидание выполнения на другом сайте) в деф-сайте, потом в обоих сайтах меняется список административных запросов (END_PHASE_2 и GENERATE_SUPPORT_PHASE_2), и теперь дест-сайт ждет их выполнения в деф-сайте. Помните об этом и ждите (и ускоряйте) выполнение обоих фаз.

 

Решение проблем при создании мастер-групп

            После добавления дест-сайта к мастер-группе деф-сайта на первом не все объекты могут правильно реплицироваться. Достаточно ошибки по одной таблице, чтобы несколько других таблиц вместе с ней оказались в статусе Error.

Перегенерация репликационной поддержки здесь может не помочь. Если предварительно на дест-сайте удалить группу (без объектов), а затем запустить перегенерацию, то для каждой таблицы будет появляться сообщение об ошибке ORA-23312: not the masterdef according to … (тот же результат, если на дест-сайте создать затем группу без объектов).

Единственное здесь решение: удалить мастер-группу с дест-сайта со всеми объектами (в любом режиме), затем удалить (пример в ReDbBER.sql) и добавить (пример в AdDbANTA.sql) дест-сайт к мастер-группе деф-сайта (в режиме QUIESCED):

 

 

 

ПРИМЕЧАНИЕ.

Если Вы уже удалили мастер-группу с дест-сайта без удаления объектов, то вышеприведенная рекомендация не поможет, т.к. все равно объекты останутся в статусе Error. В этом случае выполните следующее.

·         Удалите и добавьте дест-сайт к мастер-группе деф-сайта.

·         После выполнения всех административных запросов (Error) удалите все запросы Error (Purge all requests контекстного меню).

·         Затем удалите мастер-группу с дест-сайта со всеми объектами.

·         Вновь удалите и добавьте дест-сайт к мастер-группе деф-сайта.

 

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

Откройте объекты мастер-группы на деф-сайте.

·         Укажите пункт контекстного меню Add Replication Object(s)….

·         Выберите основную схему и таблицу; нажмите кн. Add и Close.

·         Укажите опции Use existing object if present и Copy row data (обе отмечены по умолчанию); нажмите кн. OK.

·         Снимите отметку с опций Generate и Resume Replication Activity; нажмите кн. OK.

·         Через контекстное меню войдите в свойства (Properties…) добавленного объекта (его статус сейчас - NeedsGen). Откройте вкладку Conflict Resolution.

·         Нажмите кн. Add…, укажите название группы полей (например, DL), выберите все поля (кл. Shift + стрелка вниз) и нажмите кн. Add>>. Нажмите кн. OK.

·         Укажите группу полей (DL), нажмите 2-ю кн. Add….

·         Выберите метод Latest Timestamp и отвечающее за это поле (в большинстве таблиц – CORDATE, в таблице COUNTRY – CORDATE2). Нажмите кн. OK.

·         Откройте вкладку General и нажмите кн. Generate Support. Ждите.

·         На сообщение «Would you like to resume replication activity for group … now ?» ответьте Нет. Закройте окно свойств (кн. Close).

Если после попытки добавления сайта к группе его в ней не оказывается, проверьте, зарегистрированн ли в этом сайте REPADMIN как пропагатор и не остановлена ли БД этого сайта.

Если Вы хотите добавить сайт к группе, а в БД этого сайта имеются часть таблиц и модулей ($RP, $RR, $RU, $RL) этой группы (остались от неудачных добавлений или от прерванных добавлений), то может выйти сообщение об ошибке следующего вида (см. Часть 1, Глава 3: Возможные ошибки и методы их устранения):

 

 

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

После удаления сайта из группы на деф-сайте выполняются административные запросы END_PHASE и GENERATE_SUPPORT_PHASE_2.

 

Если административные запросы «зависают»

1.        Что делать, если операция Resume «подвешивает» самую большую группу PLIPEKN3 - как по   количеству таблиц (39), так и записей (например, в одном из Объединений - в KMCOL – 80 000, PROFILES – 80 000, WORKS – 30 000 записей)? «Оторвите» мастер-БД и остановите эту БД – после этого операция Resume на деф-сайте должно пройти (если нет таблиц Error, которые также надо удалить из мастер-группы).

2.        Если все «зависло», сделать следующее: «убить» все сессии через Oracle Instance Manager и перезапустить все БД. На этапе внедрения это допустимо, но при эксплуатации нежелательно. Однако, в этом случае возможны неприятности:

·       Будет иметь статус ERROR один из административных запросов (его потом придется перезапускать) этого сайта

·       Статус ERROR может возникнуть на административном запросе CREATE_MASTER_DATABASE на другом дест-сайте, если происходит добавление первого дест-сайта к мастер-группе деф-сайта (потом придется удалять эту группу без опции Drop, «отрывать» сайт с группы и добавлять сайт к группе без опции Copy Rows)

3.        Если генерация репликационной поддержки зависает сделайте следующее:

·         остановите БД;

·         удалите административный запрос;

·         запустите БД;

·         выполните генерацию репликационной поддержки.

4.        Нельзя активизировать мастер-группы на деф-сайте при хотя бы одной остановленной БД из описанных для группы дест-сайтов.

 

Администрирование задач

            Для управления задачами можете использовать (после корретировки и добавления новых задач) нижеприведенные скрипты с описанием DBMS-процедуры, выполняемой для каждой задачи:

·         JobBack.sql – восстанавливает исходные свойства всех задач деф-сайта:

 

 

·         JobBreak.sql – временный приостанов всех задач деф-сайта:

 

 

·         JobForw.sql – увеличение интервалов активизации всех задач деф-сайта вперед (отсрочивание момента выполнения задач, например, до момента исправления ошибок):

 

 

·         JobNorm.sql – приведение всех задач деф-сайта в нормальное состояние (из приостановленного):

 

 

·         JobRun.sql – запуск всех задач деф-сайта:

 

 

ПРИМЕЧАНИЕ.

После операций по изменению свойств задачи, произведенных не средствами Oracle Replication Manager (UpdJob.sql и пр.) необходимо сделать COMMIT, иначе они не вступят в силу и не отобразятся в окне ORM.

 

Наблюдение за транзакциями

            После создания нового мастер-сайта обычно делается проверка репликаций, в т.ч. изменение на разных сайтах одной и той же записи одной таблицы, чтобы проверить корректное разрешение конфликтов. Можно предложить такой способ:  изменение поля NAME (описательной части) какого-либо справочника тривиальными командами:

 

 

 

            После выполнения этих SQL-команд нужно обязательно выполнить COMMIT, иначе удаленная транзакция не сформируется (и Вы не увидите ее в разделе ORM  Administration \ Deferred Transaction by Dest – см. рис. 3.1-3.2).

 

 

 

Рис. 3.1. Утилита Oracle Replication Manager. Просмотр пакета  транзакции.

 

 

 

Рис. 3.2. Утилита Oracle Replication Manager. Просмотр удаленных процедур транзакции.

 

 

            Теперь нужно дождаться автоматического срабатывания 2 задач: по мастер-группе 1 и по Sheduled Link (или «толкнуть» их вручную операцией Run Now), затем дождаться исчезновения пакета транзакций из указанного раздела - и можно смотреть результат.

            Если какой-либо сайт инициирует транзакцию, необходимо также смотреть раздел ORM Administration \ Local Errors на других сайтах. Если возникли ошибки, то номер ошибки можно увидеть, указав пункт контекстного меню Properties.

            Следует также иметь ввиду, что после формирования первого пакета транзакций, он имеет статус No sheduled!, т.е. периодичность его выполнения ненастроена (несмотря на настройку Sheduled Link при создании мастер-сайта). В этом случае следует войти в свойства пакета транзакций, затем войти в (Re)Sheduled…, указать интервал и нажать кл. Create. После этого произойдет изменение статуса в Normal и через указанный интервал транзакция начнет выполняться (т.е. выполняться сформированная этими действиями задача Sheduled Link, запускающая процесс PUSH).

 

ПРИМЕЧАНИЕ 1.

Иногда бывают ситуации, когда в одной таблице на разных сайтах изменяются разные записи и выполнение транзакций без видимых причин вызывает ошибку. К удивлению, если настроить на эту таблицу метод разрешения конфликтов, то при повторении такого изменения транзакция проходит без ошибки. Не ясно, почему так происходит, поэтому рекомендуется в любом случае запускать скрипт настройки на МРК, например UpdRes.sql (см. Часть 2, Глава 3: Управление разрешением конфликтов). Не забудьте, что после этого нужно выполнить команду COMMIT и запустить генерацию репликационной поддержки, т.к. после запуска скрипта статус таблиц в мастер-группе – NeedsGen (нуждаются в генерации).

 

ПРИМЕЧАНИЕ 2.

Для просмотра значения полей в записи транзакции, выберите и откройте пакет транзакции, затем выберите и откройте удаленную процедуру (рис. 3.3).

 

 

 

Рис. 3.3. Утилита Oracle Replication Manager. Просмотр полей записи  в транзакции.

 

Разбор ошибочных транзакций

Для определения ошибки транзакции зайдите в ее свойства и откройте вкладку Errors. Не пытайтесь перезапустить (Retry) ошибочную транзакцию, пока не определите и не исправите ошибку. Кроме того, после такой попытки сообщение об ошибке будет сокращено до простого сообщения Data not found (рис. 3.4).

На другом сайте в разделе Administration / Errors войдите в свойства ошибки и выясните следующее: имя таблицы (определяется по имени модуля $RP или $RR) и тип операции (определяется по имени процедуры модуля: _INSERT, _UPDATE или _DELETE).

Если не удается исправить ошибку путем просмотра и исправления свойств объекта, значит необходимо определить запись, которая не поддается изменению транзакцией. Например, в CИСТЕМЕ идентификатор записи, как правило, имеет имя ID. Его значение является входным параметром процедуры модуля $RP или $RR (номер аргумента можно увидеть в описании заголовка модуля (Package) – имя аргумента состоит из имени поля и номера аргумента).

 

ПРИМЕЧАНИЕ 1.

Ряд полезных SQL-запросов по анализу транзакций и ошибок транзакций см. в Часть 2, Глава 3: Анализ транзакций.

 

ПРИМЕЧАНИЕ 2.

Иногда ошибочные транзакции и ошибки их выполнения пропадают при перезапуске БД.

           

ПРИМЕЧАНИЕ 3.

Для просмотра значения полей в записи ошибочной транзакции, выберите и откройте ошибочную транзакцию, затем выберите и откройте удаленную процедуру (рис. 3.5).

 

 

 

Рис. 3.4. Утилита Oracle Replication Manager. Просмотр ошибочных транзакций.

 

 

 

Рис. 3.5. Утилита Oracle Replication Manager. Просмотр полей записи  в ошибочной транзакции.

 

 

Управление разрешением конфликтов

            Допустим, в Вашей системе используется МРК по последней дате изменения (Latest Timestamp). Для настройки этого метода для каждой таблицы используется скрипт UpdRes.sql. По каждой таблице при этом запускаются три DBMS-процедуры (пример для таблицы BRANCH приведен ниже):

1.      Создается имя группы полей (действия в ORM: Properties… контекстного меню => вкладка Conflict Resolution => кн. Add… справа от поля-списка Column Groups => заполнение полей Group Name, Remark в окне Create Column Group).

2.      Формируется список полей для группы полей (кн. Add>> в окне Create Column Group).

3.      Определяется МРК для группы полей (выбор Column Groups на вкладке Conflict Resolution => кн. Add… справа от поля-списка Update Resolution Methods (for above) => выбор МРК из открывающегося поля-списка Method Type в окне Add Update Resolution Method).

 

 

ВНИМАНИЕ !

Если после запуска указанных DBMS-процедур запустить перегенерацию репликационной поддержки, она «зависнет». Чтобы этого не случилось, необходимо предварительно сделать COMMIT.

 

Изменение структуры таблицы (ALTER TABLE)

1.      Если Вы выполнили для объекта репликации DDL-команду вне операций,   предоставляемых Oracle Replication Manager (например, в SQL*Plus или в OEM Oracle Scheme Manager) и перед этим не выгрузили этот объект из мастер-группы, то реплицировать его на другой сайт Вы не сможете. Не поможет даже выполнение этой DDL-команды на другом сайте. Единственный способ:

1)      выгрузите объект из мастер-группы

2)      дождитесь появления административных запросов на деф-сайте и дест-сайте

3)      удалите все административные запросы на обоих сайтах (поскольку все равно их статус Error и они не будут выполняться)

4)      удалите объект на дест-сайте (в SQL*Plus или в Oracle Scheme Manager)

5)      заново включите объект в мастер-группу на деф-сайте и повторите все необходимые операции

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

 

Если пропала связь с сервером

·         При останове сервера на дест-сайте (или при потере связи с ним) необходимо прервать его PUSH (перевести в состояние BROKEN). Если есть уверенность, что на дест-сайте не осталось порожденных им транзакций, а связи не будет долгое время, то можно при восстановлении связи пересоздать весь этот сайт. А чтобы на этот сайт не копились транзакции с других сайтов, необходимо его удалить со всех мастер-групп деф-сайта, причем делать это для мастер-групп в состоянии NORMAL (подробнее – ниже в Главе 3: Пересоздание дест-сайта).

·         При останове сервера на деф-сайте рекомендуется перевести в состояние BROKEN шедулед-линки (задача PUSH) на дест-сайтах. После возобновления связи эти задачи нужно по-очереди для каждого дест-сайта перевести в состояние NORMAL и запустить их (Run Now).

·         При восстановлении связи с сайтом и попытке посмотреть существующие пакеты транзакций с другого сайта (при действительном наличии больших пакетов транзакций) можно увидеть всплывшее окно Please Wait с сообщением Accessing Database. Практика показывает, что это может быть навсегда. При этом с помощью Oracle Instance Manager можно наблюдать для этого сайта два десятка сессий пользователя UNKNOWN. Самый «варварский», но надежный способ справиться с этим – сделать SHUTDOWN ABORT для принимающего сайта, удалить транзакции на отправляющем сайте и перегенерить репликационную поддержку заново (или пересоздать сайт – см. Часть 2, Глава 3: Пересоздание дест-сайта).

ВНИМАНИЕ !

Если связь с одним из сайтов отсутствует продолжительное время, в течение которого на других сайтах интенсивно выполняются правки таблиц (ввод, изменение или  удаление данных), то при последующем после восстановления связи запуске накопившегося пакета транзакций «вал» обратных подтверждений (даже если транзакции выполняются без ошибок) порождает большое кол-во процессов на  серверах других сайтов. Для Netware-серверов это часто заканчивается плачевно: возникает критическая ошибка и имеющиеся БД Oracle становятся недоступными (возникает ошибка ORA-03113: end-of-file on communication channel – см. Часть 2, Глава 3: Возможные ошибки и методы их устранения), что требует перезагрузки сервера. Для избежания этого на Netware-сервере должно быть достаточно оперативной памяти, и не должны быть установлены (или хотя бы не должны быть запущены) другие БД Oracle, особенно имеющие репликацию.

 

Пересоздание дест-сайта

Если Вы планируете пересоздать всю репликацию на дест-сайте, то последовательность действий такова:

1.        Удалить дест-сайт из каждой мастер-группы деф-сайта. При этом мастер-группа должна быть в состоянии NORMAL.

 

ПРИМЕЧАНИЕ 1.

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

 

ПРИМЕЧАНИЕ 2.

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

 

2.        Удалить эту мастер-группу на дест-сайте с ее объектами, указав опцию Drop (также в состоянии NORMAL).

 

ПРИМЕЧАНИЕ.

Это необходимо, иначе при последующей попытке Resume (см. ниже - п.5) на деф-сайте будет сообщение о необходимости перегенерации реп-поддержки, а при попытке ее осуществить появится сообщение о необходимости удалить объекты.

 

3.        Перевести мастер-группу на деф-сайте в состояние QUIESCED (сделать Suspend).

 

ВНИМАНИЕ !

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

 

4.        Вновь добавить дест-сайт к мастер-группе.

5.        Перевести мастер-группу на деф-сайте в состояние NORMAL (сделать Resume). При этом генерация репликационной поддержки выполнится автоматически. Ждать выполнения всех административных запросов (или «подталкивать» их вручную – см. Часть 2, Глава 3: Работа с административными запросами, Ускорение выполнения).

 

Перенос основной БД на сервер с другой ОС

            При переносе БД, участвующей в репликации Мультимастер, с одного сервера на другой, необходимо сделать следующее:

1.      Произвести полный экспорт БД. Пример с использованием утилиты EXP80 находится в файле ExpFulAn.bat или ExpFulAn.ncf, которую запускают на сервере в подкаталоге DMP, где создается файл экспорта  (дамп-файл) и протокольный файл (лог-файл):

 

 

2.      Несмотря на то, что при последующем полном импорте все табличные пространства (кроме SYSTEM) создадутся сами, а также будут создаваться некоторые объекты Словаря, на новом сервере необходимо создать БД со всеми табличными пространствами и формированием словарей ( CATALOG.SQL, CATPROC.SQL, CATHS.SQL, CATREP8M.SQL, PUPBLD.SQL ). Т.е., после создания инстанса нужно выполнить скрипты Start.sql, CDb.sql и CDb2.sql (см. Часть 1, Глава  2: Создание основных физических объектов БД; Создание Словаря данных, табличных пространств и сегментов отката).

 

3.      Произвести полный импорт БД. Пример с использованием утилиты IMP80 находится в файле ImpFulAr.bat или ImpFulAr.ncf, с помощью которых утилиту запускают на сервере в подкаталоге DMP, где создается файл экспорта  (дамп-файл) и протокольный файл (лог-файл):

 

 

Поскольку перед полным импортом были созданы табличные пространства и системные таблицы (запускались скрипты создания словарей), то в лог-файле будут сообщения об ошибке IMP-00015: following statement failed because the object already exists (следующее предложение пропущено, поскольку объект уже существует). На это можно внимание не обращать.

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

5.      Посмотрите в Oracle Schema Manager статус объектов в разделах Function, Package Bodies и Package, Procedures. Если есть объекты со статусом Invalid – перекомпилируйте их (для перекомпиляции всех функций можно использовать скрипт AFunc.sql). Проверьте также статус объектов VIEW.

6.      С помощью ORM войдите в сайт и посмотрите наличие мастер-групп, объектов репликации и их статус. Проблемы могут быть с отсутствием регистрации пользователя REPADMIN как Пропагатора («проталкивателя») и отсутствием мастер-групп. В этом случае запустите скрипты создания мастер-сайта (CMs.sql) и мастер-групп (CMGr.sql) еще раз.