Mientras probaba algunos scripts de migración con una copia de los datos de producción (los scripts funcionan bien con los datos de desarrollo), encontré una situación curiosa. Una CONSTRAINT ha cambiado, así que estoy emitiendo comandos DROP + ADD:
ALTER TABLE A_DUP_CALLE
DROP CONSTRAINT A_DUP_CALLE_UK1;
ALTER TABLE A_DUP_CALLE
ADD CONSTRAINT A_DUP_CALLE_UK1 UNIQUE (
CONTROL_ID,
CALLE_AYTO_DUPL
)
ENABLE;
El comando DROP funcionó bien pero el ADD falló. Ahora estoy en un círculo vicioso. No puedo descartar la restricción porque no existe (la caída inicial funcionó como se esperaba):
ORA-02443: No se puede eliminar la restricción: restricción inexistente
Y no puedo crearlo porque el nombre ya existe:
ORA-00955: el nombre ya lo utiliza un objeto existente
Escribo A_DUP_CALLE_UK1
en el cuadro de búsqueda del desarrollador SQL y ... ¡ahí está! Propietario, nombre de la tabla, tablescape ... todo coincide: no es un objeto diferente con el mismo nombre, es mi restricción original. La tabla aparece en los detalles de la restricción, pero la restricción no aparece en los detalles de la tabla.
Mis preguntas:
- ¿Cuál es la explicación de esto?
- ¿Cómo puedo asegurarme de que no sucederá cuando realizo la actualización real en el servidor en vivo?
(El servidor es 10g XE, no tengo suficiente reputación para crear la etiqueta).
fuente
Respuestas:
Supongo que diría que Marian tiene razón y esto es causado por un índice y una restricción únicos que tienen el mismo nombre, por ejemplo:
Normalmente, cuando agrega una restricción única, se crea un índice único con el mismo nombre, pero el índice y la restricción no son lo mismo. ¡Eche un vistazo
all_indexes
para ver si hay un índice llamadoA_DUP_CALLE_UK1
e intente averiguar si algo más lo utiliza antes de soltarlo!fuente
exp
comando contiene unaCREATE UNIQUE INDEX "A_DUP_CALLE_UK1" ...
declaración que no está presente en el conjunto de scripts original.Parece muy extraño
Tu puedes correr:
para verificar si de qué tipo de objeto se queja Oracle. Luego puede ejecutar la declaración DROP apropiada para eso.
Lo único que se me ocurre es dejar caer la tabla por completo
DROP TABLE A_DUP_CALLE CASCADE CONSTRAINTS
para deshacerse de todo lo que pertenece a esa tabla y luego volver a crearla por completo.Si la tabla contiene datos valiosos, puede hacer una copia de seguridad antes:
Una vez que haya recreado la mesa, puede hacer
para restaurar los datos
fuente
Hace unos minutos tuve el mismo problema ... y encontré una explicación.
Al crear una clave primaria, Oracle crea dos objetos: una restricción y un índice que controla la parte "ÚNICA".
Al soltar la restricción, el índice permanece allí, usando el mismo nombre del índice, por lo que si ejecuta solo
Solo dejarás caer la restricción. Para soltar el índice, deberá ejecutar
Esto debería hacer el trabajo. Alternativamente, puede ejecutar ambos comandos al mismo tiempo con el comando
fuente
La restricción de clave principal viene con el índice. Cae la restricción pero no el índice. Cheque:
y ya ves
OBJECT_TYPE
esINDEX
.Así que ambos:
fuente
Hacer esto
Funcionará.
IMAGEN:
fuente
ALTER TABLE A_DUP_CALLE DROP CONSTRAINT A_DUP_CALLE_UK1;
Relationship142
y otro nombre deNOT NULL
restricción se le dioSYS_C0015910
. PorSYS_C0015910
lo tanto, se eliminó con éxito con una simple consulta ALTER, peroRelationship142
necesitaba COTIZACIONES DOBLESalter table ... add constraint "Relationship143" ...
"Relationship143"
es de hecho un nombre diferente alRELATIONSHIP143
. Pero"RELATIONSHIP143"
yRELATIONSHIP143
son idénticos"Relationship143"
propio. Probablemente fue una de sus herramientas que hizo esto. De todos modos: tal como está, su respuesta es simplemente incorrecta en el contexto de la pregunta original.