Using AL32UTF8 or ZHS16GBK Characterset

Hi,
Currently, our database is using AL32UTF8 as the characterset but we need to store some Simplified Chinese data in tables.
I know what AL32UTF8 characterset is able to store Simplified Chinese data but not being able to sort the Chinese character by Han yu pin yin (By default). The default is by Binary.
I also know that ZHS16GBK characterset is able to store Simplified Chinese and the default sorting is by Han yu pin yin, which is what I want.
1. So I just wonder what type of characterset should I use, AL32UTF8 or ZHS16GBK?
2. AL32UTF8 is an unicode characterset which can support multi-language but ZHS16GBK characterset can only store Simplified Chinese? Am I right? What about English words, can ZHS16GBK characterset being able to store English words?
3.Which is the recommended Characterset to use for my case?
4. If I choose to set my characterset as AL32UTF8 but I want all the Simplified Chinese data to be sort by Han yu pin yin, how should I do?
5. I read one of the documentation and it state that I can set the NLS_SORT in the nls_Session_parameters to SCHINESE_PINYIN_M. After setting the session parameters, I want into SQLPLUS and execute a select statement (e.g. select short_name from client order by short_name) and the Simplified Chinese short name retrieve is sorted by Han yu pin yin. But when my application (NOT through SQLPLUS) execute the same select statement, the result is not sorted by Han yu pin yin. Why is this so? Did I miss out anything?
6. Lastly, I tried to set the NLS_SORT in the instance parameters as well by changing the spfile but the application using the select statement still cannot sort the Simplified Chinese data by Han yu pin yin. What should I do?

Hi,
Actually, I change the nls_sort for the session paramaters through the setting of the nls_sort in the registry instead of using the alter session command line.
This is so as using alter session command line will only change the nls_sort for that particular session and once I exit the session, the nls_sort will be reset back to the default which is in Binary. I will have to re-alter the nls_sort in the session parameters again.
Thats why I set the nls_sort in the registry so that the nls_sort in the session parameters will remain in the client machine.
After setting the nls_sort in the registry, I am able to sort the Simplified Chinese characters by Han yu pin yin using the SQL*PLUS but not in my application.
My applications are running on Windows environment (Microsoft Windows 2000 5.00.2195 SP3).
The applications are split into front-end and back-end. The backend is using java and the front-end is using a software that is also using java to control.
Basically, the front-end application will execute an electronic data exchange service and it will establish a jdbc oracle thin connection to the database.
There is configuration file that is attached with each Electronic data exchange service. This configuration file contains the select statement (select short_name from client order by short_name) and each configuration file is linked with a datasource which will establish a jdbc oracle thin connection to the database.
But seems like the result of the select statement in the configuration file are not sorted by Han yu pin yin. But executing the same select statement through SQL*PLUS will return the data sorted by Han yu pin yin.
Thanks.

Similar Messages

  • NLS support problems when using AL32UTF8 in dads.conf

    Hello,
    Following a post by Joel Kallman, in one of the forum threads, about the mandatory use of AL32UTF8 in dads.conf, when running HTML DB v2.0, I changed my PlsqlNLSLanguage parameter accordingly.
    Prior to the change, I experienced some problems when using non-English characters – some application items appeared as gibberish when contained non-English characters, and the LIKE operator didn't perform as expected. After the change, it all seems to work OK, but now I have a different problem.
    All the non-English characters in my HTML page source code appears as gibberish. On screen, at run time, everything display correctly, but the source code seems to be corrupted. It is very difficult, and very annoying to debug the pages that way. Is there a way to enjoy both worlds – Using AL32UTF8 in the dads.conf, as required, and still getting a coherent HTML source code, containing non-English characters?
    Thanks,
    Arie.

    Joel,
    I use the following settings and they work fine for me:
    Operating system:
    LANG=de_DE
    LANGVAR=de_DE.UTF-8
    NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
    daust:oracle[o1020]> uname -a
    Linux daust.opal-consulting.de 2.4.21-37.EL #1 Wed Sep 7 13:35:21 EDT 2005 i686 i686 i386 GNU/Linux
    daust:oracle[o1020]> cat /etc/redhat-release
    Red Hat Enterprise Linux ES release 3 (Taroon Update 6)
    daust:oracle[o1020]>
    marvel.conf:
    <Location /pls/htmldb>
        Order deny,allow
        PlsqlDocumentPath docs
        AllowOverride None
        PlsqlDocumentProcedure wwv_flow_file_manager.process_download
        PlsqlDatabaseConnectString localhost:1521:o1020
        PlsqlNLSLanguage AMERICAN_AMERICA.WE8ISO8859P1
        PlsqlAuthenticationMode Basic
        SetHandler pls_handler
        PlsqlDocumentTablename wwv_flow_file_objects$
        PlsqlDatabaseUsername HTMLDB_PUBLIC_USER
        PlsqlDefaultPage htmldb
        PlsqlDatabasePassword @BZvJYqadreElOqj5poCB5gE=
        Allow from all
    </Location>
    Database:
    daust:oracle[o1020]> sqlplus "/ as sysdba"
    SQL> select * from nls_database_parameters;
    PARAMETER                      VALUE
    NLS_LANGUAGE                   AMERICAN
    NLS_TERRITORY                  AMERICA
    NLS_CURRENCY                   $
    NLS_ISO_CURRENCY               AMERICA
    NLS_NUMERIC_CHARACTERS         .,
    NLS_CHARACTERSET               WE8ISO8859P1
    NLS_CALENDAR                   GREGORIAN
    NLS_DATE_FORMAT                DD-MON-RR
    NLS_DATE_LANGUAGE              AMERICAN
    NLS_SORT                       BINARY
    NLS_TIME_FORMAT                HH.MI.SSXFF AM
    PARAMETER                      VALUE
    NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY              $
    NLS_COMP                       BINARY
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    NLS_NCHAR_CHARACTERSET         AL16UTF16
    NLS_RDBMS_VERSION              10.2.0.1.0####################
    Using AL32UTF8 resulted in the same problem as described ( and fixed ) here: Re: Strange - HTML not written correctly
    So, what is the proper configuration of the DAD, perhaps there are different ones for Unicode instances and non-Unicode instances.
    ~Dietmar.

  • AL32UTF8 / US7ASCII db characterset

    Hi Guys,
    My DB is currently on 10.2.0.5 using US7ASCII as character set. Definately for now and future, my DB will only be storing english language.
    We are intending to migrate to 11g database. Have some queries to ask experts out there (pardon me, i have not started testing. very soon i will)
    1. when creating db in 11g, can we choose the character set as us7ascii?
    2. oracle recommended to use unicode in 11g (eg: al32utf8). For my case here, does it bring any benefits to me by changing us7ascii to al32utf8 since i'm quite sure we will only be using english? Not sure if it's work the risk or efforts to migrate as my application is very huge.
    3. if the db is converted from us7ascii to al32utf8 successfully (without any loose of data using csscan), do i have to change anything on the application end? Will it impact the application in anyway if the db character set is changed?
    thanks

    dbaing wrote:
    1. when creating db in 11g, can we choose the character set as us7ascii?Yes.
    2. oracle recommended to use unicode in 11g (eg: al32utf8). For my case here, does it bring any benefits to me by changing us7ascii to al32utf8 since i'm quite sure we will only be using english? Not sure if it's work the risk or efforts to migrate as my application is very huge.If you're only storing US7ASCII data, there is effectively no difference between a US7ASCII database and an AL32UTF8 (assuming the clients have been properly configured all along). Every character is still going to require 1 byte of storage. But if you use AL32UTF8, you have the potential to store far more characters in the future. Even if you're just going to store English, is there any chance that you'd need to store a Euro character or a British Pound symbol? Microsoft smart-quotes?
    3. if the db is converted from us7ascii to al32utf8 successfully (without any loose of data using csscan), do i have to change anything on the application end? Will it impact the application in anyway if the db character set is changed?If the application is configured correctly, no. If the application is configured incorrectly (particularly if it relies on bypassing character set conversion), then you'll have a much bigger task.
    Justin

  • Server uses AL32UTF8 character set

    Hello All,
    OS: Linux (SLES 8)
    Recently I have applied 10g Relase 1 (10.1.0.5) patch set for AIX 64 -- Patch #
    4505133.
    My earler version of database was 10.1.0.3.0.
    I got message patch successfully installed.
    I can login to the database.
    One of our weekly routine is to run our internal shell script interface
    programs.
    Very first step of this program is to created .dmp (exp) file. We are doing this
    from years.
    Now after applying this patch set,
    I am getting error in this program as below:
    Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 -
    Production
    With the Partitioning, OLAP and Data Mining options
    Export done in US7ASCII character set and AL16UTF16 NCHAR character set
    server uses AL32UTF8 character set (possible charset conversion)
    About to export specified users ...
    . exporting pre-schema procedural objects and actions
    . exporting foreign function library names for user abc
    . exporting PUBLIC type synonyms
    . exporting private type synonyms
    . exporting object type definitions for user abc
    About to export abc's objects ...
    . exporting database links
    . exporting sequence numbers
    . exporting cluster definitions
    EXP-00056: ORACLE error 932 encountered
    ORA-00932: inconsistent datatypes: expected BLOB, CLOB got CHAR
    EXP-00000: Export terminated unsuccessfully
    DN

    Pierre,
    I do not have any invalid objects.
    But I run
    SQL> @?/rdbms/admin/catmetx.sql (Per Metalink note 339938.1).
    But now I am getting errorsbelow:
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_COM_USER_PRIVILEGES 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_COLLECTION_DEFINITION 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_COLLECTION_DEF_REPOS 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_COLLECTION_REPOSITORY 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_ERRORS 0 rows exported
    . . exporting table QUEST_SL_EXPLAIN 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_EXPLAIN_PICK 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_QUERY_DEFINITIONS 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
    . . exporting table QUEST_SL_QUERY_DEF_REPOSITORY 0 rows exported
    EXP-00056: ORACLE error 904 encountered
    ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identif
    Now I am running @catproc.sql.
    After that I will run utlrp.sql script if there is any invalid objects..
    DN

  • Using CSSCAN to change characterset

    Hello... I am looking at changing our 10.2.0.4 database (EE) from WE8ISO8859P1 to AL32UTF8. Because I have a number of "lossy" data records, it appears to me as if the first logical step is to convert (using CSALTER) my database to WE8MSWIN1252 because my CSSCAN from WE8MSWIN1252 to WE8MSWIN1252 shows the "lossy" data items are recognized and no other data records are flagged. (Probably due to those fancy quotation marks Microsoft uses)
    But I'm a bit confused about how to take care of the "lossy" data to get CSALTER to allow me to go to WE8MSWIN1252 since I've read that CSALTER won't execute without a "clean" run.
    Thanks in advance for your help.

    Hi,
    Only way to correct the lossydata is idenifying it and correcting it by updating the rows. I am not sure if there any other way. If you proceed without correcting lossy data, you will loose some data or corrupt some data due to conversion.
    I believe, csscan does not look at the data in the specifically, but it checks if the existing data will fit in the exiting table columns after conversion due to some charsets being multi byte, it may require them to have bigger column size.
    Regards

  • Nvarchar2 data type

    Hi
    I have emp_ino table in oracle database 10g R2.
    emp_id Number(5);
    emp_name nvarchar2(50);
    I insert data through sql script its ok.
    In emp_name I used Arabic character.
    I creat A form module in oracle developer suite 10g R2 when I query record in forms 10g then it does not display in arabic format.
    please tell me what i have to do ?
    thanks

    emp_name nvarchar2(50);First of all ist the table column you are inserting your data also of type nvarchar2 ? The NVARCHAR2 uses the National Characterset whereas VARCHAR2 uses the database characterset which means you could have a characterset conversion with possible data loss at hand when trying to insert NVARCHAR2 into VARCHAR2 or vice versa.
    The national characterset itself is simply there to support 2 different charactersets in your database; meaning when having a West-European Database Characterset you could switch the national characterset to something else if you'd need to support something else quickly.
    Personally I wouldn't go for it. The idea of having different charactersets with possible characterset conversions and data loss in one database sounds complicated enough; you'd have to worry everytime which datatype you have to use and how to convert it from characterset A to characterset B. The horrorstory continues when you plan to use another database characterset, as - you guessed it - the national characterset will make this also more complicated.
    The by far easier way is to use AL32UTF8 as Database characterset and forget about that there even is a National Chararacterset.
    cheers

  • Export From 3.0 and Import to 3.1

    Hi guys,
    I'm having error at below while i'm trying to import my application which is exported from apex 3.0. Right now i'm working on Application Express 3.1.0.00.32
    Can anybody help me please?
    Thanks for your interest
    ORA-20001: GET_BLOCK Error. ORA-20001: Execution of the statement was unsuccessful. ORA-06550: line 17, column 71: PLS-00103: Encountered the symbol &amp;quot;,&amp;quot; when expecting one of the following: * &amp;amp; = - + ; &amp;lt; / &amp;gt; at in is mod remainder not rem &amp;lt;an exponent (**)&amp;gt; &amp;lt;&amp;gt; or != or ~= &amp;gt;= &amp;lt;= &amp;lt;&amp;gt; and or like LIKE2_ LIKE4_ LIKEC_ between || member SUBMULTISET_ &lt;pre&gt;begin declare p varchar2(32767) := null;

    All DADs used for Application Express must use AL32UTF8 as the characterset. If they are something else you need to change them, restart the HTTP servers and export again. Then try to import/install. I would test the export and import/install on 3.0 first. When that works error-free, take the export files and import/install into 3.1.
    Scott

  • Converting charaterset.

    Hi All,
    My DB is in 11.1.0.7.0 and NLS_Characterset is AL32UTF8.
    One of my table column is in varchar2 and it contains different characterset (� ). My BO reports are failing because of this character set (BO character set is in AL32UTF8)
    Using covert function one set/pattern of data i converted to the original characterset. [ Select column1, convert(column2, 'AL32UTF8', 'WE8ISO8859P1') FROM xyz ]
    I also create a new table with same filed as nvarchar2 and inserted the data from the coverted records. From the new table BO reports are fine.
    Now i wanted to move complete table data (around 20 GB, not sure how many rows and and what all types of charater set having non-UTF8 character) to the new table with nvarchar2. Problem is that Since it is worldwide application there are many types of characterset involved in the database. Converting each one like previous query won't be possible and accurate.
    Is there any way i can perform this task
    1. Identify all the rows that not UTF8 format.
    2. Convert to a correct character set and move to a new table with nvarchar2 that by default will take care of this (I hope so). Pelase note that i can't remove the charaters that have non-utf8 format
    So looks like diffrent character set data is in UTF8 format and we can't really see the extact charater set since it is in AL32UTF8. we need to convert back to the original character set and save it in nvarchar2 format.
    Please share your suggestions. Thanks in advance.
    Regards,
    Anto.

    Hi Anto,
    I would doubt that, as NVARCHAR2 columns are in the NCHAR characterset.
    The original idea was: you can use characters in the characterset in both columns and identifiers, so you would use a more or less restrictive characterset for that.
    For the NCHAR characterset, used in colum values only, you would typically use an unicode characterset. You had to designate a literal as NCHAR by prefixing N before the literal.
    Now Oracle allows AL32UTF8 for the normal characterset about the only NCHAR characterset is AL16UTF16. The N prefix is removed. If the change to NVARCHAR2 would force you to change you anything in your code, I wouldn't do that. You should be able to resolve it using AL32UTF8.
    I once, several years ago, read Oracle was going to desupport single byte characters in the next major release of Oracle. You may best use Oracle's recommendations which is to use AL32UTF8 as database characterset when you need unicode.
    Sybrand Bakker
    Senior Oracle DBA

  • Unicode Migration using National Characterset data types - Best Practice ?

    I know that Oracle discourages the use of the national characterset and national characterset data types(NCHAR, NVARCHAR) but that is the route my company has decide to take and I would like to know what is the best practice regarding this specifically in relation to stored procedures.
    The database schema is being converted by changing all CHAR, VARCHAR and CLOB data types to NCHAR, NVARCHAR and NCLOB data types respectively and I would appreciate any suggestions regarding the changes that need to be made to stored procedures and if there are any hard and fast rules that need to be followed.
    Specific questions that I have are :
    1. Do CHAR and VARCHAR parameters need to be changed to NCHAR and NVARCHAR types ?
    2. Do CHAR and VARCHAR variables need to be changed to NCHAR and NVARCHAR types ?
    3. Do string literals need to be prefixed with 'N' in all cases ? e.g.
    in variable assignments - v_module_name := N'ABCD'
    in variable comparisons - IF v_sp_access_mode = N'DL'
    in calls to other procedures passing string parameters - proc_xyz(v_module_name, N'String Parameter')
    in database column comparisons - WHERE COLUMN_XYZ = N'ABCD'
    If anybody has been through a similar exercise, please share your experience and point out any additional changes that may be required in other areas.
    Database details are as follows and the application is written in COBOL and this is also being changed to be Unicode compliant:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    NLS_CHARACTERSET = WE8MSWIN1252
    NLS_NCHAR_CHARACTERSET = AL16UTF16

    ##1. while doing a test convertion I discovered that VARCHAR paramaters need to be changed to NVARCHAR2 and not VARCHAR2, same for VARCHAR variables.
    VARCHAR columns/parameters/variables should not by used as Oracle reserves the right to change their semantics in the future. You should use VARCHAR2/NVARCHAR2.
    ##3. Not sure I understand, are you saying that unicode columns(NVARCHAR2, NCHAR) in the database will only be able to store character strings made up from WE8MSWIN1252 characters ?
    No, I meant literals. You cannot include non-WE8MSWIN1252 characters into a literal. Actually, you can include them under certain conditions but they will be transformed to an escaped form. See also the UNISTR function.
    ## Reason given for going down this route is that our application works with SQL Server and Oracle and this was the best option
    ## to keep the code/schemas consistent between the two databases
    First, you have to keep two sets of scripts anyway because syntax of DDL is different between SQL Server and Oracle. There is therefore little benefit of just keeping the data type names the same while so many things need to be different. If I designed your system, I would use a DB-agnostic object repository and a script generator to produce either SQL Server or Oracle scripts with the appropriate data types or at least I would use some placeholder syntax to replace placeholders with appropriate data types per target system in the application installer.
    ## I don't know if it is possible to create a database in SQL Server with a Unicode characterset/collation like you can in Oracle, that would have been the better option.
    I am not an SQL Server expert but I think VARCHAR data types are restricted to Windows ANSI code pages and those do not include Unicode.
    -- Sergiusz

  • Use of UTF8 and AL32UTF8 for database character set

    I will be implementing Unicode on a 10g database, and am considering using AL32UTF8 as the database character set, as opposed to AL16UTF16 as the national character set, primarily to economize storage requirements for primarily English-based string data.
    Is anyone aware of any issues, or tradeoffs, for implementing AL32UTF8 as the database character set, as opposed to using the national character set for storing Unicode data? I am aware of the fact that UTF-8 may require 3 bytes where UTF-16 would only require 2, so my question is more specific to the use of the database character set vs. the national character set, as opposed to differences between the encoding itself. (I realize that I could use UTF8 as the national character set, but don't want to lose the ability to store supplementary characters, which UTF8 does not support, as this Oracle character set supports up to Unicode 3.0 only.)
    Thanks in advance for any counsel.

    I don't have a lot of experience with SQL Server, but my belief is that a fair number of tools that handle SQL Server NCHAR/ NVARCHAR2 columns do not handle Oracle NCHAR/ NVARCHAR2 columns. I'm not sure if that's because of differences in the provided drivers, because of architectural differences, or because I don't have enough data points on the SQL Server side.
    I've not run into any barriers, no. The two most common speedbumps I've seen are
    - I generally prefer in Unicode databases to set NLS_LENGTH_SEMANTICS to CHAR so that a VARCHAR2(100) holds 100 characters rather than 100 bytes (the default). You could also declare the fields as VARCHAR2(100 CHAR), but I'm generally lazy.
    - Making sure that the client NLS_LANG properly identifies the character set of the data going in to the database (and the character set of the data that the client wants to come out) so that Oracle's character set conversion libraries will work. If this is set incorrectly, all manner of grief can befall you. If your client NLS_LANG matches your database character set, for example, Oracle doesn't do a character set conversion, so if you have an application that is passing in Windows-1252 data, Oracle will store it using the same binary representation. If another application thinks that data is really UTF-8, the character set conversion will fail, causing it to display garbage, and then you get to go through the database to figure out which rows in which tables are affected and do a major cleanup. If you have multiple character sets inadvertently stored in the database (i.e. a few rows of Windows-1252, a few of Shift-JIS, and a few of UTF8), you'll have a gigantic mess to clean up. This is a concern whether you're using CHAR/ VARCHAR2 or NCHAR/ NVARCHAR2, and it's actually slightly harder with the N data types, but it's something to be very aware of.
    Justin

  • Characterset mismatch error while export

    Hi,
    I am getting characterset mismatch error while exporting a schema.
    select * from nls_database_parameters where parameter in('NLS_LANGUAGE','NLS_TERRITORY','NLS_CHARACTERSET')
    PARAMETER
    VALUE
    NLS_LANGUAGE
    AMERICAN
    NLS_TERRITORY
    AMERICA
    NLS_CHARACTERSET
    AL32UTF8
    i have set nls_lang on OS level
    NLS_LANG = AMERICAN_AMERICA.AL32UTF8
    C:\oracle\ora92\bin>
    C:\oracle\ora92\bin>
    C:\oracle\ora92\bin>exp hrtemp_v6/hrtemp_v6@testdb file=c:\hrtemp_v6 statistics=
    none
    Export: Release 9.2.0.1.0 - Production on Mon May 14 11:55:58 2007
    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
    Connected to: Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.1.0 - Production
    Export done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
    server uses AL32UTF8 character set (possible charset conversion)
    About to export specified users ...
    . exporting pre-schema procedural objects and actions
    . exporting foreign function library names for user HRTEMP_V6
    . exporting PUBLIC type synonyms
    EXP-00008: ORACLE error 6552 encountered
    ORA-06552: PL/SQL: Compilation unit analysis terminated
    ORA-06553: PLS-553: character set name is not recognized
    EXP-00000: Export terminated unsuccessfully
    please suggest , whats wrong here
    thanks & regards

    i have set nls_lang on OS level
    NLS_LANG = AMERICAN_AMERICA.AL32UTF8How and where?
    C:\oracle\ora92\bin>At this command prompt, what do you get back from "set nls"
    You can use
    c:\> set nls_lang=.al32utf8
    ...right before you issue exp command.

  • How is WE8MSWIN1252 characterset storing chinese characters???

    I've read several oracle globalization documents and I'm very confused now. Here's my setup:.. everything is on 1 machine
    I'm runnig oracle 9.2.0.4 database on windowsXP.
    HKLM\SOFTWARE\ORACLE\NLS_LANG registry key value = NA
    HKLM\SOFTWARE\ORACLE\HOME0 registry key value = AMERICAN_AMERICA.WE8MSWIN1252
    select * from nls_database_parameters
    returns:
    NLS_CHARACTERSET = WE8MSWIN1252
    NLS_LANGUAGE =     AMERICAN
    NLS_NCHAR_CHARACTERSET = AL16UTF16
    windows xp settings for regional & language options, advanced tab under language for non-unicode programs is set to Chinese(Taiwan).
    Using the strgen tool available for free from MS here (http://www.microsoft.com/globaldev/tools/strgen.mspx). I generate hundreds of CHT(Chinese Taiwan) characters and then insert them via sqlplus into a varchar2(100), then query the results getting what looks like the exact characters I put in.
    If I run:
    select dump(column_name), column_name from table_name;
    on a row containing 4 chinese characters the results are:
    Typ=1 Len=8: 165,250,184,234,187,219,179,225 [4 chinese characters go here - sorry they aren't pasting properly]
    Looks like multibyte to me, but I must be missing something??
    My main question is why DON'T I get question marks??? I.e. Since I'm using an single byte characterset shouldn't it be junk that is return instead of exactly, or at least what looks like exactly, the same characters be returned. I'm missing something -- please, someone clear things up for me. I will provide whatever info that is necessary.
    This is very critical to us in that we've been using a front-end application for some time with this configuration and have only recently tried globalizing/localizing our web based products. It seems that in order for apache to send the proper encoding to the web based client, that the nls_lang registry entry should be set to ZHT16BIG5, which will make the browser work, but this then breaks our front-end app.
    Thank you,
    Jason

    This is typical pass-through scenario (known as "garbage-in garbage-out").
    You have defined NLS_LANG to be the same as the database character set.
    Therefore, the database does no character set conversion as it thinks
    no conversion is needed. You see Chinese characters because the SQL*Plus
    font is set to the system default for Chinese locale. The operating system
    displays received codes as Chinese and not as Western European.
    For the data that you DUMPed, call LENGTH(). In a correct configuration,
    with the ZHT16MSWIN950 character set, the function would return 4.
    But it will return 8, because Oracle thinks the input is a string of WE8MSWIN1252
    single-bytes codes. Also, try Java to show the characters. You will
    not succeed, because Java converts to Unicode and this conversion from
    WE8MSWIN1252 will produce mess from the Chinese codes.
    In a proper configuration, you need NLS_LANG=.ZHT16MSWIN950 and
    the database character set (NLS_CHARACTERSET) either ZHT16MSWIN950,
    or AL32UTF8, if the database is to be really multilingual.
    -- Sergiusz

  • AL32UTF8

    CMS install docs (http://download-west.oracle.com/docs/html/B13614_01/database.htm#i634543) say:
    Select Unicode (UTF8) as the database character set to enable full multi-language functionality in Oracle CM SDK. Specifying a different database character set can limit Oracle CM SDK functionality.
    Our corporate standard is to use AL32UTF8 since it supports Unicode 3.2 vs. UTF8 which is only 3.0. This is important for some of our customers.
    Will this "limit Oracle CM SDK functionality" or is this part of the docs incomplete and AL32UTF8 should be fine as well?

    Oracle strongly recommends using this characterset.
    You will otherwise get a warning during RCU run.

  • PlsqlNLSLanguage WE8ISO8859P1 vs AL32UTF8

    Hi,
    I upgraded to 3.0.1 and I am having some issues with apostrophe when I switch the PlsqlNLSLanguage from WE8ISO8859P1 to AL32UTF8.
    I did run the OWAINST script to upgrade Web Toolkit.
    So my pages displays correctly except for those apostrophe that shows as little squares.
    If I use WE8ISO8859P1 , everything displays and inserts correctly. Why can't I keep this setting for PlsqlNLSLanguage ?
    If I use AL32UTF8 , when I insert, the apostrophe shows as reversed questionmarks ( de l¿AQIII ). When I select apostrophe inserted in WE8ISO8859P1 , it shows as little boxes. (de l�AQIII )
    I am kind of stuck with this.
    Anybody experiencing this behaviour ?
    Normal apostrophe works, it's when I cut and paste from Word that it does not inserts correctly.
    I am using APEX 3.0.1
    OWA 10.1.2.0.6
    DB : 10.1.0.5.0
    DB Characterset : WE8ISO8859P1
    Thanks
    Francis.

    Hi Francis,
    Thanks for explaining this and thanks for including the information in #4. You have stated precisely your issue.
    The fundamental problem is you are attempting to include the MS Word-generated apostophe, in your data. This character is known as RIGHT SINGLE QUOTATION MARK, Unicode character U+2019, AL32UTF8 codepoint E28099. There is no equivalent codepoint in your database character set, WE8ISO8859P1 which can accommodate this character.
    Of course, you're going to ask, why wasn't this a problem before? And that's because in HTML DB 1.6 and earlier, when the database character set matched the DAD character set, no character set conversion was attempted. So even though the character couldn't directly be accommodated in WE8ISO8859P1, the bytes were stored as is.
    Now, in HTML DB 2.0 and APEX 3.0 and later, the DAD character set must be AL32UTF8. So there will be character set conversion between mod_plsql and your database - on data going into the database and data coming out of the database.
    Unfortunately, the DAD character set must be AL32UTF8 in APEX 3.0 - otherwise, you'll run into trouble later - guaranteed. The only viable solution for you, as I see it, is either change your database character set to AL32UTF8 or somehow avoid entering these characters.
    I hope this helps.
    Joel

  • Convert characterset WE8MSWIN1252 to UTF8

    Hi all
    I am using Oracle 10g Database. Now the Characterset as WE8MSWIN1252. I want to change my CharacterSet to UTF8. It is possible.
    Can anyone please post me the steps involved.
    Very Urgent !!!!!!!
    Regds
    Nirmal

    Subject: Changing WE8ISO8859P1/ WE8ISO8859P15 or WE8MSWIN1252 to (AL32)UTF8
    Doc ID: Note:260192.1 Type: BULLETIN
    Last Revision Date: 24-JUL-2007 Status: PUBLISHED
    Changing the database character set to (AL32)UTF8
    =================================================
    When changing a Oracle Applications Database:
    Please see the following note for Oracle Applications database
    Note 124721.1 Migrating an Applications Installation to a New Character Set
    If you have any doubt log an Oracle Applications TAR for assistance.
    It might be usefull to read this note, even when using Oracle Applications
    seen it explains what to do with "lossy" and "truncation" in the csscan output.
    Scope:
    You can't simply use "ALTER DATABASE CHARACTER SET" to go from WE8ISO8859P1 or
    WE8ISO8859P15 or WE8MSWIN1252 to (AL32)UTF8 because (AL32)UTF8 is not a
    binary superset of any of these character sets.
    You will run into ORA-12712 or ORA-12710 because the code points for the
    "extended ASCII" characters are different between these 3 character sets
    and (AL32)UTF8.
    This note will describe a method of still using a
    "ALTER DATABASE CHARACTER SET" in a limited way.
    Note that we strongly recommend to use the SAME flow when doing a full
    export / import.
    The choise between using FULL exp/imp and a PARTIAL exp/imp is made in point
    7)
    DO NOT USE THIS NOTE WITH ANY OTHER CHARACTERSETS
    WITHOUT CHECKING THIS WITH ORACLE SUPPORT
    THIS NOTE IS SPECIFIC TO CHANGING:
    FROM: WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252
    TO: AL32UTF8 or UTF8
    AL32UTF8 and UTF8 are both Unicode character sets in the oracle database.
    UTF8 encodes Unicode version 3.0 and will remain like that.
    AL32UTF8 is kept up to date with the Unicode standard and encodes the Unicode
    standards 3.0 (in database 9.0), 3.1 (database 9.2) or 3.2 (database 10g).
    For the purposes of this note we shall only use AL32UTF8 from here on forward,
    you can substitute that for UTF8 without any modifications.
    If you use 8i or lower clients please have a look at
    Note 237593.1 Problems connecting to AL32UTF8 databases from older versions (8i and lower)
    WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 are the 3 main character sets that
    are used to store Western European or English/American data in.
    All standard ASCII characters that are used for English/American do not have to
    be converted into AL32UTF8 - they are the same in AL32UTF8. However, all other
    characters, like accented characters, the Euro sign, MS "smart quotes", etc.
    etc., have a different code point in AL32UTF8.
    That means that if you make extensive use of these types of characters the
    preferred way of changing to AL32UTF8 would be to export the entire database and
    import the data into a new AL32UTF8 database.
    However, if you mainly use standard ASCII characters and not a lot else (for
    example if you only store English text, maybe with some Euro signs or smart
    quotes here and there), then it could be a lot quicker to proceed with this
    method.
    Please DO read in any case before going to UTF8 this note:
    Note 119119.1 AL32UTF8 / UTF8 (unicode) Database Character Set Implications
    and consider to use CHAR semantics if on 9i or higher:
    Note 144808.1 Examples and limits of BYTE and CHAR semantics usage
    It's best to change the tables and so to CHAR semantics before the change
    to UTF8.
    This procedure is valid for Oracle 8i, 9i and 10g.
    Note:
    * If you are on 9i please make sure you are at least on Patch 9204, see
    Note 250802.1 Changing character set takes a very long time and uses lots of rollback space
    * if you have any function-based indexes on columns using CHAR length semantics
    then these have to be removed and re-created after the character set has
    been changed. Failure to do so will result in ORA-604 / ORA-2262 /ORA-904
    when the "alter database character set" statement is used in step 4.
    Actions to take:
    1) install the csscan tool.
    1A)For 10g use the csscan 2.x found in /bin, no need to install a newer version
    Goto 1C)
    1B)For 9.2 and lower:
    Please DO install the version 1.2 or higher from TechNet for you version.
    http://technet.oracle.com/software/tech/globalization/content.html
    and install this.
    copy all scripts and executables found in the zip file you downloaded
    to your oracle_home overwriting the old versions.
    goto 1C).
    Note: do NOT use the CSSCAN of a 10g installation for 9i/8i!
    1C)Run csminst.sql using these commands and SQL statements:
    cd $ORACLE_HOME/rdbms/admin
    set oracle_sid=<your SID>
    sqlplus "sys as sysdba"
    SQL>set TERMOUT ON
    SQL>set ECHO ON
    SQL>spool csminst.log
    SQL> START csminst.sql
    Check the csminst.log for errors.
    If you get when running CSSCAN the error
    "Character set migrate utility schema not compatible."
    then
    1ca) or you are starting the old executable, please do overwrite all old files with the files
    from the newer version from technet (1.2 has more files than some older versions, that's normal).
    1cb) or check your PATH , you are not starting csscan from this ORACLE_HOME
    1cc) or you have not runned the csminst.sql from the newer version from technet
    More info is in Note 123670.1 Use Scanner Utility before Altering the Database Character Set
    Please, make sure you use/install csscan version 1.2 .
    2) Check if you have no invalid code points in the current character set:
    Run csscan with the following syntax:
    csscan FULL=Y FROMCHAR=<existing database character set> TOCHAR=<existing database character set> LOG=WE8check CAPTURE=Y ARRAY=1000000 PROCESS=2
    Always run CSSCAN with 'sys as sysdba'
    This will create 3 files :
    WE8check.out a log of the output of csscan
    WE8check.txt a Database Scan Summary Report
    WE8check.err contains the rowid's of the rows reported in WE8check.txt
    At this moment we are just checking that all data is stored correctly in the
    current character set. Because you've entered the TO and FROM character sets as
    the same you will not have any "Convertible" or "Truncation" data.
    If all the data in the database is stored correctly at the moment then there
    should only be "Changeless" data.
    If there is any "Lossy" data then those rows contain code points that are not
    currently stored correctly and they should be cleared up before you can continue
    with the steps in this note. Please see the following note for clearing up any
    "Lossy" data:
    Note 225938.1 Database Character Set Healthcheck
    Only if ALL data in WE8check.txt is reported as "Changeless" it is safe to
    proceed to point 3)
    NOTE:
    if you have a WE8ISO8859P1 database and lossy then changing your WE8ISO8859P1 to
    WE8MSWIN1252 will most likly solve you lossy.
    Why ? this is explained in
    Note 252352.1 Euro Symbol Turns up as Upside-Down Questionmark
    Do first a
    csscan FULL=Y FROMCHAR=WE8MSWIN1252 TOCHAR=WE8MSWIN1252 LOG=1252check CAPTURE=Y ARRAY=1000000 PROCESS=2
    Always run CSSCAN with 'sys as sysdba'
    For 9i, 8i:
    Only if ALL data in 1252check.txt is reported as "Changeless" it is safe to
    proceed to the next point. If not, log a tar and provide the 3 generated files.
    Shutdown the listener and any application that connects locally to the database.
    There should be only ONE connection the database during the WHOLE time and that's
    the sqlplus session where you do the change.
    2.1. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all.
    If you are using RAC see
    Note 221646.1 Changing the Character Set for a RAC Database Fails with an ORA-12720 Error
    2.2. Execute the following commands in sqlplus connected as "/ AS SYSDBA":
    SPOOL Nswitch.log
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    ALTER SYSTEM ENABLE RESTRICTED SESSION;
    ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
    ALTER SYSTEM SET AQ_TM_PROCESSES=0;
    ALTER DATABASE OPEN;
    ALTER DATABASE CHARACTER SET WE8MSWIN1252;
    SHUTDOWN IMMEDIATE;
    STARTUP RESTRICT;
    SHUTDOWN;
    The extra restart/shutdown is necessary in Oracle8(i) because of a SGA
    initialization bug which is fixed in Oracle9i.
    -- a alter database takes typically only a few minutes or less,
    -- it depends on the number of columns in the database, not the amount of data
    2.3. Restore the parallel_server parameter in INIT.ORA, if necessary.
    2.4. STARTUP;
    now go to point 3) of this note of course your database is then WE8MSWIN1252, so
    you need to replace <existing database character set> with WE8MSWIN1252 from now on.
    For 10g and up:
    When using CSSCAN 2.x (10g database) you should see in 1252check.txt this:
    All character type data in the data dictionary remain the same in the new character set
    All character type application data remain the same in the new character set
    and
    The data dictionary can be safely migrated using the CSALTER script
    IF you see this then you need first to go to WE8MSWIN1252
    If not, log a tar and provide all 3 generated files.
    Shutdown the listener and any application that connects locally to the database.
    There should be only ONE connection the database during the WHOLE time and that's
    the sqlplus session where you do the change.
    Then you do in sqlplus connected as "/ AS SYSDBA":
    -- check if you are using spfile
    sho parameter pfile
    -- if this "spfile" then you are using spfile
    -- in that case note the
    sho parameter job_queue_processes
    sho parameter aq_tm_processes
    -- (this is Bug 6005344 fixed in 11g )
    -- then do
    shutdown immediate
    startup restrict
    SPOOL Nswitch.log
    @@?\rdbms\admin\csalter.plb
    -- Csalter will aks confirmation - do not copy paste the whole actions on one time
    -- sample Csalter output:
    -- 3 rows created.
    -- This script will update the content of the Oracle Data Dictionary.
    -- Please ensure you have a full backup before initiating this procedure.
    -- Would you like to proceed (Y/N)?y
    -- old 6: if (UPPER('&conf') <> 'Y') then
    -- New 6: if (UPPER('y') <> 'Y') then
    -- Checking data validility...
    -- begin converting system objects
    -- PL/SQL procedure successfully completed.
    -- Alter the database character set...
    -- CSALTER operation completed, please restart database
    -- PL/SQL procedure successfully completed.
    -- Procedure dropped.
    -- if you are using spfile then you need to also
    -- ALTER SYSTEM SET job_queue_processes=<original value> SCOPE=BOTH;
    -- ALTER SYSTEM SET aq_tm_processes=<original value> SCOPE=BOTH;
    shutdown
    startup
    and the 10g database will be WE8MSWIN1252
    now go to point 3) of this note of course your database is then WE8MSWIN1252, so
    you need to replace <existing database character set> with WE8MSWIN1252 from now on.
    3) Check which rows contain data for which the code point will change
    Run csscan with the following syntax:
    csscan FULL=Y FROMCHAR=<your database character set> TOCHAR=AL32UTF8 LOG=WE8TOUTF8 CAPTURE=Y ARRAY=1000000 PROCESS=2
    Always run CSSCAN with 'sys as sysdba'
    This will create 3 files :
    WE8TOUTF8.out a log of the output of csscan
    WE8TOUTF8.txt a Database Scan Summary Report
    WE8TOUTF8.err a contains the rowid's of the rows reported in WE8check.txt
    + You should have NO entries under Lossy, because they should have been filtered
    out in step 2), if you have data under Lossy then please redo step 2).
    + If you have any entries under Truncation then go to step 4)
    + If you only have entries for Convertible (and Changeless) then solve those in
    step 5).
    + If you have NO entry's under the Convertible, Truncation or Lossy,
    and all data is reported as "Changeless" then proceed to step 6).
    4) If you have Truncation entries.
    Whichever way you migrate from WE8(...) to AL32UTF8, you will always have to
    solve the entries under Truncation.
    Standard ASCII characters require 1 byte of storage space under in WE8(...) and
    in AL32UTF8, however, other characters (like accented characters and the Euro
    sign) require only 1 byte of storage space in WE8(...), but they require 2 or
    more bytes of space in AL32UTF8.
    That means that the total amount of space needed to store a string can exceed
    the defined column size.
    For more information about this see:
    Note 119119.1 AL32UTF8 / UTF8 (unicode) Database Character Set Implications
    and
    "Truncation" data is always also "Convertible" data, which means that whatever
    else you do, these rows have to be exported before the character set is changed
    and re-imported after the character set has changed. If you proceed with that
    without dealing with the truncation issue then the import will fail on these
    columns because the size of the data exceeds the maximum size of the column.
    So these truncation issues will always require some work, there are a number of
    ways to deal with them:
    A) Update these rows in the source database so that they contain less data
    B) Update the table definition in the source database so that it can contain
    longer data. You can do this by either making the column larger, or by using
    CHAR length semantics instead of BYTE length semantics (only possible in
    Oracle9i).
    C) Pre-create the table before the import so that it can contain 'longer' data.
    Again you have a choice between simply making it larger, or switching from BYTE
    to CHAR length semantics.
    If you've chosen option A or B then please rerun csscan to make sure there is no
    Truncation data left. If that also means there is no Convertible data left then
    proceed to step 6), otherwise proceed to step 5).
    To know how much the data expands simply check the csscan output.
    you can find that in the .err file as "Max Post Conversion Data Size"
    For example, check in the .txt file wich table has "Truncation",
    let's assume you have there a row that say's
    -- snip from WE8TOUTF8.txt
    [Distribution of Convertible, Truncated and Lossy Data by Table]
    USER.TABLE Convertible Truncation Lossy
    SCOTT.TESTUTF8 69 6 0
    -- snip from WE8TOUTF8.txt
    then look in the .err file for "TESTUTF8" until the
    "Max Post Conversion Data Size" is bigger then the column size for that table.
    User : SCOTT
    Table : TESTUTF8
    Column: ITEM_NAME
    Type : VARCHAR2(80)
    Number of Exceptions : 6
    Max Post Conversion Data Size: 81
    -> the max size after going to UT8 will be 81 bytes for this column.
    5) If you have Convertible entries.
    This is where you have to make a choice whether or not you want to continue
    on this path or if it's simpler to do a complete export/import in the
    traditional way of changing character sets.
    All the data that is marked as Convertible needs to be exported and then
    re-imported after the character set has changed.
    6) check if you have functional indexes on CHAR based columns and purge the RECYCLEBIN.
    select OWNER, INDEX_NAME , INDEX_TYPE, TABLE_OWNER, TABLE_NAME, STATUS,
    FUNCIDX_STATUS from ALL_INDEXES where INDEX_TYPE not in
    ('NORMAL', 'BITMAP','IOT - TOP') and TABLE_NAME in (select unique
    (table_name) from dba_tab_columns where char_used ='C');
    if this gives rows back then the change will fail with
    ORA-30556: functional index is defined on the column to be modified
    if you have functional indexes on CHAR based columns you need to drop the
    index and recreate after the change , note that a disable will not be enough.
    On 10g check ,while connected as sysdba, if there are objects in the recyclebin
    SQL> show recyclebin
    If so do also a PURGE DBA_RECYCLEBIN; other wise you will recieve a ORA-38301 during CSALTER.
    7) Choose on how to do the actual change
    you have 2 choices now:
    Option 1 - exp/imp the entire database and stop using the rest of this note.
    a. Export the current entire database (with NLS_LANG set to <your old
    database character set>)
    b. Create a new database in the AL32UTF8 character set
    c. Import all data into the new database (with NLS_LANG set to <your old database character set>)
    d. The conversion is complete, do not continue with this note.
    note that you do need to deal with truncation issues described in step 4), even
    if you use the export/import method.
    Option 2 - export only the convertible data and continue using this note.
    For 9i and lower:
    a. If you have "convertible" data for the sys objects SYS.METASTYLESHEET,
    SYS.RULE$ or SYS.JOB$ then follow the following note for those objects:
    Note 258904.1 Convertible data in data dictionary: Workarounds when changing character set
    make sure to combine the next steps in the example script given in that note.
    b. Export all the tables that csscan shows have convertible data
    (make sure that the character set part of the NLS_LANG is set to the current
    database character set during the export session)
    c. Truncate those tables
    d. Run csscan again to verify you only have "changeless" application data left
    e. If this now reports only Changeless data then proceed to step 8), otherwise
    do the same again for the rows you've missed out.
    For 10g and up:
    a. Export all the USER tables that csscan shows have convertible data
    (make sure that the character set part of the NLS_LANG is set to the current
    database character set during the export session)
    b. Fix any "convertible" in the SYS schema, note that the 10g way to change
    the characterset (= the CSALTER script) will deal with any CLOB data in the
    sys schema. All "no 9i only" fixes in
    Note 258904.1 Convertible data in data dictionary: Workarounds when changing character set
    should NOT be done in 10g
    c. Truncate the exported user tables.
    d. Run csscan again to verify you only have "changeless" application data left
    e. If this now reports only Changeless data then proceed to step 8), otherwise
    do the same again for the rows you've missed out.
    When using CSSCAN 2.x (10g database) you should see in WE8TOUTF8.txt this:
    The data dictionary can be safely migrated using the CSALTER script
    If you do NOT have this when working on a 10g system CSALTER will NOT work and this
    means you have missed something or not followed all steps in this note.
    8) Perform the character set change:
    Perform a backup of the database.
    Check the backup.
    Double-check the backup.
    For 9i and below:
    Then use the "alter database" command, this changes the current database
    character set definition WITHOUT changing the actual stored data.
    Shutdown the listener and any application that connects locally to the database.
    There should be only ONE connection the database during the WHOLE time and that's
    the sqlplus session where you do the change.
    1. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all.
    If you are using RAC see
    Note 221646.1 Changing the Character Set for a RAC Database Fails with an ORA-12720 Error
    2. Execute the following commands in sqlplus connected as "/ AS SYSDBA":
    SPOOL Nswitch.log
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    ALTER SYSTEM ENABLE RESTRICTED SESSION;
    ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
    ALTER SYSTEM SET AQ_TM_PROCESSES=0;
    ALTER DATABASE OPEN;
    ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8;
    SHUTDOWN IMMEDIATE;
    -- a alter database takes typically only a few minutes or less,
    -- it depends on the number of columns in the database, not the amount of data
    3. Restore the parallel_server parameter in INIT.ORA, if necessary.
    4. STARTUP;
    Without the INTERNAL_USE you get a ORA-12712: new character set must be a superset of old character set
    WARNING WARNING WARNING
    Do NEVER use "INTERNAL_USE" unless you did follow the guidelines STEP BY STEP
    here in this note and you have a good idea what you are doing.
    Do NEVER use "INTERNAL_USE" to "fix" display problems, but follow Note 225938.1
    If you use the INTERNAL_USE clause on a database where there is data listed
    as convertible without exporting that data then the data will be corrupted by
    changing the database character set !
    For 10g and up:
    Shutdown the listener and any application that connects locally to the database.
    There should be only ONE connection the database during the WHOLE time and that's
    the sqlplus session where you do the change.
    Then you do in sqlplus connected as "/ AS SYSDBA":
    -- check if you are using spfile
    sho parameter pfile
    -- if this "spfile" then you are using spfile
    -- in that case note the
    sho parameter job_queue_processes
    sho parameter aq_tm_processes
    -- (this is Bug 6005344 fixed in 11g )
    -- then do
    shutdown
    startup restrict
    SPOOL Nswitch.log
    @@?\rdbms\admin\csalter.plb
    -- Csalter will aks confirmation - do not copy paste the whole actions on one time
    -- sample Csalter output:
    -- 3 rows created.
    -- This script will update the content of the Oracle Data Dictionary.
    -- Please ensure you have a full backup before initiating this procedure.
    -- Would you like to proceed (Y/N)?y
    -- old 6: if (UPPER('&conf') <> 'Y') then
    -- New 6: if (UPPER('y') <> 'Y') then
    -- Checking data validility...
    -- begin converting system objects
    -- PL/SQL procedure successfully completed.
    -- Alter the database character set...
    -- CSALTER operation completed, please restart database
    -- PL/SQL procedure successfully completed.
    -- Procedure dropped.
    -- if you are using spfile then you need to also
    -- ALTER SYSTEM SET job_queue_processes=<original value> SCOPE=BOTH;
    -- ALTER SYSTEM SET aq_tm_processes=<original value> SCOPE=BOTH;
    shutdown
    startup
    and the 10g database will be AL32UTF8
    9) Reload the data pump packages after a change to AL32UTF8 / UTF8 in Oracle10
    If you use Oracle10 then the datapump packages need to be reloaded after
    a conversion to UTF8/AL32UTF8. In order to do this run the following 3
    scripts from $ORACLE_HOME/rdbms/admin in sqlplus connected as "/ AS SYSDBA":
    For 10.2.X:
    catnodp.sql
    catdph.sql
    catdpb.sql
    For 10.1.X:
    catnodp.sql
    catdp.sql
    10) Reimporting the exported data:
    If you exported any data in step 5) then you now need to reimport that data.
    Make sure that the character set part of the NLS_LANG is still set to the
    original database character set during the import session (just as it was during
    the export session).
    11) Verify the clients NLS_LANG:
    Make sure your clients are using the correct NLS_LANG setting:
    Regards,
    Chotu,
    Bangalore

Maybe you are looking for

  • Function module to convert character value of month into numeric value?

    Hi Experts,                  I need to convert a character value of a month in three alphabets to its numeric value. e.g. 'jun' should be converted into '06' and 'jan' into '01' using a function module.Can anybody please provide me a similar function

  • Is there a way to temporarily prevent my phone from locking / sleeping?

    I'd love a way to temporarily prevent my phone from going to sleep -- like when I'm making a recipe and don't want to keep entering my password, etc., every time I check the next step. Is there an app I could turn on / off that would block the sleep

  • Document pricing procedure in Billing

    Dear All, Can anybody tell me, what is the use of having a document price procedure in billing doc type ? Rgds, Indrajit

  • Timed structure for output in producer consumer data acquisition

    Hello LabVIEW community, I have a bit of a problem.  I am writing a program that is primarily for data aquisition but has a few control features as well.  I need the program to aquire and write several channels of data at a relitively high speed.  Th

  • PHP_MySQL error msg in Dreamweaver CS3

    I tried to open my Dreamweaver (CS3) today, and it gave me this weird error message that I've never seen before: The following translators were not loaded due to errors: PHP_MySQL.htm: has configuration information that is invalid. Here's a screensho