Oracle Scratchpad

February 16, 2017

Truncate 12c

Filed under: 12c,Infrastructure,Oracle — Jonathan Lewis @ 12:52 pm GMT Feb 16,2017

Here’s one of those little improvements in 12c (including 12.1) that will probably end up being described as “little known features” in about 3 years time. Arguably it’s one of those little things that no-one should care about because it’s not the sort of thing you should do on a production system, but that doesn’t mean it won’t be seen in the wild.

Rather than simply state the feature I’m going to demonstrate it, starting with a little code to build a couple of tables with referential integrity:

create table parent (
        id      number(4),
        name    varchar2(10),
        constraint par_pk primary key (id)

create table child(
        id_p    number(4)
                        constraint chi_fk_par
                        references parent
                        on delete cascade,
        id      number(4),
        name    varchar2(10),
        constraint chi_pk primary key (id_p, id)

insert into parent values (1,'Smith');
insert into parent values (2,'Jones');

insert into child values(1,1,'Sally');
insert into child values(1,2,'Simon');

insert into child values(2,1,'Jack');
insert into child values(2,2,'Jill');


There’s one important detail in this code that isn’t taking the default and isn’t used very frequently – it’s the option on the foreign key to take the action “on delete cascade”. If you delete a row from the parent table then Oracle will automatically delete any referenced rows from the child table first thus avoiding the error ORA-02292: integrity constraint (TEST_USER.CHI_FK_PAR) violated – child record found. (Conveniently I have a suitable index on the child table that will bypass the problem of a mode 4 (or, where child rows already exist, mode 5) TM lock being taken on the child as the parent row is deleted.)

And here’s the demonstration of the new feature – working in 12.1 onwards:

truncate table parent;

truncate table parent cascade;

The first command will raise Oracle error ORA-02266: unique/primary keys in table referenced by enabled foreign keys, but the second command will truncate the parent and child tables “simultaneously”: but only if the referential integrity constraint is set to “on delete cascade”. If the referential integrity constraint is left to its default action then the second command will raise error: ORA-14705: unique or primary keys referenced by enabled foreign keys in table “TEST_USER”.”CHILD”

This feature (and several broadly similar features) also works with matching partitions of equi-partitioned (or ref partitioned) tables – and that’s a context where the requirement  is much more likely to appear than with non-partitioned tables.



  1. Just to add – its a “full” cascade, ie, we’ll keep walking down the referential integrity “tree” merrily truncating as we go. So if you have one of those data models with a global reference table at the top of the tree…. I would advise against truncating that :-)

    Comment by connormcdonald — February 16, 2017 @ 1:45 pm GMT Feb 16,2017 | Reply

    • In that case (“TRUNCATE table root;”) this would only truncate all involved tables if all foreign keys along the way are “on delete cascade”. Also meaning that if only one FK is “no action”, the statement would fail. So in almost all cases that statement would fail, wouldn’t it?

      Comment by Salek Talangi — February 16, 2017 @ 2:30 pm GMT Feb 16,2017 | Reply

  2. Does this still work when the foreign key in the child table is nullable?

    I altered your example to make id the primary key of child (adjusting the test data to make all id values unique), and then added rows where p_id is null. If I then DELETE parent, all the rows in parent, and all the rows in child which have a p_id are deleted; the child rows without a p_id are left alone (this is the behaviour I expected). Does TRUNCATE … CASCADE remove all the rows from child? I’m not on 12.1 so I can’t test it for myself.

    It seems unlikely that you’d specify ON DELETE CASCADE for an optional FK relationship, but it’s good to know.

    Comment by Chris Hunt — February 27, 2017 @ 4:50 pm GMT Feb 27,2017 | Reply

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by