I have two tables one is Parent and Child. Parent table have primary constraint on it and the Child table have a foreign key constraint on it. Now I want to drop the Parent table without deleting or dropping constraints which are there on child table.
I have tried disabling the constraints on both parent and child table and tried to drop the parent table. But still I was not able to drop the Parent table.
And If the delete the primary constraint on the parent delete, then it also drops the foreign key constraint on the child table.
Please if any one can help me out.
Thanks.
You can't drop a parent table if you have a child table with a foreign key constraint in place, unless you specify the CASCADE CONSTRAINTS clause:
DROP TABLE P CASCADE CONSTRAINTS;
This command drops the FK constraint too.
Deleting a table will necessarily drop all constraints related to this table. if a table is referenced by this table, you will have to drop those constraints first before to avoid rules violation.
*The oracle documentation says: *
http://docs.oracle.com/cd/B28359_01/server.111/b28310/tables010.htm#ADMIN01505
The following statement drops the t table:
DROP TABLE t;
If the table to be dropped contains any primary or unique keys referenced by foreign keys of other tables and you intend to drop the FOREIGN KEY constraints of the child tables, then include the CASCADE clause in the DROP TABLE statement, as shown below:
DROP TABLE t CASCADE CONSTRAINTS;
Weird... if you disabled correctly the constraints you should be able to delete parent table without any error.
:|
Related
Scenario: We have table A (Parent Table) referring to table B (Child Table) and also we have Foreign Key Index for every Foreign Key.
Operation: Now when any user is deleting a row from table A then table B is getting locked even if there are no referring record in child table. Because of this other user cannot do anything on table A anymore since the table is locked.
Understanding: I suppose when there are some child record exists in table B then the selected row should only be locked if the parent record is involved in some transaction and other users can still work on other rows of table A.
Question: How does it work when we have foreign key and foreign key index are created but there are no child record exists. The whole table is still locked? If yes how to get rid of it then?
Note: I am using Oracle 12c.
You should have indexes on all foreign keys, otherwise you'll get TM table locks:
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:292016138754
http://www.oaktable.net/content/tm-locking-checking-missing-indexes-foreign-key-constraints
Now when any user is deleting a row from table A then table B is getting locked even if there are no referring record in child table.
If you have index on foreign key in child table, you get only TX row locks in child table. If you foerign key is not indexes, you get TM table lock on whole child table.
I have a table with Col1 and Col2 as a composite primary key pk_composit_key and a unique index that was automatically created for the constraint.
I then altered the table to add new column Col3.
I dropped the pk_composit_key constraint:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key;
Now, When I tried to insert records I got ORA-00001: unique constraint pk_composit_key violated.
Why am I getting that error?
When the key was dropped why wasn't the unique index dropped automatically?
You mentioned exporting and importing the schema, and if that happened in the environment that showed this behaviour it would explain what you're seeing; at least if you used legacy imp rather than the data pump impdp.
The original import documentation states the order objects are imported:
Table objects are imported as they are read from the export dump file. The dump file contains objects in the following order:
Type definitions
Table definitions
Table data
Table indexes
Integrity constraints, views, procedures, and triggers
Bitmap, function-based, and domain indexes
So the unique index would have been imported, then the constraint would have been created.
When you drop a primary key constraint:
If the primary key was created using an existing index, then the index is not dropped.
If the primary key was created using a system-generated index, then the index is dropped.
Because of the import order, the constraint is using an existing index,so the first bullet applies; and the index is retained when the constraint is dropped.
You can use the drop index clause to drop the index even if it wasn't created automatically:
ALTER TABLE table_name DROP CONSTRAINT pk_composit_key DROP INDEX;
See also My Oracle Support note 370633.1; and 1455492.1 suggests similar behaviour will occur with data pump import as well. I'm not aware of any way to check if an index is associated with a constraint at this level; there is no difference in the dba_constraints or dba_indexes views when you create the index manually or automatically. Including drop index will make it consistent though.
It depends on how unique index was created...below are the various ways and behaviour
1) first create unique index (on the column for which primary key to be defined) and then add the primary key constraint. In this situation your DDL to add the primary key will utilize the existing unique index. So when you drop the primary key it will not drop the index but only primary key. ==> this is your situation I guess...
2) While creating the table you define the primary key OR when you add the primary key when there was no existing unique index for the column(s) on which primary key to be defined, so system will create a unique index and use it for primary key. So in this case when you drop the primary key the unique index will also get dropped.
I need to modify an existing PK. Therefore I drop an recreate it.
ALTER TABLE B DROP CONSTRAINT PK_B;
ALTER TABLE B ADD CONSTRAINT PK_B PRIMARY KEY ("TYP", "NR", "HH", "QUART");
Unfortunately the last Statement will give me an error ORA-00955
If I create the PK constraint like it was defined originally with:
ALTER TABLE B ADD CONSTRAINT PK_B PRIMARY KEY ("TYP", "NR", "HH");
everything works fine.
Perhaps there is an INDEX associated with the PRIMARY KEY CONSTRAINT, and it is also named as PK_B.
You can check it as :
SELECT * FROM USER_INDEXES WHERE TABLE_NAME='<table_name>';
If that's true, then do :
ALTER INDEX "PK_B" RENAME TO "PK_XYZ";
Update : Regarding ALTER INDEX statement, few important points as mentioned by Justin in the comments
Oracle implicitly creates an UNIQUE index to support the PRIMARY KEY CONSTRAINT. Since, the index is of the same name that of the primary key, and now that the primary key is being modified, it is better to drop and re-create the index again as per the definition of the old primary key.
My conclusion :
The primary key constraint is enforced through a unique index.
If Oracle already finds an index – unique or non-unique – it uses it
for the primary key.
If the index was initially created as non-unique, it will continue to
show as non-unique, however it will actually be a unique index.
A good demonstration and quite detailed on other aspects too, by Arup : Primary Keys Guarantee Uniqueness? Think Again.
I had the same issue where I had to do the following to delete reference to a table from the view whilst recreating the database from the scratch. I was searching for the same in tables and indexes first.
connect sys/oracle as sysdba;
select * from all_tables
select * from all_indexes
(finally located the reference in the views)
select * from all_views where view_name like '%WKSTSTATE%';
drop view RUEGEN.WKSTSTATE;
I'm working on H2 database, and I meet this problem -
to drop one constraint is fine, I can use this statement
alter table customer drop constraint if exists fk_customer_order ;
for add one constraint is fine too, I can use this statement.
alter table customer add constraint fk_customer_order foreign key (order_id) references order (id) on delete cascade on update cascade;
but the problems is, in customer table I have more foreign key and I want delete them in one query statement.
Something like this
alter table customer drop constraint fk_customer_order
drop constraint fk_customer_information
drop constraint ....
but this seem can not be done in h2 database, anyone can tell me can or not add or drop multi constraint by 1 sql statment? Any answer are welcome and I appreciate much.
I think it can not be done. Why don't you use multiple statements?
I have a application database where there are lots of different copies of the schema on different servers (developers, stag, prod etc)
I have two tables that were related by a FK contraint like
Foo.fk = Bar.Id
I want to drop the Bar table. but I don't want to drop the Foo.fk column. I just want to remove the constraint from it.
The problem is that the script that originally created the constraint made it different in different environments. Is there a way to remove the constraint by some way other than drop by name?
No need to drop the constraint manually:
DROP TABLE bar CASCADE CONSTRAINTS;
will drop the bar table and any constraint referencing it.