Почему при удалении первичного ключа не удаляется его уникальный индекс?

  1. У меня есть таблица с Col1 и Col2 в качестве составного первичного ключа pk_composit_key и уникального индекса, который был автоматически создан для ограничения.
  2. Затем я изменил таблицу, добавив новый столбец Col3.

  3. Я снял ограничение pk_composit_key:

    ALTER TABLE имя_таблицы DROP CONSTRAINT pk_composit_key;

  4. Теперь, когда я попытался вставить записи, я получил ORA-00001: unique constraint pk_composit_key violated.

    • Why am I getting that error?
    • Когда ключ был сброшен, почему уникальный индекс не был удален автоматически?

oracle composite-primary-key unique-constraint
person touchchandra    schedule 28.10.2015    source источник
comment
Были ли вставленные вами записи просто нарушением нового трехзначного составного ключа, у которого в любом случае будет индекс с тем же именем? Вы не можете делать то, что сказали. Если бы индекс был создан автоматически первым ограничением, он был бы удален. Если бы он был создан вручную до ограничения, то он остался бы после отбрасывания, но создание второго ограничения не удалось бы, потому что существующий индекс теперь не соответствует столбцам ограничения.   -  person Alex Poole    schedule 28.10.2015
comment
@AlexPoole, когда мы отбрасываем ограничение, индекс все еще существует. затем, когда мы пытаемся вставить новую запись, он говорит о нарушении уникального индекса. Я немного обновил вопрос   -  person touchchandra    schedule 28.10.2015
comment
Вы получаете нарушение уникального индекса, когда пытаетесь нарушить ограничение, это нормально. Вы говорите, что получили эту ошибку до того, как попытались воссоздать первичный ключ? Или после воссоздания? Как вы проверяли, что он все еще существует после первого падения? На данный момент я не уверен, что вы просто неверно истолковываете ошибку, которую получаете, когда вставляете данные, которые действительно имеют повторяющиеся значения col1, col2, col3; или, если вы не воссоздали ограничение, создавали ли вы индекс вручную в первый раз.   -  person Alex Poole    schedule 28.10.2015
comment
@AlexPoole Я получил ошибку на шаге 4 при вставке. Новое ограничение еще не создано. Я могу указать это имя индекса в user_indexes.   -  person touchchandra    schedule 28.10.2015
comment
Можете ли вы создать тестовый пример, содержащий все операторы создания таблицы, ограничения и т. д., который воспроизводит проблему, пожалуйста? Таким образом, мы можем попробовать повторить те же шаги для себя, что позволит нам лучше помочь вам.   -  person Boneist    schedule 28.10.2015
comment
@AlexPoole, я не могу воспроизвести проблему, потому что я пытался создать, но такое поведение не наблюдается в среде разработки. При чем тут экспорт и импорт схемы?   -  person touchchandra    schedule 28.10.2015
comment
@touchchandra - да, это могло создать индекс до ограничения. Я не могу вспомнить, может ли это imp или impdp, я давно это не видел. Оригинальный импортный думаю. Вы можете подтвердить, что это то, что вы использовали?   -  person Alex Poole    schedule 28.10.2015

Ответы (2)


arrow_upward
9
arrow_downward

Вы упомянули об экспорте и импорте схемы, и если это произойдет в среде, которая демонстрирует такое поведение, это объяснит, что вы видите; по крайней мере, если вы использовали устаревшую imp, а не перекачку данных impdp.

Исходная документация по импорту утверждает, что объекты заказа импортировано:

Объекты таблицы импортируются по мере чтения из файла дампа экспорта. Файл дампа содержит объекты в следующем порядке:

  • Определения типов
  • Определения таблиц
  • Табличные данные
  • Индексы таблиц
  • Ограничения целостности, представления, процедуры и триггеры
  • Растровые, функциональные и доменные индексы

Таким образом, уникальный индекс был бы импортирован, а затем было бы создано ограничение.

Когда вы отбрасываете ограничение первичного ключа:

  • Если первичный ключ был создан с использованием существующего индекса, то индекс не удаляется.
  • Если первичный ключ был создан с использованием индекса, созданного системой, то индекс удаляется.

Из-за порядка импорта ограничение использует существующий индекс, поэтому применяется первый маркер; и индекс сохраняется при снятии ограничения.

Чтобы удалить index, даже если он не был создан автоматически:

ALTER TABLE table_name DROP CONSTRAINT pk_composit_key DROP INDEX;

См. Также My Oracle Support note 370633.1; и 1455492.1 предполагает, что аналогичное поведение будет происходить и при импорте перекачки данных. Я не знаю, как проверить, связан ли индекс с ограничением на этом уровне; нет никакой разницы в dba_constraints или dba_indexes представлениях, когда вы создаете индекс вручную или автоматически. Однако включение drop index сделает его согласованным.

person Alex Poole    schedule 28.10.2015
comment
Нашел это Поскольку вы выполнили экспорт и импорт, импорт работает путем создания отдельного индекса и затем отдельного добавления ограничения первичного ключа. Поскольку в случае импорта эти две вещи происходят отдельно, удаление первичного ключа теперь НЕ приведет к удалению индекса. community.oracle.com/message/1223619 - person touchchandra; 28.10.2015

arrow_upward
2
arrow_downward

Это зависит от того, как был создан уникальный индекс ... ниже приведены различные способы и поведение

1) сначала создайте уникальный индекс (в столбце, для которого должен быть определен первичный ключ), а затем добавьте ограничение первичного ключа. В этой ситуации ваш DDL для добавления первичного ключа будет использовать существующий уникальный индекс. Поэтому, когда вы отбрасываете первичный ключ, он удаляет не индекс, а только первичный ключ. ==> Думаю, это твоя ситуация ...

2) При создании таблицы вы определяете первичный ключ ИЛИ при добавлении первичного ключа, когда не было существующего уникального индекса для столбца (столбцов), для которого должен быть определен первичный ключ, поэтому система создаст уникальный индекс и будет использовать его для первичный ключ. Таким образом, в этом случае, когда вы отбрасываете первичный ключ, уникальный индекс также будет удален.

person narendra    schedule 28.10.2015
comment
За исключением того, что в вопросе указано, что индекс был создан автоматически. Что, конечно, может быть неверным - скорее всего, описание того, что произошло, не совсем правильное. Хотя это было бы странное название для отдельного уникального индекса. (Кроме того, ссылка на документ для поведения ). - person Alex Poole; 28.10.2015
comment
Да @AlexPoole, я предполагал, что уникальное ограничение было создано автоматически при создании ограничения. Можем ли мы подтвердить, создано ли оно вручную или автоматически? - person touchchandra; 28.10.2015
comment
если ограничение или индекс создается системой автоматически, тогда у него будет другое соглашение об именах (SYS%), то же самое будет показано в сообщении об ошибке, это не будет pk_composit_key в сообщении об ошибке. - person narendra; 28.10.2015
comment
@narendra, вот как создавалась таблица в производственной среде CREATE TABLE DATA_SOURCE (COL1 VARCHAR2 (4), COL2 VARCHAR2 (4), COL3 VARCHAR2 (200), DATA1 VARCHAR2 (30), DATA2 VARCHAR2 (30) CONSTRAINT_ PK_COMPOSITARY_KOMPOSITARY_KEY) , COL2)); - person touchchandra; 28.10.2015
comment
@narendra - только если не назван; если вы назовете ограничение, имя индекса будет совпадать. - person Alex Poole; 28.10.2015
comment
@AlexPoole, да, я думаю, поэтому имена ограничений и индексов совпадают. - person touchchandra; 28.10.2015
comment
да, имя ограничения и имя индекса в этом случае будут такими же, но если вы удалите ограничение, уникальный индекс также будет удален. - person narendra; 28.10.2015