How to Use Export and Import when Transferring Data Across Platforms or Across 32-bit and 64-bit Servers

[ID 277650.1]

Applies to:
Oracle Server - Standard Edition - Version: 8.1.7.0 to 10.2.0.1 - Release: 8.1.7 to 10.2 Oracle Server - Standard Edition - Version: 8.1.7.0 to 10.2.0.1 [Release: 8.1.7 to 10.2] Oracle Server - Standard Edition - Version: 10.1.0.2 to 10.2.0.1 [Release: 10.1 to 10.2] Oracle Server - Personal Edition - Version: 10.1.0.2 to 10.2.0.1 [Release: 10.1 to 10.2] Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 10.2.0.1 [Release: 8.1.7 to 10.2] Information in this document applies to any platform.

Goal
This document provides the concepts how the export and import utilities can be used to transfer data, schemas, tablespaces, databases across platforms and across 32-bit/64-bit processor servers. The document is limited to the usage of the Export and Import utilities, and does not give detailed information about the following upgrade or migrate procedures: - upgrade of the Operating System (e.g. move from HP-UX 10.20 to HP-UX 11.0) - upgrade of the hardware (e.g. move from 32-bit to 64-bit) - upgrade of Oracle Software (e.g. move from Oracle9i 9.2.0.8.0 to Oracle10g 10.2.0.3.0) For details about those procedures, see the Knowledge Browser in MetaLink: - Tab: Knowledge - Knowledge Browser - Product: Database - Installation, Upgrade and Migration.

Solution
1. Transfer in binary mode. Essential for a correct data transfer process is that the export dump files (and in case of a transport tablespace: also the datafiles) are transferred in binary mode to the target system. This can be achieved by using any facility for copying binary files, for example an operating system copy utility, FTP in binary mode, or publishing on CD's. An incorrect transfer of the export dump file results in a corrupted export dump file that cannot be read by the import utility. Typical errors upon import are: IMP-00010: not a valid export file, header failed verification IMP-00000: Import terminated unsuccessfully Note that if you were exporting on Unix through a named pipe, and have compressed the export dump file before writing to disk, you have to decompress the file before importing the data back into a database. If the target database is on a different platform that does not have the utility to decompress the export dump file, you have to decompress the file before transferring it to the target platform. 2. Parameter RECORDLENGTH. The parameter RECORDLENGTH specifies the length, in bytes, of the file record. This parameter is necessary when you must transfer the export file to another operating system that uses a different default value. If you do not define this parameter, it defaults to your platform-dependent value for buffer size. You can set RECORDLENGTH to any value equal to or greater than your system's buffer size (the highest value is 64 kb). Frequently used values for buffer size are: 512 bytes, 4096 (4 kb), 8192 (8 kb), 32768 (32 kb), 65535 (64

kb). 3. Platform compatibility. The export and import utilities can be used to connect to databases on different platforms. Example: - source database is 9.2.0.7 database on Sun Solaris 9 - target database is 9.2.0.7 database on Linux Red Hat Enterprise Server v2.1 - client 1 is 9.2.0.7 on Microsoft Windows 2000 - client 2 is 9.2.0.7 on Microsoft Windows XP The following is a supported way to transfer data from one database to another (note that for the sake of the example we export and import via client machines): a. On client 1 (Microsoft Windows 2000 platform), export with the 9.2.0.7 export utility and connect with Oracle Net to your 9.2.0.7 source database on the Sun Solaris 9 platform. b. The export dump file will be created via Oracle Net on your Windows 2000 machine. c. Ftp the export dump file in binary mode to the client 2 machine (Microsoft Windows XP platform). d. Import with the 9.2.0.7 import utility on client 2 (Microsoft Windows XP platform), and connect with Oracle Net to your 9.2.0.7 target database on Linux Red Hat Enterprise Server v2.1. 4. 32-bit / 64-bit compatibility. The export and import utilities can be used to connect to databases with different word-size. Example: - source database is 64-bit 8.1.7.4 database on 64-bit Sun Solaris 9 - target database is 32-bit 10.2.0.3 database on 32-bit Linux SuSE SLES 8 - client is 64-bit 10.2.0.3 on 64-bit Microsoft Windows XP (AMD64) The following is a supported way to transfer data from one database to another (note that for the sake of the example we export and import via client machines): a. Export with the 8.1.7.4 export utility from the 64-bit 8.1.7.4 source database on the 64-bit Sun Solaris 9 platform (note that this export utility is actually a 32-bit program). b. FTP the export dump file in binary mode to the client machine (64-bit Microsoft Windows XP 2003 platform). c. Import with the 64-bit 10.2.0.3 import utility on the 64-bit Microsoft Windows XP (AMD64) client platform, and connect with Oracle Net to your 32-bit 10.2.0.3 target database on the 32-bit Linux SuSE SLES8 server. 5. Oracle version compatibility. The export and import utilities can be used to connect to databases with different Oracle versions. The basic compatibility rules are: - Export the data with the Export utility of the lowest database version involved. - Import the data with the Import utility of the target database. - An export dump file created with the (old-style) export utility 'exp' (e.g. Oracle9i), cannot be imported with the new Oracle10g import datapump utility 'impdp' (and vice versa). Example: - source database is 10.1.0.4 database on Linux Red Hat Enterprise Server v4 - target database is 9.2.0.8 database on HP-Tru64 5.1b The following is a supported way to transfer the data from one database to another: a. Export with the 9.2.0.8 export utility on your HP-Tru64 server, and connect with Oracle Net to your 10.1.0.4 source database on the Linux Red Hat platform b. The export dump file will be created via Oracle Net on your HP-Tru64 server.

c. Import with the 9.2.0.8 import utility on your HP-Tru64 server into your 9.2.0.8 database. 6. Combinations. Combinations of the previous three examples are possible. Example: - source database is 64-bit 8.1.7.4 database on 64-bit Sun Solaris 9 - target database is 64-bit 10.2.0.3 database on 64-bit Linux Red Hat Enterprise Server v5 (AMD64) - client 1 is 32-bit 8.1.7.4 on 32-bit Microsoft Windows 2000 - client 2 is 32-bit 10.2.0.3 on 32-bit Microsoft Windows XP The following is a supported way to transfer data from one database to another: a. Export with the 32-bit 8.1.7.4 export utility on client 1 (Microsoft Windows 2000 platform), and connect with Oracle Net8 to your 64-bit 8.1.7.4 source database on the Sun Solaris 9 platform. b. FTP the export dump file in binary mode to client 2 (Microsoft Windows XP platform). c. Import with the 32-bit 10.2.0.3 import utility on client 2 (Microsoft Windows XP platform), and connect with Oracle Net to your 64-bit 10.2.0.3 target database on Linux Red Hat Enterprise Server v5 (AMD64). 7. Example scenario's. Scenario 1: Transfer of a table. If one or more tables need to be transferred between databases across platforms, then you can use the TABLE level export mode. Example: - source database is 64-bit 8.1.7.4 database on 64-bit Sun Solaris 9 - target database is 64-bit 10.1.0.5 database on 64-bit Linux Red Hat Enterprise Server v3 - tables scott.emp and hugo.dept need to be transferred a. On Sun Solaris, export with the 8.1.7.4 export utility:
> exp system/manager FILE=exp_tabs.dmp LOG=exp_tabs.log \ RECORDLENGTH=65535 TABLES=scott.emp,hugo.dept

b. Transfer the file in binary mode to the Linux Red Hat Enterprise Server. c. On Linux Red Hat, import with the 10.1.0.5 import utility:
> imp system/manager FILE=exp_tabs.dmp LOG=imp_tabs.log \ RECORDLENGTH=65535 FROMUSER=scott,hugo TOUSER=scott,hugo

Notes: 1. The export and import parameter RECORDLENGTH was used with the maximum value (64 kb). 2. The users SCOTT and HUGO must exist in the target database prior to the import operation; otherwise an error is returned. Scenario 2: Transfer of a schema. If one or more schema's need to be transferred between databases across platforms, you can use the USER (owner) level export mode. Example: - source database is 32-bit 9.0.1.4 database on Microsoft Windows 2000

- target database is 64-bit 9.2.0.8 database on HP-Unix 11i - schema's scott and hugo need to be transferred a. On Windows 2000, export with the 9.0.1.4 export utility:
-- Windows: type all parameters on one single line: D:\> exp system/manager FILE=exp_u.dmp LOG=exp_u.log RECORDLENGTH=65535 OWNER=scott,hugo

b. Transfer the file in binary mode to the HP-UX 11i Server. c. On HP-Unix, import with the 9.2.0.8 import utility:
> imp system/manager FILE=exp_u.dmp LOG=imp_u.log \ RECORDLENGTH=65535 FROMUSER=scott,hugo TOUSER=scott,hugo

Notes: 1. The user names SCOTT and HUGO must exist in the target database prior to the import operation; otherwise an error is returned. 2. In Oracle10g when using export DataPump and import DataPump, you can use the import DataPump parameter REMAP_SCHEMA which loads all objects from a source schema into a target schema, and creates the target schema if it does not exist. Scenario 3: Transfer of a tablespace. Beginning with the Oracle10g database, a tablespace can always be transported to a database with the same or higher compatibility setting, whether the target database is on the same or a different platform. Example: - source database is 32-bit 10.1.0.2 database on 32-bit Microsoft Windows 2000 - target database is 64-bit 10.2.0.1 database on AIX 5.2 - tablespaces USERS and EXAMPLE example need to be transferred a. On the Microsoft Windows 2000 platform:
-- check involved datafiles, and check if the transportable set is self -- contained: SELECT file_name FROM dba_data_files WHERE tablespace_name IN ('USERS','EXAMPLE'); EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('users,example', TRUE); SELECT * FROM transport_set_violations; -- make tablespaces read-only, and export the transportable set: ALTER TABLESPACE users READ ONLY; ALTER TABLESPACE example READ ONLY; -- export the transport tablespace set: -- (Windows: type parameters on one single line) D:\> expdp system/manager DIRECTORY=my_dir DUMPFILE=exp_tbsp.dmp LOGFILE=exp_tbsp.log TRANSPORT_TABLESPACES=users,example TRANSPORT_FULL_CHECK=Y

b. Check platform, and check if the datafiles need to be converted (difference exists in endian format):
SELECT platform_name FROM v$database; SELECT * FROM v$transportable_platform; -- Use RMAN if the datafiles need to be converted: > rman target / RMAN> CONVERT TABLESPACE users,example TO PLATFORM 'AIX-Based Systems (64-bit)' FORMAT 'N:\temp\%U'; RMAN> EXIT;

Otherwise, copy the datafiles to a temporary location, and put the tablespaces back to read write. c. Transfer the export dumpfile and the copied/converted datafiles in binary mode to the AIX 5.2 Server. d. Plug in the tablespaces:
> impdp system/manager DIRECTORY=my_dir2 DUMPFILE=exp_tbsp.dmp \ LOGFILE=imp_tbsp.log TRANSPORT_DATAFILES=\('/dbdir/users01.dbf', \ '/dbdir/example01.dbf'\) REMAP_SCHEMA=\(scott:scott2\) \ TRANSPORT_FULL_CHECK=Y REMAP_SCHEMA=\(hugo:hugo2\)

e. Change the plugged in tablespaces back to read write. Notes: 1. In this example we assumed that only the users SCOTT and HUGO owned objects in the tablespaces USERS and EXAMPLE. The users SCOTT2 and HUGO2 become the new owners of the objects. These users should have been created in the target database prior to the import. 2. You cannot transport the SYSTEM tablespace. 3. You cannot transport objects owned by the user SYS (such as: PL/SQL, Java classes, callouts, views, synonyms, users, privileges, dimensions, directories, and sequences). 4. The source and target database must use the same character set and national character set. 5. In Oracle9i and Oracle8i the source and target database must be on the same hardware platform. Scenario 4: Transfer of a database. The Export and Import utilities are the only method that Oracle supports for moving an existing Oracle database from one hardware platform to another. This includes moving between UNIX and NT systems. In Oracle10g you can use the transportable tablespace feature to migrate a database to a different platform by creating a new database on the destination platform and performing a transport of all the user tablespaces. Note that you cannot transport the SYSTEM tablespace. Therefore, objects such as sequences, PL/SQL packages, and other objects that depend on the SYSTEM tablespace are not transported. You must either create these objects manually on the destination database, or use Data Pump to transport the objects that are not moved by transportable tablespace. A full database export and import can be used in all Oracle version to transfer a database across platforms. Example: - source database is 32-bit 9.2.0.8 database on 32-bit Microsoft Windows 2000 - target database is 64-bit 10.2.0.3 database on 64-bit HP-Unix Itanium 11.22 The following steps provide a general overview of how to move a database between platforms. a. Query the views dba_tablespaces, dba_data_files and dba_temp_files. You will need this information later in the

process. b. Perform a full export from the source database:

> exp system/manager FULL=y FILE=exp_full.dmp LOG=exp_full.log

c. Transfer the export dumpfile in binary mode to the HP-Unix 11.22 server. d. Create a new database on the target server. e. Before importing the dump file, you must first create your tablespaces, using the information obtained in step a (otherwise, the import will create the corresponding datafiles in the same file structure as at the source database, which may not be compatible with the file structure on the target system). f. Perform a full import with the IGNORE parameter enabled:
> imp system/manager FULL=y FILE=exp_full.dmp LOG=imp_full.log IGNORE=y

Using IGNORE=y instructs Oracle to ignore any creation errors during the import and permit the import to complete.

References
NOTE:132904.1 - Compatibility Matrix for Export And Import Between Different Oracle Versions [Video] NOTE:134966.1 - How to determine Recordlength Parameter Default Value for Export and Import NOTE:149914.1 - Oracle's 9i Platform Strategy Advisory NOTE:243304.1 - 10g : Transportable Tablespaces Across Different Platforms NOTE:272132.1 - Import DataPump - User Schema is Created by Import if it does not Exist in Target Database NOTE:291024.1 - Compatibility and New Features when Transporting Tablespaces with Export and Import NOTE:30528.1 - Large File Issues (2Gb+) when Using Export (EXP-2 EXP-15), Import (IMP-2 IMP-21), or SQL*Loader NOTE:62290.1 - Changing between 32-bit and 64-bit Word Sizes