Rails: нарушение ограничений Oracle

Question

Я занимаюсь обслуживанием на сайте Rails, который я унаследовал; это связано с базой данных Oracle, и у меня есть доступ как к разработке, так и к производственным установкам сайта (каждый со своей собственной БД Oracle). Я бегу в ошибку 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), то Схема БД для сайта-разработчика идентична схеме БД. Я не эксперт Oracle; может ли кто-нибудь пролить свет на то, почему я получаю ошибку в одной установке, а не в другой?

Кстати, обе таблицы dev и production registration_ownerships заполнены большим количеством данных, включая дубликаты записей для country_ownership_id (управляемые индексом PK_REGISTRATION_OWNERSHIP). Пожалуйста, дайте мне знать, если вам нужна дополнительная информация для устранения неполадок. Мне жаль, что я уже не дал больше, но я просто не был уверен, какие детали будут полезны.

UPDATE: Я попытался удалить ограничение на производственном сервере, но это не повлияло; Я тоже не хотел отказываться от индекса, потому что я не уверен, каковы могут быть последствия, и я не хочу делать продукцию менее стабильной, чем она есть.

Любопытно, что я попытался выполнить вручную SQL, который выдавал ошибку, и Oracle принял инструкцию insert (хотя мне пришлось переносить даты в вызовы to_date() со строковыми литералами, чтобы обойти «ORA-01861: literal не соответствует строке формата "error". Что может быть здесь?

Answer 1

Как это случилось, была запасная копия модели «регистрации», лежащей вокруг каталога; даже несмотря на то, что у него другое имя («registrations_2349871.rb» или что-то в этом роде) Rails запускала все функциональные возможности модели (сохранение, проверка и т. д.) дважды, отсюда и ограничение ограничения ключа! Раньше я никогда не видел такого поведения. Удаление файла-изгоев решило проблему.

Answer 2

Основываясь на названии ограничения, PK_REGISTRATION_OWNERSHIP, у вас есть нарушение первичного ключа. Если эти базы данных не поддерживают эти данные в блокировке, что-то/кто-то уже вставил запись в таблицу registration_ownerships в вашу производственную базу данных с помощью company_ownership_id = 2 & registration_id = 2920. (Я предполагаю, что на специфику на основе имен)

Если этот конкретный набор значений должен существовать в базе данных производства,

1) проверить, что там уже не то, что вы пытаетесь вставить. если да, то все готово.

2) Если вы необходимости для вставки данных образцов как есть, вам необходимо изменить существующие данные & повторно вставить его (и все зависимые/Отсносящиеся записи), то вы можете вставить свои значения.

Answer 3

Если запрос таблицы и не найти соответствующих строк, то один из следующих может быть причиной:

1. Сеанс пытается вставить строку дважды.
2. Другая сессия вставила строку, но еще не зафиксирована.

Кроме того, убедитесь, что состояние уникального ограничения одинаково между dev и prod. Возможно, тот, что на dev отмечен как не проверенный, - проверьте, что индекс существует на dev и является индексом (обратите внимание: в Oracle возможно иметь уникальное ограничение, подтвержденное неидеальным индексом).

Answer 4

Внимательно изучите базовый уникальный индекс для ограничения. Причина отказа от ограничения ничего не меняет, потому что индекс остается, и это уникальный индекс.Что расскажет вам об индексах в обеих средах? Имеются ли оба индекса? Оба они определены одинаково? Действительно ли они оба уникальны?

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;