Change the TABLESPACE of the destination when restoring a database in Oracle 11g (Windows Server 2012 R2)

Question

I was doing an import of a database (schema) from a previous version (Oracle 10g express editon) to a more recent version (Oracle 11g express edition) in Oracle from a .dmp file (I did not export, I was only responsible for make the import into the new environment) , the way to do it I consulted in a previous forum and I managed to import using imp , I could not use the impdp because the export was not done with the expdp .

Well, once the restoration was done what I needed most was to restore all the objects in another tablespace, for that I had previously created a user, a tablespace associated with that user and naturally a datafile associated with that tablespace. But all the objects had been restored within the system tablespace ( USERS ), since in the source database these are in that tablespace.

The instruction that I used and thought would help me was the following:

imp my_user/password@XE FILE=C:\oraclexe\app\oracle\admin\XE\dpdump\my_file.dmp FROMUSER=my_user TOUSER=my_user

However, even though I tried to change the user ( FR0MUSER and TOUSER ), the data is still restored in the USERS tablespace and also in SYSTEM .

I guess the only way to solve this is to export again. I have three options: The exp , expdp and the RMAN . Although I am not sure that these help me alone to change or modify the destination tablespace.

Any reference would be very helpful.

Answer 1

To clarify, you have already completed an import and the data has been loaded into the database, however, the imported objects were loaded into the Users and System tablespaces, rather than the tablespace you created for them, correct?

There are a number of ways to do this, such as using the DBMS_REDEFINITION package or issuing commands like ALTER TABLE [SCHEMA].[TABLE] MOVE TABLESPACE [NEW TABLESPACE] , however that can be extremely tedious, and may present problems if the database is in use. You would have to rebuild the indexes, and you would also have to move the lob files.

I would recommend using data pump ( EXPDP ) to create a new export of the schema, then remap the tablespaces while re-importing it into the database. Your steps would follow this general outline:

1. Export the schema using a command similar to this: expdp [user]/[pass] SCHEMAS=[SCHEMA] DIRECTORY=DATA_PUMP_DIR DUMPFILE=Export.dmp LOGFILE=export.log , where [SCHEMA] is the name of the schema that you want to remap. You can use any directory, dumpfile, and logfile name you want - this is just an example.
2. You'll want to drop the schema before re-importing it. Make sure to use the cascade option so that all of the objects are dropped: DROP USER [SCHEMA] CASCADE;
3. Finally, you can re-import the schema and use the REMAP_TABLESPACE clause to remap the objects to your desired tablespace: impdp [user]/[pass] SCHEMAS=[SCHEMA] REMAP_TABLESPACE=SYSTEM:[TABLESPACE] REMAP_TABLESPACE=USERS:[TABLESPACE] DIRECTORY=DATA_PUMP_DIR DUMPFILE=Export.dmp LOGFILE=import.log , where [TABLESPACE] is the tablespace you created for the schema.

Assuming all goes well, the schema will be re-imported into the database, and the objects of that schema that were originally mapped to the USERS and SYSTEM tablespaces will be remapped to your [TABLESPACE] .

Answer 2

As you've already imported everything, you could move all the tables and indexes to your preferred tablespace with alter table and alter index commands, eg:

alter table my_table move tablespace my_tablespace;
alter index my_index rebuild tablespace my_tablespace;

You can use the data dictionary to generate those statements, with something like:

select 'alter table "' || object_name || '" move tablespace my_tablespace;'
from user_objects
where object_type = 'TABLE';

select 'alter index "' || object_name || '" rebuild tablespace my_tablespace;'
from user_objects
where object_type = 'INDEX';

with the output written to a script you then run; or you could use similar queries and dynamic SQL to do it all in one go.

There may be edge cases you need to deal with - maybe additional steps for partitions, and I'm not sure if IOTs will cause problems, but that might get you started - and at least reduce the amount of re-export/re-import you need to do.

Of course, you need enough space for both the old and new tablespaces to move the objects, as they'll exist in both as they move - one at a time, but may still be an issue too...