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/]

Similar Messages

  • 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.

  • 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

  • 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

  • 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

  • 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.

  • 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

  • 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

  • Change character set

    Hi
    is anyone can tell me how to change characterset.
    i try with alter session but it doesnt work.
    thanks

    Article from Metalink
    Doc ID:      Note:66320.1
    Subject:      Changing the Database Character Set or the Database National Character Set
    Type:      BULLETIN
    Status:      PUBLISHED
         Content Type:      TEXT/PLAIN
    Creation Date:      23-OCT-1998
    Last Revision Date:      12-DEC-2003
    PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> 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 <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
         Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.     
    Joel P�rez

  • 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

  • NLS character set non AL32UTF8 versus AL32UTF8

    Good morning Gurus,
    RCU utility strongly recommends to have this parameter set to AL32UTF8.
    My database by default was set as WE8MSWIN1252.
    I have read a lot about these settings. and like to have exact steps to take to accomplish this. I posted this problem in "Problem with RCU utility' but did not get any response.
    My question is why oracle makes things difficult. I only use american language, if both are good for that then why do RCU requires to change it.
    I have seen people who have ignored this message had trouble down the road of installation process.
    I appreciate if some one can explain to me the implications of not changing versus changing.
    Is that means, my database has to be kept with AL32UTF8 parameter all the time after installation is done?
    Also another question
    I have 3 meg RAM on my laptop, Oracle requires 4, will this cause the problem during installation?
    Thank you
    j

    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

  • Impdp error ORA 316931 29913, 31011, 19202

    One of my colleague got this error while importing a database from dump and he passed it to me resolve the issue.
    The import command used:
    impdp raviuyre/systemcr DUMPFILE=3_dir:FITHA_0.dmp LOGFILE=import_0.log TABLES=SLATIONS TABLE_EXISTS_ACTION=APPEND*
    Error:
    Processing object type SCHEMA_EXPORT/TABLE/TABLE
    ORA-39153: Table "RAVIUYRE"."SLATIONS" exists and has been appended. Data will be loaded but all dependent metadata will be skipped due to table_exists_action of append
    Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
    ORA-31693: Table data object "RAVIUYRE"."SLATIONS" failed to load/unload and is being skipped due to error:
    ORA-29913: error in executing ODCIEXTTABLEFETCH callout
    ORA-31011: XML parsing failed
    ORA-19202: Error occurred in XML processing
    LPX-00217: invalid character 133 (U0085)+
    Error at line 1
    Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
    Is the below error
    ORA-31693: Table data object "RAVIUYRE"."SLATIONS" failed to load/unload and is being skipped due to error:
    ORA-29913: error in executing ODCIEXTTABLEFETCH callout
    ORA-31011: XML parsing failed
    ORA-19202: Error occurred in XML processing
    LPX-00217: invalid character 133 (U0085)+
    caused because of the table which has been appended.
    Kindly help me.....
    Thanks in advance,
    NONUDAY

    897910 wrote:
    Hi Srini,
    I found out that this database has a character set WE8MSWIN1252 which doesn't support XML type.Pl elaborate on how you determined this. I am not an expert in XML types, but I do not think support is related to NLS_CHARACTERSET.
    >
    SQL> select * from nls_database_parameters where parameter ='NLS_CHARACTERSET';
    PARAMETER                      VALUE
    NLS_CHARACTERSET               WE8MSWIN1252
    Is above the character set is reason for the error, if yes can you tell me how can I change the WE8MSWIN1252 to AL32UTF8(supports XML)?
    Thanks for your inputs..
    Regards,
    KarthikFor changing charactersets, pl see these MOS Docs
    Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode)          [Document 260192.1]
    AL32UTF8 / UTF8 (Unicode) Database Character Set Implications          [Document 788156.1]
    HTH
    Srini

  • Setting the database character set problem!

    I'm sorry if this is beaten to death, I've read the FAQ and many questions in this forum and I didn't find it.
    I want to change the database character set from the beginning. Where do I place the NLS_CHARACTERSET=EL8ISO8859P7 ?
    I know I can alter the existing database character but EL8ISO8859P7 is not a superset of WE8ISO8859P1 and I don't want to go to Unicode yet...
    Do I have to create a brand new database or can I just alter a script and restart it ?
    I didn't find any nls_setting in the database creations, uh, wizard.
    Please be as specific as possible because as you can understand I'm not what you can call a db expert...
    Thank you.

    which version of Oracle? these things change between versions.
    v7 - update sys.props$ (unsupported!)
    v8.0 - rebuild database
    v8.1 - alter database change characterset
    remember, backup and test before you do this on a used/production database!
    good luck, Nogah.

Maybe you are looking for

  • Hard Disk verifies OK but wont boot. Can't re-install or erase.

    I have a problem with my Powerbook (Tibook) G4 667. It won't boot. After the initial grey screen, it gets as far as a completely blue screen and eventually resorts to the Darwin console (?). I'm running OS X 10.4.? (sorry - can't remember when I last

  • 5.1.1 unknown or illegal user

    Can anyone tell me what I'm doing wrong here? First off, I'm doing direct LDAP rather than the dirsync stuff. I'm getting the following when doing an 'imsimta test -rewrite -debug [email protected]': Initializing mm_. Initializing mm_ submissio

  • Zero timecode start for XDCAM EX files

    After importing 1280x720 24p Sony XDCAM EX files, Project window displays zero starting timecode. I'm using the CS3 Education version, but it's the up-to-date 3.2.0. I have read that others have experienced this while others have not. No matter how I

  • FCE not recongnizing DV camera

    My computer sees my Canon DV camera via firewire but when I try to capture through FCE, it does not see it. When I try to select my settings in easy setup FCE crashes on me. Any help would be much appreciated! -Liz

  • An error occurred within an XI interface: Exception occurred

    Hi I am doing a scenario in which I am integrating R3-XI-SUS for PO,PO Response, ASN,GR and INVOICE. In which PO, PO Response and ASN working fine but when I am sending GR from R3 to SUS it is coming to XI correctly but it is received in SUS with err