RE: Database character set conversion.

  • From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
  • To: <Thomas.Mercadante@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 14 Aug 2009 17:54:40 -0400

The other thing to consider is that you probably want to move to
AL32UTF8 characterset.   Metalink doc id  260192.1 is what I normally
use to perform the characterset change.



From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mercadante, Thomas F
Sent: Wednesday, August 12, 2009 12:02 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Database character set conversion.




Dave is correct is his statements.


But let me say that generally (and I mean generally), most applications
that do not use the extended character sets can exist in a database that
supports extended character sets.  There is some discussion about
additional use of disk space when using the extended character set.  But
I don't think you will see any differences if you move your application

The CSSCAN utility will tell you everything you need to know about your
specific database.


And as always, test, test, test and for a change of pace, test it again.





From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Mann
Sent: Wednesday, August 12, 2009 11:20 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Database character set conversion.


Fred Tilly wrote:

>We have two applications that use one database, and the database is
>with character set WE8ISO8859P1. One of the applications needs to
>multiple languages so the vendor wants us to convert ot a 16 bit
character set. 
>However the other application in the database has not been tested
against a 
>16bit database, and there are a lot of tables with fields defined as 
>varchar2(4000) and clobs.
>Has anyone actually done such a conversion and is there anything we
should be 
>looking out for. 


My first stop for character set conversions is usually the CSSCAN
utility. You can run it against your database and indicate the character
set you would like to convert to and it will check all fields for any
conversion anomalies and report them. 


Here is a pointer to the documentation for 10g:


As far as application issues, an analysis of your technology stack would
be in order. For projects such as this I usually lean on my developers
to analyze their client apps and access methods for character set
compatibility. If all else fails you can convert a test system and have
QA give the data a once over. 



Dave Mann - Database Stuff -

Other related posts: