Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 GoldenGate Sqlexec on a different database  [new]
versus82
Member

Откуда:
Сообщений: 3
Добрый день,
есть вопрос по использованию в OGG функционала обращения через SQLEXEC к другой базе.
вот такая конфигурация работает, запрос соответственно выполняется на источнике данных db1:

EXTRACT EXTTST
USERID GGUSER@db1, PASSWORD xxx
SETENV (ORACLE_SID=db2)
SETENV (ORACLE_HOME=/opt/ora/product/18.0.0.0/db_1)
SETENV (NLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251)
TRANLOGOPTIONS MININGUSER GGUSER, MININGPASSWORD xxx
TRANLOGOPTIONS INTEGRATEDPARAMS (downstream_real_time_mine Y)
EXTTRAIL ./dirdat/cc

TABLE TST.TBL1, TARGET TST.TBL1
, SQLEXEC (ID hashing_col1, QUERY 'select cast(standard_hash(:V1, ''MD5'') as varchar2(64)) hash_val1 from dual', PARAMS (V1 = col1))
, COLMAP (USEDEFAULTS, COL1 = @GETVAL(hashing_col1.hash_val1))
, KEYCOLS (col2);

но при попытке перенаправить запрос на другую базу (Downstream базу db2), как описано в документации:тыц
If you want to execute a query on a table residing on a different database than the current database, then the different database name has to be specified with the table. The delimiter between the database name and the tablename should be a colon (:). The following are some example use cases:

select col1 from db1:tab1
select col2 from db2:schema2.tab2
select col3 from tab3
select col3 from schema4.tab4

т.е. так
, SQLEXEC (ID hashing_col1, QUERY 'select cast(standard_hash(:V1, ''MD5'') as varchar2(64)) hash_val1 from db2:dual', PARAMS (V1 = col1))
или так
, SQLEXEC (ID hashing_col1, QUERY 'select cast(standard_hash(:V1, ''MD5'') as varchar2(64)) hash_val1 from db2:sys.dual', PARAMS (V1 = col1))

получаю ошибку
2019-03-28 09:06:16 ERROR OGG-00664 OCI Error describe for query hashing_col1 (bad syntax) (status = 933-ORA-00933: SQL command not properly ended).

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

цель - перенаправить нагрузку с источника данных на Downstream базу.
у нас пакт о ненападении несоздании дополнительной нагрузки на источник.

использовать OGG_SHA1 мы не можем – нужен именно MD5,
делать преобразование второй очередью EXTRACT'а тоже бы не хотелось.

если кто знает как работает этот функционал - подскажите пожалуйста.
10 апр 19, 13:46    [21858280]     Ответить | Цитировать Сообщить модератору
 Re: GoldenGate Sqlexec on a different database  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4897
Блог
Не подскажу про обращение к базе, но не пробовали глянуть на userexit?
10 апр 19, 19:26    [21858729]     Ответить | Цитировать Сообщить модератору
 Re: GoldenGate Sqlexec on a different database  [new]
versus82
Member

Откуда:
Сообщений: 3
Глянуть пробовали,
но компетенции в области разработки на С нет, разбираться долго,
готового решения нет.
Тем более что есть рабочий вариант в виде преобразования на второй очереди EXTRACT'а/PUMP'е.
Только хотелось бы сделать максимально проще (все преобразования в первичном EXTRACT'е + PUMP в passthrough режиме), а не усложнять,
в доке ведь написано что это возможно..
ну и так, на будущее, знать - как можно обратиться к LOOKUP таблице расположенной в другой базе, это тоже могло бы пригодиться.
11 апр 19, 06:44    [21858887]     Ответить | Цитировать Сообщить модератору
 Re: GoldenGate Sqlexec on a different database  [new]
versus82
Member

Откуда:
Сообщений: 3
надежда не оправдалась, это всё таки для PDB было написано.
заключение по SR (может пригодится кому):
This is for multitenant databases, like oracle and SQL Server where the original connection that is used for the USERID parameter has access to different databases or PDBs. It does not allow for a separate connection to be established with different credentials.
3 июн 19, 08:52    [21900095]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить