About Transporting Data

Transporting data使用的技术就是使用Data Pump导入导出元数据，而数据文件直接复制

Transporting data moves the data from one database to another. 

Transporting data is much faster than performing either an export/import or unload/load of the same data. It is faster because the data files containing all of the actual data are copied to the target location, and you use Data Pump to transfer only the metadata of the database objects to the new database.

You can transport data at the following levels:

database, tablespaces, tables, partitions, and subpartitions.

传输表空间及传输表只导出在用户表空间相关对象的元数据；传输数据库会导出在用户表空间相关对象的元数据，以及在系统表空间用户定义对象的元数据以及真实数据，不会导出系统对象信息

Transportable tablespaces and transportable tables only transports data that resides in user-defined tablespaces. However, full transportable export/import transports data that resides in both user-defined and administrative tablespaces, such as SYSTEM and SYSAUX. Full transportable export/import transports metadata for objects contained within the user-defined tablespaces and both the metadata and data for user-defined objects contained within the administrative tablespaces.

（一）Transporting Data: Scenarios

Transporting data is useful in several scenarios.

1. Scenarios for Full Transportable Export/import

1. Moving a Non-CDB Into a CDB
2. Moving a Database to a New Computer System
   You might want to move a database to a new computer system to upgrade the hardware or to move the database to a different platform.
3. Upgrading to a New Release of Oracle Database

You can use full transportable export/import to upgrade a database from an Oracle Database 11g Release 2 (11.2.0.3) or later to Oracle Database 12c.

To do so, install Oracle Database 12c and create an empty database. Next, use full transportable export/import to transport the Oracle Database 11g Release 2 (11.2.0.3) database into the Oracle Database 12c database.

1. Scenarios for Transportable Tablespaces or Transportable Tables

1. Scenarios That Apply to Transportable Tablespaces or Transportable Tables
2. Transporting and Attaching Partitions for Data Warehousing
3. Publishing Structured Data on CDs

可以相关数据文件放到CD中, 在把元信息导入目标库后只需要挂载CD即可，相当于挂载了READ ONLY TABLESPACE

如果取消挂载并不影响数据库对其它数据操作

You can remove the CD while the database is still up. Subsequent queries to the data return an error indicating that the database cannot open the data files on the CD. However, operations to other parts of the database are not affected. Placing the CD back into the drive makes the data readable again.

如果启动数据库需要设置 READ_ONLY_OPEN_DELAYED to TRUE，数据库即可在未挂载CD也能启动到OPEN状态

If you shut down and restart the database, then the database indicates that it cannot find the removed data file and does not open the database (unless you set the initialization parameter READ_ONLY_OPEN_DELAYED to TRUE). When READ_ONLY_OPEN_DELAYED is set to TRUE, the database reads the file only when someone queries the data.

1. Mounting the Same Tablespace Read-Only on Multiple Databases

可以把元信息导入到多个数据，相关数据文件放到共享存储中作READ ONLY TABLESPACE

1. Archiving Historical Data
2. Using Transportable Tablespaces to Perform TSPITR
3. Copying or Moving Individual Tables

（二）General Limitations on Transporting Data

本章只是transport data通用限制，传输数据库、表空间及表各自限制分到相关文档中了

Be aware of the following general limitations as you plan to transport data:

1. The source and the target databases must use compatible database character sets. Specifically, one of the following must be true:

1. The database character sets of the source and the target databases are the same.
2. The source database character set is a strict (binary) subset of the target database character set, and the following three conditions are true:

1. The source database is Oracle Database 10g Release 1 (10.1.0.3) or later.
2. The tablespaces to be transported contain no table columns with character length semantics or the maximum character width is the same in both the source and target database character sets.
3. The data to be transported contains no columns with the CLOB data type, or the source and the target database character sets are both single-byte or both multibyte.

1. The source database character set is a strict (binary) subset of the target database character set, and the following two conditions are true:

1. The source database is before Oracle Database 10g Release 1 (10.1.0.3).
2. The maximum character width is the same in the source and target database character sets.

1. The source and the target databases must use compatible national character sets. Specifically, one of the following must be true:

1. The national character sets of the source and target databases are the same.
2. The source database is Oracle Database 10g Release 1 (10.1.0.3) or later and the tablespaces to be transported contain no columns with NCHAR, NVARCHAR2, or NCLOB data type.

1. When running a transportable export operation, the following limitations apply:

1. The default tablespace of the user performing the export must not be one of the tablespaces being transported.
2. The default tablespace of the user performing the export must be writable.

1. In a non-CDB, you cannot transport a tablespace to a target database that contains a tablespace of the same name.

In a CDB, you cannot transport a tablespace to a target container that contains a tablespace of the same name. However, different containers can have tablespaces with the same name.

You can use the REMAP_TABLESPACE import parameter to import the database objects into a different tablespace. Alternatively, before the transport operation, you can rename either the tablespace to be transported or the target tablespace.

Starting with Oracle Database 12c Release 2 (12.2), the Recovery Manager (RMAN) RECOVER command can move tables to a different schema while remapping a tablespace.

1. In a CDB, the default Data Pump directory object, DATA_PUMP_DIR, does not work with PDBs. You must define an explicit directory object within the PDB that you are using with Data Pump export/import.

1. Transporting data with XMLTypes has the following limitations:

1. The target database must have XML DB installed.
2. Schemas referenced by XMLType tables cannot be the XML DB standard schemas.
3. If the schema for a transported XMLType table is not present in the target database, then it is imported and registered. If the schema already exists in the target database, then a message is displayed during import.
4. You must use only Data Pump to export and import the metadata for data that contains XMLTypes.

The following query returns a list of tablespaces that contain XMLTypes:

select distinct p.tablespace_name from dba_tablespaces p,

  dba_xml_tables x, dba_users u, all_all_tables t where

  t.table_name=x.table_name and t.tablespace_name=p.tablespace_name

  and x.owner=u.username;

1. Types whose interpretation is application-specific and opaque to the database (such as RAW, BFILE, and the AnyTypes) can be transported, but they are not converted as part of the cross-platform transport operation. Their actual structure is known only to the application, so the application must address any endianness issues after these types are moved to the new platform. Types and objects that use these opaque types, either directly or indirectly, are also subject to this limitation.

1. When you transport a tablespace containing tables with TIMESTAMP WITH LOCAL TIME ZONE (TSLTZ) data between databases with different time zones, the tables with the TSLTZ data are not transported. Error messages describe the tables that were not transported. However, tables in the tablespace that do not contain TSLTZ data are transported.

You can determine the time zone of a database with the following query:

SELECT DBTIMEZONE FROM DUAL;

You can alter the time zone for a database with an ALTER DATABASE SQL statement.

You can use Data Pump to perform a conventional export/import of tables with TSLTZ data after the transport operation completes.

1. Analytic workspaces cannot be part of cross-platform transport operations. If the source platform and target platform are different, then use Data Pump export/import to export and import analytic workspaces. See Oracle OLAP DML Reference for more information about analytic workspaces.

Note: Do not invoke Data Pump export utility expdp or import utility impdp as SYSDBA, except at the request of Oracle technical support. SYSDBA is used internally and has specialized functions; its behavior is not the same as for general users.

（三）Compatibility Considerations for Transporting Data

When transporting data, Oracle Database computes the lowest compatibility level at which the target database must run.

A tablespace or table can always be transported to a database with the same or higher compatibility setting using transportable tablespaces, whether the target database is on the same or a different platform. The database signals an error if the compatibility level of the source database is higher than the compatibility level of the target database.

The following table shows the minimum compatibility requirements of the source and target databases in various scenarios. The source and target database need not have the same compatibility setting.

Table 15-2 Minimum Compatibility Requirements

Transport Scenario	Minimum Compatibility Setting
	Source Database	Target Database
Transporting a database using full transportable export/import	12.0 (COMPATIBLE initialization parameter setting for an Oracle Database 12c database 12 (VERSION Data Pump export parameter setting for an 11.2.0.3 or later database)	12.0 (COMPATIBLE initialization parameter setting)
Transporting a tablespace between databases on the same platform using transportable tablespaces	8.0 (COMPATIBLE initialization parameter setting)	8.0 (COMPATIBLE initialization parameter setting)
Transporting a tablespace with different database block size than the target database using transportable tablespaces	9.0 (COMPATIBLE initialization parameter setting)	9.0 (COMPATIBLE initialization parameter setting)
Transporting a tablespace between databases on different platforms using transportable tablespaces	10.0 (COMPATIBLE initialization parameter setting)	10.0 (COMPATIBLE initialization parameter setting)
Transporting tables between databases	11.1.0.6 (COMPATIBLE initialization parameter setting for an Oracle Database 12c database	11.1.0.6 (COMPATIBLE initialization parameter setting)

When you use full transportable export/import, the source database must be an Oracle Database 11g Release 2 (11.2.0.3) or later database, and the target database must be an Oracle Database 12c database. When transporting a database from Oracle Database 11g Release 2 (11.2.0.3) or a later to Oracle Database 12c, the VERSION Data Pump export parameter must be set to 12 or higher. When transporting a database from Oracle Database 12c to Oracle Database 12c, the COMPATIBLE initialization parameter must be set to 12.0.0 or higher.

（四）Guidelines for Transferring Data Files

1. If both the source and target are file systems, then you can transport using:

Any facility for copying flat files (for example, an operating system copy utility or ftp)

The DBMS_FILE_TRANSFER package

RMAN

Any facility for publishing on CDs

If either the source or target is an Oracle Automatic Storage Management (Oracle ASM) disk group, then you can use:

ftp to or from the /sys/asm virtual folder in the XML DB repository

The DBMS_FILE_TRANSFER package

RMAN

Note: Starting with Oracle Database 12c, RMAN can transfer files using network-enabled restore. RMAN restores database files, over the network, from a remote database instance by using the FROM SERVICE clause of the RESTORE command.

2. Do not transport the data files for the administrative tablespaces (such as SYSTEM and SYSAUX) or any undo or temporary tablespaces.

1. If you are transporting data of a different block size than the standard block size of the database receiving the data, then you must first have a DB_nK_CACHE_SIZE initialization parameter entry in the receiving database parameter file.