Change characterset  to WE8MSWIN1252

When I try to change characterset from AL32UTF8 to WE8MSWIN1252, I get this error:-
ORA-12712: new character set must be a superset of old character set.
a) How to switch off the superset check to allow changes between formally incompatible character sets to solve this character set problem ?
b) Or is it that there is only one way to solve this problem :-
1) export database
2) reinstall database
3) Import database
c) Can some one tell me that ø,æ,å characters are found in AL32UTF8 characterset.
Rajkum

I had read somewhere that simply using the command to change the characterset does not quite do a clean job. The best way is to recreate the db.

Similar Messages

  • Convert Characterset from WE8MSWIN1252  to AL32UTF8

    Dear Friends,
    How to conver Characterset from WE8MSWIN1252 of Oracle 10.2.0.2 Database (32 bit Ent Edition) to AL32UTF8 on 11.2.0.2 (64 Bit Std Edition) during 11g DB Upgrade.
    How to check the Limitations of Characterset conversions and the objects which will be affected during the conversion.
    Regards,
    DB

    If you want help from this forum, i recommend:
    1) Search before post
    2) close your threads when it will be answered:
         839396     
    Handle:     839396
    Status Level:     Newbie
    Registered:     Feb 23, 2011
    Total Posts:     21
    Total Questions:     14 (14 unresolved)

  • Change characterset of db

    Hello
    When I want to change WE8MSWIN1252 to UTF-8 or al32utf8 using export import.
    What should be the order?
    Export data.
    Create new databse with new characterset
    Import data
    or
    Do I need to perform any additional step to convert characterset prior to import ?

    Hi,
    1. Run Csscan utility on ur existing DB to determine any other problems can occurs during conversion.
    csscan system/password full=y tochar=UTF8 array=10240 process=10
    2.Check CSSCAN logs and error.log files to see if any character conversion problem occurs.....
    3. if problem with Varchar2 field length then u can to run the following script to change the fields length or change the type to CLOB.
    --To generate the script run the following query
    select 'alter table '||owner||'.'||table_name||' modify ('||column_name||' varchar2('||DATA_LENGTH||' CHAR));' 
    from dba_tab_columns
    where data_type  = 'VARCHAR2';4.Repeat step 1 and 2
    5. Compile all invalid objects
    6. Export ur current DB
    7. Create new DB with UTF8 Characterset
    8.Import into new DB make sure the Enviornment Variable NLS_LANG=UTF8 is set to avoid statistics error
    9. Generate object statistics after import.
    plz mark as correct/helpful if it is
    Baig,
    [My Oracle Blog|http://baigsorcl.blogspot.com/]

  • 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

  • How change CHARACTERSET to WE8ISO8859P1?

    Hi,
    How change character set the XE to WEISO8859P1, have problem with word special like ç, á, ã, â. I it would not work NCHAR ou NVARCHAR.
    Thank you.
    Ivan

    Dear friend.
    Thanks for your interest in this matter.
    But believe in me, the problemas was solved. !!
    Five people was tested all the programs for hours today, retrieving data from the database, inserting all kind of Brazilian characters in new records, updating it a lot of times using lowercase and uppercase, and all the Braziian characters with acentuation and every other special character was tested one by one.
    My customer works with very critical and official documents, therefore needs this kind of characters in the screen and to print in paper. All is working fine now.
    Of course before to change the NLS_CHARCHARACTERSET from WE8ISO8859P1 to WE8MSWIN1252 I tested all the NLS_LANG sets, including the NSL_LANG sugguested by you, without success. (I spent 3 days in this week to research this matter, and before to place a post here, I was already tested all the NLS_LANG sets possible.
    Don´t worry, the problem "is solved" only changing the NLS_CHARCHARACTERSET from WE8ISO8859P1 to WE8MSWIN1252.
    Thanks you for the ALTER DATABASE sintax.
    L.

  • Change characterset on session

    Hi
    I am pankaj.I want to change the characterset of my database.
    I change the characterset of the database by alter system......cmd
    Now I want to change it at session level.
    Is is possible, How can i do this.
    pl help

    Hi Pankaj,
    I hope you know what are you doing.
    You shouldn't change your characterset on session level because the characterset on the client side depends on the OS of the client side.
    If you change it to a different characterset you can destroy your database. You don't get any error messages or warnings

  • Can I change Characterset after DB Creation?

    Hi everybody,
    Is it possible to change the parameter CHARACTER SET
    specified in database creation after database is created? How can I support
    customers who have a database installation with CHARACTER SET
    as WE8ISO8859P1, now I want to change it to something else. Is
    there any alternative to database re-creation? If not, then how
    do I go about creating the database again while retaining the old data??
    Any tips, folks?
    Regards
    Sanchayan

    Given that your current character set is WE8ISO8859P1, I don't think there are many places you can go. I think WE8ISO8859P15 (euro-support) would be be a strict superset but not much else; you need to check with Oracle what the valid ones are. This is because the character set determines how your data is encoded in the database: it's relatively simple to add new encodings to an existing set, but impossible to translate the current encoding to a new meaning.
    If you want to change to (say) UNICODE then you'll have to do a complete export, recreate the database with the new character set and then import your data.
    Good luck, APC

  • Chang Charactor set WE8MSWIN1252 to AL32UTF8 for creating RCU

    Hi
    how can I chang the Charactor set for creating RCU,
    Thanks,
    Sri.

    Balaa wrote:
    Sri,
    Follow the below steps,
    conn / as sysdba
    col parameter format a30
    col value format a30
    SELECT view_name FROM dba_views WHERE view_name LIKE '%NLS%';
    SELECT * FROM v$nls_parameters;
    SHUTDOWN IMMEDIATE;
    STARTUP RESTRICT;
    ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
    ALTER SYSTEM SET AQ_TM_PROCESSES=0;
    ALTER DATABASE CHARACTER SET AL32UTF8;
    -- if the above fails:
    ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8;
    SHUTDOWN IMMEDIATE;
    STARTUP;
    SELECT * FROM v$nls_parameters;
    Thanks,
    Balaa...
    Absolutely the INCORRECT thing to do !!
    This will result in corruption of your database that you cannot recover from.
    Review MOS Doc - 260912.1
    Difference between NLS_CHARACTERSETAL32UTF8 & NLS_CHARACTERSET WE8MSWIN125
    Supported methods are documented - Character Set Migration

  • Upgrade 8.0.5 to 10gR2 & changing Characterset

    Can you please advise on the following,,
    I would like to upgrade 8.0.5 db(AR8iso8859p6) to 10g (AR8mswin1256) what is the best way to avoid character conversion ? O/s-Solaris
    (1)
    Exp from 8.0.5(ar8iso8859p6) and IMP in 9i (AR8MSWIN1256)
    then EXP 9i (AR8MSWIN1256) & IMP in 10g (AR8MSWIN1256)
    OR
    (2)at 8.0 db
    SVRMGR> STARTUP MOUNT;
    SVRMGR> ALTER SYSTEM ENABLE RESTRICTED SESSION;
    SVRMGR> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
    SVRMGR> ALTER SYSTEM SET AQ_TM_PROCESSES=0;
    SVRMGR> ALTER DATABASE OPEN;
    SVRMGR> AALTER DATABASE NATIONAL CHARACTER SET ar8mswin1256;
    SVRMGR> SHUTDOWN IMMEDIATE;
    SVRMGR> STARTUP;
    then exp & imp in 9i and then to 10g.
    OR
    (3)
    Thanks

    The only supported way is option (1) that you describe (using exp/imp). The intermediate version could be 8.1.7.4 instead of 9i - see the 10gR2 Upgrade Guide at http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/preup.htm#i1007814
    HTH
    Srini

  • Purpose of nls_lang

    Hi
    What is the purpose of setting nls_lang before export or import?
    What happens if I dont set it ?
    As far as I understand, it is related to client issue. Is it again come into play if I do the export/import directly from server ?
    Suppose I want to change characterset from WE8MSWIN1252 to UTF-8.
    I took export.
    Create new database with utf8.
    and import.
    Do I need to set nls_lang prior to import or export?
    I appreciate if anyone clear my doubts.

    >
    What is the purpose of setting nls_lang before export or import?
    What happens if I dont set it ?
    As far as I understand, it is related to client issue. Is it again come into play if I do the export/import directly from server ?
    >
    If you use datapump, never mind. If you use exp,imp, the main reason why to set NLS_LANG is the characterset component of it. Set it to the appropriate character set of the computer, you do the exp and imp on. Else you might loose special characters stored in your tables. It is not necessarily the same as the database character set.
    Look at
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10729/ch3globenv.htm#sthref133
    Kind regards
    Uwe
    http://uhesse.wordpress.com

  • 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

  • Chinese in US7ASCII characterset change into chinese in UTF8

    Hi all
    We have chineses words in US7ASCII characterset. We used to change characterset in this way. Export (NLS_LANG=AMERICAN_AMERICA.US7ASCII) to dumpfile, then change first 3 and 4 bytes to zht16mswin950 (03 and 63). finally set NLS_LANG=AMERICAN_AMERICA.ZH6MSWIN950 then import into UTF8. It works fine until 8i exp client. After 9i above, I don't know how to change characterset. I need to exp/imp from 10g us7ascii to 11g UTF8. I try to lookup document about csscan, it seems need to issue a service request. Could somebody kindly tell me how to fix this encoding problem. Thanks a lot.
    Vega

    There are several issues here.
    >
    We have chineses words in US7ASCII characterset.
    >
    How did you manage to do that ? US7ASCII is certainly not capable of storing any Chinese characters.
    >
    ... then change first 3 and 4 bytes to zht16mswin950 ...
    >
    Change what ? where ? how ?
    >
    ... I need to exp/imp from 10g us7ascii to 11g UTF8 ...
    >
    You can certainly do that, but it will not fix your chinese characters.
    Pl post this issue on the Globalization forum - Globalization Support - where Sergiusz Wolicki may be able to help
    HTH
    Srini

  • ORA-12712 error while changing nls character set to AL32UTF8

    Hi,
    It is strongly recommend to use database character set AL32UTF8 when ever a database is going to used with our XML capabilities. The database character set in the installed DB is WE8MSWIN1252. For making use of XML DB features, I need to change it to AL32UTF8. But, when I try doing this, I'm getting ORA-12712: new character set must be a superset of old character set. Is there a way to solve this issue?
    Thanks in advance,
    Divya.

    Hi,
    a change from we8mswin1252 to al32utf8 is not directly possible. This is because al32utf is not a binary superset of we8mswin1252.
    There are 2 options:
    - use full export and import
    - Use of the Alter in a sort of restricted way
    The method you can choose depends on the characters in the database, is it only ASCII then the second one can work, in other cases the first one is needed.
    It is all described in the Support Note 260192.1, "Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode)". Get it from the support/metalink site.
    You can also read the chapters about this issue in the Globalization Guide: [url http://download.oracle.com/docs/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#g1011430]Change characterset.
    Herald ten Dam
    http://htendam.wordpress.com

  • Unable to migrate table, character set from WE8MSWIN1252 to AL32UTF8

    Hi,
    On our source db the character set is AL32UTF8
    On our own db, we used the default character set of WE8MSWIN1252 .
    When migrating one of the table, we get an error of this: ORA-29275: partial multibyte character
    So in to alter our character set from WE8MSWIN1252 to AL32UTF8, we get this error:
    ALTER DATABASE CHARACTER SET AL32UTF8
    ERROR at line 1:
    ORA-12712: new character set must be a superset of old character set
    I would sure not like to reinstall the db and migrate the tables again. Thanks.

    See this related thread - Re: Want to change characterset of DB
    You can use the ALTER DATABASE CHARACTER SET command in very few cases. You will most likely have to recreate the database and re-migrate the data.
    HTH
    Srini

  • A easy and simple database change?

    Hi folks:
    I have a easy and simple question (I guess) that I need to resolve a database problem.
    I installed a 9.2.0.1 database but I setting up the wrong character set.
    Now I need to change the character set to AL32UTF8 but I really don't know how.
    I amot newbe on database but there are some things that I don't know because of my main area: Development.
    Can anyone tell me in a easy way, how I need to do to change it.
    Somethin like a sga parameter on enterprise manager, spfile or maybe a database table update?
    Thank you so much in advanced,
    Abdel Miranda
    AEMS Global Group
    Panama

    The current characterset is WE8MSWIN1252 but I must have AL32UTF8 because I am installing Oracle Application Express.
    So, I have a oracle express objects which I export from a machine with a AL32UTF8 characterset and now I am ready to import those objects using the file.
    But I was trying to imported and Apex sends me an error related with "a huge unrecognize lines on selected file" becasue of the character set.
    I already changed the Oracle Application Express character set modifying the dad's file but still giving me the unrecognize lines on the exported file.
    So I must change my database character set to be able to import all the objects I requiered to use my applications on Apex (Oracle Application Express).
    I know it is probablly not as easy and simple as I want, but my databse is working properly and because of the apex installation I am not able to deleted and created again with the correct characterset......
    Which is the best way to do it?
    Abdel Miranda
    AEMS Global Group
    Panama

Maybe you are looking for