Import ascii dmp file into an Oracle Unicode database - oracle

Does an import from a WE8ISO8859P1 or IW8ISO8859P8 dmp file into an AL32UTF8 Oracle database, avoid the truncation problem of string fields when changing character set in a database?
If a table field was defined as varchar2(10) in the source database, will it be imported as varchar2(10 CHAR) or as it was originally defined?
Thanks in advance

If you do it properly, Oracle will translate from whatever charset your file is to the database one. sqlloader for example lets you specify the charset of the file. If it is a dmp file (i.e. coming from exp or expdp), then the importing tool, impdp or imp will do the conversion. Problems occur only if the charsets are not compatible, e.g. importing WE8ISO into an ASCII.

Related

Convert a .dmp Database (made with EXP) to an unique .sql file (with Oracle 12.2.0)

I need to convert a .dmp database file to an unique .sql file.
I have installed Oracle 12.2.0.
I am using Windows 10.
How can i do it?
Thank you so much
Be it a datapump dump or a dump exported with conventional export: both tools create files in a proprietary format, and you can't convert them to text.
Why would you want to do that? If you want to recreate the schema with all the data in it just import the dump with impdp (datapump) or imp (conventional) and you have the schema.
If you want to know a certain structure of an object (e.g. a view) you could import only that object.
just run impdp help=Y (datapump) or imp help=Y (conventional) to see how to do that.
If you really want a readable file of your database then have a look at Oracle SQL*Developer which supports unloading tables into insert statements and the like and exporting DDL Statements of certain objects into text format.
cheers

Conversion between NVARCHAR to VARCHAR

I've got an Oracle DB with ALL the character columns defined as NVARCHAR or NCHAR or NCLOB, using charset UTF-16.
Now I want to migrate to a new DB that has charset UTF-8. Since it can store unicode characters, I'm wandering if I will be able to import data converting column types.
The reason I'm doubtful is I know that I cannot convert a NVARCHAR2 column in a VARCHAR2 if not empty.
What is the best option to perform the import. Will datapump complain if I import the schema, modify the column types and after that I'll import the data?
Thank
Yes datapump would be unimpressed with your proposed solution. You need to use to_char() or cast( MYNVARCHAR2 as VARCHAR2 ) to convert the datatypes after the import or before the export. As far as I know, any characters which can't be converted will be turned into '?'s so you have to be careful not to convert any data that contains non-english-alphabet characters.
It will probably be easiest to just import the data as is into a different schema, then convert the data while copying it to the correct, modified schema. i.e.
impdp remap_schema=myschema:tempschema
insert into myschema.mytable (select myprimarykey, to_char(mynvarchar2) from tempschema.mytable);
But this will obviously use up twice the space in your database.

ORACLE import/export CLOB data

I am trying to import an excel file into an oracle table via sql developer. One of the oracle columns is of type CLOB, and during the verification step of the import wizard, i get the following message in the information column: "Data Types CLOB, not supported for import." The data fields i am attempting to import for the CLOB column is empty. Does anybody have any idea what might be wrong? Thanks.
If it is not possible, How can I import/export CLOB data in Oracle?
You just need to use a more recent copy of SQL Developer. We support importing into a CLOB field now from Excel.
And then when it's over, checking the data...

Loading XMLTYPE data with IMPDP

I am trying to take a schema from an existing database and place it in a new database.
I've created dependant tablespaces for the data and everything seems to work ok except any tables with XMLTYPE columns error and fail with the error message below. The XMLTYPE are unvalidated CLOBs
KUP-11007: conversion error loading table "SCHEMA"."TABLE_NAME"
ORA-01400: cannot insert NULL into (XML_COLUMN)
KUP-11009: data for row: XML_COLUMN : 0X''
Some investigation seemed to indicate that using TABLES=TABLE_NAME instead of SCHEMA=SCHEMA would help but I have had no such luck.
Note that there are no constraints on this column and that some data could indeed be null (though after the import I get 0 of my several million records)
The command I am using to initiate the datapump is:
impdp TABLES=SCHEMA.TABLE_NAME DIRECTORY=DATA_PUMP_DIR DUMPFILE=oracledpexport.dmp LOGFILE=LOGFILE.LOG TABLE_EXISTS_ACTION=REPLACE
We have been facing some problems during ORACLE import process.
The IMPDP process was not able to import tables containing XML data types.
The reason for this is due to a bug in ORACLE 11g R1 version.
The work around for this is to use EXP process to create a dump instead of EXPDP.
For a permanent fix, we have to explicitly save XML Type columns as CLOB
Also, Oracle has confirmed that this issue has been fixed in ORACLE 11gR2 version.

Store cyrillic in Oracle

I have Oracle database with following settings
NLS_CHARACTERSET EE8MSWIN1250
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
I've created test table with one column of type NVARCHAR2, where I'm going to store cyrillic.
I use SQL Developer to connect DB.
The problem is when I put a cyrillic chain into DB using SQL Developer cell, the data is stored correctly. But when I use INSERT query with the same data using N'' or not the data is stored as question marks.
Interesting thing is that query generated by SQL Developer, and written by me is identical.
I solved this problem by changing NLS_CHARACTERSET to UTF8, but on production server I can't do such a thing.
IMO it must be some way to store cyrillic into that DB in proper way using query if SQL Developer can do that.
Regards
Depending on the ODBC/JDBC in use, localization settings on your computer may override any config values in the database. Try using ALTER SESSION and set the proper NLS parameters before executing your query, and see if that helps. SQL developer might do this behind the scenes when you edit the data cell.

Resources