Running an oracle in multibyte unicode storage like
AL32UTF8, disregarding the char and byte column length topic, is actually no different from the old days single byte storage, e.g. in
WE8MSWIN1252. However, any job that includes sort of character conversion in terms of character, decimal and hex reprasentations, does require at least a basic understanding of available unicode storage options and sql functions with oracle. To me, the main reason of common problems is the mismatch being imposed by oracle’s impure layout of the sql functions
unistr concerning the database and the national characterset.
The following has been executed on a 11gR2 on win64 using these database and the national characterset storage options.
SQL> select * from NLS_database_PARAMETERS where parameter like '%CHARACTERSET%'; PARAMETER VALUE --------- ----- NLS_CHARACTERSET AL32UTF8 NLS_NCHAR_CHARACTERSET AL16UTF16