ORA-12712 Characterset UTF8

Hi
I´m trying to change my character set to UTF8 but i dont know what characterset do i have?
I run the follow syntax and only i'm more confused:
SQL> show parameter nls_language;
NAME TYPE VALUE
nls_language string AMERICAN
SQL> select * from NLS_SESSION_PARAMETERS;
PARAMETER VALUE
NLS_LANGUAGE SPANISH
NLS_TERRITORY SPAIN
NLS_CURRENCY
NLS_ISO_CURRENCY SPAIN
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD/MM/RR
NLS_DATE_LANGUAGE SPANISH
NLS_SORT SPANISH
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF
PARAMETER VALUE
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 filas seleccionadas.
SQL> select * from nls_database_parameters where parameter='NLS_NCHAR_CHARACTERSET';
PARAMETER VALUE
NLS_NCHAR_CHARACTERSET AL16UTF16
I remember when i installed my database, the character set was WE8MSWIN1252
I read that the NLS_LANG is composed by <language>_<territory>. <characterset>
But with the querys i can't understad if i have in my NLS LANGUAGE is spanish or american or what character set i have WE8MSWIN1252 or AL16UTF16
If i try to run
ALTER DATABASE CHARACTER SET UTF8 (or any other)
and i have the follow message error.
ORA-12712 new character set must be a superset of old character set
then i´m a little confused. I'm reading the information but i don't understand it.
Someone can tell me why my querys tell different things.
Thanks to all
Alex

what is the difference between...sesion , instance and database parameters? for NLS_LANG.Session settings can generally override instance setting that can generally override database settings.
Note also that NLS_LANG has 3 parts:
- territory
- language
- character set.
Territory and language can be redefined in the client side using ALTER SESSION in your session but character set cannot be redefined using ALTER SESSION. You must redefine it at OS level with the environment variable (or registy setting under Windows).
See the reference document the Globalization Guide http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch3.htm#49632

Similar Messages

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

ORA-12712: new character set must be a superset of old character ...-

Dear all ,
i have a problem with oracle database,
server configuration oracle 10g, solaris 9, sparc processor 64 bit,
i altered database character set to UTF8, whe i return database to old seeting ISO 8859-6
i got this error ORA-12712: new character set must be a superset of old character set.
anyone can help me and let me know how can i solve this error?
thanks
Gasir

You should recreate a new database and use export/import to transfer data from the existing UTF8 database to the new ISO 8859-6 database according to the ]Globalization Guide.

ORA:12712

hi...
my DB having WE8ISO8859P1 character set but I need to modify AL32UTF8
ALTER DATABASE CHARACTER SET UTF8;
If I modify that it gives the fallowing error
ORA-12712: new character set must be a superset of old character set
please give solution ........
Thanks,

1. backup your database
2. use exp to export your source database, character should be set as WEB8ISO8859P1
3. use imp to import into your target database, character should be set as UTF8 or AL32UTF8
4. use tool : csscan to check if there are characters which can not convert successfully.
Guide for csscan:
1. use sys to create a user account for csscan
sqlplus "/ as sysdba"
SQL>@?/rdbms/admin/csminst.sql
2.in dos command, you can execuse like this:
csscan FULL=Y FROMCHAR=WEB8ISO8859P1 TOCHAR=UTF8 LOG=WEB8check.log CAPTURE=Y ARRAY=1000000 PROCESS=2
3.you can check your WEB8check.log, if it can not convert, delete that row and insert again.
Good luck
Bruce

Convert characterset WE8MSWIN1252 to UTF8

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

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

Changing the Database characterset

Hi,
My oracle 9i database characterset is AL32UTF8.
I wanted to change this to UTF8 for some testing purpose...
After few days i need to reset this characterset back to AL32UTF8.
how should i proceed on this?
Plz adivice.....
Regards,
Ashok Kumar.G

Thanks Pierre Forstmann,
In metalink i found out the following
In 9i you can't simply use "ALTER DATABASE CHARACTERSET" to go from
AL32UTF8 to UTF8 because UTF8 is a SUB-set of AL32UTF8
(some codepoints which are correct in AL32UTF8 are not known in UTF8)
So you will run into ORA-12712 if you try alter database ....
I hope this makes sense when the database contains data.
suppose if i drop my schema(now the database has no user data) and try to change the database characterset from AL32UTF8 to UTF8 will it impact any other?
and after changing to UTF8 can i import the user data again (say from export file which was taken from a UTF8 database) ?
Regards,
Ashok Kumar.G

Error while running package ORA-06553: PLS-553 character set name is not re

Hi all.
I have a problem with a package, when I run it returns me code error:
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
The full context of the problem is this:
Previously I had a developing data base, then was migrated to a new server. After that I started to receive the error, so I began to check for the solution.
My first move was compare the “old database” with the “new database”, so I check the nls parameters, and this was the result:
select * from nls_database_parameters;
Result from the old
NLS_LANGUAGE     AMERICAN
NLS_TERRITORY     AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CHARACTERSET     US7ASCII
NLS_CALENDAR     GREGORIAN
NLS_DATE_FORMAT     DD-MON-RR
NLS_DATE_LANGUAGE     AMERICAN
NLS_SORT     BINARY
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY     $
NLS_COMP     BINARY
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_RDBMS_VERSION     10.2.0.1.0
Result from the new
NLS_LANGUAGE     AMERICAN
NLS_TERRITORY     AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CHARACTERSET     US7ASCII
NLS_CALENDAR     GREGORIAN
NLS_DATE_FORMAT     DD-MON-RR
NLS_DATE_LANGUAGE     AMERICAN
NLS_SORT     BINARY
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY     $
NLS_COMP     BINARY
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_RDBMS_VERSION     10.2.0.1.0
As the result was identical, I decided to look for more info in the log file of the new database. What I find was this:
Database Characterset is US7ASCII
Threshold validation cannot be done before catproc is loaded.
Threshold validation cannot be done before catproc is loaded.
alter database character set INTERNAL_CONVERT WE8MSWIN1252
Updating character set in controlfile to WE8MSWIN1252
Synchronizing connection with database character set information
Refreshing type attributes with new character set information
Completed: alter database character set INTERNAL_CONVERT WE8MSWIN1252
alter database character set US7ASCII
ORA-12712 signalled during: alter database character set US7ASCII...
alter database character set US7ASCII
ORA-12712 signalled during: alter database character set US7ASCII...
Errors in file e:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_3132.trc:
Regards

Ohselotl wrote:
Hi all.
I have a problem with a package, when I run it returns me code error:
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
The full context of the problem is this:
Previously I had a developing data base, then was migrated to a new server. After that I started to receive the error, so I began to check for the solution.
My first move was compare the “old database” with the “new database”, so I check the nls parameters, and this was the result:
select * from nls_database_parameters;
Result from the old
NLS_LANGUAGE     AMERICAN
NLS_TERRITORY     AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CHARACTERSET     US7ASCII
NLS_CALENDAR     GREGORIAN
NLS_DATE_FORMAT     DD-MON-RR
NLS_DATE_LANGUAGE     AMERICAN
NLS_SORT     BINARY
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY     $
NLS_COMP     BINARY
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_RDBMS_VERSION     10.2.0.1.0
Result from the new
NLS_LANGUAGE     AMERICAN
NLS_TERRITORY     AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CHARACTERSET     US7ASCII
NLS_CALENDAR     GREGORIAN
NLS_DATE_FORMAT     DD-MON-RR
NLS_DATE_LANGUAGE     AMERICAN
NLS_SORT     BINARY
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY     $
NLS_COMP     BINARY
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CONV_EXCP     FALSE
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_RDBMS_VERSION     10.2.0.1.0
As the result was identical, I decided to look for more info in the log file of the new database. What I find was this:
Database Characterset is US7ASCII
Threshold validation cannot be done before catproc is loaded.
Threshold validation cannot be done before catproc is loaded.
alter database character set INTERNAL_CONVERT WE8MSWIN1252
Updating character set in controlfile to WE8MSWIN1252
Synchronizing connection with database character set information
Refreshing type attributes with new character set information
Completed: alter database character set INTERNAL_CONVERT WE8MSWIN1252
*********************************************************************This is an unsupported method to change the characterset of a database - it has caused the corruption of your database beyond repair. Hopefully you have a backup you can recover from. Whoever did this did not know what they were doing.
alter database character set US7ASCII
ORA-12712 signalled during: alter database character set US7ASCII...
alter database character set US7ASCII
ORA-12712 signalled during: alter database character set US7ASCII...
Errors in file e:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_3132.trc:
RegardsThe correct way to change the characterset of a database is documented - http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#sthref1476
HTH
Srini

Converting server from Big5 to UTF8.

I try to convert oracle 8i server from big5 to UTF8 by using "alter database character set utf8". But it tells me "ORA-12712: new character set must be a superset of old character set. Is there any way to enforce this conversion? I understand there will be data conversion problem that I don't care.
Rick Lin
null

Why would you want to do this ? In UTF8 all your 2 byte chinese BIG5 characters will be increased to 3 bytes in length. Basically each character needs to be converted when you migrate your database to UTF8, since their current binary representations are not longer valid.
The ALTER DATABASE CHARACTER SET doesn't perform any character conversion ,if your operation proceed without the error, then all you chinese data will be lost !

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.

External table: How to load data from a fixed format UTF8 external file

Hi Experts,
I am trying to read data from a fixed format UTF8 external file in to a external table. The file has non-ascii characters, and the presence of the non-ascii characters causes the data to be positioned incorrectly in the external table.
The following is the content's of the file:
20100423094529000000I1 ABÄCDE 1 000004
20100423094529000000I2 OMS Crew 2 2 000004
20100423094529000000I3 OMS Crew 3 3 000004
20100423094529000000I4 OMS Crew 4 4 000004
20100423094529000000I5 OMS Crew 5 5 000004
20100423094529000000I6 OMS Crew 6 6 000004
20100423094529000000I7 Mobile Crew 7 7 000004
20100423094529000000I8 Mobile Crew 8 8 000004
The structure of the data is as follows:
Name Type Start End Length
UPDATE_DTTM CHAR 1 20 20
CHANGE_TYPE_CD CHAR 21 21 1
CREW_CD CHAR 22 37 16
CREW_DESCR CHAR 38 97 60
CREW_ID CHAR 98 113 16
UDF1_CD CHAR 114 143 30
UDF1_DESCR CHAR 144 203 60
UDF2_CD CHAR 204 233 30
DATA_SOURCE_IND CHAR 294 299 6
UDF2_DESCR CHAR 234 293 60
I create the external table as follows:
CREATE TABLE "D_CREW_EXT"
"UPDATE_DTTM" CHAR(20 BYTE),
"CHANGE_TYPE_CD" CHAR(1 BYTE),
"CREW_CD" CHAR(16 BYTE),
"CREW_DESCR" CHAR(60 BYTE),
"CREW_ID" CHAR(16 BYTE),
"UDF1_CD" CHAR(30 BYTE),
"UDF1_DESCR" CHAR(60 BYTE),
"UDF2_CD" CHAR(30 BYTE),
"DATA_SOURCE_IND" CHAR(6 BYTE),
"UDF2_DESCR" CHAR(60 BYTE)
ORGANIZATION EXTERNAL
TYPE ORACLE_LOADER DEFAULT DIRECTORY "TMP"
ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE
CHARACTERSET UTF8
STRING SIZES ARE IN BYTES
NOBADFILE NODISCARDFILE NOLOGFILE FIELDS NOTRIM
( "UPDATE_DTTM" POSITION (1:20) CHAR(20),
"CHANGE_TYPE_CD" POSITION (21:21) CHAR(1),
"CREW_CD" POSITION (22:37) CHAR(16),
"CREW_DESCR" POSITION (38:97) CHAR(60),
"CREW_ID" POSITION (98:113) CHAR(16),
"UDF1_CD" POSITION (114:143) CHAR(30),
"UDF1_DESCR" POSITION (144:203) CHAR(60),
"UDF2_CD" POSITION (204:233) CHAR(30),
"DATA_SOURCE_IND" POSITION (294:299) CHAR(6),
"UDF2_DESCR" POSITION (234:293) CHAR(60) )
) LOCATION ( 'D_CREW_EXT.DAT' )
REJECT LIMIT UNLIMITED;
Check the result in database:
select * from D_CREW_EXT;
I found the first row is incorrect. For each non-ascii character,the fields to the right of the non-ascii character are off by 1 character,meaning that the data is moved 1 character to the right.
Then I tried to use the option STRING SIZES ARE IN CHARACTERS instead of STRING SIZES ARE IN BYTES, it doesn't work either.
The database version is 11.1.0.6.
Edited by: yuan on May 21, 2010 2:43 AM

Hi,
I changed the BYTE in the create table part to CHAR, it still doesn't work. The result is the same. I think the problem is in ACCESS PARAMETERS.
Any other suggestion?

Multibyte character error in SqlLoader when utf8 file with chars like €Ää

hello,
posting from Germany, special charactes like german umlaute and euro sign in UTF8 Textfile, SqlLoader rejecting row with Multibyte character error
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
Database Characterset: WE8MSWIN1252
OS: SLES 11 x86_64
Testcase SqlDeveloper:
CREATE TABLE utf8file_to_we8mswin1252 (
ID NUMBER,
text VARCHAR2(40 CHAR)
can't enter euro symbol in this posting, end's in '€' (?)
SELECT ascii(euro symbol) FROM dual;
128
SELECT chr(128) from dual;
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (1, '0987654321098765432109876543210987654321');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (2, 'äüöäüöäüöäÄÖÜÄÖÜÄÖÜÄßßßßßßßßßß€€€€€€€€€€');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (3, 'äüöäüöäüöäÄÖÜÄÖÜÄÖÜÄäüöäüöäüöäÄÖÜÄÖÜÄÖÜÄ');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (4, '€ß€ß€ß€ß€ß€ß€ß€ß€ß€ß1');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (5, 'äüöäüöäüöäÄÖÜÄÖÜÄÖÜÄäüöäüöäüöä');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (6, 'ßßßßßßßßßß€€€€€€€€€€1');
INSERT INTO utf8file_to_we8mswin1252 (ID, text) VALUES (7, 'ßßßßßßßßßß€€€€€€€€€€äüöäüöäüöäÄÖÜÄÖÜÄÖÜÄ');
commit;
Select shows correct result, no character is wrong or missing!!!!
put this in a UTF8 file without delimiter and enclosure like
10987654321098765432109876543210987654321
the SqlLoader controlfile:
LOAD DATA characterset UTF8
TRUNCATE
INTO TABLE utf8file_to_we8mswin1252
ID CHAR(1)
, TEXT CHAR(40)
on a linux client machine, NOT the Oracle-Server
export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
sqlldr user/pwd@connectstring CONTROL=TEST01.ctl DATA=TEST01.dat LOG=TEST01.log
Record 6: Rejected - Error on table UTF8FILE_TO_WE8MSWIN1252, column TEXT.
Multibyte character error.
Record 7: Rejected - Error on table UTF8FILE_TO_WE8MSWIN1252, column TEXT.
Multibyte character error.
Select shows missing characters in row 4 and 5, SqlLoader loads only the first 20 characters (maybe at random)
and as shown above, row 6 and 7 never loaded
Problem:
can't load UTF8 Flatfiles with SqlLoader when german umlaute and special characters like euro symbol included.
Any hint or help would be appreciated
Regards
Michael

## put this in a UTF8 file without delimiter and enclosure like
The basic question is how you put the characters into the file. Most probably, you produced a WE8MSWIN1252 file and not an UTF8 file. To confirm, a look at the binary codes in the file would be necessary. Use a hex-mode-capable editor. If the file is WE8MSWIN1252, and not UTF8, then the SQL*Loader control file should be:
LOAD DATA characterset WE8MSWIN1252
TRUNCATE
INTO TABLE utf8file_to_we8mswin1252
ID CHAR(1)
, TEXT CHAR(40)
)-- Sergiusz

{SOL}Problem in Export/Import a simple table between two diff. characterset

Hi ,
I have created a simple table on SCOTT schema....
SQL> CREATE TABLE TEST(A NUMBER(1) , B VARCHAR2(10));
Table created
SQL> INSERT INTO TEST VALUES(1 , 'TEST_TEST');
1 row inserted
SQL> COMMIT;
Commit complete
SQL> INSERT INTO TEST VALUES(2 , 'ΤΕΣΤ_ΤΕΣΤ');     <------------greek chars
1 row inserted
SQL> COMMIT;
Commit complete
The nls_parameters:
SQL> SELECT * FROM NLS_INSTANCE_PARAMETERS;
PARAMETER                      VALUE
NLS_LANGUAGE                   GREEK
NLS_TERRITORY                  GREECE
NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT
NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT
NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT
NLS_DUAL_CURRENCY
NLS_COMP
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
17 rows selected
SQL> SELECT * FROM NLS_SESSION_PARAMETERS;
PARAMETER                      VALUE
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
17 rows selected
and db characterset is EL8MSWIN1253
I export such as(following generally the instuctions found on Note:227332.1-Metalink):
C:\Documents and Settings\s_k>SET ORACLE_SID=EPESY
C:\Documents and Settings\s_k>SET NLS_LANG=GREEK_GREECE.EL8MSWIN1253
C:\Documents and Settings\s_k>C:\oracle\product\10.2.0\database10g\BIN\exp SYSTE
M/passwd@EPESY FILE=C:\TEST.DMP TABLES=(SCOTT.TEST) ROWS=Y LOG=C:\TEST2.TXT
Export: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:28:58 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
╕ήώΊί ≤²Ίϊί≤ύ ≤ί: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Pr
oduction
With the Partitioning, OLAP and Data Mining options
╟ ίΌάή∙ή▐ ▌ήώΊί ≤ΪΎ ≤ίΪ ≈ά±άΆΪ▐±∙Ί EL8MSWIN1253 Άάώ ≤ΪΎ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR AL1
6UTF16
╨±ΎίΪΎώΉά≤▀ά ήώά ίΌάή∙ή▐ Ϊ∙Ί Ώ±Ύ≤ϊώΎ±ώ≤Ή▌Ί∙Ί ΏώΊ▄Ά∙Ί Ή▌≤∙ ╙ΫΉέάΪώΆ▐≥ ─ώάϊ±ΎΉ▐≥ .
╧ Ϊ±▌≈∙Ί ≈±▐≤Ϊύ≥ ▄ΈΈάΌί ≤ί SCOTT
. . ίΌάή∙ή▐ ΪΎΫ Ώ▀ΊάΆά                           TEST          2 ή±άΉΉ▌≥ ίΌ▐≈ϋύ≤
άΊ
╟ ίΌάή∙ή▐ ΪίΈί▀∙≤ί ίΏώΪΫ≈■≥ ≈∙±▀≥ Ώ±ΎίώϊΎΏΎ▀ύ≤ύ.Then , i shutdown this database and i start the other.....
with this nls_parameters
SQL> select * from nls_session_parameters;
PARAMETER                                                                        VALUE
NLS_LANGUAGE                                                                     AMERICAN
NLS_TERRITORY                                                                    AMERICA
NLS_CURRENCY                                                                     $
NLS_ISO_CURRENCY                                                                 AMERICA
NLS_NUMERIC_CHARACTERS                                                           .,
NLS_CALENDAR                                                                     GREGORIAN
NLS_DATE_FORMAT                                                                  DD-MON-RR
NLS_DATE_LANGUAGE                                                                AMERICAN
NLS_SORT                                                                         BINARY
NLS_TIME_FORMAT                                                                  HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT                                                             DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT                                                               HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT                                                          DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY                                                                $
NLS_COMP                                                                         BINARY
NLS_LENGTH_SEMANTICS                                                             CHAR
NLS_NCHAR_CONV_EXCP                                                              FALSE
17 rows selected
SQL>
SQL> select * from nls_instance_parameters;
PARAMETER                                                                        VALUE
NLS_LANGUAGE                                                                     GREEK
NLS_TERRITORY                                                                    GREECE
NLS_SORT
NLS_DATE_LANGUAGE
NLS_DATE_FORMAT
NLS_CURRENCY
NLS_NUMERIC_CHARACTERS
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT
NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT
NLS_DUAL_CURRENCY
NLS_COMP
NLS_LENGTH_SEMANTICS                                                             CHAR
NLS_NCHAR_CONV_EXCP                                                              FALSE
17 rows selected
with this db characterset: UTF8
C:\Documents and Settings\s_k>SET NLS_LANG=GREEK_GREECE.EL8MSWIN1253
C:\Documents and Settings\s_k>C:\oracle\product\10.2.0\database10g\BIN\imp syste
m/passwd@info FROMUSER=SCOTT TOUSER=SCOTT FILE=C:\TEST.DMP LOG=C:\TEST0_IMP.TXT
Import: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:40:16 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
╕ήώΊί ≤²Ίϊί≤ύ ≤ί: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Pr
oduction
With the Partitioning, OLAP and Data Mining options
┴±≈ί▀Ύ ίΌάή∙ή▐≥ ϊύΉώΎΫ±ή▐ϋύΆί άΏⁿ EXPORT:V10.02.01 Ή▌≤∙ ≤ΫΉέάΪώΆ▐≥ ϊώάϊ±ΎΉ▐≥
ίώ≤άή∙ή▐ ▌ήώΊί ≤ί ≤ίΪ ≈ά±άΆΪ▐±∙Ί EL8MSWIN1253 Άάώ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR UTF8
server ίώ≤άή∙ή▐≥ ≈±ύ≤ώΉΎΏΎώί▀ ≤ίΪ ≈ά±άΆΪ▐±∙Ί UTF8 (ϊΫΊάΪ▐ ΉίΪάΪ±ΎΏ▐ ≤ίΪ ≈ά±άΆΪ▐±
∙Ί)
server ίΌάή∙ή▐≥ ≈±ύ≤ώΉΎΏΎώί▀ ≤ίΪ ≈ά±άΆΪ▐±∙Ί NCHAR AL16UTF16 (ϊΫΊάΪ▐ ΉίΪάΪ±ΎΏ▐ ≤ί
Ϊ ≈ά±άΆΪ▐±∙Ί nchar)
. ίώ≤άή∙ή▐ Ϊ∙Ί άΊΪώΆίώΉ▌Ί∙Ί ΪΎΫ SCOTT ≤ΪΎ SCOTT
. . ίώ≤άή∙ή▐ ΪΎΫ Ώ▀ΊάΆά                         "TEST"          2 ή±άΉΉ▌≥ ίώ≤▐≈ϋ
ύ≤άΊ
╟ ίώ≤άή∙ή▐ ΪίΈί▀∙≤ί ίΏώΪΫ≈■≥ ≈∙±▀≥ Ώ±ΎίώϊΎΏΎ▀ύ≤ύ.
C:\Documents and Settings\s_k>SQLPLUS SCOTT/TIGER
SQL*Plus: Release 10.2.0.1.0 - Production on ╩Ϋ± ╔ΎΫΊ 22 12:41:20 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
╙²Ίϊί≤ύ ≤ί:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SELECT * FROM TEST;
         A B
         1 TEST_TEST
         2 ????_????What may be the cause.....????
Note: I use db 10g v.2 on Windows XP platform.. and the two db instances reside on the same machine....
Thanks...
Sim

"Generally speaking the value of the NLS_LANG registry key or environment variable needs to be equal to the characterset of the database."
Yes...that's why i have set the NLS_LANG env.variable to GREEK_GREECE.EL8MSWIN1253 ..equal to:
SQL> select * from nls_database_parameters;
PARAMETER                      VALUE
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET EL8MSWIN1253
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.1.0"nls_language doesn't come into play, nor nls_instance_parameters."
Yes...it's true.
"So, in the dump you posted, no one can tell whether those characters were INSERTed correctly at all. Your NLS_LANG *registry key* may have been set to an incorrect value (it defaults to American_America.MSWIN1252)."
Actually , i have used a third-party tool PL/SQL Developer (which does have the OracleDB10g as default home).
Looking at the Windows registry of OracleDB10g the NLS_LANG is equal to GREEK_GREECE.EL8MSWIN1253.
"Thirdly, as I implied above the NLS_LANG on import should have been American_America.UTF8."
According to the Note 227332.1 , if the db characterset of the two dbs are not the same.. then it is preferable the conversion should be done on the import process and not the export....
So, in an example described there -export from a AMERICAN_AMERICA.WE8MSWIN1252 db and import on UTF8 db - (seems exactly the same as mine) the import is done as such:
c:\>set NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252
       c:\>imp ....
The conversion to UTF8 is done while inserting the data
       in the UTF8 database.Additional notes....
I have used many different patterns doing the import......
1) Use of AMERICAN_AMERICA.UTF8
2) Use of GREEK_GREECE.EL8ISO8859P7
3) Use the appropriate NLS_LANG that corresponds to the display of chcp command....
All tries display some '?' chars.....
Anyway... I 'll continue reading ... and testing
Thanks... a lot for your points
Sim

SQL Developer, UTF8 Oracle DB, extended ascii characters appear as blocks

I have this value stored on the database:
(Gestion Económica o Facturaci
Notice the second word has an extended ascii character in it. When I use SQL Developer on my windows machine to view the data, I get a box in place of the o, kinda like this:
(Gestion Econ�mica o Facturaci
If I log on to the AIX server where the oracle database in question is and run sqlplus from there, I see things properly. I also managed to regedit oracle home to get sql plus on my windows machine to display this properly. I still cannot get sql developer to work though...
Details about sql developer:
font: arial Unicode MS
environment encoding: UTF-8
NLS Lang: American
NLS Territory: America
windows regional options:
English (United States)
Location: United States
Database NLS settings:
NLS_LANGUAGE     AMERICAN
NLS_TERRITORY     AMERICA
NLS_CURRENCY     $
NLS_ISO_CURRENCY     AMERICA
NLS_NUMERIC_CHARACTERS     .,
NLS_CALENDAR     GREGORIAN
NLS_DATE_FORMAT     mm/dd/yyyy hh24:mi:ss
NLS_DATE_LANGUAGE     AMERICAN
NLS_CHARACTERSET     UTF8
NLS_SORT     BINARY
NLS_TIME_FORMAT     HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY     $
NLS_NCHAR_CHARACTERSET     AL16UTF16
NLS_COMP     BINARY
NLS_LENGTH_SEMANTICS     BYTE
NLS_NCHAR_CONV_EXCP     FALSE
Any ideas on how I can fix this. I'd rather NOT log onto the server to run queries.... thanks in advance for your thoughts!
Edited by: user10939448 on Jan 31, 2012 1:51 PM

user10939448 wrote:
This problem is quite strange in that when I've been able to manually set American_america.utf8, things work.Sorry to say, but it seems you may have an incorrect setup.
In general, you should set char set part of NLS_LANG to let Oracle know the code page used by the client. With win-1252, NLS_LANG should include .WE8MSWIN1252.
The display from sqlplus was "lying", due to incorrectly stored data coupled by incorrect nls_lang setting (char set part). The pass-through or gigo scenario can be dangerous this way. Search the Globalization forum for the term 'pass-through' for previous discussions on the theme.
The setting on AIX servers may be incorrect as well, but it depends how you use it (e.g. for database export or data load with utf-8 encoded files it may be correct).
The output of the query you recommended looks odd to me:
(Gestion Econ�mica o Facturaci     Typ=1 Len=30 CharacterSet=UTF8:
28,47,65,73,74,69,6f,6e,20,45,63,6f,6e,f3,6d,69,63,61,20,6f,20,46,61,63,74,75,72,61,63,69;This is the telling part. The 0xF3 is not legal in UTF8. Actually, the code units for ó, U+00F3 Latin small letter o with acute, are C3 B3. So instead of f3 you should have expected c3,b3 from the dump output.
>
So it looks like what's under the covers is correct, but I'm still not seeing the correct character in sql developer.The opposite is true. Data is incorrectly stored and SQL Developer is correctly showing you this. Sqlplus is not the best tool in Unicode environments, SQL Developer is better.
>
ACP according to my windows registry is 1252. OEMCP is 437Also, if you use database clients in console mode (such as sqlplus), NLS_LANG should include .US8PC437 to properly indicate that code page in use is 437.

How to retrive Original Character in Unicode Format from UTF8

Our Database is enabled UTF8 format.User entered some data through UI(html forms),which is stored as â?? (whose ascii values are 50082,49792,49817 respectively,as the data is displaying in different way here ,I am giving here with the ascii values)in to the Database.When we retrive the data into UI or into a text file(.txt) it is displaying/storing as ’(Ascii value is 15712189).How to check for is that character correct or not.

Ashok,
What is your NLS_LANG setting on the client machine where FORMS is running?
To see if the value is stored properly in the database you can use the DUMP command. You can find this in the SQL Reference. But here is a desription:
he syntax of the function call is:
DUMP( <value> [, <format> [, <offset> [, <length> ] ] ] )
where:
value - is the value to be displayed
format - is a number which describes the format in which bytes of the value are to be displayed: 8 - means octal, 10 - means decimal, 16 - means hexadecimal; other values between 0 and 16 mean decimal; values greater then 16 are a little confusing and mean: print bytes as ASCII characters if they correspond to printable ASCII codes, print them as "^x" if they correspond to ASCII control codes and print them in hexadecimal otherwise; adding 1000 to the format number will add character set information for the character data type values to the return value offset - is the offset of the first byte of the value to display; negative values mean counting from the end length - is the number of bytes to display. So for example,
SQL> SELECT DUMP(col,1016)FROM table ;
Typ=1 Len=39 CharacterSet=UTF8: 227,131,143,227,131,170
returns the value of a column consisting of 3 Japanese characters in UTF8 encoding . For example the 1st char is 227(*255)+131. You will probably need to convert this to UCS2 to verify the codepoint value with the Unicode Standard version 3.0.

RUSSIAN_RUSSIA.UTF8 language parameter is not working in windows registry

Hi All,
We are using oracle 9i.
We are storing some russian data in a database, the characterset we are using is UTF8. The NLS_LANG value we are using is RUSSIAN_CIS.CL8ISO8859P5.
Databse properties for the database is as under
NLS_LANGUAGE --> AMERICAN
NLS_TERRITORY --> AMERICA
NLS_CURRENCY --> $
NLS_ISO_CURRENCY --> AMERICA
NLS_NUMERIC_CHARACTERS --> .,
NLS_CHARACTERSET --> UTF8
NLS_CALENDAR -->GREGORIAN
NLS_DATE_FORMAT --> YYYY-MM-DD:HH24:MI:SS
NLS_DATE_LANGUAGE --> AMERICAN
NLS_SORT --> BINARY
NLS_TIME_FORMAT --> HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT --> DD-MON-RR HH.MI.SSXFFAM
NLS_TIME_TZ_FORMAT --> HH.MI.SSXFF AM TZR
NLS_COMP --> BINARY
NLS_LENGTH_SEMANTICS -->BYTE
NLS_NCHAR_CHARACTERSET --> AL16UTF16
we want to display the same russian data in SQL*PLUS (which we are using as a client). For that we tried the above mentioned NLS_LANG parameter and we also tried
NLS_LANG = RUSSIAN_CIS.CL8MSWIN1251. Both the NLS_LANG parameter is working fine.
Now i want to store some hindi data into the database, and same we want to display in SQL*PLUS. What i read is that by defining the characterset UTF8 it is possible
so i just tried RUSSIAN_RUSSIA.UTF8 as a NLS_LANG value, when i supply this value in windows registry(HKEY_LOCAL_MACHINE-->SOFTWARE-->ORACLE-->HOME0-->NLS_LANG) then it takes the value, but when i tried to connect the
database then oracle throws an error
INVALID VALUE SPECIFIED FOR NLS PARAMETER.
I also tried to store and view only hindi data in SQL*PLUS by changing the two registry values as HKEY_LOCAL_MACHINE-->SOFTWARE-->ORACLE-->HOME0-->NLS_LANG = HINDI_INDIA.IN8ISCII and SQLPLUS_FONT_CHARSET= HINDI. Then also i'm unable to view hindi data from tables.
Now what I want is that, to store and view hindi as well as russian data in a database and view the same in SQL*PLUS. Please help me out if thr is some solution for the same.
Thanks & Regards
Amit Pandey

On Windows this issue has some complications and pitfalls, you should read on metalink:
The correct NLS_LANG in a Windows Environment
Note:179133.1
Shortly, sqlplus is not a UNICODE client, you cannot use UTF8 as client characterset. I assume, currently you have an ANSI codepage, which supports cyrillic characters. When you now want to store and retrieve hindi characters, it's not sufficient to change the Oracle client characterset, you have to to change to the correct ANSI codepage, too.
Werner

ORA-12712 Characterset UTF8

Similar Messages

Maybe you are looking for