I have an exported data using exp command from a full Oracle 11gR2 database that has the AR8MSWIN1256 charset. However, when I import the data into an 11gR2 XE database, I get the error:
row rejected due to ORACLE error 12899
Could the problem be the mismatch in charsets (AL32UTF8 vs AR8MSWIN1256)? If so, is there a solution?
the table almost certainly has length semantics BYTE for the character columns. imp creates the table with the same length semantics as they were in the source database. So if you want to migrate to a multibyte character set you need to make sure that the length semantics of those columns are changed to character.
Easiest is to pre-create the tables and make sure that your column definitions don't specify their length in bytes but in characters.
Related
I am trying to import a .dmp file that was exported using Oracle Database 11g Enterprise Edition into Oracle 11g XE running on Windows 7 but I receive many errors like the following:
ORA-02374: conversion error loading table "SCHEMA"."TABLENAME"
ORA-12899: value too large for column COLNAME (actual: 90, maximum: 75)
The import command I use:
impdp system/pwd remap_schema=OLD_SCHEMA:NEW_SCHEMA tables=OLD_SCHEMA.Table1,OLD_SCHEMA.Table2 directory=DATA_PUMP_DIR dumpfile=mydump.dmp logfile=import.log exclude=grant,index,statistics
The charset of the dump file is WE8ISO8859P1 while my destination database is AL32UTF8
I read somewhere that Oracle 11g XE support AL32UTF8 only. Hence, I cannot alter this character set to match the source.
Is there any way I can import the dump file without getting the conversion errors?
Thanks
The problem is that some of the characters will take up more than one byte per character. You will need to change your database nls_length_semantics to 'CHAR' and redo the import. A step by step explanation is to be found here: http://albertolarripa.com/2012/06/10/ora-12899-changing-columns-to-char/
I'm trying to migrate Oracle data with 'we8mswin1252' encoding to my postgres database which has 'UTF8' encoding.
I'm using foreign data wrapper.
I'm getting
invalid byte sequence error
What should i do?
Such errors can be caused by two things:
There may be zero bytes in your Oracle strings. That is allowed in Oracle (even though it is problematic), but forbidden in PostgreSQL.
It is easy to get data corruption in Oracle, because it is pretty sloppy with encoding checks and allows you to insert arbitrary illegal byte sequences when client encoding and server encoding are the same.
There are two approaches to dealing with this problem:
The correct way: fix the data on the Oracle side. oracle_fdw will support you by telling you which row in the result set caused the error.
The sloppy way: use a PostgreSQL database with database encoding sql_ascii, which will allow you to store anything in a string (except zero bytes).
I'm running into errors when trying to import a table from a western character set into UTF character set. I know the problem is that some of the data "grows". F
For example:
ORA-02374: conversion error loading table "RESULT"
ORA-12899: value too large for column MATRIX_NAME (actual: 11, maximum: 10)
ORA-02372: data for row: MATRIX_NAME :
I know originally when the backup was done in the source database (which uses Western English character set), that column field length is defined as varchar(10), however when imported into target database (uses UTF character set), the data grows to length of 11.
Does Oracle have a way to automatically fix the field length (so it expands the field length automatically into 11), before it imports the data, so to ensure there is no truncating of the data. How to do it?
I'm using Oracle 11G.
Yes. Oracle's built-in import / export tool can automatically handle size issues.
I have to change the character set from AL32UTF8 to WE8MSWIN1252 in a Oracle 11g r2 Express instance... I tried to use the command:
ALTER DATABASE CHARACTER SET WE8MSWIN1252;
But it fails saying that MSWIN1252 isn't a superset of AL32UTF8. Then I found some articles talking about CSSCAN, and that tool doesn't seem to be available in Oracle 11 Express.
http://www.oracle-base.com/articles/10g/CharacterSetMigration.php
Anyone has an idea on how to do that? Thanks in advance
Edit
Clarifying a little bit: The real issue is that I'm trying to import data into a table that has a column defined as VARCHAR(6 byte). The string causing the issue is 'eq.mês', it needs 6 bytes in MSWIN1252 and 7 bytes in UT8
You can't.
The Express Edition of 11g is only available using a UTF-8 character set. If you want to go back to the express edition of 10g, there was a Western European version that used the Windows-1252 character set. Unlike with the other editions, Oracle doesn't support the full range of character sets in the Express Edition nor does it support changing the character set of an existing XE database.
Why do you believe you need to change the database character set? Other than potentially taking a bit more storage space to support the characters in the upper half of the Windows-1252 range, which generally aren't particularly heavily used, there aren't many downsides to a UTF-8 database.
I would say that your best option when you want to go to a character set that supports only a subset of the original characters, that your best option is to use exp and imp back (or expdp and impdp).
Are you sure that no single table will contain any character not found in the 1252 code page ?
The problem of only execute that ALTER DATABASE command is that the Data Dictionary was not converted and it can be corrupted.
I had the same problem. In my case, we are using a Oracle 11g Express Edition (11.2.0.2.0) and we really need that it runs on WE8MSWIN1252 character set, but I cannot change the character set on installation (it always install with AL32UTF8).
With a Oracle Client 11g installed as Administrator and run only the csscan full=y (check this link https://oracle-base.com/articles/10g/character-set-migration) and we notice that are lossy and convertible data problems in our database. But, the problems are with the MDSYS (Oracle Spatial) and APEX_040000 (Oracle Application Express) schemas. So, as we dont need this products, we remove them (check this link: http://fast-dba.blogspot.com.br/2014/04/how-to-remove-unwanted-components-from.html).
Then, we export with expdp the users schemas and drop the users (they must be recreated at the end of the process).
Executing csscan again with full=y capture=y, it reports that: The data dictionary can be safely migrated using the CSALTER script. If the report doesnt have this, the csalter.plb script will not work, because there are some conditions that will not be satisfied:
changeless for all CHAR VARCHAR2, and LONG data (Data Dictionary and Application Data)
changeless for all Application Data CLOB
changeless and/or convertible for all Data Dictionary CLOB
In our case, this conditions were satisfied and we could ran the CSALTER script successfully. Moreover, this script executes the ALTER DATABASE command you are trying to run and it converts the CLOB data of Data Dictionary that is convertible.
Finally, we create the users and the tablespaces of our application and we import the dump of the user data successfully.
I'm using an Oracle database with a collation different to my OS language. I'm accessing the database using the ODBC driver. When I prepare a statement (e.g. a "select * from x where=?"), that involves special non-ASCII characters supported by the DB's collation, I'm finding the data row with the characters. When I execute the select directly with the argument in the sql string, the data row isn't found.
Pure guess on my part, but it may be because your client computer isn't encoding the sql string with the argument written into it correctly. I think that if your client is set to a different regional setting than the DB collation, the character array containing the select statement that gets sent to Oracle would contain "incorrect" bytes where the original funky characters were located - Oracle would interpret these as some character other than the one you originally sent (causing the row to not be found).
Is there any reason you can't just use the parameterized approach (since it is working correctly)?