Oracle Spatial, Mapviewer, Semantics и ГИС системы

Продолжение. Начало смотрите в предыдущих поста: часть 1, часть 2, часть 3, часть 4, часть 5, часть 6, часть 7, часть 8.

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

Однако, у этого метода есть свои минусы: для извлечения изменений только в одной таблице приходится перекопать все огромное количество изменений в базе данных. К сожалению, такова природа лежащего в основе сбора изменений механизма – Log Miner.

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

Вот для таких случаев Oracle Streams предоставляет механизм под название синхронный сбор изменений (Synchronous Capture).

В синхронном режиме сбор изменений происходит параллельно с самими изменениям. Это замедляет работу транзакции, изменяющей таблицу, но в то же время позволяет не перекапывать все журналы. Синхронный сбор использует внутренний механизм базы данных для сбора изменений. Эти механизмы сходны с работой триггеров, но в то же время не требуют кодирования.

Настройка синхронной репликации

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

Т.е. важен только механизм сбора изменений, а когда изменения в очереди на распространение – различия теряются.

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

• DBMS_STREAMS_ADM.ADD_TABLE_RULES
• DBMS_STREAMS_ADM.ADD_SUBSET_RULES
• DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE

0. Давайте вернемся к части 7. В тот раз мы создали 2 таблицы в исходной базе src: width="70%"repl_new_user.departments и repl_new_user.employees. Мы создали 2 очереди сообщений с именем strmadmin.streams_queue на каждой из баз данных (src, dest). Настроили передачу изменений между очередями. Настроили применение изменений из очереди в базе данных dest, а также настроили сбор изменений таблиц employees и departments в очередь в базе данных src.

1. Создадим на исходной базе данных таблицу.

CREATE TABLE repl_new_user.locations TABLESPACE USERS AS SELECT * from hr.locations WHERE LOCATION_ID<1500;

2. Настроим сбор изменений.
Давайте не будет трогать существующую репликацию, но создадим и запустим дополнительно репликацию таблички ….. Для этого воспользуемся процедурой DBMS_STREAMS_ADM.ADD_TABLE_RULES. У этой процедуры есть параметр stream_type – вот он и отвечает за создание синхронного процесса сборки изменений.

BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name   => 'repl_new_user.locations',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name   => 'strmadmin.streams_queue');
END;
/

Эта процедуры выполняет следующие действия:

• создает синхронный процесс sync_capture на текущей базе данных. С таким именем не должно существовать сихнронных сборщиков.
• включает сбор изменений. Отключить нельзя.
• указывает, что сбор изменений будет происходить в очередь streams_queue
• создает положительно правило для процесса сбора
• выполняет DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION

3. Проводим процедуру первоначальной синхронизации таблиц.

В этот раз будем использовать DATAPUMP, но в режиме сетевой работы. Это очень интересная функция, т.к. позволяет не использовать промежуточный файл при заливке данных, но в то же время позволяет использовать все возможности DATAPUMP.

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

select dbms_flashback.get_system_change_number() from dual;

DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER()
-----------------------------------------
1869408

Далее запустим импорт данных в сетевом режиме:

impdp strmadmin/oracle@dest.local DIRECTORY=DEST_DIR NETWORK_LINK=src.local TABLES=repl_new_user.locations FLASHBACK_SCN=1869408

Теперь зададим начальный момент применения реплицируемых изменений:

DECLARE
iscn  NUMBER;
BEGIN
iscn := 1869408;
DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@DEST.LOCAL(
source_object_name    => 'repl_new_user.LOCATIONS',
source_database_name  => 'src.local',
instantiation_scn     => iscn);
END;
/

4. Настроим на целевом сервере (dest) применение наших изменений. Для этого мы можем выбрать несколько способов:

• В части 7 мы создали процесс применения изменений в таблицах employees, departments. Можно изменить набор правил, добавив в них применение изменений новой таблицы locations:

  BEGIN
  DBMS_RULE_ADM.CREATE_RULE( rule_name => 'strmadmin.repl_new_user_locations_dml',
  condition => ' :dml.get_object_owner() = "REPL_NEW_USER" AND :dml.get_object_name()="LOCATIONS" ');
  DBMS_RULE_ADM.ADD_RULE
  ( rule_name => 'strmadmin.repl_new_user_locations_dml',
  rule_set_name => 'strmadmin.hr_apply_rules');
  END;

• Можно создать новый новый процесс применения со своими правилами на таблицу locations
• Можно использовать упрощенный набор команд из DBMS_STREAMS_ADM.

  begin
  dbms_streams_adm.add_table_rules (
  table_name => 'repl_new_user.locations',
  streams_type => 'apply',
  queue_name => 'strmadmin.streams_queue',
  source_database => 'src.local');
  end;
  /

5. Настраиваем распространение изменений из базы src в базу dest. Аналогично доступные несколько вариантов как и для применения.

• В части 7 мы создали процесс передачи изменений для таблиц employees, departments. Можно изменить набор правил, добавив в них применение изменений новой таблицы locations
• Можно создать новый распространения со своими правилами на таблицу locations
• А можно воспользоваться упрощенным набором команд из DBMS_STREAMS_ADM.

  begin
  dbms_streams_adm.add_table_propagation_rules(
  table_name => 'repl_new_user.locations',
  source_queue_name => 'strmadmin.streams_queue',
  destination_queue_name => 'strmadmin.streams_queue@dest',
  source_database => 'src.local');
  end;
  /

6. Запустим применение и распространение на базе-источнике (src):

begin
dbms_apply_adm.stop_apply@DEST.LOCAL(apply_name => 'APPLY_REPL_NEW_USER');
dbms_apply_adm.start_apply@DEST.LOCAL(apply_name => 'APPLY_REPL_NEW_USER');
end;
/

7. Протестируем работу

На базе-источнике (src):

INSERT INTO repl_new_user.locations SELECT * from hr.locations WHERE LOCATION_ID BETWEEN 1500  and 1700;
commit;

На целевой базе (dest):

select * from repl_new_user.locations