Handling lossy data before character- set migration

Question

I am trying to migrate a database from US7ASCII to AL32UTF8 using CSSCAN. During the initial scanning using CSSCAN we have found the presence of lossy data both in data dictionary() and application data.Can any one please help as to how can we handle the lossy data before converting database from US7ASCII to AL32UTF8 .

**USER.TABLE|COLUMN      LOSSY**

SYS.SOURCE$|SOURCE         143

Answer 1

Was finally able to migrate the character-set of the database from US7ASCII to AL32UTF8.

Firstly I had converted US7ASCII to intermediate character-set WE8MSWIN1252. Which further could be migrated to AL32UTF8. The advantage to convert into the intermediate character-set is that it will be converted to WE8MSWIN1252 without any problem(lossy data) the previous lossy data from US7ASCII to AL32UTF8 will not create a problem when we convert it from WE8MSWIN1252 to AL32UTF8 as AL32UTF8 can be a strict superset of WE8MSWIN1252(means for every character in WE8MSWIN1252 can be converted to AL32UTF8 ) or the lossy data will reduce for the conversion from WE8MSWIN1252 to AL32UTF8 .

If there is still some lossy data. For data dictionary we have to handle the VARCHAR type lossy data as CLOB type lossy data is handled itself by oracle. Mostly the objects which have lossy content have to be dropped by taking their backup and are recreated after the rest of character-set migration is complete.

For application data we have to export the data objects and then drop them and import it again when the character-set migration is complete.

One should take help from Oracle support while character-set migration if you face some lossy data as it is critical activity and might lead to database corruption

Answer 2

Straight from the Manual:

The easiest approach to migrating convertible data dictionary data is to create a new database in the target character set and then re-create all of the data dictionary and schema definitions by exporting and importing. However, this method means creating a new database.

Based on what I'm reading in this manual, that's hands-down the safest and easiest way to do this migration.