Направляющие: ограничительное нарушение Oracle
Я делаю работы по техническому обслуживанию сайта направляющих, который я наследовал; это управляется базой данных Oracle, и у меня есть доступ и к разработке и к производственным установкам сайта (каждый с его собственной Oracle DB). Я сталкиваюсь с ошибкой Oracle при попытке вставить данные по месту производства, но не dev сайт:
ActiveRecord::StatementInvalid (OCIError: ORA-00001: unique constraint (DATABASE_NAME.PK_REGISTRATION_OWNERSHIP) violated: INSERT INTO registration_ownerships (updated_at, company_ownership_id, created_by, updated_by, registration_id, created_at) VALUES ('2006-05-04 16:30:47', 3, NULL, NULL, 2920, '2006-05-04 16:30:47')):
/usr/local/lib/ruby/gems/1.8/gems/activerecord-oracle-adapter-1.0.0.9250/lib/active_record/connection_adapters/oracle_adapter.rb:221:in `execute'
app/controllers/vendors_controller.rb:94:in `create'
Насколько я могу сказать (я использую Navicat в качестве клиента Oracle), схема DB для dev сайта идентична тому из живого сайта. Я не эксперт Oracle; кто-либо может пролить свет на то, почему я получил бы ошибку в одной установке а не другом?
Кстати, и dev и производство registration_ownerships таблицы заполняются с большим количеством данных, включая дублирующиеся записи для country_ownership_id (управляемый индексом PK_REGISTRATION_OWNERSHIP). Сообщите мне, нужно ли Вам больше информации для поиска и устранения неисправностей. Я сожалею, что больше уже не дал, но я просто не был уверен, какие детали будут полезны.
ОБНОВЛЕНИЕ: я попытался отбросить ограничение на рабочий сервер, но это не имело никакого эффекта; я не хотел отбрасывать индекс также, потому что я не уверен, чем могли бы быть последствия, и я не хочу делать производство менее стабильным, чем это уже.
Любопытно, я пытался выполнить вручную SQL, который бросал ошибку, и Oracle приняла оператор вставки (хотя я должен был перенести даты в to_date () вызовы со строковыми литералами для обхождения "РТОВ 01861: литерал не соответствует строке формата" ошибка). Что могло бы продолжаться здесь?
4 ответа
Как оказалось, в справочнике валялась запасная копия модели "регистрации"; даже несмотря на то, что у него было другое имя («registrations_2349871.rb» или что-то в этом роде) Rails выполнял все функции модели (сохранение, проверка и т.д.) дважды, отсюда и нарушение ключевого ограничения! Я никогда раньше не видел такого поведения. Удаление мошеннического файла решило проблему.
Исходя из названия ограничения, PK_REGISTRATION_OWNERSHIP , у вас нарушение первичного ключа. Если в этих базах данных эти данные не поддерживаются синхронно, что-то / кто-то уже вставил запись в таблицу registration_ownerships в вашей производственной базе данных с company_ownership_id = 2 & registration_id = 2920. (Я предполагаю особенности, основанные на именах)
Если этот конкретный набор значений должен существовать в производственной базе данных,
1) проверьте, что то, что уже есть, не то, что вы пытаетесь вставить . если это так, все готово.
2) Если вам требуется для вставки данных образца как есть, вам необходимо изменить существующие данные и повторно вставить их (и все зависимые / ссылающиеся записи), затем вы можете вставить свои ценности.
Если вы запрашиваете таблицу и не находите подходящих строк, причиной может быть одна из следующих причин:
- Сеанс пытается вставить строку дважды.
- Другой сеанс вставил строку, но еще не зафиксировал ее.
Также убедитесь, что состояние уникального ограничения одинаково для dev и prod. Возможно, тот, который находится на dev, отмечен как непроверенный - убедитесь, что индекс существует на dev и является уникальным индексом (примечание: в Oracle возможно иметь уникальное ограничение, подтвержденное неуникальным индексом) .
Внимательно посмотрите на базовый уникальный индекс ограничения. Причина, по которой снятие ограничения ничего не меняет, заключается в том, что индекс остается, и это уникальный индекс. Что следующее говорит вам об индексах в обеих средах? Оба индекса действительны? Оба они определены одинаково? Действительно ли они оба уникальны?
SELECT ai.table_name, ai.index_name, ai.uniqueness, aic.column_name, ai.status
FROM all_constraints ac JOIN all_indexes ai ON (ac.index_name = ai.index_name)
JOIN all_ind_columns aic ON (ai.index_name = aic.index_name)
WHERE ac.owner = 'YOUR_USER'
AND ac.constraint_name = 'PK_REGISTRATION_OWNERSHIP'
ORDER BY ai.index_name, column_position;