RE: ENABLE NOVALIDATE behaviour bug
- From: "Jacques Kilchoer" <Jacques.Kilchoer@xxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 30 Jun 2004 15:22:20 -0700
This is probably nit-picking, but what purpose does step 2 (add
constraint disable) serve?
Wouldn't this be effectively the same? Or is there some subtlety that is
going over my head?
add column
update the column where null in batches - committing
add the default
add constraint enable novalidate
update any columns still null
validate the constraint
=20
-----Original Message-----
Jonathan Lewis
One thought about adding a column with a default:
the table has to be locked while every row is updated,
and if the update fails, you have a massive rollback.
If this is not something you can spare the time for,=20
you might still want to do something like the following:
add column
add constraint disable novalidate
update the column where null in batches - committing
add the default
enable the constraint novalidate
update any columns still null
validate the constraint
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
