Обновление столбца даты с помощью sysdate вызывает нарушение ограничения Uniuqe в оракуле. Происходит случайным образом, поскольку Дата является первичным ключом
У меня есть два файла 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). как я могу избежать этой проблемы?
Я думаю о некоторых решениях, таких как
ДОБАВЬТЕ секунды к sysdate, но снова будет выдано то же исключение, что и дата в какой-то момент времени.
Я могу добавить некоторую задержку между двумя файлами, но не уверен, насколько это возможно в оракуле.
последний вариант: мне нужно найти все повторяющиеся идентификаторы планов из двух файлов и поместить их в один оператор обновления.
Но есть ли хорошие решения для подобных тезисов?
Ответы 1
Ты сказал:
Planid + Last_mod_Date is Primary Key in PLAN table. There is PLAN_HISTORY table present which gets update by using PLAN_HISTORY_TRIGGER whenever plan table gets update. which is causing this issue randomly whenever sysdate is same.
Убрать last_mod_date из первичного ключа; в вашей основной таблице должна быть только одна запись для plan_id (самая последняя). Первичный ключ для PLAN должен быть: plan_id
Пусть ваш триггер вставлять (вы сказали обновление; нет, это должна быть вставка) вводит старые значения строк из PLAN в таблицу PLAN_HISTORY во время выполнения обновления. Таблица истории не должна иметь первичный ключ, просто неуникальный индекс для идентификатора плана. В таблице истории также может быть полезен столбец даты, в котором указано, когда старые значения стали недействительными (обновлены).
Запросы, которые вы разместили, сразу не кажутся вызывающими эту проблему, если вы не поместите более одного идентификатора плана 1234 в свою таблицу планов. Я не думаю, что вы делаете это, потому что вы не помещаете last_mod_date в предложение where, и это серьезная проблема иметь составной первичный ключ в таблице, но затем не указывать один из его столбцов в предложении where. . Я думаю, ваша проблема в том, что вы поместили первичный ключ в таблицу истории, поэтому запуская два обновления достаточно быстро, чтобы триггер делал вставки в таблицу истории до изменения sysdate, вызывая нарушение PK.
Спасибо, Кайус, что поправил меня. да, вы правы, триггер PLAN_HISTORY вставляет записи в таблицу PLAN_HISTORY, где присутствует составной ключ, вызывающий проблему PLAN_ID+LAST_MOD_DT. его структура таблицы 5 лет, и я не могу изменить таблицу для этой проблемы.
Я бы сказал, что вы можете; что перестанет работать, если вы удалите первичный ключ из таблицы истории и замените его неуникальным индексом? Это баг, его надо исправлять, не важно сколько ему лет
Как решить эту проблему? Не используйте столбец даты в первичном ключе. Вместо этого я бы порекомендовал какое-то целое число с автоинкрементом.