Change NLS_LENGTH_SEMANTICS to CHAR

Question

I need to change the length semantics of all the tables in an existing application schema from BYTE to CHAR.
I have explored two methods
1- Datapump export/import
Due to large tables with numerous CLOB columns, the performance of the export/import is hardly acceptable for our production downtime window.
2- ALTER TABLE OWNER.TABLE modify (C160 VARCHAR2(255 CHAR))
This solution is to alter all table for all varchar2 or char columns.
Questions :
a) Does the alter table solution modify only the data dictionary or does it also modify/rearrange the blocks for existing rows.
a.1) What happens to a row with a varchar(3) string previously stored in three bytes when you change the semantics to CHAR and you update that string with two-bytes charactyers ? Where does the "enlarged" field in the row piece/block ? Does it go at the end of the row piece ?
b) Are there performance or management benefits to use one methods over the other one ?
Thanks for any information you can provide.
Serge Vedrine
Edited by: [email protected] on 13-Mar-2009 11:12 AM
Edited by: [email protected] on 13-Mar-2009 11:24 AM

Answer 1

## I have explored two methods
## 1- Datapump export/import
This will not work. Export/import preserves the length semantics
## 2- ALTER TABLE OWNER.TABLE modify (C160 VARCHAR2(255 CHAR))
This is the simplest approach. You can write a simple select on the view ALL_TAB_COLUMNS to generate the necessary ALTER TABLE statements.
## Questions :
## a) Does the alter table solution modify only the data dictionary or does it also modify/rearrange the blocks for existing rows.
Only data dictionary.
## a.1) What happens to a row with a varchar(3) string previously stored in three bytes when you change the semantics to CHAR
## and you update that string with two-bytes charactyers ? Where does the "enlarged" field in the row piece/block ? Does it go at the end of the row piece ?
This is the standard behavior of UPDATE when the new value is longer than the old one. If there is place in the block, the new longer value will push itself into the old place moving the rest of the block data to higher offsets. If there is no place, an extra block will be grabbed and inserted into the chain of blocks holding the row. This is called "row chaining".
## b) Are there performance or management benefits to use one methods over the other one ?
As I said, export/import will not work anyway.
-- Sergiusz