| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: [SPAM] Re: Interpreting csscan results
Off the top of my head, perhaps there's an 'invisible' control character
in there?
Try this:
Select source,dump(source) from sys.source$ where rowid =
'AAAABHAABAAAHqVABL';
Do you see anything odd or suspicious?
-- Mark J. Bobak Senior Oracle Architect ProQuest/CSA "There are 10 types of people in the world: Those who understand binary, and those who don't." -----Original Message----- From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Don Seiler Sent: Wednesday, May 09, 2007 12:12 PM To: oracle_l Subject: [SPAM] Re: Interpreting csscan results Importance: Low 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_at_seiler.us> wrote:Received on Wed May 09 2007 - 12:22:22 CDT
> 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 -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l
 |
 |