Итак, мы в настоящее время пытаемся добиться следующим:нужно загружать вставки, прежде чем обновления, прежде чем удаляются в цель ... данные все в одном источнике
SourceTableA представляет собой таблицу отслеживания измененных данных, он будет содержать, естественный ключ, I, U, D, I затем U, затем D, I затем U, затем D, или U, затем D. Первичный ключ для этой таблицы - это естественный ключ + действие (I, U или D).
TargetTableA - это таблица scd типа 2 с суррогатным ключом, сгенерированным генератором последовательности.
Основная проблема, с которой мы сталкиваемся, заключается в обработке обновления, которое еще не было вставлено (суррогатный ключ существует только в сопоставлении, а не в таблице), но пришел в тот же конвейер.
Мы должны обрабатывать все записи из SourceTableA в пакетном режиме.
Мы не можем использовать 3 разных классификатора источника, как I, U, D, из-за сложной логики поиска.
Мы не можем использовать динамический кеш, чтобы поддерживать хранилище сгенерированных суррогатных ключей, потому что мы не можем контролировать, как Oracle будет обрабатывать ins/upd/deletes. Он фактически работал, пока мы не выяснили, что он пытался обновить, прежде чем вставлять ссылочную запись.
Я нахожусь здесь.
Ex сценарий того, что должно произойти:
Вставить запись приходит, ключ генерируется для этой записи, скажем, 100. Он вставляется с active_flag = «Y» и датой_окончания является «открытым». Затем запись обновления включается для одного и того же естественного ключа, генерируется ключ, 101, а запись с новыми данными вставляется с active_flag = 'Y'. Ранее «вставленная» строка 100 деактивируется в active_flag = 'N' и end_date = (update_row) .end_date - 1 секунда.
Спасибо!
Проблема в том, что ваша таблица журналов не записывает изменения в правильном порядке или является проблемой, что informatica не может применить журнал в правильном порядке? В исходной системе вы не можете обновлять ее перед вставкой, так что где-то запись действия в этом порядке теряется. Это в журнальной таблице или в информатике? –
Проблема в том, что у нас есть один конвейер, мы не можем контролировать то, что вставлено первым. Мы тестировали это снова и снова, и мы оказались в ситуации, когда он пытался обновить то, что еще не было вставлено. С другой стороны, он работал нормально, он обновлял вставку, которая поступала в одну и ту же партию данных только потому, что БД была вставлена перед обновлением. –
Если вы используете целевой поиск (статический кеш), он не должен даже работать случайно. Потому что кеш-поиск создается перед вставкой любых записей. Динамический поиск кеша - один из способов. Другой альтернативой может быть только вставка всех записей (I, U) в текущее сопоставление и создание второго сопоставления для обновления Active_flag и даты окончания старых записей. – Samik