|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
гг 19 таблица id,stolb1,stolb2 id - primary key, stolb2 - не ключевой столбец экстракт where stolb2 <> 1 если строка сначала попадала, а потом после апдейта перестала попадать в условие, то изменение не улетит, и на целевой базе останется такая строка со старым значением столбца, никуда она не удалится если строка сначала не попадала, а потом после апдейта стала попадать в условие, то на целевой базе строки нет и гг получит No data found как решить правильно такие ситуации? убрать условие не предлагать) есть ли, например, параметр вставить строку, если прилетел апдейт, а её нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 13:17 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
Отработать логику на apply, а не на экстракт. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 16:21 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
AlexVinесли строка сначала попадала, а потом после апдейта перестала попадать в условие, то изменение не улетит, и на целевой базе останется такая строка со старым значением столбца, никуда она не удалится Придеться условия на extract менять. Например (без учета null): Код: plsql 1.
Соответственно, с ALLOWDUPTARGETMAP . На replicat через GETUPDATES / SQLEXEC можно будет провести удаление. AlexVinесли строка сначала не попадала, а потом после апдейта стала попадать в условие, то на целевой базе строки нет и гг получит No data found Проще всего через INSERTMISSINGUPDATES + необходимый supplemental logging для всех / нужных полей. В целом, если будут какие-то многоэтажные конструкции получаться, то я бы в макросы завернул, чтобы вся логика была на уровне макроса, а на уровне файлов параметров только вызов макросов и других файлов или несложные маппинги. Вот, например, примерно такой макрос для исторических таблиц использую: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
В файле параметров простой вызов макроса: Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 17:32 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
SeaGate Придется условия на extract менять. Например (без учета null): Код: plsql 1.
Соответственно, с ALLOWDUPTARGETMAP . На replicat через GETUPDATES / SQLEXEC можно будет провести удаление. это в отдельный трейл писать? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2022, 23:17 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
AlexVinэто в отдельный трейл писать? Если происходят обновления stolb2 -> 1 -> не 1, то в отдельном не безопасно, т.к. разные репликаты не смогут синхронизироваться. Также нужно учитывать, что ALLOWDUPTARGETMAP не для integrated/parallel replicats. В первом приближении, что-нибудь такое можно взять: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Изначально была идея с двумя строками TABLE на extract и с ALLOWDUPTARGETMAP, но что-то с этим нормально не получилось с OGG 19.1.0.0.211019 Oracle 19c. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 02:10 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
SeaGate Код: plsql 1. 2.
а для символьного столбца можно filter как-то попроще написать, чем вот так?) Код: plsql 1.
гг 19.1.0.0.210720 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2022, 14:56 |
|
голденгейт изменение в столбце условия выгрузки
|
|||
---|---|---|---|
#18+
AlexVin а для символьного столбца можно filter как-то попроще написать, чем вот так?) Код: plsql 1.
гг 19.1.0.0.210720 Через STREQ , как вариант: Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2022, 01:01 |
|
|
start [/forum/topic.php?fid=52&msg=40125050&tid=1879616]: |
0ms |
get settings: |
17ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
34ms |
get topic data: |
4ms |
get forum data: |
1ms |
get page messages: |
158ms |
get tp. blocked users: |
1ms |
others: | 377ms |
total: | 599ms |
0 / 0 |