Session level character set

The below are my character set in my DB
NLS_CHARACTERSET=WE8ISO8859P1
NLS_NCHAR_CHARACTERSET=UTF8
Correct Answer (If I use english language the result is correct)
==========
select product(',','AB_BC ,DE') from dual;
(AB_BC, DE,,,)
After altering the parameter at session level to get Japanese character set I am getting wrong result
ALTER SESSION NLS_SORT=JAPANESE_M_AI
ALTER SESSION NLS_COMP=LINGUISTICS
it is giving me wrong result (I should get the above result)
=================
select product(',','A_BC ,DE') from dual;
(AB, BC , DE,,,,)
How to change at session leavel to get Japanese character set

Ok,
Let's provide the broad picture, as your setup and your commands are incorrect.
You set the characterset of the database to a characterset the O/S supports.
Whether or not you have characterset conversion on the client side is determined by NLS_LANG.
You set NLS_LANG to a characterset the client O/S supports. Ie if you are running on Windows (as always you provide no details at all), the regional settings of the O/S must have been set to Japanese.
WE8ISO8859P1 is the Latin-1 alphabet and doesn't support Kanji.
Also the command you specify deal with sorting of the data, not with the characterset itself.
Also no one can tell what
select product(',','AB_BC ,DE') from dual;
constitutes.
In summary: you don't seem to be reading documentation, or you only look at it.
None of what you have posted makes any sense, and clearly shows you didn't try to understand the NLS concept.
Yet again: you don't provide platform and version info
Yet again: you don't specify any background.
If you want help, you need to provide as much info as possible.
You should not require anyone here to tear the information out of you.
After all: everyone here is a volunteer and doesn't get paid to help you out, but is spending his/her time.
If you want to continue to post in this fashion, maybe you should find a forum of mindreaders.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

  • Can we change the DB character set at session level

    hi,
    Please help me
    when iam giving the alter session command iam getting the error:
    SQL> ALTER SESSION set NLS_CHARACTERSE
    T =WE8MSWIN1252;
    ALTER SESSION set NLS_CHARACTERSET =WE8MSWIN1252
    ERROR at line 1:
    ORA-00922: missing or invalid
    i need to enter Arabic names in using the xml file.
    here i have two questions
    1)is it is possible to set character set at session level. because my client is not allowing to bounce the database. DB version is 10.2.0.4
    Right now my DB is in US7ascii
    2)is this "WE8MSWIN1252" set supports Arabic.
    Regards,
    Naresh

    You cannot change the characterset at the session level. If you want to store ARABIC characters in your database then you should change the characterset of your database to any other characterset that supports Arabic characters or to a Unicode characterset like UTF8 or AL32UTF8.
    If you try to insert Arabic characters with your present US7ASCII charancterset then the characters would be stored as junk.

  • Is it possible to set character set at instance level?

    hi all,
    I have some confusion.
    say my database character set is AL32UTF8.
    and i want tio set charcter set of instance is WE8MSWIN1252
    Is it passible to set character set at instance level?
    Please reply with yes or No or why?
    Thanks & Regards,

    Hi,
    It's DataBase Level. One best example would be when you try to change the character or characterset conversion by using "Csscan" you can check the log or report. Which can guide what the things are happening. Instance - I think you might be referring to "Session".
    - Pavan Kumar N
    - ORACLE OCP - 9i/10g
    https://www.oracleinternals.blogspot.com

  • Setting Session level parameter in FORMS 10g

    Hi folks,
    I want to setup session level setting for NLS DATE FORMAT in FORMS 10g at environment settings. because, i can't change these setting at database level. b,cz different client applications (i.e. .NET,Forms 10g and SQL PLUS) using different settings.
    So, i want to set this NLS DATE FORMAT for SESSION level in FORMS 10g.
    can i include this in default.env, if yes, how to include that one in .env file
    Edited by: user12212962 on Jul 23, 2010 7:18 PM

    No, i want to setup the session parameter for DATE FORMAT. why because, i'm executing oracle stored procedure from forms and this procedure does some logic based on date value.
    In this procedure, i have used all variables as DATE datatype only. and i can't change this procedure due to some other client application's using same procedure like JAVA, .NET, Oracle BI and scheduled jobs. And all these application's working fine, even when i use forms 6i also it's working.
    but when we use FORMS10g, date was treating as DD-MON-RR and all other client applications using DD-MON-YYYY due to session level setting and at database level also has a same format i.e. DD-MON-YYYY. because i logged this NLS value in audit_table when i executed through FORMS10G, JAVA application,.NET
    May be some where it's changing this setting to DD-MON-RR for FORMS10g. Is any settings at Oracle APP server level
    (iAS) for this parameter?

  • ORA-12709: error while loading create database character set after upgrade

    Dear All
    i m getting ORA-12709: error while loading create database character set, After upgraded the database from 10.2.0.3 to 11.2.0.3 in ebusiness suit env.
    current application version 12.0.6
    please help me to resolve it.
    SQL> startup;
    ORACLE instance started.
    Total System Global Area 1.2831E+10 bytes
    Fixed Size 2171296 bytes
    Variable Size 2650807904 bytes
    Database Buffers 1.0133E+10 bytes
    Redo Buffers 44785664 bytes
    ORA-12709: error while loading create database character set
    -bash-3.00$ echo $ORA_NLS10
    /u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
    export ORACLE_BASE=/u01/oracle
    export ORACLE_HOME=/u01/oracle/PROD/db/tech_st/11.2.0
    export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
    export PERL5LIB=$ORACLE_HOME/perl/lib/5.10.0:$ORACLE_HOME/perl/site_perl/5.10.0
    export ORA_NLS10=/u01/oracle/PROD/db/teche_st/11.2.0/nls/data/9idata
    export ORACLE_SID=PROD
    -bash-3.00$ pwd
    /u01/oracle/PROD/db/tech_st/11.2.0/nls/data/9idata
    -bash-3.00$ ls -lh |more
    total 56912
    -rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx00001.nlb
    -rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00002.nlb
    -rw-r--r-- 1 oracle oinstall 959 Jan 15 16:05 lx00003.nlb
    -rw-r--r-- 1 oracle oinstall 984 Jan 15 16:05 lx00004.nlb
    -rw-r--r-- 1 oracle oinstall 968 Jan 15 16:05 lx00005.nlb
    -rw-r--r-- 1 oracle oinstall 962 Jan 15 16:05 lx00006.nlb
    -rw-r--r-- 1 oracle oinstall 960 Jan 15 16:05 lx00007.nlb
    -rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00008.nlb
    -rw-r--r-- 1 oracle oinstall 940 Jan 15 16:05 lx00009.nlb
    -rw-r--r-- 1 oracle oinstall 939 Jan 15 16:05 lx0000a.nlb
    -rw-r--r-- 1 oracle oinstall 1006 Jan 15 16:05 lx0000b.nlb
    -rw-r--r-- 1 oracle oinstall 1008 Jan 15 16:05 lx0000c.nlb
    -rw-r--r-- 1 oracle oinstall 998 Jan 15 16:05 lx0000d.nlb
    -rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx0000e.nlb
    -rw-r--r-- 1 oracle oinstall 926 Jan 15 16:05 lx0000f.nlb
    -rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00010.nlb
    -rw-r--r-- 1 oracle oinstall 958 Jan 15 16:05 lx00011.nlb
    -rw-r--r-- 1 oracle oinstall 956 Jan 15 16:05 lx00012.nlb
    -rw-r--r-- 1 oracle oinstall 1005 Jan 15 16:05 lx00013.nlb
    -rw-r--r-- 1 oracle oinstall 970 Jan 15 16:05 lx00014.nlb
    -rw-r--r-- 1 oracle oinstall 950 Jan 15 16:05 lx00015.nlb
    -rw-r--r-- 1 oracle oinstall 1.0K Jan 15 16:05 lx00016.nlb
    -rw-r--r-- 1 oracle oinstall 957 Jan 15 16:05 lx00017.nlb
    -rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00018.nlb
    -rw-r--r-- 1 oracle oinstall 932 Jan 15 16:05 lx00019.nlb
    -rw-r--r-- 1 oracle oinstall 951 Jan 15 16:05 lx0001a.nlb
    -rw-r--r-- 1 oracle oinstall 944 Jan 15 16:05 lx0001b.nlb
    -rw-r--r-- 1 oracle oinstall 953 Jan 15 16:05 lx0001c.nlb
    Starting up:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options.
    ORACLE_HOME = /u01/oracle/PROD/db/tech_st/11.2.0
    System name: SunOS
    Node name: proddb3.zakathouse.org
    Release: 5.10
    Version: Generic_147440-19
    Machine: sun4u
    Using parameter settings in server-side spfile /u01/oracle/PROD/db/tech_st/11.2.0/dbs/spfilePROD.ora
    System parameters with non-default values:
    processes = 200
    sessions = 400
    timed_statistics = TRUE
    event = ""
    shared_pool_size = 416M
    shared_pool_reserved_size= 40M
    nls_language = "american"
    nls_territory = "america"
    nls_sort = "binary"
    nls_date_format = "DD-MON-RR"
    nls_numeric_characters = ".,"
    nls_comp = "binary"
    nls_length_semantics = "BYTE"
    memory_target = 11G
    memory_max_target = 12G
    control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl01.dbf"
    control_files = "/u01/oracle/PROD/db/tech_st/10.2.0/dbs/cntrl02.dbf"
    control_files = "/u01/oracle/PROD/db/apps_st/data/cntrl03.dbf"
    db_block_checksum = "TRUE"
    db_block_size = 8192
    compatible = "11.2.0.0.0"
    log_archive_dest_1 = "LOCATION=/u01/oracle/PROD/db/apps_st/data/archive"
    log_archive_format = "%t_%s_%r.dbf"
    log_buffer = 14278656
    log_checkpoint_interval = 100000
    log_checkpoint_timeout = 1200
    db_files = 512
    db_file_multiblock_read_count= 8
    db_recovery_file_dest = "/u01/oracle/fast_recovery_area"
    db_recovery_file_dest_size= 14726M
    log_checkpoints_to_alert = TRUE
    dml_locks = 10000
    undo_management = "AUTO"
    undo_tablespace = "APPS_UNDOTS1"
    db_block_checking = "FALSE"
    session_cached_cursors = 500
    utl_file_dir = "/usr/tmp"
    utl_file_dir = "/usr/tmp"
    utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound"
    utl_file_dir = "/u01/oracle/PROD/db/tech_st/10.2.0/appsutil/outbound/PROD_proddb3"
    utl_file_dir = "/usr/tmp"
    plsql_code_type = "INTERPRETED"
    plsql_optimize_level = 2
    job_queue_processes = 2
    cursor_sharing = "EXACT"
    parallel_min_servers = 0
    parallel_max_servers = 8
    core_dump_dest = "/u01/oracle/PROD/db/tech_st/10.2.0/admin/PROD_proddb3/cdump"
    audit_file_dest = "/u01/oracle/admin/PROD/adump"
    db_name = "PROD"
    open_cursors = 600
    pga_aggregate_target = 1G
    workarea_size_policy = "AUTO"
    optimizer_secure_view_merging= FALSE
    aq_tm_processes = 1
    olap_page_pool_size = 4M
    diagnostic_dest = "/u01/oracle"
    max_dump_file_size = "20480"
    Tue Jan 15 16:16:02 2013
    PMON started with pid=2, OS id=18608
    Tue Jan 15 16:16:02 2013
    PSP0 started with pid=3, OS id=18610
    Tue Jan 15 16:16:03 2013
    VKTM started with pid=4, OS id=18612 at elevated priority
    VKTM running at (10)millisec precision with DBRM quantum (100)ms
    Tue Jan 15 16:16:03 2013
    GEN0 started with pid=5, OS id=18616
    Tue Jan 15 16:16:03 2013
    DIAG started with pid=6, OS id=18618
    Tue Jan 15 16:16:03 2013
    DBRM started with pid=7, OS id=18620
    Tue Jan 15 16:16:03 2013
    DIA0 started with pid=8, OS id=18622
    Tue Jan 15 16:16:03 2013
    MMAN started with pid=9, OS id=18624
    Tue Jan 15 16:16:03 2013
    DBW0 started with pid=10, OS id=18626
    Tue Jan 15 16:16:03 2013
    LGWR started with pid=11, OS id=18628
    Tue Jan 15 16:16:03 2013
    CKPT started with pid=12, OS id=18630
    Tue Jan 15 16:16:03 2013
    SMON started with pid=13, OS id=18632
    Tue Jan 15 16:16:04 2013
    RECO started with pid=14, OS id=18634
    Tue Jan 15 16:16:04 2013
    MMON started with pid=15, OS id=18636
    Tue Jan 15 16:16:04 2013
    MMNL started with pid=16, OS id=18638
    DISM started, OS id=18640
    ORACLE_BASE from environment = /u01/oracle
    Tue Jan 15 16:16:08 2013
    ALTER DATABASE MOUNT
    ORA-12709 signalled during: ALTER DATABASE MOUNT...

    ORA-12709 signalled during: ALTER DATABASE MOUNT...Do you have any trace files generated at the time you get this error?
    Please see these docs.
    ORA-12709: WHILE STARTING THE DATABASE [ID 1076156.6]
    Upgrading from 9i to 10gR2 Fails With ORA-12709 : Error While Loading Create Database Character Set [ID 732861.1]
    Ora-12709 While Trying To Start The Database [ID 311035.1]
    ORA-12709 when Mounting the Database [ID 160478.1]
    How to Move From One Database Character Set to Another at the Database Level [ID 1059300.6]
    Thanks,
    Hussein

  • Query distributed database with different character sets.

    Hello experts, this is my situation:
    I have two databases A and B, the same version 11.1.0.7, the same OS Suse Linux Enterprise 10 but with different character sets, A has WE8MSWIN1252 while B has AL32UTF8. The database B is my XML DB repository so there I have some XML type tables. I need to query this tables from the database A using a dblink and in fact I have done that but the XML content is trasformed due to the different character sets between the databases. Some time there are data loss and some time there are data missmatch.
    Is there any way to query the tables stored in the database B without problems? I do not know if the following is correct: Maybe I can set the character set for the session in the database A during the time it query the database B. That is, change the character set in fly at session level.
    Do you have any special suggestion?
    I hope you can help me, thank you in advance.

    The Globalization Support Guide for 11.1.0.7 has a chapter on character set migration that should be helpful. AL32UTF8 is a superset of WE8MSWIN1252 but it is not a strict superset. That is, it doesn't meet the second prong of the test in the documentation
    The new character set is a strict superset of the current character set if:
    Each and every character in the current character set is available in the new character set.
    Each and every character in the current character set has the same code point value in the new character set. For example, many character sets are strict supersets of US7ASCII.Exporting the data from the A, changing the character set (or creating a new database with the AL32UTF8 character set), and then importing the data may be the easiest approach in your case.
    Justin
    Edited by: Justin Cave on Jan 13, 2011 12:08 PM

  • How to change Japanese character set

    The below are my character set in my DB
    NLS_CHARACTERSET=WE8ISO8859P1
    NLS_NCHAR_CHARACTERSET=UTF8
    Correct Answer (If I use english language the result is correct)
    ==========
    select product(',','AB_BC ,DE') from dual;
    (AB_BC, DE,,,)
    After altering the parameter at session level to get Japanese character set I am getting wrong result
    it is giving wrong result
    ==============
    select product(',','A_BC ,DE') from dual;
    (AB, BC , DE,,,,)
    How to change at session leavel to get Japanese character set

    user446367 wrote:
    Correct Answer (If I use english language the result is correct)What does "use english language" mean in this context?
    After altering the parameter at session level to get Japanese character set I am getting wrong resultThere is no such thing. Show us (copy paste) the commands and the resulting output, please.
    select product(',','A_BC ,DE') from dual;As requested several times already in your other thread on the same subject, it would greatly help forum members to help you if you would post the pl/sql of this function.
    AFAIK, product() is not a built-in standard Oracle function.
    How to change at session leavel to get Japanese character setThat is probably not what's needed, but anyway, here's one simple example:
    export NLS_LANG=.JA16SJIS
    sqlplus u/p@svc
    sql> ...

  • NLS Character Set problem

    Hi all,
    I am getting very tricky kind of problem oracle 10G. When I am try to insert a special character like '?' in 180 degree opposite direction( means imagine if we rotate the given special character ' ? ' in 180 degree), its perfectly inserting and I am able to see that character in the same way which I inserted in my production database. But if I try to do the sme in my development database and try to view it using select statement, its showing like normal '?' , not in a rotated one. Can any one help me to figure out this problem.
    thanks in advance.
    Karthik

    I suppose you are using a spanish database and this problem it's normal: database doesn't reconigzes this "special character" and it prints this as a "easy conversion" (but not usefull conversion). I want suggest you to use any of the 'NLS_....' parameters at session level (or statment level, if you can). With 'NLS_LANG' you can define country language characterset. If you type well your database can recognize this character among others, like 'ñ', 'á', 'à', etc. If this not runs well you probably will need to change the entire database character set.

  • 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

  • How to measure undo at a session level

    Below is what are trying to do.
    We are trying to implement Oracle's table block compression feature.
    In doing so, in one of our testing we discovered that the session performing the DML (inserts) generated almost 30x undo.
    We measured this undo by using below query (before the transaction commited).
    SELECT a.sid, a.username, used_ublk, used_ublk*8192 bytes
    FROM v$session a, v$transaction b
    WHERE a.saddr = b.ses_addr
    However, above is at a transaction level since it still not committed, we would lose this value once the transaction either committed or rolled back, for this reason, we are trying to find an equivalent statistic at a session level.
    1. What we are trying to find it out whether if an equivalent session level statistic exist to measure the amount of undo generated?
    2. Is the undo generated always in terms of "undo blocks?"
    3. When querying v$statname for name like '%undo%' we came across several statistics, the closest one
    undo change vector size -in bytes?
    4. desc test_table;
    Name Type
    ID NUMBER
    sql> insert into test_table values (1);
    5. However when we run the query against:
    SELECT s.username,sn.name, ss.value
    FROM v$sesstat ss, v$session s, v$statname sn
    WHERE ss.sid = s.sid
    AND sn.statistic# = ss.statistic#
    AND s.sid =204
    AND sn.name ='undo change vector size'
    SID USERNAME NAME BYTES
    204 NP4 undo change vector size 492
    6. Query against: v$transaction
    SELECT a.sid, a.username, used_ublk, used_ublk*8192 bytes
    FROM v$session a, v$transaction b
    WHERE a.saddr = b.ses_addr
    SID USED_UBLK BYTES
    204 1 8192
    What are trying to understand is:
    1. How can we or what is the correct statistic to determine how many undo blocks were generated by particular session?
    2. What is the statistic: undo change vector size? What does it really mean? or measure?

    Any transaction that generates Undo will use Undo Blocks in multiples of 1 --- i.e. the minimum allocation on disk is 8KB.
    Furthermore, an Undo_Rec does not translate to a Table Row. The Undo has to capture changes to Indexes, block splits, other actions. Multiple changes to the same table/index block may be collapsed into one undo record/block etc etc.
    Therefore, a transaction that generated 492 bytes of Undo would use 8KB of undo space because that is the minimum allocation.
    You need to test with larger transactions.
    SQL> update P_10 set col_2='ABC2' where mod(col_1,10)=0;
    250000 rows updated.
    SQL>
    SQL> @active_transactions
           SID    SERIAL# SPID         USERNAME     PROGRAM                       XIDUSN  USED_UBLK  USED_UREC
           143        542 17159        HEMANT       sqlplus@DG844 (TNS V1-V3)          6       5176     500000
    Statistic : db block changes                                      1,009,903
    Statistic : db block gets                                         1,469,623
    Statistic : redo entries                                            502,507
    Statistic : redo size                                           117,922,016
    Statistic : undo change vector size                              41,000,368
    Statistic : table scan blocks gotten                                 51,954
    Statistic : table scan rows gotten                               10,075,245Hemant K Chitale

  • How to Use Transient View Objects to Store Session-level Global Variables

    hi
    Please consider section "40.8.5 How to Use Transient View Objects to Store Session-level Global Variables"
    at http://download.oracle.com/docs/cd/E14571_01/web.1111/b31974/bcstatemgmt.htm#ADFFD19610
    Based on this documentation I created the example application
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.01.zip
    It behaves as show in the screencast at http://screencast.com/t/qDvSQCgpvYdd
    Its Application Module has a Transient View Object instance "MyEmployeesContextVOVI", as master for the child View Object instance "EmpInCtxJobVI".
    On rollback the Transient View Object instance keeps its row and attribute values.
    Also when passivation and activation is forced (using jbo.ampool.doampooling=false ) the Transient View Object instance seems to keep its row and attribute values.
    questions:
    - (q1) Why does the expression #{bindings.MyEmployeesContextVOVIIterator.dataControl.transactionDirty} evaluate as true when a Transient View Object instance attribute value is changed (as shown in screencast at http://screencast.com/t/qDvSQCgpvYdd )?
    - (q2) What would be a robust approach to make a Transient View Object instance more self-contained, and manage itself to have only one single row (per instance) at all times (and as such removing the dependency on the Application Module prepareSession() as documented in "5. Create an empty row in the view object when a new user begins using the application module.")?
    many thanks
    Jan Vervecken

    Thanks for your reply Frank.
    q1) Does sample 90 help ? http://blogs.oracle.com/smuenchadf/examples/
    Yes, the sample from Steve Muench does help, "90. Avoiding Dirtying the ADF Model Transaction When Transient Attributes are Set [10.1.3] "
    at http://blogs.oracle.com/smuenchadf/examples/#90
    It does point out a difference in marking transactions dirty by different layers of the framework, "... When any attribute's value is changed through an ADFM binding, the ADFM-layer transaction is marked as dirty. ...".
    This can be illustrate with a small change in the example application
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.02.zip
    It now shows the result of both these expressions on the page ...
    #{bindings.MyEmployeesContextVOVIIterator.dataControl.transactionDirty}
    #{bindings.MyEmployeesContextVOVIIterator.dataControl.dataProvider.transaction.dirty}... where one can be true and the other false respectively.
    See also the screencast at http://screencast.com/t/k8vgNqdKgD
    Similar to the sample from Steve Muench, another modification to the example application introduces MyCustomADFBCDataControl
    at http://www.consideringred.com/files/oracle/2010/ProgrammaticalViewObjectAndRollbackApp-v0.03.zip
    public class MyCustomADFBCDataControl
      extends JUApplication
      @Override
      public void setTransactionModified()
        ApplicationModule vApplicationModule = (ApplicationModule)getDataProvider();
        Transaction vTransaction = vApplicationModule.getTransaction();
        if (vTransaction.isDirty())
          super.setTransactionModified();
    }Resulting in what seems to be more consistent/expected transaction (dirty) information,
    see also the screencast at http://screencast.com/t/756yCs1L1
    Any feedback on why the ADF Model layer is so eager to mark a transaction dirty is always welcome.
    Currently, question (q2) remains.
    regards
    Jan

  • Changing database character set

    Can anyone help with the way to change the database character set.
    I am runn into problem while exporting with error message exp-00091
    Thanks

    You don't need to change the database character set. You have only to set the correct character set at
    OS level before doing the export. Execute the following at Sql prompt as DBA :
    SQL> select * from v$nls_parameters
      2* where parameter in ('NLS_LANGUAGE', 'NLS_TERRITORY', 'NLS_CHARACTERSET')
    SQL> /
    PARAMETER            VALUE
    NLS_LANGUAGE         AMERICAN
    NLS_TERRITORY        AMERICA
    NLS_CHARACTERSET     WE8ISO8859P15
    SQL>then at OS prompt :
    $ export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
    $ exp ..............
    Of course you have to use your values.

  • Getting ORA-01429 error while changing character set

    When I am changing character set from WE8DEC to AL32UTF8, I am getting ORA-01429 error
    SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8 ;
    ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8
    ERROR at line 1:
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01429: Index-Organized Table: no data segment to store overflow row-pieces

    Chockalingam wrote:
    I am using above steps as per oracle doc only.
    http://docs.oracle.com/cd/B10500_01/server.920/a96529/ch10.htm
    No, you are not.
    - You are not using the correct version doc vs. Oracle server version. Try to find the same suggestion in the relevant doc.
    - The doc you reference specifically says "... it can be used only under special circumstances. The ALTER DATABASE CHARACTER SET statement does not perform any data conversion, so it can be used +if and only if the new character set is a strict superset of the current character set+." (emphasis is mine)
    You do not have a strict superset.
    - Also the special clauses you have used are not documented - for a reason.
    Please edit your posts above to remove the ill-advice (steps with internal use only clauses) that does not belong on a forum.
    Edited by: orafad on Mar 16, 2012 9:47 PM

  • Matching across multiple character sets

    Would like to know whether anyone has attempted matching across multiple character sets, for example, between English and Japanese: what are the pitfalls to avoid, what are the best practices, and what you would like to see from application/tools perspective as an ideal solution. thanks

    If you upgrade to Logic Pro, you'll get WaveBurner as part of the package which helps you do this, including tweaking your pauses between tracks, fades etc.
    If you have Toast, you can do it there too.
    If you don't have any 3rd. party software, the work around would be to assemble all your songs in order, end to end in a new Logic file, and listen to all your tracks and adjust the relative levels between songs, then bounce out the individual tracks which have volume changes with their new volume settings. Finally you could then use any burning app such as [SimplyBurns|http://bit.ly/c1oglP] to create CDs or bounce them out in Logic with the additional .mp3 option.
    Obviously it's important to listen to your material in order, in context, as some songs will be at the wrong subjective level depending on the tracks either side in the placement. This isn't really important in digital distribution where your material probably won't be listened to as a whole, but as individual downloads.

  • Character Sets - socketchannel read error

    I have made an FTPserver which i have just noticed is having trouble when the file name being requested/send has non-ASCII characters in it such as '�'.
    Since i am using nio i thought it would just be an simple task of just changing the character set from "US-ASCII" to "UTF-8" or "UTF-16".
    but when i changed it to UTF-8 there was no change, that is i still recieve an error:
    java.nio.charset.MalformedInputException: Input length = 1
    java.nio.charset.CoderResult.throwException(CoderResult.java:260)
    java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:763)
    Worker.readCommand(Worker.java:282)
    Worker.handleClient(Worker.java:562)
    Worker.run(Worker.java:144)
    java.lang.Thread.run(Thread.java:536)
    And when i tried UTF-16 no input was ever detected by my server...
    This 'input length = 1' business... does this mean that there must be more than one byte in the recieved byte array or am i going off on a incorrect tangent?
    Any suggestions or theories would be listened to!
    Cheers
    (btw i will not be able to reply to this post for another 11 hrs)

    I can but it will not be of much use as it is more a logical error or a misunderstanding of how to use the character set.
    well here is the relevant code anyway:
    // readCommand: waits until a command is recieved from the client and then returns the command
           String readCommand(InputStream is, PrintStream ps) throws java.io.IOException
             int nread = 0, r = 0;
             String str="";
             Charset charset = Charset.forName("UTF-8");
             CharsetDecoder decoder = charset.newDecoder();
          // Direct byte buffer for reading
             ByteBuffer dbuf = ByteBuffer.allocateDirect(1024);
    //      outerloop:
             do
                dbuf.clear();
                boolean quit=false;
                String message="";
                int bytesRead=0;
    // while there is no input in the buffer            
                while (dbuf.position()==0)
    // read in any bytes that are waiting into the buffer
                   sc.configureBlocking(false);
                   bytesRead=sc.read(dbuf);
                   sc.configureBlocking(true);
    // wait for two milliseconds before trying to read again
                   try
                      wait(2);
                       catch (InterruptedException e)
    // if the client has not yet finished the connection negoiation see if the client has been connected for more than 30 seconds, if so disconnect the client
                   if (account==-1)
                      if (System.currentTimeMillis()>clientStartTime+30000)
                         quit=true;
                   else
    // if the thread has been told to quit the connection set the quit flag
                      if (exitThread)
                           message="421 Quitting...";
                           quit=true;
    // If there is a sessionlimit see if the connection has exceeded the limit, if so set the quit flag
                      if (staticSessionLimit[account]>0)
                         if (System.currentTimeMillis()>clientStartTime+staticSessionLimit[account])
                            message="421 Session Limit Exceeded... please re-connect in 30 seconds";
                            quit=true;
    // if there is an inactivity timout see if the client has not been active for more than the timeout, if so set the quit flag
                      if (staticInactivityTimeout[account]>0)
                         if (System.currentTimeMillis()>lastActiveTime+staticInactivityTimeout[account])
                            message="421 Inactivity Timeout Exceeded... closing connection";
                            quit=true;
    // if the quit flag is set return "QUIT" which tells the thread to close the connection and return to the pool
                   if (quit)
                      ps.print(message);
                      ps.write(EOL);
                      ps.flush();
                      return "QUIT";
                dbuf.flip();
                   CharBuffer cb=null;
    // if there are bytes in the buffer, add the data to the recieved command string (str)
                   if (bytesRead>=0)
                        cb = decoder.decode(dbuf);
                          str=str+cb.toString();
    // repeat while EOL is not detected
             } while (str.length()<2 || !str.substring(str.length()-2).equals("\r\n"));
             str=str.substring(0,str.length()-2);
             FTPServer.log("STRING: "+str);
             lastActiveTime=System.currentTimeMillis();
    // update the last action requested by the client in the governor
             governor.addAction(str,this);
             return str;
          }

Maybe you are looking for