Comments on: Quiz Night.

By: Hemant K Chitale

Hemant K Chitale — Tue, 12 Oct 2010 14:29:27 +0000

Not commenting on the Quiz question but on the CHECK CONSTRAINT instead of a Column Definition to impose NOT NULL, Tom Kyte writes about the advantage of a NOT NULL definition over a Constraint : http://www.oracle.com/technetwork/issue-archive/2010/10-nov/o60asktom-176254.html

as the Optimizer can better use the Column definition.

Hemant K Chitale

By: Not NULL « Oracle Scratchpad

Not NULL « Oracle Scratchpad — Sun, 05 Sep 2010 17:56:50 +0000

[...] may remember a short note I wrote a few days ago about adding a not null constraint to a table with 200 million rows without causing the system to stop for a few minutes. I did it with the intent of giving the [...]

By: Jonathan Lewis

Jonathan Lewis — Sat, 28 Aug 2010 09:24:31 +0000

Flado,

Good point. In fact, several good points at once about the benefits of isolating values to partitions and the effects of highwater marks on performance. (I was looking at a table recently that had a highwater mark at 438000 blocks and no data – it was a materialized view log table that had suffered an accident at some point in the past, and refreshes weren’t going quite as fast as expected.)

By: Flado

Flado — Sat, 28 Aug 2010 09:13:31 +0000

Jonathan,
Just wanted to point out that it shouldn’t be necessary to not have a partition that can accept NULLs – just a partition that only accepts NULLs, e.g. DEFAULT for list or MAXVALUE for range. The partition would be empty (if the constraint was satisfied) and a full scan would be very quick (assuming there have never been NULLs in that column, otherwise the HWM would have been bumped). Under 11g it might even be “segmentless,” making the performance identical to your case; under 10g and earlier, it would require just a single LIO for the segment header so it could still fit in your 0.15 seconds.
Cheers,

Flado

By: Jonathan Lewis

Jonathan Lewis — Sat, 28 Aug 2010 07:56:05 +0000

Robert,

The future’s already here – Exadata with tens of gigabutes of SSD at the drive level. (But that wasn’t it – but it probably could have been.)

By: Jonathan Lewis

Jonathan Lewis — Sat, 28 Aug 2010 07:53:22 +0000

Andras, In this case, Oracle wouldn't depend on num_nulls being zero. Statisitics are always treated as estimates and potentially out of date - even the microsecond after a 100% compute. I haven't tested the effects of ddl_lock_timeout. It isn't really possible to guess from the description whether or not it should have an effect in this case. Perhaps some other reader has already experimented with it - or can point to a decent blog item about it.

By: Andras Gabor

Andras Gabor — Sat, 28 Aug 2010 05:24:15 +0000

My guess: DBA_TAB_COL_STATISTICS has the column NUM_NULLS. Can the system use a zero value from here, knowing it is up2date (not stale) ?

For 200M rows we can also think of a possible partitioning in place, where partition-wise statistics or local indexes might be present. So if not the stats the parallel processing of partitions can also make things like this faster.

Btw when using 11g do you still need the pl/sql and the loop? Would “ALTER SESSION SET ddl_lock_timeout=…” work here or it does not apply?

By: jgarry

jgarry — Fri, 27 Aug 2010 23:03:18 +0000

I note in the docs:

…validating a constraint that is already enabled does not require any DML locks during validation (unlike validating a previously disabled constraint). Enforcement guarantees that no violations are introduced during the validation. Hence, enabling without validating enables you to reduce the downtime typically associated with enabling a constraint.
…

Some benefits of using constraints in this order are:
…
No locks are held.
All constraints can go to enable state concurrently.
Constraint enabling is done in parallel.

So maybe you have a highly parallel system. And maybe some quantity of the rows were added while you had the enable novalidate on.

By: Flado

Flado — Fri, 27 Aug 2010 22:56:23 +0000

The table was partitioned (list or range) on this column?

By: Robert V

Robert V — Fri, 27 Aug 2010 21:50:16 +0000

Maybe because your stopwatch broke. Or maybe you were in a jet going so fast that time slowed. Perhaps your server is from the future when there’s processing power is an order faster. Maybe you ran it on a table where the constraint had already been validated. Wow I can think of lots of reasons.