Query distributed database with different character sets.

Hello experts, this is my situation:
I have two databases A and B, the same version 11.1.0.7, the same OS Suse Linux Enterprise 10 but with different character sets, A has WE8MSWIN1252 while B has AL32UTF8. The database B is my XML DB repository so there I have some XML type tables. I need to query this tables from the database A using a dblink and in fact I have done that but the XML content is trasformed due to the different character sets between the databases. Some time there are data loss and some time there are data missmatch.
Is there any way to query the tables stored in the database B without problems? I do not know if the following is correct: Maybe I can set the character set for the session in the database A during the time it query the database B. That is, change the character set in fly at session level.
Do you have any special suggestion?
I hope you can help me, thank you in advance.

The Globalization Support Guide for 11.1.0.7 has a chapter on character set migration that should be helpful. AL32UTF8 is a superset of WE8MSWIN1252 but it is not a strict superset. That is, it doesn't meet the second prong of the test in the documentation
The new character set is a strict superset of the current character set if:
Each and every character in the current character set is available in the new character set.
Each and every character in the current character set has the same code point value in the new character set. For example, many character sets are strict supersets of US7ASCII.Exporting the data from the A, changing the character set (or creating a new database with the AL32UTF8 character set), and then importing the data may be the easiest approach in your case.
Justin
Edited by: Justin Cave on Jan 13, 2011 12:08 PM

Similar Messages

  • Transport tablespaces between databases with different character sets

    Hi everyone:
    I have two 10R2 databases on the same hp-ux 64bit server, 1st one with NLS_CHARACTERSET=US7ASCII, 2nd one with
    NLS_CHARACTERSET=AL32UTF8.
    NLS_NCHAR_CHARACTERSET on both databases is AL16UTF16.
    Can I transfer tablespaces from the 1st one to the 2nd. The data could be in English, French & Spanish.
    If not what are my options?
    Thanks in advance.

    First off, if you are storing French and Spanish data in database 1 where the character set is US7ASCII, you've got some serious problems. US7ASCII doesn't support non-English characters (accents, tildes, etc). If you're storing data this way, you've introduced data corruption that you'd have to resolve before copying the data data over to another machine.
    Second, technically, the source and target character set have to be identical. Since US7ASCII is a strict binary superset of AL32UTF8, you could theoretically transport a US7ASCII tablespace to an AL32UTF8 database. In your case, though, since the data is not really US7ASCII, you'd end up with corruption.
    Any of the Oracle built-in replication options is going to require that you resolve the corruption issue. Assuming that you can figure out what character set the source database really is, you could potentially dump the data to flat files (taking care not to allow character set conversion to take place) and SQL*Loader them into the destination system by identifying the proper character set in your control file. That's obviously going to be a rather laborious process, though.
    Justin

  • NLS settings for a database link between DBs with different character sets

    I am using a database link to move data from one database to another and I am seeing some strange data problems. The databases have different character sets and different NLS settings. I wonder if this could be causing my problem.
    Here are the NLS parameters for the database where the database link exists. (the SOURCE database)
    1     NLS_CALENDAR     GREGORIAN
    2     NLS_CHARACTERSET     WE8MSWIN1252
    3     NLS_COMP     BINARY
    4     NLS_CURRENCY     $
    5     NLS_DATE_FORMAT     DD-MON-RR
    6     NLS_DATE_LANGUAGE     AMERICAN
    7     NLS_DUAL_CURRENCY     $
    8     NLS_ISO_CURRENCY     AMERICA
    9     NLS_LANGUAGE     AMERICAN
    10     NLS_LENGTH_SEMANTICS     BYTE
    11     NLS_NCHAR_CHARACTERSET     AL16UTF16
    12     NLS_NCHAR_CONV_EXCP     FALSE
    13     NLS_NUMERIC_CHARACTERS     .,
    14     NLS_SORT     BINARY
    15     NLS_TERRITORY     AMERICA
    16     NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
    17     NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
    18     NLS_TIME_FORMAT     HH.MI.SSXFF AM
    19     NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
    Here are the NLS parameters for the database that the database link connects to. (the TARGET database)
    1     NLS_CALENDAR     GREGORIAN
    2     NLS_CHARACTERSET     AL32UTF8
    3     NLS_COMP     BINARY
    4     NLS_CURRENCY     $
    5     NLS_DATE_FORMAT     DD-MON-RR
    6     NLS_DATE_LANGUAGE     AMERICAN
    7     NLS_DUAL_CURRENCY     $
    8     NLS_ISO_CURRENCY     AMERICA
    9     NLS_LANGUAGE     AMERICAN
    10     NLS_LENGTH_SEMANTICS     BYTE
    11     NLS_NCHAR_CHARACTERSET     AL16UTF16
    12     NLS_NCHAR_CONV_EXCP     FALSE
    13     NLS_NUMERIC_CHARACTERS     .,
    14     NLS_SORT     BINARY
    15     NLS_TERRITORY     AMERICA
    16     NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AM
    17     NLS_TIMESTAMP_TZ_FORMAT     DD-MON-RR HH.MI.SSXFF AM TZR
    18     NLS_TIME_FORMAT     HH.MI.SSXFF AM
    19     NLS_TIME_TZ_FORMAT     HH.MI.SSXFF AM TZR
    The SOURCE database version is 10g Release 10.2.0.3.0 - Production
    The TARGET database version is 11g Release 11.1.0.6.0 - 64bit Production
    Do I need to modify the NLS settings in the SOURCE database before executing a script to insert data into the TARGET database?
    Thanks, Jack

    The difference in settings is not a problem by itself, especially that only the NLS_CHARACTERSET matters. Of course, this difference may lead to certain issues if not taken into consideration.
    Please, describe symptoms of your problems.
    -- Sergiusz

  • Searching with different character sets

    Hello,
    we have a problem with Intermedia 8.1.6. running on Solaris.
    The table contains the text with different character sets and that's the problem. User submits the query in his char.set and the IM sometimes doesn't find the data.
    Idea is to create the index using the flat ascii chars and to search in ascii ... but how?
    Can anybody help me?
    Thanks.
    Zozzi
    null

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Zozzi ([email protected]):
    sorry, wrong email in the prev msg ...
    this one is correct<HR></BLOCKQUOTE>
    Hello,
    Did you solve it ?
    If yes, how to do it. I am interested in knowing it.
    Many Thanks
    null

  • Can't Create Database with SJISYEN character set

    I am trying to create a new database in Oracle 10g using the SJISYEN character set. The summary page display in the Database Configuration wizard shows the following
    Character Sets
    Database Character Set JA16SJISYEN
    National Character Set AL16UTF16
    The database gets created successfully with no errors, but when I query the V$NLS_PARAMETERS view, the NLS_CHARACTERSET is reported as US7ASCII
    Should I be able to create a database with the SJISYEN character set with Oracle 10g?

    Can you please run the following SQL statement and see what you get:
    SQL>
    1 select * from nls_database_parameters
    2* where parameter like '%CHARACTERSET'

  • Migrating from 8.1.7 to 9.2 with different character set

    Are there going to be issues when I try to migrate from 8.1.7 to 9.2 where the character set in the 8i database was the default western european to utf8 in 9i?
    I ran the 8i scan utility to see if there would be issues importing into an 8i db with a different char set and it said that there would.

    Hi Jim,
    As your first step, I would recommend reading the white paper Character Set Migration Best Practices for Oracle9i on the Globalization Support Home page - http://otn.oracle.com/tech/globalization/index.html
    Since you mentioned that CSSCAN has already reported there are potential issues (I guess you have exceptional/Lossy data ?), I would strongly recommend splitting up the UTF8 character set change and the database version upgrade into 2 distant phrases. Probably moving to UTF8 in 8.1.7 first, then upgrading to 9.2 later.
    BTW, there is a separate Globlization Support and NLS discussion forum on OTN for further discussion on character set related issues.
    Nat

  • 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

  • Issue with MView betweem DB's with different character sets

    source system is char set IS0-8859-15.
    BUT - there is some data in the db that is outside the range of ISO - values are between 128 and 159 decimal. - The data is valid in teh Windows-1252 charset but its not valid ISO.
    target is utf-8
    Current issue is value in source system is 232 (x84). Thiis is lower double quotation mark, but not valid iso character.
    After mview replicates the value, it is xC284. This is not a valid utf8 encoded value.
    Correct value in utf-8 would be xE2809E (unicode 201E).
    Any suggestions on how to get the mviuew to recognize windows-1252 characters, even though the charset of the database is iso?

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Zozzi ([email protected]):
    sorry, wrong email in the prev msg ...
    this one is correct<HR></BLOCKQUOTE>
    Hello,
    Did you solve it ?
    If yes, how to do it. I am interested in knowing it.
    Many Thanks
    null

  • Different Character sets?

    Oracle version: 11.1.0.7.0
    There are any problems if I configure an Oracle Streams Replication between to database with different character set? I have configured a propagation between two database A and B. The A character set is WE8MSWIN1252 and the B character set is WEISO8859P1 but when the propagation passes about 30 minutes configured and ora-07445 begin. Also when I do the same configuration between two database with the same character set the problems does not appear.
    Here I write the error in the alert log:
    ORA-07445: se ha encontrado una excepción: volcado de memoria [kohrsmc()+1484] [SIGSEGV] [ADDR:0x18] [PC:0x7CCC92E] [Address not mapped to object] []
    Incident details in: /opt/oracle/diag/rdbms/bdmdic/bdmdic2/incident/incdir_110004/bdmdic2_j000_18185_i110004.trc
    Fri Aug 06 16:57:31 2010
    Trace dumping is performing id=[cdmp_20100806165731]
    Exception [type: SIGILL, Illegal operand] [ADDR:0x2ACE05EEFE60] [PC:0x2ACE05EEFE60, {empty}]
    Errors in file /opt/oracle/diag/rdbms/bdmdic/bdmdic2/trace/bdmdic2_j000_18185.trc (incident=110005):
    ORA-07445: se ha encontrado una excepción: volcado de memoria [PC:0x2ACE05EEFE60] [SIGILL] [ADDR:0x2ACE05EEFE60] [PC:0x2ACE05EEFE60] [Illegal operand] []
    ORA-07445: se ha encontrado una excepción: volcado de memoria [kohrsmc()+1484] [SIGSEGV] [ADDR:0x18] [PC:0x7CCC92E] [Address not mapped to object] []
    Incident details in: /opt/oracle/diag/rdbms/bdmdic/bdmdic2/incident/incdir_110005/bdmdic2_j000_18185_i110005.trc

    Where did I said that charset is interfering in propogataion? It will not interfere. Char set difference will cause the target database populated with data which it may not understand and will show you as garbage data. As you replication is working find without an issue for sometime, so it looks like you are hitting some bug when you hit replication for some specific data. To confirm this you may have to work with Oracle to find the exact cause or which bug you may be hitting.
    All my suggestions till this point in time is without knowing your proper environment (Server A,B OS and database version, also the error description except english words are all foreign to me). As suggested you will be better off working with Oracle support to find the resolution. Please let us know what fixed your issue when you work with Oracle to help all forum members.
    Regards

  • Different character sets on database links

    Does someone know, how to select data from different machines with different character sets via database link transferring the umlauts correctly ?
    The destination instance uses we8iso8859p1, the source machines have us7ascii (SAP) or we8iso8859p1. It is NOT allowed to change the character sets on the source databases!

    This is not so easy to solve. The correct procedure is to fix your non-ASCII database to reflect the correct character set encoding of your data. Have you checked with SAP to see whether it is really not possible/supported to change the application db character set ?
    The only workaround that I can think of ,is to create another database with 'WE8ISO8859P1' as the db character set. Populate it with the data you need from your SAP database using either SQL*LOADER or from insert statements generated by SPOOLing out the data using SQL*PLUS

  • Import dump from a satabase with a different character set

    My database has this character set:
    select * from database_properties:
    NLS_CHARACTERSET     AL32UTF8     Character set
    NLS_NCHAR_CHARACTERSET     AL16UTF16     NCHAR Character set
    I need to import a dump from a database with WE8MSWIN1252 character set.
    After the import I have seet that some character in the table are wrog:
    I see this simbol " " insted of this "à".
    How can I solve the problem?
    The nls_lang variable on my os is: NLS_LANG=ITALIAN_ITALY.AL32UTF8
    I work with oracle 10.0.4 on linux
    Message was edited by:
    user613483

    I have read thos doc on metalink: Note:227332.1
    I also tried to set nls_lang = NLS_LANG=ITALIAN_ITALY.WE8MSWIN1252
    and then I execute the import command.
    BUt didn't work.

  • Expdp with network_link and different character sets for source and target?

    DB versions 10.2 and 10.1
    Is there any limitation for implementing expdp with network_link but target and source have different character sets?
    I tried with many combinations, but only had success when target and source have the same character sets. In other combinations there was invalid character set conversion (loose of some characters in VARCHAR2 and CLOB fields).
    I didn't find anything on the internet, forums or Oracle documentation. There was only limitation for transportable tablespace mode export (Database Utilities).
    Thanks

    Hi DBA-One
    This link
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14215/dp_overview.htm#CEGFCFFI
    is from Database Utilities 10g Release 2 (10.2) (I read it many times)
    There is only one thing about different character sets.
    I quote:
    Data Pump supports character set conversion for both direct path and external tables. Most of the restrictions that exist for character set conversions in the original Import utility do not apply to Data Pump. The one case in which character set conversions are not supported under the Data Pump is when using transportable tablespaces.
    Parameter VERSION also doesn't play role here, because the behaviour (character set) is the same if I use for target and source only 10.2 or (10.2 and 10.1) respectivly.

  • Different Character sets (Codepages) in the same Login

    Hi,
    I need to enter different character sets (Russian and English) in the same login and save the different characters to SAP database tables.
    The codepage for Russian is different from English codepage. I have Russian codepage language settings on both Windows and SAP. Can anybody let me know how to proceed with this.
    Any pointers on this would be really helpful.
    Thanks and Regards,
    Sirisha

    Hi,
    I need to enter different character sets (Russian and English) in the same login and save the different characters to SAP database tables.
    The codepage for Russian is different from English codepage. I have Russian codepage language settings on both Windows and SAP. Can anybody let me know how to proceed with this.
    Any pointers on this would be really helpful.
    Thanks and Regards,
    Sirisha

  • Importing from a different character set

    Oracle 8.1.7 / Windows NT
    I'm trying to import a dump file which was created with character set WE8ISO8859P9. My database uses character set UTF8. Some of the records can't be inserted because of error "ORA-1401: Value too large for column". Is this because of the different character sets? If I switch my session to WE8ISO8859P9, imp says "character set conversion from x to y not supported."
    How can I get these last records inserted? Here's an excerpt from the log:
    Verbunden mit: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
    With the Partitioning option
    JServer Release 8.1.7.0.0 - Production
    <
    Export-Datei wurde von EXPORT:V08.00.05 |ber konventionellen Pfad erstellt
    Warnung: Die Objekte wurden von NOC_ADMIN exportiert, nicht von Ihnen.
    Importvorgang mit Zeichensatz WE8ISO8859P9 und Zeichensatz UTF8 NCHAR durchgef|hrt
    Import-Server verwendet Zeichensatz UTF8 (mvgliche Zeichensatzkonvertierung)
    Export-Server verwendet Zeichensatz WE8ISO8859P9 NCHAR (mvgliche Zeichensatzkonvertierung)
    . Import NOC_ADMIN's Objekte in NOC_ADMIN
    . . Import der Tabelle "ACCESSROUTERIFS_" 782 Zeilen importiert
    . . Import der Tabelle "ITEM_"
    IMP-00019: Zeile zur|ckgewiesen aufgrund von Oracle-Fehler 1401
    IMP-00003: Oracle-Fehler 1401 gefunden
    ORA-01401: Eingef|gter Wert zu gro_ f|r Spalte
    Spalte 1 33886
    Spalte 2
    Spalte 3
    Spalte 4 1323
    Spalte 5
    Spalte 6 11
    Spalte 7 18600
    Spalte 8 18600
    Spalte 9 20-NOV-2000:00:00:00
    Spalte 10 processing
    Spalte 11 inactive
    Spalte 12
    Spalte 13
    Spalte 14 35682.0
    Spalte 15
    Spalte 16
    Spalte 17
    Spalte 18 05.12.00: KD weiss noch nix neues, er wird uns inf...
    Spalte 19
    Spalte 20 kschmid
    Spalte 21 09-FEB-2001:15:50:21
    Spalte 22
    Spalte 23 12
    Spalte 24
    Spalte 25 06-NOV-2000:00:00:00
    null

    Please try ORacle RDBMS support. this issues is to do with Oracle Import.

  • Unable to copy database with different name in the same instance

    I had a huge database and wanted to try some change optimization changes.
    So wanted to make a copy of the database along with data in the same instance.
    I have tried copy database wizard several times but always see the error as in attachment.
    Can someone let me know how to troubleshoot further?
    If this is not the correct way please suggest how do i copy a database with different name in the same instance along with data.

    Hi Nandu,
    From the screenshot, the error 1813 happens when corrupt database log is attempted to attach to the SQL Server. To work around this issue, please preform the following steps, for more details, please review this
    blog.
    1. Create a new database with same name which you want to recover. Make sure that the MDF file and LDF file have same name with previous database data and log file.
    2. Stop SQL Server. Move original MDF file from old location to new location by replacing just created MDF file. Delete the LDF file of new location just created.
    3. Start SQL Server. At this point, the database is in suspect status.
    4. Make sure that system tables of Master database allows to update the values. Please note that you will be performing this in query window.
    Use Master
    go
    sp_configure 'allow updates',1
    reconfigure with override
    go
    5. Change database mode to emergency mode.
    SELECT *
    FROM sysdatabases
    WHERE name = 'DatabaseName'
    BEGIN
    UPDATE sysdatabases
    SET status = 32768
    WHERE name = ' DatabaseName '
    COMMIT TRAN
    6. Restart SQL Server. Then execute the following DBCC command in query window to create new log file.
    DBCC TRACEON (3604)
    DBCC REBUILD_LOG(databasename,'c:\yourdatabasename_log.ldf')
    GO
    7. Reset the database status using following command.
    sp_RESETSTATUS yourdatabasename
    GO
    8. Turn off the update to system tables of Master database running following script.
    USE MASTER
    GO
    sp_CONFIGURE 'allow updates',0
    RECONFIGURE WITH OVERRIDE
    GO
    9. Reset the database status to previous status.
    BEGIN
    UPDATE sysdatabases
    SET status = (value retrieved in first query of step 5)
    WHERE name = 'DatabaseName‘
    COMMIT TRAN
    GO
    Make sure that you have done all the steps in order and restarted SQL Server where it is mentioned. Also run SQL Server Management Studio as administrator.(Right click-> Run as Administrator)
    Thanks,
    Lydia Zhang

Maybe you are looking for