If you will have to reorg after processing the entire table, another
option is to do a SELECT of the entire table, constructing the output as
csv (comma separated variable) data. The SELECT can, using COALESCE,
replace any nulls with blanks. Once the data has been unloaded, change
the table definition from nullable to NOT NULL WITH DEFAULT and use the
load utility to rebuild the table. This will, however involve a lot more
DBA work. It'll also allow existing code to continue running and have
new data rows have appropriate defaults.

Phil Sherman


shorti wrote:
> On Apr 12, 6:50 am, Phil Sherman <psher...@ameritech.net> wrote:
>> Don't forget to check the space consequences of changing the columns
>> from null to blanks. You'll be adding 8-32 bytes for each row containing
>> null columns. If you don't have enough free space in the existing pages,
>> rows will physically move during this update. This could have
>> significant performance consequences for existing SQL.
>>
>> Phil Sherman
>>
>
> Can I just do a reorg after all the records are updated to prevent the
> performance problem?
>
> I am leaning towards doing the EXPORT and LOAD of the 4 columns since
> I agree this would be the most effecient. I dont expect anyone to be
> manipulating the table while this is being done but do I need to
> "LOCK" the table? I noticed the LOAD does it's own lock so will this
> interfere? I am just concerned with the time between the EXPORT and
> the LOAD.
>
> The other queries are great and I will add them to my list for future
> use.
>
> (forgive me if this is a duplicate response...my last reply did not
> seem to come through after 30+ minutes).
>