I looked deeper into the specific exceptions. All of the data dictionary exceptions are just histograms on the application data fields with the WestEuro characters, except for this oddball: User : SYS Table : SOURCE$ Column: SOURCE Type : VARCHAR2(4000) Number of Exceptions : 1 Max Post Conversion Data Size: 4000 ROWID Exception Type Size Cell Data(first 30 bytes) ------------------ ------------------ ----- ------------------------------ AAAABHAABAAAHqVABL lossy conversion end; ------------------ ------------------ ----- ------------------------------ Not sure why "end;" is a problem. Don. On 5/9/07, Don Seiler <don@xxxxxxxxx> wrote:
Morning all. Our production database (10.2.0.2 on RHEL3) is USASCII7, and we've recently had issues with western euro characters being used. I'm researching the idea of migrating to WE8ISO8859P1. So last night I ran csscan with those from/to parameters, and I'm more than a little confused. My reading led me to believe that since WE8ISO8859P1 is a complete superset of USASCII7, there should be no issues. Perhaps I'm just interpreting the results wrong. The scan summary says: Some character type data in the data dictionary are not convertible to the new character set Some character type application data are not convertible to the new character set Here is the summary for each data dictionary and app data: [Data Dictionary Conversion Summary] Datatype Changeless Convertible Truncation Lossy --------------------- ---------------- ---------------- ---------------- ---------------- VARCHAR2 17,344,573 0 0 30 CHAR 1,216 0 0 0 LONG 916,150 0 0 0 CLOB 1,505,729 0 0 0 VARRAY 17,408 0 0 0 --------------------- ---------------- ---------------- ---------------- ---------------- Total 19,785,076 0 0 30 Total in percentage 100.000% 0.000% 0.000% 0.000% The data dictionary can not be safely migrated using the CSALTER script [Application Data Conversion Summary] Datatype Changeless Convertible Truncation Lossy --------------------- ---------------- ---------------- ---------------- ---------------- VARCHAR2 49,180,912,298 0 0 11,819 CHAR 10,295,777,604 0 0 736 LONG 4,957 0 0 0 CLOB 1 0 0 0 VARRAY 0 0 0 0 --------------------- ---------------- ---------------- ---------------- ---------------- Total 59,476,694,860 0 0 12,555 Total in percentage 100.000% 0.000% 0.000% 0.000% The scan.err file lists those names with mangled WE characters with a "lossy conversion" exception. I'm wondering if this (in particular the data dictionary warning) means my database will be horribly corrupted if I try CSALTER, or if it just means I will have to correct those particular fields afterward. -- Don Seiler oracle blog: http://ora.seiler.us ultimate: http://www.mufc.us
-- Don Seiler oracle blog: http://ora.seiler.us ultimate: http://www.mufc.us -- //www.freelists.org/webpage/oracle-l