Oracle length semantics migration documention

Question

Due to the oracle documention to migrate length semantics:
To convert an existing schema and its associated data from byte semantics and a single-byte character set to character semantics and a multibyte character set, such as UTF-8, you need only follow these steps: [The following steps have been corrected since the magazine was printed.]
1. Export the schema.
2. Issue an ALTER SYSTEM SET NLS_LENGTH_SEMANTICS=CHAR SCOPE=BOTH command on the target database.
3. Stop and restart the instance so that the parameter change takes effect.
4. Drop the original schema.
5. Recreate the original schema and its tables (you can use import's show=Y option to get the CREATE TABLE statements). Columns in the recreated tables will use character semantics, because that's now the default.
6. Import the schema into the target database using the IGNORE=Y import option.
What is the meaning of the terms target and original?
Suppose there is a (source) database with length semantics byte. If a (target) database
is to be created as a clone of the (source) database, except for the length semantic char, does one have to migrate the (source) database first?
Or rather, why is it not possible to
1. Export the data from the source database with length semantic byte,
2. Create a target database with length semantics char,
3. Import the data from the source database?)

Answer 1

This documentation is, unfortunately, poorly written.
If you want to migrate data from one database to another, with both databases having different character sets, you can avoid some data expansion issues, if you migrate to character set semantics at the same time.
You cannot just export data, and import it into a character semantics database, because export/import preserves original semantics of the exported tables.
Note: there is actually no such thing as a character semantics database. Character semantics is a column/variable property. The "character semantics database" is a confusing, though commonly used, term that actually means an instance which has NLS_LENGTH_SEMANTICS set to CHAR in its initialization file. The only significant meaning of this parameter is to be the default for session-level NLS_LENGTH_SEMANTICS. It is used for sessions that do not set this parameter explictly (through environment variable or ALTER SESSION). The session-level parameter is significant for CREATE TABLE/PROCEDURE/FUNCTION/PACKAGE [BODY] statements and tells the default for column and variable declarations that do not specify BYTE or CHAR explicitly.
To migrate semantics of an original schema you need to create a script that will contain all CREATE statements needed to recreate this schema (at least CREATE {TYPE | TABLE | MATERIALIZED VIEW | PROCEDURE | FUNCTION | PACKAGE [BODY]}). Then, you can just add the ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR after any CONNECT command in this script. You can than run the script in the target database. How you create the script is irrelevant. You can use any reverse-engineering tool available (e.g. SHOW=Y option of import, DBMS_METADATA package, etc.)
After you pre-create the schema with the new semantics, you can import the data from the original (source) database with IGNORE=Y. The original semantics saved in the export file will be ignored for pre-created objects.
Note: PL/SQL may need manual corrections to migrate to character semantics. For example, SUBSTRB used to trim values before assignment may need to be replaced with SUBSTR.
-- Sergiusz