andrey_anonymousНуфьсо.
Если старшие товарищи сказали дед Лок - значит дед Лок.
Это плохо, наверное, да?
Побегу срочно переделывать все ETLи, а то мерджат, собаки, по 10-20 миллионов за один присест...
))))))))))))))))))))))))))))

AmKad,

Вы правы, с этого и надо было начать )))
Есть две таблицы operation в двух БД по ДБ-линку, достаточно большие, записей больше миллиона, много столбцов, почти на всех fk-ключи, есть pk
недавно добавили новый столбец в двух БД в этих таблицах
Синхронизация происходит по джобу, но с какого-то момента, эти таблицы перестали синхронизироваться совсем.
Была проблема с датами, вроде удалось решить
теперь почему-то курсор не отрабатывает, думал переписать под merge, но не знаю как быстро это может отрабатывать.
Логика следующая - берётся select за определённый интервал с последней даты синхронизации по текущую, и по нму бежит курсор и уже update и insert

Вот. На сколько я понял, merge может так же мержить от этого селекта за последний интервал времени, однако кол-во записей м.б. больше 1000 за указанный период времени...

=nomad=У вас БД на линках - обе Oracle?
Да

=nomad=Это разовое действие? Может просто тогда склонировать одну таблицу в другую? А потом пусть работает ваш джоб-синхронизатор?
Может быть, но он не синхронизирует, а должен, там курсор стоит, почему он не отрабатывает не могу понять, хотел переписать на merge, но не знаю, будет ли тормозить или нет (((

=nomad=stax..ето шютка Ваших товарищей
Может не совсем так. Видя как RMagistr2015 задает вопросы, то может они отвечали не на тот вопрос, или не так, как тут приведено, или что-то другое.
Например, у меня был deadlock, когда я попробовал merge делать с базы ms sql. Или Doc ID 5970280.8 исправление патча для Oracle 10/11. Ну и так далее.
Спасибо Вам большое )))
Буду рад почитать ваш "API" по задаванию Вам вопросов )))
API-query - connecting peoples ;-)))

Evgeny2RMagistr2015AmKad,

Вы правы, с этого и надо было начать )))
Есть две таблицы operation в двух БД по ДБ-линку, достаточно большие, записей больше миллиона, много столбцов, почти на всех fk-ключи, есть pk
недавно добавили новый столбец в двух БД в этих таблицах
Синхронизация происходит по джобу, но с какого-то момента, эти таблицы перестали синхронизироваться совсем.
Была проблема с датами, вроде удалось решить
теперь почему-то курсор не отрабатывает, думал переписать под merge, но не знаю как быстро это может отрабатывать.
Логика следующая - берётся select за определённый интервал с последней даты синхронизации по текущую, и по нму бежит курсор и уже update и insert

Вот. На сколько я понял, merge может так же мержить от этого селекта за последний интервал времени, однако кол-во записей м.б. больше 1000 за указанный период времени...

Ты сначала из удаленной БД сделай выгрузку таблицы по предикату изменения на свою сторону в GTT (on commit preserve rows).
Потом merge на своей стороне с факторной таблицей и GTT.

Если merge будет делаться долго и будет вылетать на snapshot too old.
То разбей с цикле по периодам времени. (не сколько я понимаю в таблице есть время)
И выполняй себе спокойно.
В пакете сделай логирование в спец таблицу, чтобы контролировать время выполнения каждого DML и сообщений об ошибках.
К этой мысли я то же приходил, спасибо Вам большое )))) Очень дельный совет )))

Evgeny2RMagistr2015пропущено...

К этой мысли я то же приходил, спасибо Вам большое )))) Очень дельный совет )))

Как успехи? какое время показывает синхронизация?
Пока отложил, думаю вернуться в свободное время )))