The Oracle new tablespace name must fit with the old tablespace name?
For example:
The dump file tablespace name is A,and i create a new tablespace B,and it could import table, but has many error?
ORA-00959:tablespace 'ECASYS'(old) not exits.
This is my import statement:
imp userid='ZHPE/zhpe#ORCL' file='E:\xxxx\xxxx2013-08-15Bak\130815.dmp' log='D:\app\Administrator\oradata\orcl\ZHPE.log' full=y ignore=y;
Is the new tablespace must must must fit the old one???
help!
If you're forced to use the legacy exp and imp tools then the tablespace cannot be changed during the import itself using command-line options. If you can, switch to using the datapump versions, expdp and impdp, and then follow #schurik's advice.
If you can't do that then you'll need a workaround, which is to create the schema objects manually first.
If you run imp with the indexfile option then it will create a file containing the DDL for the tables and indexes:
imp user/password indexfile=schema.sql file=...
The table creation DDL is commented out with REM markers, which you need to remove. You can then edit it to change the tablespace and any other storage options that are no longer appropriate. Then run that schema creation SQL to create all the tables as empty.
Then run the normal import again, but with the ignore=y flag so it doesn't complain (much) that the tables now already exist. The data will still be inserted into those existing tables.
This will be a bit slower if you create the indexes as well as the tables beforehand; normally it would create the tables, insert the data, and then build the indexes, which is more efficient. If the slowdown is significant then you can split your schema.sql into separate table and index creation files and do the same thing manually - create the tables, run the import with ignore=y and indexes=n (to stop it trying and failing to create them), and then create the indexes yourself afterwards.
Clearly this is a bit of a pain, and one of many reasons that switching to datapump is a good idea.
take a look at the REMAP_TABLESPACE import parameter e.g
REMAP_TABLESPACE=A:B
Related
I created a dump of a local oracle database like this:
expdp mydb/passwd -schemas=myschema -dumpfile=mydumpfile.dmp -logfile=oralog.log
I sent the dump to someone who is supposed to import the dump in his oracle server. Now, he tells me, the import fails due to some errors related to tablespaces (like tablespace XYZ is not available, - the database XYZ is in no relation to the respective database). Besides, he asks me to give some information about the dump concerning the tablespaces.
Since I am usually working with MySQL and have limited knowledge about these Oracle-Tablespace things: I would really appreciate to get some advise.
Use REMAP_TABLESPACE parameter.
For example,
REMAP_TABLESPACE=(source1:destination1,source2:destination1,source3:destination1,source4:destination1)
Go through the documentation about Data Pump Import. A small quote -
Multiple REMAP_TABLESPACE parameters can be specified, but no two can
have the same source tablespace. The target schema must have
sufficient quota in the target tablespace.
Note that use of the REMAP_TABLESPACE parameter is the only way to
remap a tablespace in Data Pump Import. This is a simpler and cleaner
method than the one provided in the original Import utility. That
method was subject to many restrictions (including the number of
tablespace subclauses) which sometimes resulted in the failure of some
DDL commands.
By contrast, the Data Pump Import method of using the REMAP_TABLESPACE
parameter works for all objects, including the user, and it works
regardless of how many tablespace subclauses are in the DDL statement.
I use oracle 11, and use exp/imp tools to migrate data between databases.
It works very fine IF all empty tables and sequences are already created in target database.
But If tables dont exists in target DB than a few bad things happen;
It still creates tables but only the ones with data, I couldnt find a way to force it create empty tables in target DB.
It does not create the sequences.
This is how I enter my values to export tool;
Users or Tables -> Tables
Export table data -> yes
Compress -> yes
Table or Partition to be exported -> I enter table names here one by one,
But it does accept table names without data..It says table does not exist, so no surprize they are not imported later.
Import Data only > no
Import File > Full path to Dump file.
List contents of import file > no
Ignore create error > no
import grants > yes
import table data > yes
import entire export > yes
Sequences are not exported in table mode. The documentation lists the objects exported in each mode, and that shows that sequences are only exported in user and full database modes.
Export is deprecated in 11g, as the documentation also states:
Original Export is desupported for general use as of Oracle Database 11g. The only supported use of original Export in Oracle Database 11g is backward migration of XMLType data to Oracle Database 10g release 2 (10.2) or earlier. Therefore, Oracle recommends that you use the new Data Pump Export and Import utilities
The empty tables are not being exported if you have deferred segment creation. This AskTom articles refers to it, and it's also mentioned in the documentation:
The original Export utility does not export any table that was created
with deferred segment creation and has not had a segment created for
it.
You can either use dbms_metadata.get_ddl() to get the table creation statements for all the tables, or just the empty ones, and build them manually from that; or force an extent to be allocated (as mentioned in the docs too); or use the supported and current data pump export and import. Based on previous questions you should only be using exp/imp if your customer refuses to handle data pump files, and I can't really think of a good justification for that.
I have an oracle dump file which I assume has been created using the exp command and not the expdp
The dump file is about 4 GB and I would like to import it into my Oracle 11.2 database.
The dump file which was created has the tablespace as "spaceA" but my tablespace is "spaceB"
So I would need to remap the tablespace as well.
I did use impdp commands before and it used to work perfectly fine but guess as I understand
impdp could only be used on dump file if it was exported using expdp..
Since I am not very familiar with the process of exporting/importing, I would like to get help with this
If the tablespace is not hardcoded in the dmp file create table statements then you should be able to import without a problem. So my suggestion would be to first try something like the following (for more details: http://docs.oracle.com/cd/E11882_01/server.112/e10701/original_import.htm)
imp user/password#instance file=FILE.dmp log=LOG.log fromuser=DMPSCHEMA touser=NEWSCHEMA
If you get IMP-00017 errors. Then you have to take the longer route. You need to first create the tables and then import with ignore=y.
To first create the tables you need the DDL statements, which you can obtain by running:
imp user/password#instance file=FILE.dmp log=LOG.log full=y indexfile=INDEXFILE.log
The INDEXFILE.log will contain all the create table statements. Find and replace "spaceA" with "spaceB", create the tables, and then run the import with the ignore=y parameter which will ignore table creation errors (since tables already exist) and load data:
imp user/password#instance file=FILE.dmp log=LOG.log fromuser=DMPSCHEMA touser=NEWSCHEMA ignore=y
I trying to take oracle DB backup using expdp. I have a specific case where an application table resides in the SYSTEM tablespace.
The backup export of this schema is successfully created with options SCHEMAS=SYSTEM and INCLUDE=TABLE:"like 'USER%'" which corresponds to my application tables.
I have created another schema with the user impexp which has a different tablespace allocated to it.
when I try to import the .dmp file into impexp, the import is unsuccessful stating "SYSTEM"."USER_SYS_MAST" exists.
Is there a way to import this table in the newly created schema. I also tried using the option REMAP_SCHEMA=SYSTEM:IMPEXP, but it seems to error out saying ORA-39013: Remapping the SYSTEM schema is not supported.
Summarizing : I want to import my application tables in the SYSTEM tablespace into a new TABLESPACE 'IMPEXP'.
Please let me know If I am going wrong somewhere and trying to do something that isn't supported.
any help will be greatly appreciated.
This is one of the reasons why putting application tables in the SYS or SYSTEM schemas is considered bad practice. These schemas are vital to the running of our databases and should not be meddled with.
You have compounded this bloomer by naming your tables with a prefix of USER, which is the same convention the data dictionary uses.
What you need to do is create a new schema to hold these tables. Grant it whatever privileges it needs that made you think it had to be owned by SYSTEM. Then move those tables out of the SYSTEM schema.
To do a proper job you should change your application to use this new schema, but as temporary fix you could give SYSTEM rights on the tables and build synonyms for them. If you have the time, change the application. It will cause you less grief in the long run.
Either way, you will be able to export the data out of the old database and into the target database using this new schema.
Agree with APC.
In your specific case, I would look at DBMS_METADATA.GET_DDL to extract the DDL so I can recreate all the objects in the new schema. There are options to exclude the TABLESPACE component so they would get created in the new schema's default tablespace.
Then I would simply do INSERT /*+APPEND */ INTO newschema.table AS SELECT * FROM SYSTEM.table
If space is an issue, you may need to TRUNCATE or DROP individual tables immediately after they are successfully copied.
I have encountered a problem in importing the dump file to a new database.
When importing the dump file it requires a new tablespace which does not exist in the database.
To create the tablespace I need to hijack some scripts which is readonly.For this reason it is complicated to export the table structure through imp tool of Oracle so my colleage changed the dump file manually and it is able to be imported.
Is it OK to change the dump file manually in order to import the file if it is the quickest way?
if are comfortable to change the dump file manually then it is fine, keeping that you are aware of the the complete structure of the .dmp file.
i will suggest u to use data pump as it remaps the table space of the existing schema with the new one. and performance wise data pump is much faster then normal dump.
As an alternative, get a dummy database and
create the tablespace/schema.
Do the import there with ROWS=N
ALTER TABLE ... MOVE .... to put the tables into the desired tablespace
Export tables (structures) from there
import corrected structures
Import the data with IGNORE=Y so that the data can be imported over the existing structures.
if you create the user with a default tablespace that is a tablespace that exists, you can import with rows=n and ignore=y and that should bring the objects in for you into that tablespace.