Is there a note that supports what you are saying? As Note 1283764.1 says we should use note 124721.1 that says to use DMU to change NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET [ID 1283764.1]
Note 124721.1 is a bit confusing. It correctly mandates the use of the DMU for scanning but it does not mandate the use of it for conversion. Conversion to a character set other than UTF8/AL32UTF8 requires export/import. I will contact the authors of the note and ask them to clarify this issue.
By the way, why do you want to go from UTF8 to AR8ISO8859P6? It is generally not a good idea.
Thanks for the reply
The reason for going from UTF8 to AR8ISO8859P6 is because all description fields in the application which are using VARCHAR2(240) are now available for only 120 characters (since in UTF8 each character takes 2 bytes instead of 1 byte in AR8ISO8859P6). Thus our users can't use the descriptions available in the E-Business Suite
Also in order to use the DMU for validation only, how can we then do the Exp/Imp ? Can we use the truncate in case of E-Business Suite R12 tables? What about the triggers, shouldn't the note advise to disable them so as not to cause corruption in the database?
Also just to highlight, the Consultant who installed the application for us installed it on UTF8 by mistake while it should have been AR8ISO8859P6. We discovered after they had finished the setup and 80% of the Master data upload
OK, I understand. This is a very unfortunate reason but justified. Next generation of Applications will hopefully ease the issue by using character length semantics.
Regarding the use of the DMU, the DMU replaces CSSCAN. It will report which columns contain data with invalid representation. There should be no such data but it is better to check. DMU will not properly show any length issues for the type of migration you perform, but as you go to a single-byte character set, no such issues are even possible.
Regarding triggers, if you import to an empty database, triggers will be imported after the tables, so they should not interfere with the loaded data. If you pre-created Applications objects, then yes, triggers should be disabled, indexes dropped and later recreated, etc. But as we talk about Oracle Applications, you have to check with Applications support on the correct procedure. This is no longer a globalization issue as such and I am not qualified to give any definitive answers in this area.