Question

Say I have two tables:

create table parent (
  id number not null,
  constraint parent_pk primary key(id),
)

create table child (
  id number not null,
  parent_id number not null,
  constraint child_pk primary key(id),
  constraint child_fk1 foreign key(parent_id)
    references parent(id)
)

The parent table is big, say, 3 millions records. Now I run delete statement:

delete from parent; //even without where clause

Could you please explain what actually happens when this statement is executed? Where is no “ON DELETE CASCADE” option specified, as far as I understand it means that delete from parent table should fail if the child table contains references to parent id. So this means that before deleting the row from parent table Oracle should check if any child records exists. But this is really extremely slow – it’s row-by-row delete.

Am I correct? If not, please explain how Oracle works when deleting from parent table and check whether there are no orphans left in child table?

Answer 1

Here’s a test. My PARENT table has 100000 rows. Against an empty CHILD table (with an index on PARENT_ID) deletion takes this long:

SQL> set timing on
SQL> delete from parent;

100000 rows deleted.

Elapsed: 00:00:07.24
SQL> 

Let’s insert some rows into CHILD. This will generate one row for every row in PARENT

SQL> insert into child
  2  select level, level from dual
  3  connect by level <= 100000;


100000 rows created.

Elapsed: 00:00:02.21
SQL> 

If we delete from parent now, it fails instantly.

SQL> delete from parent;
delete from parent
*
ERROR at line 1:
ORA-02292: integrity constraint (APC.CHILD_FK1) violated - child record found


Elapsed: 00:00:00.14
SQL> 

Whereas, if we have every record in CHILD point to just one record in PARENT it takes a bit longer…

SQL> update child set parent_id=99999;

100000 rows updated.

Elapsed: 00:00:09.65
SQL> commit;

SQL> delete from parent;
delete from parent
*
ERROR at line 1:
ORA-02292: integrity constraint (APC.CHILD_FK1) violated - child record found


Elapsed: 00:00:07.32

Wallclock timings are notoriously unreliable, but that looks like roughly the same amount of time. And as it happens, the time to delete the PARENT table without foreign key dependencies is in the same ballpark:

SQL> drop table child;

Table dropped.

Elapsed: 00:00:02.29
SQL> delete from parent;

100000 rows deleted.

Elapsed: 00:00:06.54
SQL> 

So, basically, there is little or no overhead to check the foreign key constraint

There is a proviso: this is true providing the foreign key column is indexed. I dropped the CHILD_FK1_I index, and the delete from parent statement still hasn’t finished in the time it’s taken me to type up this response i.e. about ten minutes.