Oracle mgw что это
Обновлено: 05.07.2024
[ Note ] In addition to these generic limitations, each gateway can have additional limitations. Please consult the gateway documentation for individual gateways for a complete list of limitations of the product.
Heterogeneous Replication
Гетерогенная репликация может быть реализована при помощи материальных представлений.
[ Note ] There is another means of replicating information between Oracle and non-Oracle databases called Streams.
Ограничения репликации non Oracle-to-Oracle по сравнению с Oracle-to-Oracle:
- Only the non-Oracle system can be the master site. This is because materialized views can be created only on an Oracle server.
- Materialized views must use complete refresh. This is because fast refresh would require Oracle-specific functionality in the non-Oracle system.
- Not all types of materialized views can be created to reference tables on a non-Oracle system. Primary key and subquery materialized views are supported, but ROWID and OBJECT ID materialized views are not supported. This is because there is no SQL standard for the format and contents of ROWID, and non-Oracle systems do not implement Oracle objects.
- Совместимость типов данных, как правило совместимыми являются типы данных определённые стандартом ANSI SQL.
- Совместимость под запросов представления как правило обеспечивается переводом их на язык удаленной системы, однако иногда совместимость не может быть проверена до выполнения запроса.
Passthrough SQL (Сквозной SQL)
Passthrough SQL позволяет отправлять запросы напрямую удаленной базе, пропуская интерпретацию запроса в Oracle. Эта возможность полезна при выполнении запросов для которых не эквивалента в Oracle.
- Using the DBMS_HS_PASSTHROUGH Package;
- Considering the Implications of Using Passthrough SQL;
- Executing Passthrough SQL Statements.
Использование пакета DBMS_HS_PASSTHROUGH
Сквозные (Транзитивные) SQL операторы выполняются при помощи пакета DBMS_HS_PASSTHROUGH . Этот пакет является виртуальным. Концептуально он находится в удаленной базе. На самом деле запросы выполняемые через этот пакет перехватываются HS и распространяются на необходимое количество вызовов. Драйвер в свою очередь преобразует эти запросы в API удаленной базы. [ 45 DBMS_HS_PASSTHROUGH ]
Considering the Implications of Using Passthrough SQL
Executing Passthrough SQL Statements
Функции и процедуры пакета DBMS_HS_PASSTHROUGH, позволяющие выполнять транзитивные SQL запросы:
- OPEN_CURSOR
- CLOSE_CURSOR
- PARSE
- BIND_VARIABLE
- BIND_OUT_VARIABLE
- BIND_INOUT_VARIABLE
- EXECUTE_NON_QUERY
- EXECUTE_IMMEDIATE
- FETCH_ROW
- GET_VALUE
Executing non Queries
Для этого запроса следует использовать функцию EXECUTE_IMMEDIATE .
DECLARE
num_rows INTEGER ;
BEGIN
num_rows : = DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@salesdb ( 'CREATE TABLE dept1 (n SMALLINT, loc CHARACTER(10))' ) ;
END ;
Функция EXECUTE_IMMEDIATE возвращает количество строк затронутых выполнение SQL оператора, для DDL операторов функция возвращает ноль.
Using Bind Variables (Использование Связанных Переменных)
Для выполнения сквозного SQL ( Passthrough SQL ) вместе со связанными переменными необходимо:
Знает названье потока лишь тот, кто вблизи обитает.
От Махачкалы до Баку
Луны плавают на боку,
И, качаясь, плывут валы
От Баку до Махачкалы.
Введение
Потоки данных появились в Oracle версии 9, а в версии 10 получили свое развитие в возможностях (например, Down Stream) и в организации (например, собственный источник памяти streams pool).
В отличие от "обычной" репликации Oracle Streams не требует заведения особых структур в БД (журналов таблиц, materialized views). Подбно механизму репликации, давно использовавшемуся в Sybase, репликация в Oracle Streams основана на обработке информации из журнала БД.
Основные понятия
Конфигурация СУБД и БД для возможности организации потоков
Параметры СУБД
Для организации потоков данных нужно иметь должные значения целого ряда параметров СУБД, однако чаще всего достаточно удостовериться в следующем:COMPATIBLE >= 9.2
Далее предполагается >= 10.1.0.
GLOBAL_NAMES = TRUE
для каждой БД, участвующей в переносе данных.
STREAMS_POOL_SIZE >= 200m
Параметр существует с версии 10.1 и задает область памяти для временного размещения захваченных событий. Если STREAMS_POOL_SIZE = 0, будет использована память из shared pool, вплоть до 10% от этой области.
- + 10m для каждого нового уровня параллелизма процесса захвата
- + 1m для каждой степени параллелизма процесса применения
- + 10m для каждой новой очереди захваченных событий.
В версии 9.2 нагрузка на выделение памяти под нужды потоков ложится на shared pool.
SHARED_POOL_SIZE
Каждый процесс захвата требует 10M в памяти shared pool для буфера очереди; в то же время все нужды Oracle Streams в shared pool не могут занимать более 10% этой области.
SGA_MAX_SIZE
(Если речь идет о версии 10). Значение должно учитывать нужды частей SGA (см. выше), особенно для выполнения захвата изменений с помощью LogMiner. Пример, приводимый ниже, в силу его простоты работает даже при значении SGA_MAX_SIZE = 400m.
Конфигурация БД
БД, поддерживающая процесс захвата изменений, должна работать в режиме архивирования.БД, поддерживающая процесс захвата изменений, должна обеспечить на уровне отдельных таблиц или всей БД режим расширенной журнализации (supplemental logging). В этом режиме журнальные записи об изменениях в таблицах заносятся в расширенном формате, включая данные старых и новых значений полей (независимо от того, какие поля фактически изменялись) для того, чтобы процесс применения изменения в принимающей СУБД смог однозначно воспроизвести изменение.
- индексирован (хотя бы вследствие имеющегося ограничения целостности)
- участвует в правиле преобразования данных или обрабатывается программой обработки (handler)
Как БД-источник, так и БД-получатель используют рабочие таблицы для хранения данных очередей и прочих нужд. Для их размещения целесообразно выделить отдельные табличные пространства. В БД-источнике желательно назначить процессу LogMiner табличное пространство, иное, чем SYSTEM.
Системные пакеты
Технологически организация потоков осуществляется через употребление ряда встроенных пакетов из схемы SYS:DBMS_APPLY_ADM
DBMS_CAPTURE_ADM
DBMS_PROPAGATION_ADM
DBMS_STREAMS_ADM
DBMS_STREAMS
DBMS_STREAMS_MESSAGING
DBMS_RULE_ADM
DBMS_RULE
DBMS_STREAMS_AUTH 2
DBMS_STREAMS_TABLESPACE_ADM 2
Пример построения потока изменений
В этом примере БД-источник потока носит имя MAINDB.CLASS, БД-приемник потока носит имя SUBDB1.CLASS. Сетевые имена баз в Oracle Net соответственно SOURCE и DESTINATION. Предполагается, что в обеих БД имеется схема SCOTT.Пример приводится для версии 10.2. Предполагается, что команды выдаются в SQL*Plus.
Подготовка
Переведем БД-источник в режим архивирования журнальных файлов:CONNECT /@source AS SYSDBA
STARTUP MOUNT FORCE
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
Создадим рабочие табличные пространства в обоих БД, например:
CREATE TABLESPACE streams_ts
DATAFILE 'C:\oracle\oradata\maindb\streams_ts.dbf' SIZE 25m;
CONNECT /@destination AS SYSDBA
CREATE TABLESPACE streams_ts
DATAFILE 'C:\oracle\oradata\subdb1\streams_ts.dbf' SIZE 25m;
В версия 9.2 в БД-источнике желательно назначить процессу LogMiner табличное пространство, иное, чем SYSTEM (в версия 10 оно уже SYSAUX), например:
CONNECT /@source AS SYSDBA
EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE ( 'TOOLS' )
В обеих базах создадим администратора потоков:
CONNECT /@source AS SYSDBA
CREATE USER streamadmin IDENTIFIED BY streamadmin
DEFAULT TABLESPACE streams_ts
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON streams_ts
;
GRANT dba TO streamadmin;
EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE ( 'streamadmin' )
Повторить те же действия для SUBDB1.CLASS.
В БД-источнике заведем связь с БД-получателем. Так как БД-получатель именована глобально, имя связи обязано совпадать с этим глобальным именем:
CONNECT streamadmin/streamadmin@source
CREATE DATABASE LINK subdb1.class
CONNECT TO streamadmin
IDENTIFIED BY streamadmin
USING 'destination'
;
Формирование потоков
Создадим очередь для передачи событий в БД-источнике и очередь для применения событий в БД-получателе, например:CONNECT streamadmin/streamadmin@destination
Коли указано специально, очереди в обеих БД (и таблицы для данных этих очередей) получили умолчательные названия. Их можно наблюдать так:
Для возможности передавать потоком изменения в исходной таблице SCOTT.EMP требуется заявить расширенную журнализацию хотя бы для этой таблицы:
CONNECT scott/tiger@source
ALTER TABLE emp ADD SUPPLEMENTAL LOG DATA ( PRIMARY KEY ) COLUMNS;
Теперь правка любого поля в таблице EMP будет сопровождаться (безусловно) занесением в журнал не только старого и нового значений этого поля, но также и значения ключевого поля (то есть EMPNO).
В БД-источнике создадим процесс захвата изменений, одновременно указав правила отбора изменений в очередь: Проверка:
Среди прочих умолчаний при создании процесса захвата изменений выше использовано подразумеваемое молчаливо имя очереди STREAMS_QUEUE. В нашем случае это можно было бы обозначить явно, указав параметр QUEUE_NAME => 'streamadmin.streams_queue'. Этим же параметром можно воспользоваться, когда процесс захвата потребуется связать с очередью под иным именем.
Правила отбора изменений в очередь STREAMS_QUEUE также были построены автоматически, но могли бы быть дополнены, или даже выписаны явно с помощью других параметров процедуры ADD_TABLE_RULES.
Создадим процесс переноса изменений: Проверка: Убедиться в учете процессом применения для таблиц точки отсчета можно запросом: Принимающая БД готова к активации процесса применения изменений: Проверка: Для удобства отключим реакцию на ошибки, иначе процесс применения изменений может самопроизвольно прекращаться: Осталось запустить процессы захвата и примения изменений: Проверка: Заметьте, что поток переносит изменения только в одну сторону. Таблица-приемник при этом не закрыта от обычной правки. Однако же такую правку следует выполнять осмотрительно, поскольку она может привести к ошибкам при автоматическом изменении данных потоком (эта проблема решается специально седствами разрешении конфликтов). Вдобавок учтите, что множественные операции INSERT, UPDATE, DELETE применяются в принимающей БД в рамках одной (автономной) транзакции (невзирая на то, что в журнале БД множественные изменения фиксируются набором однострочных изменений). Следовательно ошибка хотя бы в изменении одной-единственной строки приведет к отказу изменений всей множественной операции.
Читайте также: