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

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

В предыдущих четырех частях мы:

• кратко рассмотрели основные термины и концепции, связанные с использованием Oracle Streams
• выполнили настройки, необходимые для начала работы (создание необходимых пользователей, database links и т.д.)
• посмотрели, как настраивать репликацию средствами Database Control
• посмотрели, как настраивать репликацию с помощью процедур MAINTAIN_*. Эти процедуры представляют собой простой, но очень мощный механизм настройки репликации. Для их применения нужно еще знать. как проводить простейший troubleshooting. Но об этом в следующей часть

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

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

0. Для режима downstream обе базы данных должны находить в режиме archivelog. Если они еще не переведены в этот режим – переведите. Также необходимо настроить аутенфикацию в этих базах данных для того, чтобы они могут передавать журнальные данные между собой. Простейший способ это синхронизировать файл паролей между собой. Я сделал вот так (у меня все на одном компьютере):

cp /u01/app/oracle/product/11.1.0/db_1/dbs/orapwsrc /u01/app/oracle/product/11.1.0/db_1/dbs/orapwdest

1. Настройте параметры доставки журнальной информации исходной базе (src.local):

1.1. На исходной базе данных настройте LOG_ARCHIVE_DEST_n параметр для доставки журнальной информации. Для этого необходимо настроить следующие параметры:

• SERVICE – указывает сетевое имя downstream базы (dest.local)
• ASYNC или SYNC – указывает режим передачи журналов
  ASYNC почти не влияет на производительность исходной базы.
  SYNC журнальные данные пересылаются на downstream базу с меньшей задержкой
  Если указать SYNC AFFIRM, то эффекти будет сходен с MAXIMUM AVAILABILITY для standby. Команда ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITY SQL не влияет на работу Oracle Streams.
• NOREGISTER – указывает, что местоположение не надо регистрировать в управляющих файлах downstream базы .
• VALID_FOR – укажите либо (ONLINE_LOGFILE,PRIMARY_ROLE), либо (ONLINE_LOGFILE,ALL_ROLES).
• DB_UNIQUE_NAME – уникальное имя downstream базы. Используйте значение, указанное в инициализационном параметре DB_UNIQUE_NAME с downstream базы.

Ниже пример:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=DEST.LOCAL ASYNC NOREGISTER
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=dest' SCOPE=BOTH;

1.2 Установите LOG_ARCHIVE_DEST_STATE_n в ENABLE.

Ниже пример:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

1.3. В LOG_ARCHIVE_CONFIG установите атрибут DB_CONFIG в инициализационном файле, чтобы он включал DB_UNIQUE_NAME исходной и целевой базы (downstream базы).

Например, если DB_UNIQUE_NAME исходной базы src, а DB_UNIQUE_NAME downstream базы dest:
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(src,dest)' SCOPE=BOTH;

По умолчанию LOG_ARCHIVE_CONFIG позволяет базе передавать и принимать журналы.

2. Настройте параметры доставки журнальной информации на downstream базе (dest.local):

2.1. Настройте как минимум один LOG_ARCHIVE_DEST_n (в каталог или flash recovery area) для этого укажите:

• LOCATION – укажите каталог или USE_DB_RECOVERY_FILE_DEST. Это локальный каталог.
• VALID_FOR – укажите (ONLINE_LOGFILE,PRIMARY_ROLE) или (ONLINE_LOGFILE,ALL_ROLES).

Например вот так:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oradata/dest/arch1 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)' SCOPE=SPFILE;

2.2. Установите LOG_ARCHIVE_DEST_STATE_n в ENABLE:

Например:
LOG_ARCHIVE_DEST_STATE_1=ENABLE

2.3. Добавьте еще один LOG_ARCHIVE_DEST_n (в каталог или flash recovery area) для этого укажите следующие параметры

• LOCATION – укажите каталог или USE_DB_RECOVERY_FILE_DEST. Это локальный каталог. Сюда будут складываться архивные журналы по генерируемым standby журналам.
• VALID_FOR – укажите (STANDBY_LOGFILE,PRIMARY_ROLE) или (STANDBY_LOGFILE,ALL_ROLES).

Например вот так:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='LOCATION=/u01/app/oracle/oradata/dest/arch2
VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)' SCOPE=SPFILE;

ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

2.4. В LOG_ARCHIVE_CONFIG задайте аналогично основной базе.

Например, если DB_UNIQUE_NAME исходной базы src, а DB_UNIQUE_NAME downstream базы dest:
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(src,dest)' SCOPE=BOTH;

3. На downstream базе нужно создать standby журналы:

Посмотрите список журналов на исходной базе данных и добавьте аналогичные, standby журналы на downstream базе.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
('/u01/app/oracle/oradata/dest/slog4a.rdo') SIZE 50M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
('/u01/app/oracle/oradata/dest/slog5a.rdo') SIZE 50M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6
('/u01/app/oracle/oradata/dest/slog6a.rdo') SIZE 50M;

4.1 Создадим схему, которую будем реплицировать

CREATE USER repl_ds_user IDENTIFIED BY oracle DEFAULT TABLESPACE users QUOTA UNLIMITED ON users;

CREATE TABLE repl_ds_user.employees TABLESPACE users AS SELECT * FROM hr.employees WHERE department_id in (10,20,30,40);

CREATE TABLE repl_ds_user.departments TABLESPACE users AS SELECT * FROM hr.departments WHERE department_id in (10,20,30,40);
ALTER TABLE repl_ds_user.employees ADD CONSTRAINT employee_id_pk PRIMARY KEY (employee_id);

ALTER TABLE repl_ds_user.departments ADD CONSTRAINT department_id_pk PRIMARY KEY (department_id);

ALTER TABLE repl_ds_user.employees ADD CONSTRAINT department_fk FOREIGN KEY (department_id) REFERENCES repl_ds_user.departments(department_id);

4.2 Подключившись к целевой(downstream) базе данных под пользователем STRMADMIN (создан на предыдущих уроках) выполните команду настройки репликации:

BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'repl_ds_user',
source_directory_object => 'SRC_DIR',
destination_directory_object => 'DEST_DIR',
source_database => 'src.local',
destination_database => 'dest.local',
DUMP_FILE_NAME=>'downstream.dmp',
capture_name => 'downstream_capture',
CAPTURE_QUEUE_TABLE=>'downstream_capture_t',
CAPTURE_QUEUE_NAME=>'downstream_capture_q',
CAPTURE_QUEUE_USER=>'strmadmin',
propagation_name =>'downstream_propagation',
apply_name => 'downstream_apply',
APPLY_QUEUE_TABLE =>'downstream_apply_t',
APPLY_QUEUE_NAME=>'downstream_apply_q',
APPLY_QUEUE_USER=>'strmadmin'
);
END;
/

5. Подключитесь к целевой (downstream) базе и выполните команду перевода в режим downstream.

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'downstream_capture',
parameter => 'downstream_real_time_mine',
value => 'Y');
END;
/

6. Все. После этого можно проверять. Если что-то не реплицируется – смотрите в alert. Даст бог поможет

В следующей статье расскажу как заниматься troubleshootingом репликации.

Ошибки, которые я встретил:

1. ERROR at line 1:
ORA-23616: Failure in executing block 2 for script 66E3D95F7BE36E8FE040007F01003A24 with
ORA-26727: Cannot alter queue_to_queue property of existing propagation.
ORA-06512: at "SYS.DBMS_RECOVERABLE_SCRIPT", line 576
ORA-06512: at "SYS.DBMS_RECOVERABLE_SCRIPT", line 599
ORA-06512: at "SYS.DBMS_STREAMS_MT", line 7755
ORA-06512: at "SYS.DBMS_STREAMS_ADM", line 2644
ORA-06512: at "SYS.DBMS_STREAMS_ADM", line 2705
ORA-06512: at line 2

Я перед этим вручную пересоздал процесс передачи (propagation) из database control. В результате этот процесс получился QUEUE_TO_QUEUE=FALSE (это я увидел из dba_propagation). Я удалил процесс передачи и перезапустил процесс создания репликации.

2. Эту ошибку встретил второй раз. Связана она с работой DATAPUMP. В данном случае это был мой косяк: я не создал исходную таблицу, ну и очевидно DATAPUMP не смог найти и ругался.

ERROR at line 1:
ORA-23616: Failure in executing block 5 for script 66E3D95F7BE76E8FE040007F01003A24 with
ORA-39001: invalid argument value
ORA-06512: at "SYS.DBMS_RECOVERABLE_SCRIPT", line 576
ORA-06512: at "SYS.DBMS_RECOVERABLE_SCRIPT", line 599
ORA-06512: at "SYS.DBMS_STREAMS_MT", line 2281
ORA-06512: at "SYS.DBMS_STREAMS_ADM", line 2945
ORA-06512: at line 2