Comments on: Not NULL

By: Log Buffer #202, A Carnival of The Vanities for DBAs

Log Buffer #202, A Carnival of The Vanities for DBAs — Tue, 26 Feb 2013 16:28:12 +0000

[...] enticing features for the DBAs and the performance tuners, and so its no wonder that Jonathan Lewis re-discovers that not all “not null” are the [...]

By: Jonathan Lewis

Jonathan Lewis — Wed, 15 Sep 2010 08:41:47 +0000

Nigel,
Thank you; now corrected

By: Nigel

Nigel — Tue, 14 Sep 2010 10:43:34 +0000

So is spelling “language” correctly!!!

By: Sokrates

Sokrates — Mon, 13 Sep 2010 15:48:54 +0000

yes but orthography is also noteworthy

By: Nigel

Nigel — Mon, 13 Sep 2010 12:58:48 +0000

“the importance of being very careful with lnaguage”

;)

By: Stefan

Stefan — Tue, 07 Sep 2010 22:11:08 +0000

but I should have tested the exact topic at question, not with another type of constraint
I tested and it doesn’t work like that with not null constraints, exchange fails with check constraint mismatch or type mismatch depending on intial not null check or declaration(why it worked above in my case, the remaining index …)

however I like to mention, upon disabling a not null declared column via the system generated constraint name, then the nullable flag is set to Y. Upon reenabling it is back there to N. (also null$ switches from 1 to 0 to 1) So the “declarative” nature of the constraint must be stored somewhere as well, I just do not know where.
(10.2.0.4)

By: Jonathan Lewis

Jonathan Lewis — Tue, 07 Sep 2010 17:52:20 +0000

Stefan

Nice thought.

It’s always a good idea to ask the question: “can I think of any circumstances which explain why feature X does not behave the way I might expect?” You’ve certainly found an area that’s worth looking at a little more closely by doing exactly that.

By: Stefan

Stefan — Tue, 07 Sep 2010 15:58:54 +0000

considering the potential impact of

alter table test enable novalidate constraint test_pk
followed by
alter table part_tab exchange partition p_max with table test without validation

might be one of the reasons not to rely on constraint information on a follwing select count(*)

at least with primary key constraints (ok I probably should have sticked to the not null constraints) the ‘NOT VALIDATE’ on the table seems not to be transfered to user_constraints of the partitioned table.

By: Sokrates

Sokrates — Mon, 06 Sep 2010 09:49:18 +0000

cmp. also the discussion on this topic on http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2665514800346181577#2666583500346063752

I find it interesting to mention that since the use of LNNVL is now officially supported, one could also specify a not-null-constraint for example via
alter table t1 add constraint ch_on_nn check(lnnvl(object_name is null));

(works at least in 11.2)

By: Bhavik Desai

Bhavik Desai — Mon, 06 Sep 2010 06:52:15 +0000

Interesting test !

Constraint
Name C SEARCH_CONDITION STATUS DEFERRABLE DEFERRED VALIDATED GENERATED
—————————— – ——————————————————————————– ——– ————– ——— ————- ————–
SYS_C002299687 C “OBJECT_NAME” IS NOT NULL ENABLED NOT DEFERRABLE IMMEDIATE VALIDATED GENERATED NAME —>

Constraint
Name C SEARCH_CONDITION STATUS DEFERRABLE DEFERRED VALIDATED GENERATED
—————————— – ——————————————————————————– ——– ————– ——— ————- ————–
T1_CK_ON_NN C object_name is not null ENABLED NOT DEFERRABLE IMMEDIATE VALIDATED USER NAME —>

Does that mean,CBO only considers IMPLICIT CHECK constraint (dba_constraints.generated=’GENERATED NAME’) and does not look at EXPLICIT check constraint (dba_constraints.generated=’USER NAME’)while deciding index access ?

Even in case of explicit check constraint (T1_CK_ON_NN), CBO has surety that index does not contain any NULL values and thus it should use the index…isn’t it ?

Is this a BUG or expected behavior ?