Dropping a NOTNULL contraint results in a full table scan - oracle

Question

I have a table that contains about 25 million records and has some NOTNULL-constraint on several fields.
When i drop one of these NOTNULL contraints a full table scan is executed (which takes quite a lot of time). I can see that in the session browser of a second instance of TOAD (i use TOAD to drop the constraint).
Is there a way to avoid this full table scan when a constraint gets dropped?

Answer 1

This suggests the column causing the full table scan has a default value, possibly from adding the column to the table while data already existed, with a not-null constraint (which is only possibly since 11gR1).
As a demo, without a default value:
create table t42 (id number);
alter table t42 add (some_col number not null);
select data_default, default_length from user_tab_columns where column_name = 'SOME_COL';
DATA_DEFAULT DEFAULT_LENGTH
------------------------------------------------------------ --------------
insert into t42 (id, some_col)
select level, 0 from dual
connect by level <= 100000;
insert into t42 (id, some_col)
select 100000 + level, 1 from dual
connect by level <= 10000;
select some_col, count(*) from t42 group by some_col;
SOME_COL COUNT(*)
---------- ----------
1 10000
0 100000
set timing on
alter table t42 modify (some_col null);
Table T42 altered.
Elapsed: 00:00:00.056
But with a default value:
create table t42 (id number);
insert into t42 (id)
select level from dual
connect by level <= 100000;
alter table t42 add (some_col number default 0 not null);
select data_default, default_length from user_tab_columns where column_name = 'SOME_COL';
DATA_DEFAULT DEFAULT_LENGTH
------------------------------------------------------------ --------------
0 2
insert into t42 (id, some_col)
select 100000 + level, 1 from dual
connect by level <= 10000;
select some_col, count(*) from t42 group by some_col;
SOME_COL COUNT(*)
---------- ----------
1 10000
0 100000
set timing on
alter table t42 modify (some_col null);
Table T42 altered.
Elapsed: 00:00:04.734
Now the alter takes much longer, because it has to actually update all the pre-constraint rows to physically have a value zero. After the alter you see the same data, even if you change the default value (before or after the original alter; though if you do it before you potentially have a small window where a constraint violation could occur):
alter table t42 modify (some_col default null);
select data_default, default_length from user_tab_columns where column_name = 'SOME_COL';
DATA_DEFAULT DEFAULT_LENGTH
------------------------------------------------------------ --------------
null 4
select some_col, count(*) from t42 group by some_col;
SOME_COL COUNT(*)
---------- ----------
1 10000
0 100000
There isn't really any way around this, other than adding a new column without the default (which will take at least as long, and probably cause other side-effects).
Notice that the default value has change from not being set at all to explicitly being null. When you insert a row there isn't any practical difference - the column value ends up null either way - but you can't completely remove the default once it's been set.
It's also interesting that if you change the column default without dropping the constraint, that has no effect on the reported value for the rows that were using it - they would still show as zero. Oracle seems to be storing that constraint default somewhere else, which makes sense.
Any rows inserted after the default/not-null column was added will have an actual value stored in the table anyway, and changing the default will affect subsequent insertions - but the rows that already existed before the constraint was added behave as if they had actually been updated to whatever default value was specified when the constraint was added.
This change in 11g was mainly to speed the column addition up, and stop you having to to separate steps to add the column without a constraint, then update all existing rows (which was the slow bit), and then altering the table again to add the constraint. This mechanism lets you do it (almost) instantly with just a metadata change. But that update cost still has to be pain if the constraint is then removed.