Обновление столбца даты с sysdate, бросающим Uniuqe ограничение ограничения в оракуле.Случайно происходит, поскольку Дата является первичным ключом

Question

У меня есть два файла sqls, которые содержат более 300000 записей в каждом. Проблема в том, что есть некоторые повторяющиеся записи, которые получают обновление что вызывает уникальную проблему нарушения ограничения. Пожалуйста, найдите пример ниже

Planid + Last_mod_Date - составной первичный ключ в таблице PLAN_HISTORY. Присутствует таблица PLAN_HISTORY, куда записи вставляются с использованием PLAN_HISTORY_TRIGGER всякий раз, когда таблица PLAN получает обновление. которая вызывает эту проблему случайным образом, когда sysdate одинаков.

Пример:

File 1: 

UPDATE plan SET enroll_id = '1', Last_mod_Dt = sysdate where plan_id = '1234';

File 2 : 

UPDATE plan SET plan_name = 'TPA', Last_mod_Dt = sysdate where plan_id = '1234';

Поскольку существует много записей, которые могут получить дубликаты для PLAN_ID + SYSDATE (last_mod_dt). как я могу избежать этой проблемы?

Я думаю о некоторых решениях, таких как

1. ДОБАВЛЯТЬ секунды в sysdate, но опять-таки будет выдано то же исключение, что и в некоторый момент времени.

2. Я могу добавить некоторую задержку между двумя файлами, но не уверен, насколько это возможно в Oracle

3. Последний вариант - мне нужно найти все дубликаты плановых идентификаторов из двух файлов и поместить их в один оператор обновления.

Но есть ли хорошие решения для подобных задач?

Answer 1

Вы сказали:

Planid + Last_mod_Date - это первичный ключ в таблице PLAN. Присутствует таблица PLAN_HISTORY, которая обновляется с помощью PLAN_HISTORY_TRIGGER всякий раз, когда таблица плана получает обновление. которая вызывает эту проблему случайным образом, когда sysdate одинаков.

Извлечь last_mod_date из первичного ключа; Ваша главная таблица должна иметь только одну запись для plan_id (самая последняя). Первичный ключ для PLAN должен быть следующим: plan_id

Ваш триггер вставляет (вы сказали обновление; нет, это должна быть вставка) старых значений строки из PLAN в таблицу PLAN_HISTORY во время выполнения обновления. Таблица истории не должна иметь первичного ключа , только неуникальный индекс для идентификатора плана. Таблица истории может также извлечь пользу из столбца даты, в котором указано, когда старые значения стали недействительными (обновлены)

Запросы, которые вы разместили, не сразу могут привести к возникновению этой проблемы, если только вы не указали более одного кода плана 1234 в таблице плана. Я не думаю, что вы делаете это, потому что вы не помещаете last_mod_date в предложении where, и это большая проблема - иметь составной первичный ключ в таблице, но не указывать один из ее столбцов в предложении where , Я думаю, что ваша проблема в том, что вы поместили первичный ключ в таблицу истории, чтобы два обновления были запущены достаточно быстро, чтобы триггер делал вставки в таблицу истории перед изменением sysdate, вызывая нарушение PK.