sakthikumar
asked on
How to speed up deleting rows, when there are child tables?
Hi,
I want to delete nearly 9000 rows from a table of 4 million rows.
The table is having two child tables.
The table is having primary key.
primary key is used when deleting.
I tried the following, but still it is taking 3 hours
Forall statement.
Nologging.
Delete using ROWID.
Please let me know is there any other general approach, I can try.
If you want I want, I can post more details tomorrow.
I want to delete nearly 9000 rows from a table of 4 million rows.
The table is having two child tables.
The table is having primary key.
primary key is used when deleting.
I tried the following, but still it is taking 3 hours
Forall statement.
Nologging.
Delete using ROWID.
Please let me know is there any other general approach, I can try.
If you want I want, I can post more details tomorrow.
I assume you have cascading constraints. If that is the case, don't use the constraints to do the deletes of the child tables. Delete them yourself. Locking down the parent child tree and then deleting back up the tree takes a lot of time. We have found that deleting children first, then parents is much faster.
Does the child table have an index on the foreign_key columns referring to the parent table ?
Hi,
The forall approach is ok if you want to do it online. You can do intermediate commits and run it ad several times for few rows. And as you can do it online, the duration should not matter.
Note that NOLOGGING has no meaning here for the delete statement.
Regards,
Franck.
The forall approach is ok if you want to do it online. You can do intermediate commits and run it ad several times for few rows. And as you can do it online, the duration should not matter.
Note that NOLOGGING has no meaning here for the delete statement.
Regards,
Franck.
ASKER
If I disable the constraints, it is very fast. let me check the other things.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please post the entire SQL statement, changing names as necessary.
ASKER
Correct. It was not indexed, When it is indexed, it is fast.
Thank you very much.
Thank you very much.
Based on 9000/4000000, that's should be quick.
Less than a minute even with full table scans.
Any triggers firing?
And the most likely cause - any blocking locks from other sessions on the parent or any of the children?