Hi DBA2008,
I recommend you to create all the structure first, then import all the data.
Pre-create tablespaces, users, and tables in the new database to improve space usage by changing storage parameters. When you pre-create tables using SQL*Plus, either run the database in the original database compatibility mode or make allowances for the specific data definition conversions that occur during import. You need to specify IGNORE=Y on Import when items have been pre-created.
Note: If the new Oracle Database will be created on the same computer as the source database, and you do not want to overwrite the source database data files, then you must pre-create the tablespaces and specify DESTROY=N when you import.
This is the Upgrade Compatibility Matrix for Upgrading to 10g:
Source Database |
Destination Database |
8.1.7.4 (or higher) | 10.2.x |
9.0.1.4 (or higher) | 10.2.x |
9.2.0.4 (or higher) | 10.2.x |
10.1.0.2 (or higher) | 10.2.x |
This is the Upgrade Compatibility Matrix for Upgrading to 11g:
Source Database |
Destination Database |
9.2.0.4 (or higher) | 11.1.x |
10.1.0.2 (or higher) | 11.1.x |
10.2.0.1 (or higher) | 11.1.x |
The Data Pump method for moving data between different database versions is different than the method used by original Export/Import. With original Export, you had to run an older version of Export (exp
) to produce a dump file that was compatible with an older database version. With Data Pump, you can use the current Export (expdp
) version and simply use the VERSION
parameter to specify the target database version.
Keep the following information in mind when you are using Data Pump Export and Import to move data between different database versions:
- If you specify a database version that is older than the current database version, certain features may be unavailable. For example, specifying
VERSION=10.1
will cause an error if data compression is also specified for the job because compression was not supported in 10.1. - On a Data Pump export, if you specify a database version that is older than the current database version, then a dump file set is created that you can import into that older version of the database. However, the dump file set will not contain any objects that the older database version does not support. For example, if you export from a version 10.2 database to a version 10.1 database, comments on indextypes will not be exported into the dump file set.
- Data Pump Import can always read dump file sets created by older versions of the database.
- Data Pump Import cannot read dump file sets created by a database version that is newer than the current database version, unless those dump file sets were created with the version parameter set to the version of the target database. Therefore, the best way to perform a downgrade is to perform your Data Pump export with the
VERSION
parameter set to the version of the target database. - When operating across a network link, Data Pump requires that the remote database version be either the same as the local database or one version older, at the most. For example, if the local database is version 10.2, the remote database must be either version 10.1 or 10.2. If the local database is version 10.1, then 10.1 is the only version supported for the remote database
More information, please refer to: https://metalink.oracle.com/metalink/plsql/f?p=130:14:4088601010728200477::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,551141.1,1,1,1,helvetica
Regards,
Francisco Munoz Alvarez