Charecter set problem - WE8MSWIN1252 Vs. UTF8 ...!!!!!

Hello,
My database is in UTF8 character set. Bu while I export it, it exported like below -
" Export done in WE8MSWIN1252 character set and UTF8 NCHAR character set
server uses UTF8 character set (possible charset conversion) "
So I think the primary character set is WE8MSWIN1252.
Hence my query is
1. Is there any impact while importing the dump.
2. User need only UTF8 character set, so if I set NLS character set as UTF8 and then import it, will it do the correct import, or it will change the expected result.
3. In the above situation, do i need to follow below steps -
c:> set NLS_LANG=ENGLISH.UTF8
then do export
Regards,
Subir

I recommend you upgrade at least to 10.1.0.5. 10.1.0.2 comes with the very first version of csalter.plb, which has not the current implementation. From and to which character set do you try to migrate?
-- Sergiusz

Similar Messages

Convert characterset WE8MSWIN1252 to UTF8

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

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

DB Creation(character set Problem)

HI,
I am in the process of creating new database from the full export dump file which i got from client. In the export logfile i can see,
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
I am creating the database manually at my site and planning to import that full export dumpfile from the client.
Do i need to create the DB with national character set WE8MSWIN1252 or can i also use character set as AL32UTF8
I want to se the correct character set so that my import doesn't fails because of charactor set problem.
Please help me.
Oracle Version At client site:9.2.0.1
OS :Windows
Oracle Version at my site:9.2.0.1
OS:LINUX
Thank You..

I can't answer your question because of several things.
The first is that all versions of 9i are currently in desupport and it has been years since I've seen one.
But if I was forced to work with 9i I certainly wouldn't do anything at all until I had patched to 9.2.0.8.
My recommendation would be, unless someone else can help you, to try it and see what happens.
Nothing ventured nothing gained.

Agent control character set problem

Hi,
here's my problem :
i've got the grid that's running on a RHES4 with an agent. On another RHES4, i've got 10g databases that run and another agent.
The repository database is configured like this :
nsl_language = AMERICAN
nls_territory = AMERICA
character set = AL32UTF8
all the uploads from the agent on the RHES4 where the grid is installed are ok.
On the other server, as soon as there's an UTF8 character in a xml file (like " é " ou " ' "), the upload fails and the agent stops.
in the logs, it s clear it comes from this. I've deleted all the occurences of UTF8 characters in the xml file and restarted the upload and it's ok...
I've tested different configurations but without success.
Any clue ?
Alivetu

Thanks for the reply,
NLS LANG is set on the 2 machines with FRENCHFRANCE.WE8ISO8859P15
I've added the line '<?xml version="1.0" encoding="ISO-8859-1"?>' at the beginning of the xml file that doesn't work and made a 'emctl upload'....it has passed and the agent has stopped arrived to another UTF8 xml file...
So, it really is a character set problem but where to set it ???
Alivetu

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

Backup failure due to Character set problem

Hi,
I am manually running a COLD backup script in Windows NT environment and all the logs has been captured below:
Recovery Manager: Release 8.1.6.0.0 - Production
RMAN-06005: connected to target database: db1 (DBID=754030292)
RMAN-06009: using target database controlfile instead of recovery catalog
RMAN> shutdown immediate;
2> startup mount;
3> RUN {
4> ALLOCATE CHANNEL disk1 TYPE disk;
5> BACKUP DATABASE TAG 'db1_db_full' FORMAT 'e:\backup\db1\db1_backup';
6> copy current controlfile to 'e:\backup\db1\Control_db1.ctl';
7> }
8>
RMAN-06405: database closed
RMAN-06404: database dismounted
RMAN-06402: Oracle instance shut down
RMAN-06193: connected to target database (not started)
RMAN-06196: Oracle instance started
RMAN-06199: database mounted
Total System Global Area 934143244 bytes
Fixed Size 70924 bytes
Variable Size 260554752 bytes
Database Buffers 673439744 bytes
Redo Buffers 77824 bytes
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=13 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure during compilation of command
RMAN-03013: command type: backup
RMAN-06003: ORACLE error from target database: ORA-06550: line 1, column 166:
PLS-00553: character set name is not recognized
ORA-06550: line 0, column 0:
PL/SQL: Compilation unit analysis terminated
RMAN-06031: could not translate database keyword
Recovery Manager complete.
As the above log shown, I cannot do any backup command in the RUN bracket and it complains that the character set is not recognized.
This set of error happens when I have create six other Oracle databases in my NT box. Before that, I can manually run the backup with no problem and a backupset has been generated.
If you have come across this problem and have solutions of it. That will be great.
Thanks !!
null

kk001 wrote:
Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
I don't know what you have.
I don't know what you do.
I don't know what you see.
It is really, Really, REALLY difficult to fix a problem that can not be seen.
use COPY & PASTE so we can see what you do & how Oracle responds.
do as below so we can know complete Oracle version & OS name.
Post via COPY & PASTE complete results of
SELECT * from v$version;

Using translate function to correct character set problem....

I have a table(TBL_STOCK) on Oracle XE.
Rows come from sql server 2005 with a trigger on sql server table via the linked server.
But there is a character set problem with some character like İ,Ş,Ğ.
They change to Ý,Þ,Ð. in Oracle.
How can i correct these ? Do you suggest the TRANSLATE function ?
What do u think, if i create an After Insert trigger on Oracle table(TBL_STOCK) and convert these character using the Translate function when they inserted from sql server.
Anyone have any other ideas that can be more efficient. Any thoughts appreciated.
Thanks in advance.
Adam
PS:The NLS_CHARACTERSET of Oracle is AL32UTF8.

It is sql server 2005 and Collation is SQL_Latin1_General_CP1_CI_AS

I cannot run You Tube Videos on my Apple Macbook Air MD760HN/B with OS X 10.9.4. the video window displays a message " An error occurred, Please try again later." Learn more. The screen is black with this message. There appears to be some setting problem?

Macbook Air MD 760HN/B with OS X 10.9.4
4 GB RAM, 1.4 Ghz intel Core i5
Problem 1
I.     On Youtube whenever I try to play a video, I get a message on a black screen "An Error Occurred, Please Try Again later. Learn More."
2.   I think it is some setting problem, being a new mac user, I am unable to sort it out.
Problem 2.
How to select more than one file in a folder to copy or delete. like it can be done in Windows with shift Click together.
if one has to select say, file 25 to file 37 in a folder with 75 files. select all (command A) works but I cannot select few continuous files.

Macbook Air MD 760HN/B with OS X 10.9.4
4 GB RAM, 1.4 Ghz intel Core i5
Problem 1
I.     On Youtube whenever I try to play a video, I get a message on a black screen "An Error Occurred, Please Try Again later. Learn More."
2.   I think it is some setting problem, being a new mac user, I am unable to sort it out.
Problem 2.
How to select more than one file in a folder to copy or delete. like it can be done in Windows with shift Click together.
if one has to select say, file 25 to file 37 in a folder with 75 files. select all (command A) works but I cannot select few continuous files.

JDeveloper IDE simple setting problem

Hi,
Recently we switched to JDeveloper from Visual Cafe .I have a simple setting problem.How can I set the options so that IDE gives, the core java classes and packages,and our application classes and packeges, prompts in imports as well as in code.Where to set the options.
eg: when I write
import java. it should prompt all the pakages.
Thanks in advance.
-Gopal
null

I am not sure I understand what you are requesting, but ...
You can configure JDeveloper projects to include various libraries by default.
This is done by selecting menu Tools | Default Project Properties.../ Libraries tab.
You should define a library for your classes.
You can import any of the packages / classes from all the libraries which your project includes.
It would be incorrect for a tool to automatically add a bunch of import lines at the top of every file because each file should import what it needs and just as importantly, not import what it does not need depending on the component type (e.g. a servlet should not include javax.swing.* ).
An easy way to import elements into JDeveloper is to type in something like:
import java.
// and then type in Ctrl Space
and this launches the package browser, you can select packages or classes to import.
You can also do this at the variable declaratiton point such as typing in:
foo() {
Frame x
// Press Control Alt Space
and this will correctly change the type (Frame) to the type you select in the package browser and add the import statement.
-John
null

Reflection function is not working, unable to click on it at all. Need help! Setting problem?

Hi all, I seek for your kind expertise advise on my Keynote. Once I've chosen a slide to open, any type of slide at all, my Reflection button or function is unable to be clicked on to perform that function. However, Shadow function facing no problem.
I can see the Reflection button but it's blurred like not allowing me to click on it at all. Is this cause by some software problem? Or setting problem? iWork has just being installed.
Appreciate your expert advice and help!

Thanks Kelly... That's very helpful. Appreciate that very much!
By the way, if I may ask further, do you know how to how to make the animation like Steve Jobs did during his presentation on Ipad or Ipad2 where the "word" will drop from top onto the centre of the slide with effect or sort of like smoke or dust floating off and dissolved at both sides of the "word"?
Will be more than grateful to be hear from again! Cheers and thanks again.

Oracle 8i us7ascii character set problem - help required urgent.

Hi frnds,
I have a oracle 8i database server installed on sun solaris os. The database character set is us7ascii. In one of the tables TIFF images are stored in a long column. I m trying to fetch these images using oracle 9i client and visual basic(oracle ODBC drivers). But i m unable to do so. I can not fetch special characters.
Is it because of the character set problem? but when i run my code on the server itself, i m able to fetch the images. I tried to fetch the images using oracle 8 i client on windows XP machine but could not do so. Are there any special settings that i have to do on the client side?

Indeed, it's an ODBC issue. Read this statement from Oracle:
From ODBC 8.1.7.2.0 drivers onwards it's NOT possible any more to
"disable" Characterset conversion by specifying for the NLS_LANG
the same characterset as the database characterset. There is now
ALWAYS a check to see if a codepoint is valid for that characterset.
Typically you will encounter problems if you upgrade an environment
that has NO NLS_LANG set on the client (or US7ASCII) and the database
was also US7ASCII. This incorrect setup allowed you to store characters
like èçàé in an US7ASCII database, with the new 8i drivers this is not possible
any more.
Basic problem is the 'wrong' characterset US7ASCII in the database. As long as no characterset conversion happens (that's the case on the unix server), special characters are no problem.
Werner

Oracle character set problem - help reqed urgent !!

Hello frnds,
I have a oracle 8i database server installed on sun solaris os. The database character set is us7ascii. In one of the tables TIFF images are stored in a long column. I m trying to fetch these images using oracle 9i client and visual basic(oracle ODBC drivers). But i m unable to do so. I can not fetch special characters.
Is it because of the character set problem? but when i run my code on the server itself, i m able to fetch the images. I tried to fetch the images using oracle 8 i client on windows XP machine but could not do so. Are there any special settings that i have to do on the client side?

i run my code on the server itself, i m able to fetch
the images. I tried to fetch the images using oracle
8 i client on windows XP machine but could not do so.You able to fetch the image , So it is not because of the character set.
First thing you need to consider is that use certified combination of OS , client and database server only. Check Certify - Oracle's Certification Matrices
Virag

EXPORT Backup failing due to character set problem

Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
Regards,
kk
Edited by: kk001 on Aug 29, 2011 7:22 PM

kk001 wrote:
Hi ,
The export Backup failing due to character set problem
. . exporting table ravidlx
EXP-00008: ORACLE error 6552 encountered
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-553: character set name is not recognized
P
Please suggest how to set character set
I don't know what you have.
I don't know what you do.
I don't know what you see.
It is really, Really, REALLY difficult to fix a problem that can not be seen.
use COPY & PASTE so we can see what you do & how Oracle responds.
do as below so we can know complete Oracle version & OS name.
Post via COPY & PASTE complete results of
SELECT * from v$version;

Space Designer Save Setting Problems

Space Designer Save Setting Problems
On the right side of the space designer you have "dry" and "rev" settings.
On reopening the plug-in the dry setting switches back to zero, although I saved it at a different setting...
Everytime, every project...

Does it do this on audio/software instrument channels and aux channels?
In general, when you load SD on an aux channel, Logic assumes it's going to be an FX return and so "helps you out" by setting the dry level to zero for you...
On other channel types it should work as expected...

Charecter set invalid issue

I have installed a Oracle9.2.0.1 for Solaris8 that downloaded from OTN.
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
ORACLE_HOME=/export/home/OraHome1
ORACLE_SID=testdb
use default init.ora as inittestdb.ora,
SQLPLUS /nolog
CONNECT SYS/password AS SYSDBA
STARTUP NOMOUNT
SQL> CREATE DATABASE "testdb"
MAXINSTANCES 8
MAXLOGFILES 32
CHARACTER SET "UTF8"
NATIONAL CHARACTER SET "WE8ISO8859P1"
DATAFILE
'/u01/oradata/testdb/system01.dbf' SIZE 10M
DATAFILE
ERROR at line 6:
ORA-12714: invalid national character set specified

Error:       ORA-12714 (ORA-12714)
Text:       invalid national character set specified
Cause:     Only UTF8 and AL16UTF16 are allowed to be used as the national
     character set
Action:     Ensure that the specified national character set is valid The CHARACTER SET specifies the character set used to store data in this database.
NATIONAL CHARACTER SET specifies the character set used to store data in columns
specifically defined as NCHAR, NCLOB, or NVARCHAR2.
For more information see the Globalisation Guide
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2.htm#100779

Charecter set problem - WE8MSWIN1252 Vs. UTF8 ...!!!!!

Similar Messages

Maybe you are looking for