The purpose of this post is to discourage DBAs from creating “Enabled” foreign keys on tables that are expected to have bulk operations. I still suggest to create foreign keys but disable them so designers, DBAs and developers will still know which tables are related.
Our test cases were run in our development environment which is 10.2.0.5 RAC sitting on HP Itanium.
The target was to delete a few million rows from 2 tables which were related 1 to many with an enabled foreign key “on delete cascade”.
The initial plan was simple:
1) Delete from child table first so we can eliminate lookups from parent to child.
2) Delete from parent .
3) Use a nice parallel hint for both steps.
We tested our plan with about 35,000 rows.
First step went fine, but second step the query went for a long time, when we checked, we found that query is waiting for TX Lock even though we executed the query in the same session.
Why wait for TX Lock in the same session?
This is because the first query was using a parallel hint which created parallel sessions. These parallel sessions locked the rows in the child table. You couldn’t move forward unless we issue a commit.
You can also produce the same behavior in a single instance environment without using any parallelism by doing the following simple steps:
1) Delete child row
2) Create a new session and then delete the parent row.
The deletion of the parent row will hang until you commit in the child row.
Foreign Keys Performance
The following test cases were executed for about 35,000 rows. Every time we delete, we copy the data back.
We deleted child data first, committed and then deleted from parent table, it took 75 seconds
We deleted directly from parent table, it took 75 seconds (apparently there is no gain from deleting from child table first then deleting from parent table, bummer!)
We disabled foreign keys, delete from child, then delete from parent, total time was 12 seconds only, 6 times as fast.
Foreign Keys are excellent for ERD diagrams and remind everybody which tables are related, but physically disable them and you should live happily every after.
Senior Oracle DBA