Comments on: DDL triggers

By: Jared

Jared — Wed, 14 Nov 2012 00:21:48 +0000

It certainly would be nice to find a method to take some action when a new partition is added to an interval partitioned table.
So far all efforts have been stymied.
In my case I would like to set some statistics on the new partition, so as to avoid any possible chance of the optimizer deciding to use dynamic sampling due to missing statistics.
On very large tables we have seen parses take up to 40 minutes due to CBO induced dynamic sampling, all the time holding the library cache lock.
I had hoped that some other idea would occur to me while typing this, but so far nothing…

By: Mirek

Mirek — Sun, 11 Nov 2012 11:37:08 +0000

Adding interval partition cannot be ordinary DDL because of „before DDL commit” .

By: Jonathan Lewis

Jonathan Lewis — Thu, 13 Sep 2012 08:17:32 +0000

Guest.

Nice thought – too bad it was doomed to fail.

By: guest

guest — Wed, 12 Sep 2012 15:34:27 +0000

When you trace the insert statement into transactions table with 10046 event, you can see that Oracle is actually running DML statements to create new interval partition: insert into seg$, insert into tabpart$ etc. So internally it is not a DDL. So I tried to add row level trigger (after insert) on sys.tabpart$ table and check :new.obj# and :new.bo# for the object I wanted and raise error if found. However, I got ORA-04089: cannot create triggers on objects owned by SYS. Oh well…

By: Jonathan Lewis

Jonathan Lewis — Tue, 11 Sep 2012 18:10:55 +0000

Adrian,

Thanks for that – it’s an excellent justification for why the trigger should be fired.

By: Adrian Billington

Adrian Billington — Tue, 11 Sep 2012 17:24:29 +0000

Jonathan,

I also tried this technique some time back. I wanted to respond to the creation of interval partitions by immediately copying stats into them.

Regards
Adrian

By: Uwe Hesse

Uwe Hesse — Tue, 11 Sep 2012 10:08:55 +0000

That happens from time to time also, but in this case, I was planning to investigate because I published postings about interval partitioning and wondered myself whether the tablespace could be specified in other ways apart from the ‘store in’ clause. It looks like you watch the OTN forum much closer resp. more often than I do :-)

By: Jonathan Lewis

Jonathan Lewis — Tue, 11 Sep 2012 09:16:34 +0000

Jared,

You can rename them, but only if you find out that they’ve been added in time to rename them (and possibly move them) before the other automatic jobs kick in; and this is where the problem of the (ineffictive) DDL trigger comes in.

By: Jonathan Lewis

Jonathan Lewis — Tue, 11 Sep 2012 09:15:18 +0000

Uwe,

I wonder if you saw the same question on OTN as I did and went through the same thought processes, as in: “all you have to do is …., oh, it doesn’t work.”

By: Jonathan Lewis

Jonathan Lewis — Tue, 11 Sep 2012 09:14:26 +0000

Wissem,
The note gives some idea about spreading partitions across tablespaces – but it doesn’t cover deal with the problems of “future” partitions arriving at random points in time and having to be relocated to a suitable tablespace asap.

One detail that isn’t obvious from that note, by the way – if the code adds (say) the 99th partition when partitions 4 to 98 have not yet appeared, would that partition go into the next tablespace in the ring, or would it go into the tablespace that it would have gone into if all the other partitions had been added in order first ? (That’s only a rhetorical question – it’s easy enough to check – it was just a nice example of an Oracle note that doesn’t quite tell you what you might think it’s telling you.)