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.

Similar Messages

HT201250 How do you let time machine know that a restored drive does not need a brand new backup set and just append to the old one?

I had an external drive failure and had to buy a brand new drive. I was able to restore my info onto a new drive, about 1.5 TB of data. When I go to launch time machine now with the new drive connected and my backup connected, it treats the new drive as if it had different data and wants to create a whole new backup set when it should just append. How do I get around this?
I could just reformat the backup drive and start fresh again but would rather not do that if I can avoid it, just in case there were errors in copying etc.

Hi
I should have been more clear, sorry. I work from a laptop. I have 2 external drives - one for my projects which failed but has since been replaced and restored from a backup. My 2nd external drive is the time machine backup drive.
When my project drive crashed, I bought a brand new drive and restored it using my time machine backup drive.
Now the data exists on 2 drives - the time machine backup drive, and the new drive. When I connect the backup drive now, it thinks my new drive has new data, probably since it is a new device/drive, and wants to do a brand new backup, when in fact the data already exists on that very drive. It shouldn't have to back up all 1.5 TB when nothing has changed!
Unless there is a way to tell time machine to simply append to the old backup, I think it will try and do a new backup (1.5 TB). I'm thinking maybe I should just initialize my time machine backup drive now and start over so it is only one backup set of 1.5 TB instead of (2) sets of 1.5 TB!

Upgraded: New Mac, Setting up iPhoto Library From Multiple Old Backups

Over the years (Jaguar to Snow Leopard), I've had multiple Macs in different locations (work, home) to which I've loaded photos from cameras into multiple iPhoto libraries. As these Macs have died (G4s, G5s), or I've been forced to upgrade, I've made a backup on CDs and DVDs of the iPhoto libraries (different versions of iPhoto over the years).
Now I've got a brand new Macbook Pro and I want to put all these photos into one library on one disk. I don't care much about preserving photos edited in iPhoto (I use Photoshop for serious editing), nor do I have particular album or roll data from these old libraries that matters. I just want to get all the original photos into one library so I can search and access them all in one place.
I have always found the way iPhoto organizes the photos on disk a bit confusing, especailly when it comes to backing up and accessing the files at the Finder level. And now it seems things have gotten even more dumbed away from the user in "package" w/ the latest iPhoto.
I would like to just have my photos in a folder, not a "package," but I would like to be able to search and organize photos and load them to my iPod Touch. (Maybe isn't the best application for me?) I'd also like my iPhoto folder to be on an external HD.
This is one of those grueling tasks I've been putting off for years. So many disks, so many libraries, how to get them all into one. I want to get it right once and for all, so I'll have all my photos on in one place and hopefully in a Finder-level folder that will be easy to back up and easy to port to my next Mac down the road in the future.
Can anyone offer any advice on the best way to proceed? Anyone else been through something like this?
Thanks in advance,
Babz

This is actually more simple than it seems as you
just want to get all the original photos into one library so I can search and access them all in one place.
So, create a Library: Hold down the option (or alt) key key and launch iPhoto. From the resulting menu select 'Create Library' and import the contents of the originals from the other Libraries: (File -> Import, Drag to the iPhoto Window, Drag to the iPhoto icon on the Dock)
That's all your originals in a single Library.
I have always found the way iPhoto organizes the photos on disk a bit confusing, especailly when it comes to backing up and accessing the files at the Finder level.
It's actually quite straightforward, but the key is +you don't access the files at a Finder level+.
And now it seems things have gotten even more dumbed away from the user in "package" w/ the latest iPhoto.
Remember: iPhoto is a Database. Like any database, you need to manipulate the data via the db and not a back door.
Since iPhoto 7 (iLife 08) the old iPhoto Library Folder is now a Package File. This is simply a folder that looks like a file in the Finder. The change was made to the format of the iPhoto library because many users were inadvertently corrupting their library by browsing through it with other software or making changes in it themselves. That's why +you don't access the files at a Finder level+.
Want to see inside: Go to your Pictures Folder and find the iPhoto Library there. Right (or Control-) Click on the icon and select 'Show Package Contents'. A finder window will open with the Library exposed.
Standard Warning: Don't change anything in the iPhoto Library Folder via the Finder or any other application. iPhoto depends on the structure as well as the contents of this folder. Moving things, renaming things or otherwise making changes will prevent iPhoto from working and could even cause you to damage or lose your photos.
How the library is organised: There are various files, which are the Library itself and some ancillary files. Then you have three core folders
Originals are the photos as they were downloaded from your camera or scanner.
(ii) Modified contains edited pics, shots that you have cropped, rotated or changed in any way.
(iii) Data holds the thumbnails the the app needs to show you the photos in the iPhoto Window.
But none of that matters, as you never access the files via the Finder.
*To back up an iPhoto Library* make a copy of the Library on another disk. You can automate this process with Time Machine or many other back up apps like Chronosync or DejaVu. There are many, many other options. Search on MacUpdate.
I would like to just have my photos in a folder, not a "package,"
*How to do it:*
Simply go to iPhoto Menu -> Preferences -> Advanced and uncheck 'Copy Files to the iPhoto Library on Import'.
*What Happens:*
Now iPhoto will not copy the files, but rather simply reference them on your HD. To do this it will create an alias in the Originals Folder that points to your file. It will still create a thumbnail and, if you modify the pics, a Modified version within the iPhoto Library Folder.
*Some things to consider:*
1. Importing and deleting pics are more complex procedures. You have to to put the files where they will be stored before importing them. When you delete them you'll need to remove the files from the HD yourself.
2. You cannot move or rename the files on your system or iPhoto will lose track of them on systems prior to 10.5 and iPhoto 08. Even with the later versions issues can still arise if you move the referenced files to new volumes or between volumes.
3. Most importantly, migrating to a new disk or computer can be much more complex.
4. Because iPhoto has no tools for managing Referenced Files, if, for some reason, the path to the photos changes then you could find yourself resolving aliases for +each photo in the Library+ one by one.
My own opinion:
I've yet to see a good reason to run iPhoto in referenced mode unless you're using two photo organiser
If disk space is an issue, you can run an entire iPhoto Library from an external disk:
1. Quit iPhoto
2. Copy the iPhoto Library from your Pictures Folder to the External Disk.
3. Hold down the option (or alt) key while launching iPhoto. From the resulting menu select 'Choose Library' and navigate to the new location. From that point on this will be the default location of your library.
4. Test the library and when you're sure all is well, trash the one on your internal HD to free up space.
If you're concerned about accessing the files, There are many, many ways to access your files in iPhoto:
*For Users of 10.5 and later*
You can use any Open / Attach / Browse dialogue. On the left there's a Media heading, your pics can be accessed there. Command-Click for selecting multiple pics.
Uploaded with plasq's Skitch!
You can access the Library from the New Message Window in Mail:
Uploaded with plasq's Skitch!
*For users of 10.4 and later* ...
Many internet sites such as Flickr and SmugMug have plug-ins for accessing the iPhoto Library. If the site you want to use doesn’t then some, one or any of these will also work:
To upload to a site that does not have an iPhoto Export Plug-in the recommended way is to Select the Pic in the iPhoto Window and go File -> Export and export the pic to the desktop, then upload from there. After the upload you can trash the pic on the desktop. It's only a copy and your original is safe in iPhoto.
This is also true for emailing with Web-based services. However, if you're using Gmail you can use iPhoto2GMail
If you use Apple's Mail, Entourage, AOL or Eudora you can email from within iPhoto.
If you use a Cocoa-based Browser such as Safari, you can drag the pics from the iPhoto Window to the Attach window in the browser.
*If you want to access the files with iPhoto not running*:
For users of 10.6 and later:
You can download a free Services component from MacOSXAutomation which will give you access to the iPhoto Library from your Services Menu. Using the Services Preference Pane you can even create a keyboard shortcut for it.
For Users of 10.4 and later:
Create a Media Browser using Automator (takes about 10 seconds) or use this free utility Karelia iMedia Browser
Other options include:
1. *Drag and Drop*: Drag a photo from the iPhoto Window to the desktop, there iPhoto will make a full-sized copy of the pic.
2. *File -> Export*: Select the files in the iPhoto Window and go File -> Export. The dialogue will give you various options, including altering the format, naming the files and changing the size. Again, producing a copy.
3. *Show File*: Right- (or Control-) Click on a pic and in the resulting dialogue choose 'Show File'. A Finder window will pop open with the file already selected.
*To use iPhoto with Photoshop*
You can set Photoshop (or any image editor) as an external editor in iPhoto. (Preferences -> General -> Edit Photo: Choose from the Drop Down Menu.) This way, when you double click a pic to edit in iPhoto it will open automatically in Photoshop or your Image Editor, and when you save it it's sent back to iPhoto automatically. This is the only way that edits made in another application will be displayed in iPhoto.
Note that iPhoto sends a copy+ of the file to Photoshop, so when you save be sure to use the Save command, not Save As... If you use Save As then you're creating a new file and iPhoto has no way of knowing about this new file. iPhoto is preserving your original anyway.
There's a lot of material there. By all means come back for clarification if you need it. But I strongly urge you to think very carefully before running a Referenced Library.
Regards
TD

Ahhh! New iPod, setting up another library with my old iPod!

So, I got a new iPod5 to replace my old iPod4, and gave said iPod4 to my sister. How on Earth can I delete all the stuff from the iPod4 and set up a new library with it? I had no trouble Putting my iPod5 on MY library, but since my sister and I have VERY different music tastes, she has her own library on a different user name. Can anyone tell me how I can put this old iPod4 on that library?
Thanks in advance,
Kristina

Kristina,
Restoring your iPod does not delete iTunes. All they are saying is that as you are about to remove everything from your iPod make sure you have a back up. Common sense really. iPods are often restored as a method of troubleshooting problems so you want to make sure you have something to put back. You should back up iTunes as a matter of course especially if you have purchased downloads, your own CDs can always be re-added even if it's a pain but other stuff you can lose forever. Just for additional info, here's a link on the subject "How to back up your media in iTunes 5 or iTunes 6" http://docs.info.apple.com/article.html?artnum=302392

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

Character set AL32UTF8;

Hello All,
I have oracle 10gr2 and i want to get support of Portuguese character set, for that , i suppose AL32UTF8 is recommended, but when i try to modify the character set i get this error.
SQL> select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
VALUE
WE8ISO8859P1
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 should i do now? any idea?
thanks

here it is:
SQL> select news_detail from news_tbl;
NEWS_DETAIL
A Directora nacional-Adjunta do Patrim?nio ligado ao Minist?rio das Finan?as
de Mo?ambique, Albertina Fruquia, esteve nesta quarta-feira, do dia 22 de Novemb
ro, na Secretaria de Log?stica e Tecnologia de Informa??o ( SLTI )para conhecer
o sistema de compras do Governo Federal Brasileiro e verificar a possibilidade d
e estabelecer acordos de coopera??o nessa ?rea.
 
Na opini?o da Directora Mo?ambicana, o Brasil tem uma experi?ncia importante
em compras p?blicas que pode colaborar com Mo?ambique nesta ?rea. Ela lembrou qu
e o pa?s Africano est? imlpementando um novo regulamento de compras que constitu
i o preg?o presencial, modalidade regulamentada no Brasil desde 2000.
 
you can see that even in sqlplus the data is not shown the portugueses language chars, now what you think, that whether this data is stored wrong or either i can recover it by changing chars set or language?
Message was edited by:
nayyares
Message was edited by:
nayyares

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

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

Can i Change Character set WE8ISO8859P1 TO AR8MSWIN1256 IN ORACLE 8i

I tried to change character set from WE8ISO8859P1 TO AR8MSWIN1256 on oracle 8i database.
Getting the follwoing error for both character set and National character set.
ORA-12712:New character set must be a superset of old character set.
My question can i change or have to do export and import in arabic character set DB.
null

Hello Sarath,
There is an extension CODE PAGE with OPEN DATASET stmt.
Can you please elaborate which character set you want to write to the application server?
BR,
Suhas

How to change character set

hi my database character set is non-AL32UTF8 HOW can i change this to be AL32UTF8 am in database 11g
SQL> select * from v$nls_parameters where parameter like '%CHARACTERSET%';
PARAMETER
VALUE
NLS_CHARACTERSET
WE8MSWIN1252
NLS_NCHAR_CHARACTERSET
AL16UTF16
there is something in database i cannot drop database

i did this
SQL> @C:\app\Tshifhiwa\product\11.2.0\dbhome_1\RDBMS\ADMIN\csalter.plb
insert into csm$dictusers
ERROR at line 1:
ORA-00942: table or view does not exist
Function created.
Warning: Function created with compilation errors.
Warning: Procedure created with compilation errors.
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
 csm$main();
ERROR at line 10:
ORA-06550: line 10, column 5:
PLS-00905: object SYS.CSM$MAIN is invalid
ORA-06550: line 10, column 5:
PL/SQL: Statement ignored
 select value into svalue from csm$parameters where name='CSALTER_FINISHED';
ERROR at line 9:
ORA-06550: line 9, column 35:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 9, column 5:
PL/SQL: SQL Statement ignored
ORA-06550: line 18, column 35:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 18, column 5:
PL/SQL: SQL Statement ignored
ORA-06550: line 21, column 38:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 21, column 8:
PL/SQL: SQL Statement ignored
ORA-06550: line 27, column 35:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 27, column 5:
PL/SQL: SQL Statement ignored
ORA-06550: line 30, column 38:
PL/SQL: ORA-00942: table or view does not exist
ORA-06550: line 30, column 8:
PL/SQL: SQL Statement ignored
delete from csm$dictusers where username in ('PM', 'SH', 'HR', 'OE')
ERROR at line 1:
ORA-00942: table or view does not exist
Function dropped.
Function dropped.
Procedure dropped.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM ENABLE RESTRICTED SESSION
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ERROR:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
SQL> ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ERROR:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
ALTER SYSTEM SET AQ_TM_PROCESSES=0
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ERROR:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 4360
Session ID: 139 Serial number: 6
SQL> connect /as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size 1375792 bytes
Variable Size 373293520 bytes
Database Buffers 155189248 bytes
Redo Buffers 5804032 bytes
Database mounted.
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
System altered.
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
System altered.
SQL> ALTER SYSTEM SET AQ_TM_PROCESSES=0;
System altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL> ALTER DATABASE CHARACTER SET 'AL32UTF8';
ALTER DATABASE CHARACTER SET 'AL32UTF8'
ERROR at line 1:
ORA-24329: invalid character set identifier
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
SQL> select * from v$nls_parameters where parameter like '%CHARACTERSET%';
PARAMETER
VALUE
NLS_CHARACTERSET
WE8MSWIN1252
NLS_NCHAR_CHARACTERSET

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

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

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

Default character set

I installed the database 10.2.01 with basic installation (not advanced option).
what is the default charater set in the basic installation?
how to show character set in command line?
Can I change it to AL32UTF8?
like:
SQL>alter database character set AL32UTF8;
Thanks

thanks.
I'm using Linux
So default character is "WE8ISO8859P1".
But it seems I can not alter to AL32UTF8, which has the globalization support.
SQL> select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
VALUE
WE8ISO8859P1
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
----------------------

Change character set

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

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

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

Similar Messages

Maybe you are looking for