WE8MSWIN1252 && AL32UTF8

Hi
My current 10g database has WE8ISO8859P1 character set. I want to install a fresh 11g database and use exp/imp utility to move the data.
I notice that WE8ISO8859P1 is not available in 11g hence I have to use WE8MSWIN1252.
We have some chinese characters in the database therefore I am not sure whether I should use WE8MSWIN1252 or unicode (AL32UTF8)
What is the disadvantage of using WE8ISO8859P1 as the database character set and using AL16UTF16 as the National character set ?
In this case we will need to use Nchar datatype to store chinese characters
Thanks in advance

Hi;
pelase check your other thread
Re: character set 11g
Regard
Helios

Similar Messages

12.1.0.2 install on windows 2012 R2

Hi friends,
We are planning on migrating databases from 11.2 to 12c on Win 2012 server. Currently there are about 6 11g instances(different customer's and development databases) on one server. We will need to migrate all of them in the near future. I was reading up on the multitenant option in 12c, seems to be a great option for us hosting multiple databases on one server. But all these databases have different character sets(WE8MSWIN1252, AL32UTF8, WE8ISO8859P1) depending on the client needs.. From what I understand, the character set will be set in the container CDB and all the PDB databases will be using the same character set? Is it not possible to use different character sets and different init parameters for the respective PDB's? Also, since they are customer databases and development databases , the database size and memory needs will widely vary among the different databases.. Can this be a problem? ANy thoughts are really appreciated.... THank you so much

We are planning on migrating databases from 11.2 to 12c on Win 2012 server. Currently there are about 6 11g instances(different customer's and development databases) on one server. We will need to migrate all of them in the near future. I was reading up on the multitenant option in 12c, seems to be a great option for us hosting multiple databases on one server. But all these databases have different character sets(WE8MSWIN1252, AL32UTF8, WE8ISO8859P1) depending on the client needs.
A database can only have ONE character set. Makes no difference if you are using 12c, 11g, 10g, 9i, 8i.
. From what I understand, the character set will be set in the container CDB and all the PDB databases will be using the same character set?
Close - a multitenant DB is ONE database - so can only have ONE character set. All components of that ONE DB use that same character set. Each PDB is a component of that ONE DB.
Is it not possible to use different character sets and different init parameters for the respective PDB's?
There is only ONE database - so it only has ONE character set, one set of REDO logs, one set of memory management.
Chapters 17 and 18 of the Concepts doc discuss the ONE database and how each of those components works in that context
http://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm
Also, since they are customer databases and development databases , the database size and memory needs will widely vary among the different databases.
Just so what I said earlier was not misunderstood - there is ONLY ONE DB. So there is only ONE memory management component. When you size memory you size it to meet the requirements of that ONE DB which, by necessity, means the requirements of ANY AND ALL PDBs that you plan to have open simultaneously.
If you want to manage REDO and memory independently for each customer then you need a separate dabase for each customer.
As Srini noted that separate database can be a standard (non-multitenant) 12c DB.
Oracle 12c multitenant is a NEW architecture. Until your DBA staff has expertise in that architecture you should NOT consider using it for a production environment. It is vital that you conduct the full range of dev/test/performance test/qa test of the development lifecycle.
Even seemingly simple, mundane things like starting up the DB, connecting to the CDB or PDBs, creating users, making grants and more are either TOTALLY NEW or radically different.
No matter what the level of expertise a DBA has they will NOT be successful doing even those basic things without having first RTFM.
The above isn't meant to alarm you or discourage you from using 12c. It is merely to relate the facts as I see them. The preponderance of the forum questions have been about things as simple as 'why can I not connect to the hr schema'.
In particular see my length reply in this thread:
12c database - empty container vs PDB

UTF-8 stored in VARCHAR2 on a non-Unicode DB

Hi there,
we have a company that implements storing Unicode data in Oracle in the following way:
A plain VARCHAR2 on a non-Unicode DB (charset is actually WE8MSWIN1252) receives UTF-8 coded data.
As client and server have the same setting for NLS_LANG, no conversion takes place, and the app will run fine.
(in my eyes, a clean way to set this up would be utilizing NVARCHAR fields for this, but this is no option)
But: how can I do query based on these columns without getting garbage for each non-ASCII character?
I imagine setting up views for that purpose, but I need the syntax on how to re-interpret the UTF-8 data coming from a VARCHAR2 field.
I tried the following:
SELECT CONVERT(column, 'WE8MSWIN1252', 'AL32UTF8') FROM table where ...
This will give me the right data on a client with cp 1252 set up, with the restriction to 8 bit output.
Now I would like to have a Unicode-capable application like SQL*Developer to be fully capable of dealing with the Unicode data, but I guess, for that to work, I would need the DB to deliver a NVCHAR2 output from the above query?
Any help and comments appreciated.
Tom
Message was edited by: snmdla

we have a company that implements storing Unicode data in Oracle in the following way:
No - they don't. They are NOT storing unicode data - they are storing individual one-byte characters and using that VARCHAR2 column as a BLOB. Ask them how, of if, they query the data.
A plain VARCHAR2 on a non-Unicode DB (charset is actually WE8MSWIN1252) receives UTF-8 coded data.
No - it doesn't. It receives a string of one byte characters in the WE8MSWIN1252 character set. It does not know, or care, what those one-byte characters represent. All you are doing is storing BINARY data in that VARCHAR2 column one byte at a time. When you query it you will get one or several bytes back - but since Oracle thinks it is really character data, when it is actually binary, you can only match it by matching those one-byte characters.
I imagine setting up views for that purpose, but I need the syntax on how to re-interpret the UTF-8 data coming from a VARCHAR2 field.
You don't have UTF-8 data - you have a BLOB that you need to convert to UTF-8 data. You can use the DBMS_LOB.CONVERTTOCLOB procedure to do the conversion and specify the character set to use. See the DBMD_LOB API
http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_lob.htm#i1020356
CONVERTTOCLOB Procedure
This procedure takes a source BLOB instance, converts the binary data in the source instance to character data using the character set you specify, writes the character data to a destination CLOB or NCLOB instance, and returns the new offsets.
See this AskTom article for further review
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3575852900346063772

Unable to migrate table, character set from WE8MSWIN1252 to AL32UTF8

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

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

Running instances with different character set WE8MSWIN1252 and AL32UTF8

We have db instances running AL32UTF8 character set and our applications are built around it, however we have request to create instances using WE8MSWIN1252 character set for another application without bringing in new h/w (server).
what are the ways to implement it?
Edited by: raygear on Aug 23, 2012 7:06 PM

What is the problem? Run DBCA in the advanced mode and specify the required database character set for the new database.
-- Sergiusz

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

Unable to alter character set from WE8MSWIN1252 to AL32UTF8

Hi,
I am trying to migrate some tables to my database.
On the source DB, the character set is AL32UTF8
On My database, the character set is WE8MSWIN1252.
When I tried to alter the character set, I get this error message:
ALTER DATABASE CHARACTER SET AL32UTF8
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
Any help? Thanks.

Pl refrain from posting duplicate threads :-)
Unable to migrate table, character set from WE8MSWIN1252 to AL32UTF8
Srini

Need to change character set from WE8MSWIN1252 to AL32UTF8.

Hi,
We have installed the database with Character set WE8MSWIN1252. But off late we understood that client requirement is AL32UTF8. Is there any way to change in easy method?
Thanks in-advance.
Rgds
DBA.

Pl also see these Docs
AL32UTF8 / UTF8 (Unicode) Database Character Set Implications          [Document 788156.1]
Changing the NLS_CHARACTERSET to AL32UTF8 / UTF8 (Unicode)          [Document 260192.1]
If you are using EBS, then also see
For 11i - Appendix A of "Oracle Applications 11i Internationalization Guide          [Document 333785.1]"
For R12 - Appendix A of "Globalization Guide for Oracle Applications Release 12          [Document 393861.1]"
Changing the characterset of an existing database/application is not a trivial task - will require thorough planning and testing.
HTH
Srini

Change Oracle XE from WE8MSWIN1252 to AL32UTF8

I want to change the character set of Oracle XE 10g on my machine from WE8MSWIN1252 to AL32UTF8. I understand I need to scan, change my NLS_LANG and export and them import into new XE with Universal character set.
I need some more details to these steps if someone can help out.
My current Oracle XE details:
NLS_LANGUAGE - AMERICAN
NLS_TERRITORY - AMERICA
NLS_CHARACTERSET - WE8MSWIN1252
I want NLS_CHARACTERSET to be AL32UTF8.
Thanks,

Hi everbody,
Really OracleXE dont suport character convertion.
But I get the binary CSSCAN from another Oracle 10g Enterprise and copy to server of XE in $ORACLE_HOME/bin.
With this, I copy also CSALTER.PLB and CSMINST.SQL to ?/rdbms/admin and now, I have the scripts.
So, I run following the "howto" and read .log, .err and .out files generated from log=
If you receive the message "Checking or Converting phrase did not finish successfully", check the .err file and drop the tables listed as "with error". After this, the process run without erros and YES, the database is CHANGED.
I do this and I can afirm: this process works!
Ederson.Oliveira
www.rwit.com.br

Migratiom from WE8MSWIN1252 to al32utf8

Hi
I need to migrate my db from western Europe character set to a multi byte character set.
I exported my data from 10g instance with WE8MSWIN1252 and then imported it to an 10g instance with AL32UTF8 and nsl_lenght_semantic = 'CHAR'.
The VARCHAR2 fields and char fields are still defined as bytes.
es. my_desc varchar2(100 byte )
Then I need to convert all varchars and char fields definition to 'CHAR'.
I know that I can perform this field by field using ALTER TABLE MODIFY.
All my tables are defined into one schema, (mySchema.tab1, mySchema.tab2,...).
so, I want to know if it is possible to do this conversion in one step?
Thanks
Mario

user8091088 wrote:
then imported it to an 10g instance with AL32UTF8 and nsl_lenght_semantic = 'CHAR'.
The VARCHAR2 fields and char fields are still defined as bytes.
es. my_desc varchar2(100 byte )Check your export dump. It could be that create statements etc. are using column length specified as 'byte'.
Metalink/MOS might have some Note that documents possible supported workarounds.

Convert Characterset from WE8MSWIN1252 to AL32UTF8

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

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

Chang Charactor set WE8MSWIN1252 to AL32UTF8 for creating RCU

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

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

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

CSSCAN in 11g - Characterset not changing from WE8IMSWIN1252 to AL32UTF8

All,
We have installed a 11g database in Linux box and once after that we wanted to change the character set to AL32UTF8 from default WE8MSWIN1252.
We took the cs-alter approach and ran cs-scan utility, upon going through csscan.txt files generated by csscan utility we found that there are no lossy data but convertible data was found in data dictionary. Below is the output from csscan.txt
This is the Scan Summary
*[Scan Summary]*
All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set
Database Scan Summary Report
Time Started : 2012-10-17 21:42:17
Time Completed: 2012-10-17 21:42:47
Process ID         Time Started       Time Completed
         1 2012-10-17 21:42:18 2012-10-17 21:42:46
         2 2012-10-17 21:42:18 2012-10-17 21:42:46
         3 2012-10-17 21:42:18 2012-10-17 21:42:46
[Database Size]
Tablespace                           Used            Free           Total       Expansion
SYSTEM                            709.75M         256.00K         710.00M           2.42M
SYSAUX                            645.63M          34.38M         680.00M          12.52M
UNDOTBS1                           13.13M          16.88M          30.00M            .00K
TEMP                                 .00K            .00K            .00K            .00K
USERS                               1.31M           3.69M           5.00M            .00K
HYPE_DATA                       1,024.00K      19,999.00M      20,000.00M            .00K
HYPE_INDX                       1,024.00K      19,999.00M      20,000.00M            .00K
Total                           1,371.81M      40,053.19M      41,425.00M          14.94M
The size of the largest CLOB is 1625114 bytes
[Database Scan Parameters]
Parameter                      Value
CSSCAN Version                 v2.1
Instance Name                  dvhp081
Database Version               11.2.0.3.0
Scan type                      Full database
Scan CHAR data?                YES
Database character set         WE8MSWIN1252
FROMCHAR                       WE8MSWIN1252
TOCHAR                         al32utf8
Scan NCHAR data?               NO
Array fetch buffer size        10240
Number of processes            3
Capture convertible data?      NO
[Scan Summary]
All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set
[Data Dictionary Conversion Summary]
Data Dictionary Tables:
Datatype                    Changeless      Convertible       Truncation            Lossy
VARCHAR2                     5,408,302                0                0                0
CHAR                             4,261                0                0                0
LONG                           249,018                0                0                0
CLOB                            67,652            3,794                0                0
VARRAY                          49,807                0                0                0
Total                        5,779,040            3,794                0                0
Total in percentage             99.934%           0.066%           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                           702                0                0                0
CHAR                                 0                0                0                0
LONG                                 0                0                0                0
CLOB                                 0                0                0                0
VARRAY                               0                0                0                0
Total                              702                0                0                0
Total in percentage            100.000%           0.000%           0.000%           0.000%
[Application Data Conversion Summary]
Datatype                    Changeless      Convertible       Truncation            Lossy
VARCHAR2                     2,550,581                0                0                0
CHAR                                 0                0                0                0
LONG                                 0                0                0                0
CLOB                            22,187            8,287                0                0
VARRAY                               0                0                0                0
Total                        2,572,768            8,287                0                0
Total in percentage             99.679%           0.321%           0.000%           0.000%
[Distribution of Convertible, Truncated and Lossy Data by Table]
Data Dictionary Tables:
USER.TABLE                                              Convertible       Truncation            Lossy
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                                             5                0                0
SYS.METASTYLESHEET                                              179                0                0
SYS.RULE$                                                         1                0                0
SYS.SCHEDULER$_EVENT_LOG                                        356                0                0
SYS.WRH$_SQLTEXT                                                537                0                0
SYS.WRH$_SQL_PLAN                                               514                0                0
SYS.WRI$_ADV_DIRECTIVE_META                                       5                0                0
SYS.WRI$_ADV_OBJECTS                                             28                0                0
SYS.WRI$_ADV_SQLT_PLANS                                           2                0                0
SYS.WRI$_ADV_SQLT_PLAN_STATS                                      2                0                0
SYS.WRI$_DBU_FEATURE_METADATA                                   193                0                0
SYS.WRI$_DBU_FEATURE_USAGE                                        9                0                0
SYS.WRI$_DBU_HWM_METADATA                                        21                0                0
SYS.WRI$_REPT_FILES                                              27                0                0
SYSMAN.MGMT_IP_ELEM_DEFAULT_PARAMS                              130                0                0
SYSMAN.MGMT_IP_REPORT_ELEM_PARAMS                             1,475                0                0
SYSMAN.MGMT_IP_SQL_STATEMENTS                                    31                0                0
XML CSX Dictionary Tables:
USER.TABLE                                              Convertible       Truncation            Lossy
Application Data:
USER.TABLE                                              Convertible       Truncation            Lossy
APEX_030200.WWV_FLOW_BANNER                                      10                0                0
APEX_030200.WWV_FLOW_BUTTON_TEMPLATES                            12                0                0
APEX_030200.WWV_FLOW_CUSTOM_AUTH_SETUPS                          19                0                0
APEX_030200.WWV_FLOW_FLASH_CHART_SERIES                           5                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES                             298                0                0
APEX_030200.WWV_FLOW_PAGE_GENERIC_ATTR                           44                0                0
APEX_030200.WWV_FLOW_PAGE_PLUGS                               3,240                0                0
APEX_030200.WWV_FLOW_PAGE_PLUG_TEMPLATES                        254                0                0
APEX_030200.WWV_FLOW_PROCESSING                                  45                0                0
APEX_030200.WWV_FLOW_ROW_TEMPLATES                               66                0                0
APEX_030200.WWV_FLOW_SHORTCUTS                                   39                0                0
APEX_030200.WWV_FLOW_STEPS                                    1,795                0                0
APEX_030200.WWV_FLOW_STEP_PROCESSING                          2,238                0                0
APEX_030200.WWV_FLOW_TEMPLATES                                  192                0                0
APEX_030200.WWV_FLOW_WORKSHEETS                                  30                0                0
[Distribution of Convertible, Truncated and Lossy Data by Column]
Data Dictionary Tables:
USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
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                                   5                0                0
SYS.METASTYLESHEET|STYLESHEET                                   179                0                0
SYS.RULE$|CONDITION                                               1                0                0
SYS.SCHEDULER$_EVENT_LOG|ADDITIONAL_INFO                        356                0                0
SYS.WRH$_SQLTEXT|SQL_TEXT                                       537                0                0
SYS.WRH$_SQL_PLAN|OTHER_XML                                     514                0                0
SYS.WRI$_ADV_DIRECTIVE_META|DATA                                  5                0                0
SYS.WRI$_ADV_OBJECTS|ATTR4                                       28                0                0
SYS.WRI$_ADV_SQLT_PLANS|OTHER_XML                                 2                0                0
SYS.WRI$_ADV_SQLT_PLAN_STATS|OTHER                                2                0                0
SYS.WRI$_DBU_FEATURE_METADATA|INST_CHK_LOGIC                     22                0                0
SYS.WRI$_DBU_FEATURE_METADATA|USG_DET_LOGIC                     171                0                0
SYS.WRI$_DBU_FEATURE_USAGE|FEATURE_INFO                           9                0                0
SYS.WRI$_DBU_HWM_METADATA|LOGIC                                  21                0                0
SYS.WRI$_REPT_FILES|SYS_NC00005$                                 27                0                0
SYSMAN.MGMT_IP_ELEM_DEFAULT_PARAMS|VALUE                        130                0                0
SYSMAN.MGMT_IP_REPORT_ELEM_PARAMS|VALUE                       1,475                0                0
SYSMAN.MGMT_IP_SQL_STATEMENTS|SQL_STATEMENT                      31                0                0
XML CSX Dictionary Tables:
USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
Application Data:
USER.TABLE|COLUMN                                       Convertible       Truncation            Lossy
APEX_030200.WWV_FLOW_BANNER|BANNER                               10                0                0
APEX_030200.WWV_FLOW_BUTTON_TEMPLATES|TEMPLATE                   12                0                0
APEX_030200.WWV_FLOW_CUSTOM_AUTH_SETUPS|AUTH_FUNC                 8                0                0
APEX_030200.WWV_FLOW_CUSTOM_AUTH_SETUPS|PAGE_SENT                10                0                0
APEX_030200.WWV_FLOW_CUSTOM_AUTH_SETUPS|POST_AUTH                 1                0                0
APEX_030200.WWV_FLOW_FLASH_CHART_SERIES|SERIES_QU                 5                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|ITEM_TEMPLATE                20                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|ITEM_TEMPLATE                20                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|LIST_TEMPLATE               105                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|LIST_TEMPLATE               105                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|SUB_LIST_ITEM                12                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|SUB_LIST_ITEM                12                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|SUB_TEMPLATE_                12                0                0
APEX_030200.WWV_FLOW_LIST_TEMPLATES|SUB_TEMPLATE_                12                0                0
APEX_030200.WWV_FLOW_PAGE_GENERIC_ATTR|ATTRIBUTE_                44                0                0
APEX_030200.WWV_FLOW_PAGE_PLUGS|PLUG_SOURCE                   3,240                0                0
APEX_030200.WWV_FLOW_PAGE_PLUG_TEMPLATES|TEMPLATE               166                0                0
APEX_030200.WWV_FLOW_PAGE_PLUG_TEMPLATES|TEMPLATE                88                0                0
APEX_030200.WWV_FLOW_PROCESSING|PROCESS_SQL_CLOB                 45                0                0
APEX_030200.WWV_FLOW_ROW_TEMPLATES|ROW_TEMPLATE1                 54                0                0
APEX_030200.WWV_FLOW_ROW_TEMPLATES|ROW_TEMPLATE2                 10                0                0
APEX_030200.WWV_FLOW_ROW_TEMPLATES|ROW_TEMPLATE3                  2                0                0
APEX_030200.WWV_FLOW_SHORTCUTS|SHORTCUT                          39                0                0
APEX_030200.WWV_FLOW_STEPS|HELP_TEXT                          1,513                0                0
APEX_030200.WWV_FLOW_STEPS|HTML_PAGE_HEADER                     282                0                0
APEX_030200.WWV_FLOW_STEP_PROCESSING|PROCESS_SQL_             2,238                0                0
APEX_030200.WWV_FLOW_TEMPLATES|BOX                               64                0                0
APEX_030200.WWV_FLOW_TEMPLATES|FOOTER_TEMPLATE                   64                0                0
APEX_030200.WWV_FLOW_TEMPLATES|HEADER_TEMPLATE                   64                0                0
APEX_030200.WWV_FLOW_WORKSHEETS|SQL_QUERY                        30                0                0
[Indexes to be Rebuilt]
USER.INDEX on USER.TABLE(COLUMN)
APEX_030200.WWV_FLOW_WORKSHEETS_UNQ_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(SYS_NC00078$)
APEX_030200.WWV_FLOW_WORKSHEETS_UNQ_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(SYS_NC00079$)
APEX_030200.WWV_FLOW_WORKSHEETS_UNQ_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(SYS_NC00080$)
APEX_030200.WWV_FLOW_WORKSHEETS_UNQ_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(SYS_NC00081$)
APEX_030200.WWV_FLOW_WS_UNQ_ALIAS_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(SYS_NC00082$)
APEX_030200.WWV_FLOW_WS_UNQ_ALIAS_IDX on APEX_030200.WWV_FLOW_WORKSHEETS(ALIAS)
----------------------------------------------------------------------------------We followed few metalink documents *Solving Convertible or Lossy data in Data Dictionary objects reported by Csscan when changing the NLS_CHARACTERSET [ID 258904.1]* and found that we are good to go as convertible was found only in data dictionary and that too CLOB data. But while running csalter.plb csalter came out without changing the characterset. We ran the following query given the said document and it returned no rows which again confirms there is no problem and go ahead with running csalter.
SELECT DISTINCT z.owner_name
|| '.'
|| z.table_name
|| '('
|| z.column_name
|| ') - '
|| z.column_type
|| ' - '
|| z.error_type
|| ' ' NotHandledDataDictColumns
FROM csmig.csmv$errors z
WHERE z.owner_name IN
(SELECT DISTINCT username FROM csmig.csm$dictusers
) minus
SELECT DISTINCT z.owner_name
|| '.'
|| z.table_name
|| '('
|| z.column_name
|| ') - '
|| z.column_type
|| ' - '
|| z.error_type
|| ' ' DataDictConvCLob
FROM csmig.csmv$errors z
WHERE z.error_type ='CONVERTIBLE'
AND z.column_type = 'CLOB'
AND z.owner_name IN
(SELECT DISTINCT username FROM csmig.csm$dictusers
ORDER BY NotHandledDataDictColumns
/Sorry to have made the thread so big but to make sure and give a complete picture of the issue pasted the csscan contents. Request the PRO's to help us in this issue.

You have convertible data in the application tables. CLOB or not, such data prevents csalter.plb from changing the character set.
You are on 11.2.0.3, so use the DMU (http://www.oracle.com/technetwork/products/globalization/dmu/overview/index.html). It can cope with such data.
-- Sergiusz

Oracle11g: how I change character set to AL32UTF8?

Hi, a software is requiring to have a database with AL32UTF8 character set.
For what I understand I have an instance of db with
nls_language=american
I tried:
SQL> alter database character set AL32UTF8;
alter database character set AL32UTF8
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
what's wrong? How can I achieve this?
Thanks a lot.
Warning: you are talking with a non expert. :)

802428 wrote:
Hi schavali,
I am new bee to oracle and BPM so i am unable to get which database you are talking about to drop & recreate and also how to do so.
Any help over this will be highly appreciable.
Regards,
ITM CrazyWe are referring to OP's database (where the characterset is set to WE8MSWIN1252)
Srini

WE8MSWIN1252 && AL32UTF8

Similar Messages

Maybe you are looking for