Characterset conversion from WE8ISO8859P1 to UTF8

Hi All,
While running CSSCAN utility from WE8ISO8859P1 to UTF8 after running 8-9H, the process is going to sleep state.
We need to complete this task in next 1week of time.Can any one share why this is happening.
Thanks,
Sekhar

There is a Metalink note on [Bug 6460895 - CSSCAN may hang / run slowly|https://metalink.oracle.com/CSP/ui/flash.html#tab=Home(page=Home&id=fm2z4pjj()),(page=KBNavigator&id=fm2z4vd6(&viewingMode=1141&userQuery=csscan%20sleep&searchControl=1146))] that looks to be vaguely related. This indicates that the bug was fixed in 10.2.0.4, but unfortunately the bug itself isn't published, so it is rather hard to know if this is your problem or not. It would probably be worth logging a support request to see if Oracle support can determine whether or not you're being affected by this bug.
Meanwhile, can you apply the 10.2.0.4 patchset and see if that solves the problem?
Justin

Similar Messages

Database Character Set Conversion from WE8ISO8859P1 to UTF8

Hi All
I want to migrate data from one database to another database But my original database character set is WE8ISO8859P1 but i want to migrate it to
database which has character set UTF8
because of character set it don't shows me Marathi data which is in original database .
it shows me some symbol for Marathi words ..
please help me out.
Thanking You
Gaurav Sontakke

Dear GauravSontakke,
Since your database version is unknown, i will show you an online documentation of character set migration for 10gR2.
http://www.oracle.com/pls/db102/search?remark=quick_search&word=character+set+migration&tab_id=&format=ranked
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#sthref1442
*http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#NLSPG011*Please read those carefully.
Hope it Helps,
Ogan

Convert 10.2.0.4 RDBMS from WE8ISO8859P1 to UTF8 without install new langua

We are in 11.5.10.2 Ebusiness suite with 10.2.0.4 RDBMS. thinking to take advantage a downtime to convert the darabase character set from WE8ISO8859P1 to UTF8 right now even we ONLY want to install and configure new language in year or two in the future. I have a lot of questions and hope someone can answer them
1) Is that ok to convert the database character set witout doing anything in the apps side? Not even change any setting in apps?
2) I know Oracle is recommned AL32UTF8 for E-business suite.. but for Rel 12 only. Am I have the right information?
3) I found someone post in one of the Forum in here .. that he use CSSCAN to scan the database but realized it only change the metadata not the user data..... I though CSSCAN is only for scanning to report potential data.. should not change anything in database? I wonder he mean CSaLTER instead.... but only metadata huh??
4) I also read some people use expdp/impdp to perform the character set conversion... but I also read that oracle recommend to use exp/import utility only. Is that right? What is the better method for character set conversion if both of them are valid path?
thanks Fushan

Hi
Apart from Srini inputs, here is my inputs.
*1) Is that ok to convert the database character set without doing anything in the apps side? Not even change any setting in apps?*
No issues to convert without adding new language in EBS.
*2) I know Oracle is recommend AL32UTF8 for E-business suite.. but for Rel 12 only. Am I have the right information?*
Please note that AL32UTF8 is not certified for Oracle E-Business Suite 11i.
Note.124721.1 Migrating an Applications Installation to a New Character Set:
This is documented in Note:222663.1
Note 179133.1 The correct NLS_LANG in a Windows Environment
Note 264157.1 The correct NLS_LANG on Unix Environments
*3) I found someone post in one of the Forum in here .. that he use CSSCAN to scan the database but realized it only change the metadata not the user data..... I though CSSCAN is only for scanning to report potential data.. should not change anything in database? I wonder he mean CSaLTER instead.... but only metadata huh??*
Please follow below blog, you will get clear picture
Changing the Database Character Set ( NLS_CHARACTERSET ) [ID 225912.1]
Note 276914.1 The National Character Set in Oracle 9i and 10g
Note 458122.1 Installing and Configuring Csscan in 8i and 9i (Database Character Set Scanner)
Note 745809.1 Installing and configuring Csscan in 10g and 11g (Database Character Set Scanner)
Note 444701.1 Csscan output explained
http://www.oracle-base.com/articles/10g/CharacterSetMigration.php
http://repettas.wordpress.com/2008/05/16/national-character-set-in-oracle-9i-and-10g/
http://avdeo.com/2010/11/01/converting-migerating-database-character-set/
*4) I also read some people use expdp/impdp to perform the character set conversion... but I also read that oracle recommend to use exp/import utility only. Is that right? What is the better method for character set conversion if both of them are valid path?*
yes.
Note 227332.1 NLS considerations in Import/Export - Frequently Asked Questions

Database Characterset Conversion from AMERICAN to JAPANESE

Hello
We are creating a test environment from a database with NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1. This needs to be converted into Japanese characterset with NLS_LANG = JAPANESE_JAPAN.JA16EUC
As per my understanding, I need to first export the database, then create a new database with Japanese NLS_LANG, and then re-import it
Could someone please confirm the steps please
1. Do I need to change NLS_LANG before exporting the database?
2. Can I run a database characterset conversion check before exporting db?
3. Is there any other pre-cautions that I need to take
Oracle Version: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
OS Version: HP-UX B.11.11
Regards
Sudhanshu

Hello,
I have used the Character Set Scan utility (csscan) Version 1.2. I have attached the report results below.
To convert the character set instead of export/import, can I simply do
ALTER DATABASE CHARACTER SET ja16euc;
I would appreciate feedback on this if anyone has worked on this conversion before.
Parameter Value
CSSCAN Version v1.2
Database Version 9.2.0.6.0
Scan type Full database
Scan CHAR data? YES
Database character set WE8ISO8859P1
FROMCHAR WE8ISO8859P1
TOCHAR JA16EUC
Scan NCHAR data? NO
Array fetch buffer size 10240
Number of processes 20
Capture convertible data? NO
[Scan Summary]
Some character type data in the data dictionary are not convertible to the new character set
Some character type application data are not convertible to the new character set
[Data Dictionary Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 3,303,684 386 0 8
CHAR 5 0 0 0
LONG 219,988 1 0 0
CLOB 0 58 0 0
Total 3,523,677 445 0 8
Total in percentage 100% 0% 0% 0%
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 3,316,273,097 8,517 56 2,675
CHAR 6,954 0 0 0
LONG 197,690 0 0 0
CLOB 0 0 0 0
Total 3,316,477,741 8,517 56 2,675
Total in percentage 100% 0% 0% 0%
Convertible Truncation Lossy
1 0 0
4 0 0
28 0 6
2,792 43 20
55 1 0
45 0 0
3 0 0
39 0 0
978 0 0
69 0 0
36 0 0
16 0 0
45 0 0
21 0 0
102 4 0
195 4 0
205 0 2
102 4 0
61 0 470
2 0 0
6 0 0
67 0 487
0 0 1
1 0 0
3 0 0
8 0 0
1 0 0
3,115 0 1,689
261 0 0
4 0 0
230 0 0
5 0 0
4 0 0
4 0 0
6 0 0
3 0 0
1 0 0
58 0 0
386 0 8
Convertible Truncation Lossy
1 0 0
4 0 0
28 0 6
2,792 43 20
55 1 0
45 0 0
3 0 0
20 0 0
11 0 0
2 0 0
4 0 0
2 0 0
978 0 0
69 0 0
16 0 0
10 0 0
4 0 0
4 0 0
2 0 0
10 0 0
4 0 0
2 0 0
45 0 0
21 0 0
4 0 0
4 0 0
0 4 0
59 0 0
27 0 0
8 0 0
4 0 0
93 0 0
4 0 0
0 4 0
59 0 0
27 0 0
8 0 0
102 0 1
58 0 1
35 0 0
10 0 0
4 0 0
4 0 0
0 4 0
59 0 0
27 0 0
8 0 0
61 0 470
2 0 0
6 0 0
67 0 487
0 0 1
1 0 0
3 0 0
8 0 0
1 0 0
3,115 0 1,689
261 0 0
4 0 0
73 0 0
115 0 0
37 0 0
5 0 0
2 0 0
3 0 0
4 0 0
4 0 0
6 0 0
2 0 0
1 0 0
1 0 0
58 0 0
386 0 8
---------------- ---------------- ----------------

Characterset change from WE8ISO8859P1 to AL32UTF8

Hi,
I have restore the rman on new server oracle 11.2.0.3 (Previous backup was of oracle 10.2.0.4).
Then I have successfully upgrade the database to oracle 11g but issue which I am facing right now is that the old database have the character set WE8ISO8859P1 which is now upgraded to oracle 11.2.0.3 database server.
My required character set is AL32UTF32.
Now is there any way that while restoring the rman backup of oracle 10.2.0.4 on new server I set the character set to AL32UTF32.
Thank you for your cooperation.
Kind Regards,
Adnan Hamdussalam

It means that either I have to change it before backup or after perform the full upgrade on new server oracle 11g and then convert the character set. Am I right?Yes, You are right.
I think as you are changing from WE8ISO8859P1 to AL32UTF8, so you do not need any tool.
Must read note,
*Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) [ID 260192.1]*

Characterset conversion from US7ASCII to WE8ISO5589P1

Hi,
I need to do a Character set conversion from US7ASCII to WE8ISO5589P1 on a 10g database. I need to make the proper analysis before doing this conversion. Kindly let me know of any links/urls/metalink note ids where i can find relevant docmentation and understand on this so that i can continue with the conversion.
Regards,
Amby.

Start here:
http://www.oracle.com/technology/tech/globalization/pdf/TWP_Character_Set_Migration_Best_Practices_10gR2.pdf
Also, consider migrating to WE8MSWIN1252 in place of WE8ISO8859P1. If you have Windows clients, then WE8MSWIN1252 should be used anyway. Even if you do not have Windows clients, WE8MSWIN1252 is a binary superset of WE8ISO8859P1 and can hold all WE8ISO8859P1 codes + ca. 15 characters more. It is better to use it in case Windows clients are used in future.
-- Sergiusz

Convert NLS_CHARACTERSET 9i RAC DB from WE8ISO8859P1 to UTF8

Hi,
Currently my database has
NLS_CHARACTERSET=WE8ISO8859P1
NLS_NCHAR_CHARACTERSET=AL16UTF16
However, developers request to change NLS_CHARACTERSET to be UTF8 because new source of one of new data marts is UTF8. Currently there is issue with displaying only few records. For conversion, I need to recreate a new database which is what I'm trying to avoid.
My quesitons are
1. Since Unicode data stored in few columns in few tables in this new datamart only, can they take advantage of NCHAR and NVARCHAR instead?
2. If converted to UTF8, what is the drawback of storing all data in database in Unicode?
3. Is AL32UTF8 better (and superset) than UTF8?
Thanks

Generally, you won't be able to convert the existing database to UTF8 since UTF8 isn't a strict binary superset of the existing ISO 8859-1 character set. You would probably have to create a new database and export & import the data over. If there are special circumstances, you may have some other options, but it will involve quite a bit of administration.
Working with NCHAR columns tends to be a bit more complex from an application development perspective (though this complexity differs depending on the front end used). Depending on the language of most of the data, there are probably space implications of UTF16 vs UTF8. UTF16 is a fixed width character set, so every character occupies two bytes of storage. UTF8 is a variable width character set, so English characters will tend to be 1 byte, European characters will tend to be 2 bytes, and Asian characters will tend to be 3 bytes.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Characterset conversion from WE8MSWIN1252 to AL32UTF8

DB Version:11g
Is it possible to convert a DB of WE8MSWIN1252 characterset to AL32UTF8?

Yes it can be done..
Please refer below metalink notes:
Changing the Database Character Set ( NLS_CHARACTERSET ) [ID 225912.1]
AL32UTF8 / UTF8 (Unicode) Database Character Set Implications [ID 788156.1]
Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode) [ID 260192.1]
Regards
Rajesh

Characterset conversion from P15 to WE8MSWIN1252

I have a database with the P15 characterset.
How can I make a charactersetconversion to WE8MSWIN1252-characterset.
WhatÂ´s the most eassyiest way to do this?
Could someone please help me?

Start here:
http://www.oracle.com/technology/tech/globalization/pdf/TWP_Character_Set_Migration_Best_Practices_10gR2.pdf
Also, consider migrating to WE8MSWIN1252 in place of WE8ISO8859P1. If you have Windows clients, then WE8MSWIN1252 should be used anyway. Even if you do not have Windows clients, WE8MSWIN1252 is a binary superset of WE8ISO8859P1 and can hold all WE8ISO8859P1 codes + ca. 15 characters more. It is better to use it in case Windows clients are used in future.
-- Sergiusz

Changing WE8ISO8859P1 to UTF8 or in 10g 10.2.0.4 RHEL AS 5

Hi All,
I want to change my database charset from WE8ISO8859P1 to UTF8, I know of the export and import method . Please tell me that is it possible for me to do the same using the alter database charachterset command or cssalter utility.
Just wanted to be sure that if the new charset(UTF8) is the superset of the old one(WE8ISO8859P1) . I am not inclined for te export/import method bcas of the ammount of the time involved as the size of the database is big.
Thanks

Actually, I've imported WE8ISO... into UTF8 as well as AL32UTF8 without any problems, but you can't go backwards.
I have had problems with data conversion, but I've come up with my own way of rebuilding the tables using NLS_LENTH_SEMANTICS set to CHAR, and then changing the column lenghts that were giving problems to 4 times as long. This always works. and is a lot easier than using csscan. I've had quite a bit of bad luck and frustration using csscan which led me to writing a white paper for Oracle on data conversion using my method (which works).
The OP needs to have a firm understanding of character set conversion before he attempts what he was asking about. And, as you mentioned, needs to do it in test first. Then he needs to test doing a full export and importing the data to be sure not to get data conversion issues (ORA-01401: inserted value too large for column).
ji li

R12 Characterset conversion to UTF8 on 11 G R2 Database

We are doing Characterset conversion to UTF8, i ran csscan its complaning lot of lossy chars and Convertible chars,do i need to take export below all tables..?
ata Dictionary Tables:
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 117,133,414 0 0 0
CHAR 17,402 0 0 0
LONG 8,074,421 0 0 0
CLOB 4,348,695 22,903 0 0
VARRAY 42,001 0 0 0
Total 129,615,933 22,903 0 0
Total in percentage 99.982% 0.018% 0.000% 0.000%
The data dictionary can be safely migrated using the CSALTER script
XML CSX Dictionary Tables:
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 501 0 0 0
CHAR 0 0 0 0
LONG 0 0 0 0
CLOB 0 0 0 0
VARRAY 0 0 0 0
Total 501 0 0 0
Total in percentage 100.000% 0.000% 0.000% 0.000%
[Application Data Conversion Summary]
Datatype Changeless Convertible Truncation Lossy
VARCHAR2 118,182,641 0 103 1,260,883
CHAR 265 0 0 0
LONG 61,948 0 0 0
CLOB 129,455 827 0 0
VARRAY 32,797 0 0 0
Total 118,407,106 827 103 1,260,883
Total in percentage 98.946% 0.001% 0.000% 1.054%
Data Dictionary Tables:
USER.TABLE Convertible Truncation Lossy
MDSYS.OPENLS_NODES 17 0 0
MDSYS.SDO_COORD_OP_PARAM_VALS 200 0 0
MDSYS.SDO_GEOR_XMLSCHEMA_TABLE 1 0 0
MDSYS.SDO_STYLES_TABLE 78 0 0
MDSYS.SDO_XML_SCHEMAS 3 0 0
ORDDATA.ORDDCM_CT_PRED_OPRD 51 0 0
ORDDATA.ORDDCM_DOCS 9 0 0
ORDDATA.ORDDCM_MAPPING_DOCS 1 0 0
SYS.METASTYLESHEET 178 0 0
SYS.REGISTRY$ERROR 2 0 0
SYS.RULE$ 21 0 0
SYS.SCHEDULER$_EVENT_LOG 182 0 0
SYS.WRH$_SQLTEXT 2,099 0 0
SYS.WRH$_SQL_PLAN 1,736 0 0
SYS.WRI$_ADV_ACTIONS 5,452 0 0
SYS.WRI$_ADV_DIRECTIVE_META 5 0 0
SYS.WRI$_ADV_OBJECTS 2,278 0 0
SYS.WRI$_ADV_RATIONALE 9,594 0 0
SYS.WRI$_ADV_SQLT_PLANS 455 0 0
SYS.WRI$_ADV_SQLT_PLAN_STATS 288 0 0
SYS.WRI$_DBU_FEATURE_METADATA 188 0 0
SYS.WRI$_DBU_FEATURE_USAGE 16 0 0
SYS.WRI$_DBU_HWM_METADATA 20 0 0
SYS.WRI$_REPT_FILES 27 0 0
XDB.XDB$DXPTAB 2 0 0
XML CSX Dictionary Tables:
USER.TABLE Convertible Truncation Lossy
Application Data:
USER.TABLE Convertible Truncation Lossy
APPLSYS.BISM_OBJECTS 4 0 0
APPLSYS.DR$FND_LOBS_CTX$I 0 103 1,260,883
APPLSYS.FND_CONC_PROG_ANNOTATIONS 272 0 0
APPLSYS.FND_OAM_CONTEXT_FILES 15 0 0
APPLSYS.FND_OAM_DOC_LINK 1 0 0
APPS.FND_OAM_CONTEXT_FILES_1 6 0 0
AZ.AZ_APIS 11 0 0
AZ.AZ_SELECTION_SET_ENTITIES_B 48 0 0
ECX.ECX_DTDS 205 0 0
ECX.ECX_FILES 91 0 0
IBC.IBC_ATTRIBUTE_BUNDLES 41 0 0
JTF.JTF_HEADER_DTD 1 0 0
JTF.JTF_MESSAGE_OBJECTS 82 0 0
JTF.JTY_TRANS_USG_PGM_SQL 29 0 0
ODM.ODM_PMML_DTD 1 0 0
OKC.OKC_REPORT_SQL_B 3 0 0
OKC.OKC_REPORT_SQL_TL 2 0 0
OKC.OKC_REPORT_XSL_TL 5 0 0
XDP.XDP_PROC_BODY 10 0 0
[Distribution of Convertible, Truncated and Lossy Data by Column]
Data Dictionary Tables:
USER.TABLE|COLUMN Convertible Truncation Lossy
MDSYS.OPENLS_NODES|SYS_NC00004$ 17 0 0
MDSYS.SDO_COORD_OP_PARAM_VALS|PARAM_VALUE_FILE 200 0 0
MDSYS.SDO_GEOR_XMLSCHEMA_TABLE|XMLSCHEMA 1 0 0
MDSYS.SDO_STYLES_TABLE|DEFINITION 78 0 0
MDSYS.SDO_XML_SCHEMAS|XMLSCHEMA 3 0 0
ORDDATA.ORDDCM_CT_PRED_OPRD|SYS_NC00004$ 51 0 0
ORDDATA.ORDDCM_DOCS|SYS_NC00005$ 9 0 0
ORDDATA.ORDDCM_MAPPING_DOCS|SYS_NC00007$ 1 0 0
SYS.METASTYLESHEET|STYLESHEET 178 0 0
SYS.REGISTRY$ERROR|MESSAGE 1 0 0
SYS.REGISTRY$ERROR|STATEMENT 1 0 0
SYS.RULE$|CONDITION 21 0 0
SYS.SCHEDULER$_EVENT_LOG|ADDITIONAL_INFO 182 0 0
SYS.WRH$_SQLTEXT|SQL_TEXT 2,099 0 0
SYS.WRH$_SQL_PLAN|OTHER_XML 1,736 0 0
SYS.WRI$_ADV_ACTIONS|ATTR5 2,726 0 0
SYS.WRI$_ADV_ACTIONS|ATTR6 2,726 0 0
SYS.WRI$_ADV_DIRECTIVE_META|DATA 5 0 0
SYS.WRI$_ADV_OBJECTS|ATTR4 2,278 0 0
SYS.WRI$_ADV_RATIONALE|ATTR5 9,594 0 0
SYS.WRI$_ADV_SQLT_PLANS|OTHER_XML 455 0 0
SYS.WRI$_ADV_SQLT_PLAN_STATS|OTHER 288 0 0
SYS.WRI$_DBU_FEATURE_METADATA|INST_CHK_LOGIC 21 0 0
SYS.WRI$_DBU_FEATURE_METADATA|USG_DET_LOGIC 167 0 0
SYS.WRI$_DBU_FEATURE_USAGE|FEATURE_INFO 16 0 0
SYS.WRI$_DBU_HWM_METADATA|LOGIC 20 0 0
SYS.WRI$_REPT_FILES|SYS_NC00005$ 27 0 0
XDB.XDB$DXPTAB|SYS_NC00006$ 2 0 0
XML CSX Dictionary Tables:
USER.TABLE|COLUMN Convertible Truncation Lossy
Application Data:
USER.TABLE|COLUMN Convertible Truncation Lossy
APPLSYS.BISM_OBJECTS|SYS_NC00023$ 4 0 0
APPLSYS.DR$FND_LOBS_CTX$I|TOKEN_TEXT 0 103 1,260,883
APPLSYS.FND_CONC_PROG_ANNOTATIONS|PROGRAM_ANNOTAT 272 0 0
APPLSYS.FND_OAM_CONTEXT_FILES|TEXT 15 0 0
APPLSYS.FND_OAM_DOC_LINK|DOC_LINK_INFO 1 0 0
APPS.FND_OAM_CONTEXT_FILES_1|TEXT 6 0 0
AZ.AZ_APIS|FILTERING_PARAMETERS 11 0 0
AZ.AZ_SELECTION_SET_ENTITIES_B|FILTERING_PARAMETE 48 0 0
ECX.ECX_DTDS|PAYLOAD 205 0 0
ECX.ECX_FILES|PAYLOAD 91 0 0
IBC.IBC_ATTRIBUTE_BUNDLES|ATTRIBUTE_BUNDLE_DATA 41 0 0
JTF.JTF_HEADER_DTD|HEADER_DTD 1 0 0
JTF.JTF_MESSAGE_OBJECTS|BUS_OBJ_DTD 41 0 0
JTF.JTF_MESSAGE_OBJECTS|BUS_OBJ_SQL 41 0 0
JTF.JTY_TRANS_USG_PGM_SQL|BATCH_DEA_SQL 1 0 0
JTF.JTY_TRANS_USG_PGM_SQL|BATCH_INCR_SQL 5 0 0
JTF.JTY_TRANS_USG_PGM_SQL|BATCH_TOTAL_SQL 6 0 0
JTF.JTY_TRANS_USG_PGM_SQL|INCR_REASSIGN_SQL 5 0 0
JTF.JTY_TRANS_USG_PGM_SQL|REAL_TIME_INSERT 6 0 0
JTF.JTY_TRANS_USG_PGM_SQL|REAL_TIME_SQL 6 0 0
ODM.ODM_PMML_DTD|DTD 1 0 0
OKC.OKC_REPORT_SQL_B|SQL_TEXT 3 0 0
OKC.OKC_REPORT_SQL_TL|HELP_TEXT 2 0 0
OKC.OKC_REPORT_XSL_TL|HELP_TEXT 2 0 0
OKC.OKC_REPORT_XSL_TL|XSL_TEXT 3 0 0
XDP.XDP_PROC_BODY|PROC_BODY 10 0 0
[Indexes to be Rebuilt]
USER.INDEX on USER.TABLE(COLUMN)
APPLSYS.DR$FND_LOBS_CTX$X on APPLSYS.DR$FND_LOBS_CTX$I(TOKEN_TEXT)
APPLSYS.DR$FND_LOBS_CTX$X on APPLSYS.DR$FND_LOBS_CTX$I(TOKEN_TYPE)
APPLSYS.DR$FND_LOBS_CTX$X on APPLSYS.DR$FND_LOBS_CTX$I(TOKEN_FIRST)
APPLSYS.DR$FND_LOBS_CTX$X on APPLSYS.DR$FND_LOBS_CTX$I(TOKEN_LAST)
APPLSYS.DR$FND_LOBS_CTX$X on APPLSYS.DR$FND_LOBS_CTX$I(TOKEN_COUNT)
IBC.IBC_ATTRIBUTE_BUNDLES_CTX on IBC.IBC_ATTRIBUTE_BUNDLES(ATTRIBUTE_BUNDLE_DATA)
-----------------------------------------------------------------------------------------

Sawwan,
I am getting below error
[oracle@uat nls]$ exp file=exp_utf8.dmp parfile=exp.par
Export: Release 11.2.0.1.0 - Production on Wed Apr 20 18:43:11 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Username: system
Password:
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in UTF8 character set and AL16UTF16 NCHAR character set
server uses US7ASCII character set (possible charset conversion)
About to export specified tables via Conventional Path ...
Current user changed to APPLSYS
. . exporting table BISM_OBJECTS 4 rows exported
EXP-00011: APPLSYS.DR$FND_LOBS_CTX$I does not exist ( do i need to procced with truncation of convertable objects..?, please confirm me, i am confusing here)
http://www.oracle-latest-technology.com/2011/02/how-to-convert-character-set-of-oracle.html
. . exporting table FND_CONC_PROG_ANNOTATIONS 290 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table FND_OAM_CONTEXT_FILES 15 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table FND_OAM_DOC_LINK 1 rows exported
EXP-00091: Exporting questionable statistics.
Current user changed to APPS
. . exporting table FND_OAM_CONTEXT_FILES_1 6 rows exported
EXP-00091: Exporting questionable statistics.
Current user changed to AZ
. . exporting table AZ_APIS 356 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table AZ_SELECTION_SET_ENTITIES_B 490 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Current user changed to ECX
. . exporting table ECX_DTDS 205 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table ECX_FILES 91 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Current user changed to IBC
EXP-00011: IBC.IBC_ATTRIBUTE_BUNDLES_DATA does not exist
. . exporting table IBC_ATTRIBUTE_BUNDLES 41 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Current user changed to JTF
. . exporting table JTF_HEADER_DTD 1 rows exported
EXP-00091: Exporting questionable statistics.
. . exporting table JTF_MESSAGE_OBJECTS 41 rows exported
EXP-00091: Exporting questionable statistics.
. . exporting table JTY_TRANS_USG_PGM_SQL 7 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00010: MDSYS is not a valid username
EXP-00010: MDSYS is not a valid username
EXP-00010: MDSYS is not a valid username
EXP-00010: MDSYS is not a valid username
EXP-00010: MDSYS is not a valid username
EXP-00010: MDSYS is not a valid username
Current user changed to ODM
. . exporting table ODM_PMML_DTD 1 rows exported
EXP-00091: Exporting questionable statistics.
Current user changed to OKC
. . exporting table OKC_REPORT_SQL_B 3 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OKC_REPORT_SQL_TL 3 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
. . exporting table OKC_REPORT_XSL_TL 3 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00010: XDB is not a valid username
Current user changed to XDP
. . exporting table XDP_PROC_BODY 10 rows exported
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
EXP-00091: Exporting questionable statistics.
Current user changed to ORDDATA
. . exporting table ORDDCM_CT_PRED_OPRD 51 rows exported
. . exporting table ORDDCM_DOCS 9 rows exported
. . exporting table ORDDCM_MAPPING_DOCS 1 rows exported
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.
[oracle@uat nls]$ exp file=exp_fnd_lobs.dmp table=APPLSYS.DR$FND_LOBS_CTX$I
LRM-00101: unknown parameter name 'table'

Problem in Database convertion from US7ASCII to UTF8

Hi,
We are facing the following problem while converting the database from US7ASCII to UTF8:
We have recently changed the database character set from US7ASCII to UTF8 for the internationalization
purpose. We ran the Character set scanner utility and it did report that some data may pose problems.
We followed the the below mentioned process to convert into UTF8 -
1) alter database character set utf8
2) alter database national character set utf8.
Now we find some problem while working with the old data in our application which is java based.
We are getting the following error "java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv".
We further analyzed our data and found some interesting things :
e.g.
DB - UTF8.
NL_LANG also set to UTF8.
Select name from t1 where name like 'Gen%';
NAME
Genhve
But when we find out the length of the same data it show like this
NAME LENGTH(NAME) VSIZE(NAME)
Genhve 4 6
The question is why is it showing length as 4 only and when we try to use a substr function
its extracting like the following :-
select name,substr(name,4,1) from t1 where name like 'Gen%';
NAME SUB
Genhve hve
We have execute the above queries on US7ASCII DB and it is working fine, length it shows 6
and using SUBSTR it extracts just 'h' as well.
We also used dump function on the UTF8 Db for the above query,,this is the result :-
select name,length(name),vsize(name),dump(name) from t1 where name like 'Gen%';
NAME LENGTH(NAME) VSIZE(NAME) DUMP(NAME)
Genhve 4 6 Typ=1 Len=6: 71,101,110,232,118,101
We checked a lot with the data and it seems 'h' (accented e) is posing the problem.
We want to know where is the problem and how to overcome this.
Further, we tried all of the following :
1)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute e became h
2)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: IMP 00016 error
3)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute E became h
4)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: Acute e became h
5)
Tried using Update sys.props$
set value$='UTF8'
where name='NLS_CHARACTERSET'
RESULT: Acute e shows properly but it gives problem in the application
"java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv"
Looking further it was observed the following:
when you try this command on a column 'city' in a table which contains 'Genhva' (note the acute e after n), it shows
command: select length(city), vsize(city),substr(city,4,1),city from cities
Result: 4 6 hva Genhva
if you see the value of substr(city,4,1) , you will see the problem. Also note that the length shows 4 and size shows 6. Moreover, when these records are selected through JDBC Driver, it starts giving problems.
6)
Actually the above (point no. 5) is similar to changing the character set of the database with 'ALTER DATABASE CHARACTER SET UTF8'. Same problem is observed then too.
7)
We have also tried to with another method, that is by changing the third byte of the export file which specifies the character set, to the UTF8 code by editing the export file with a Hexdecimal editor. After import the same problem has been observed as defined in (5) and (6) above.
We have no more ideas how to migrate without corrupting the data. Of course we have known the records where these characters occur through the Oracle's cssacn utility but we do not want to manually rectify each and every record by replacing it with an ASCII character. Any other idea as to how this can be accomplised?
Thanx
Ashok

The problem you have is that although your original database is defined as US7ASCII, the data it contains is more than is covered by this code page (as the reply on Sept 4 to the previous posting already said).
This has probably happened because the client was also defined as US7ASCII, and when the DB and client are defined as having the same character set no conversion (or checdking) takes place when data is passed between them. However if you are using a Windows client then it will in fact be using Windows code page 1252 (Latin-1) or similar, and this allows many more characters, including h (accented e). So a user can enter all these characters and store them in the database, and similarly read them from the database, because data transfer is transparent.
When you did ALTER DATABASE CHARACTER SET UTF8 this will only change the label on the database, but not affect the contents. However only part of the contents are valid UTF8, any character above 7F (like h) is invalid. If your original client now uses the database, code page transformation will take place because the client and DB have different character sets defined. The invalid codes can then cause problems.
Without being able to explain what has happened in detail, it may help to see what your h (dec 232, x'E8') looks like. The actual data has not changed (you can see this as it is reported as 232). However the binary code there (11101000) is invalid UTF8. UTF8 encodes a character in 1 to 4 bytes, and the first bits in a UTF8 character tell how many bytes it uses. 0xxx tell it is one byte (same as the corresponding USASCII character), 110x that it uses 2 bytes, 1110 that it uses 3 bytes etc. So if you interpret what is there as UTF8 it looks like the first byte of a 3-byte character, which explains why the substringing is giving you the other 2 bytes as well.
Can you fix this without losing data? I believe yes. First you should check what other characters are being flagged by the scan. See if these are contained in another standard character set. If they are only Western European accentet characters then WE8ISO8859P1 is probably ok, but watch out for the euro sign which Windows has at x'80', an undefined character in ISO8859-1.
You can see the contents of the Microsoft Windows Codepage 1252 at: http://www.microsoft.com/globaldev/reference/sbcs/1252.htm
For a listing of the US-ASCII defined characters see http://czyborra.com/charsets/iso646.html and for ISO 8859-1 see http://czyborra.com/charsets/iso8859.html#ISO-8859-1
If all is well, you can first ALTER DATABASE CHARACTER SET to WE8ISO8859P1. This will not change any data, but ensure that all the data gets exported. Then export the DB and import it to a UTF8 DB. This will convert the non-US-ASCII characters to Unicode. You will also have to change the clients character set to something other than USASCII or they will just see ? for the other characters.
Good Luck!

Characterset Conversion

Hi,
I would like to change the characterset of my E-Business Suite R12.1.3 with database 10.2.0.4 from US7ASCII to UTF8. Which is the best document to follow and what all are the things I need to take care of?
Expecting expert's advice.
Sony

Sony,
Please see the docs referenced in these threads.
MLS Data Character Set Conversion
MLS Data Character Set Conversion
Oracle E-Biz Applications Database characterset conversion
Re: Oracle E-Biz Applications Database characterset conversion
Thanks,
Hussein

NLS_CHARACTERSET From WE8ISO8859P1 to Arabic Suuported NLS_CHARACTERSET

Hi Gurus..
we use Oracle 10g on HP-Unix
RDBMS_VERSION 10.2.0.1.0
We wanted the Database to Support Arabic Language as well,
Current NLS_PARAMETER
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8ISO8859P1
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
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
To what Character Set NLS_CHARACTERSET to be changed So as the Database to Support Arabic Langauge as well,
Which NLS_CHARACTERSET IS Best Suport for Arabic
We have to Change From WE8ISO8859P1
please Help
thanks All
Khaja

You will need to follow the steps in MOS Doc 225912.1 (Changing the Database Character Set ( NLS_CHARACTERSET )). This is not a trivial exercise. The easiest way to do the conversion is to export the database, drop the database, recreate it with the new characterset and perform an import. Other solutions will require the support of Oracle Consulting.
HTH
Srini

CONVERSION FROM ANSI ENCODED FILE TO UTF-8 ENCODED FILE

Hi All,
I have some issues in conversion of ANSI encoded file to utf encoded file. let me tell you in detail
I have installed the Language Support for Thai Language on My Operating System.
now, when I open my notepad and add thai character on the file and save it as ansi encoding. it saves it perfectly and also I able to see it on opening the file again.
This file need to be read by my application , store in database and should display thai character on jsp after fetching the data from database. Currently it is showing junk character on jsp reason being that my database (UTF8 compliant database) has junk data . it has junk data because my application is not able to read it correctly from the file.
If I save the file with encoding as UTF 8 it works fine. but my business requirement is such that the file is system generated and by default it is encoded in ANSI format. so I need to do the conversion of encoding from ANSI to UTF8 . so Any of you can guide me on the same how to do this conversion ?
Regards
Gaurav Nigam

Guessing the encoding of a text file by examining its contents is tricky at best, and should only be done as a last resort. If the file is auto-generated, I would first try reading it using the system default encoding. That's what you're doing whenever you read a file with a FileReader. If that doesn't work, try using an InputStreamReader and specifying a Thai encoding like TIS-620 or cp838 (I don't really know anything about Thai encodings; I just picked those out of a quick Google search). Once you've read the file correctly, you can write the text to a new file using an OutputStreamWriter and specifying UTF-8 as the encoding. It shouldn't really be necessary to transcode files like this, but without knowing a lot more about your situation, that's all I can suggest.
As for native2ascii, it isn't for encoding conversions. All it does is replace each non-ASCII character with its six-character Unicode escape, so "voilá" becomes "voil\u00e1". In other words, it avoids the problem of character encodings by converting the file's contents to a form that can be stored as ASCII. It's mainly used for converting property or resource files to a form that can be read by the Properties and ResourceBundle classes.

Characterset conversion from WE8ISO8859P1 to UTF8

Similar Messages

Maybe you are looking for