6.在目标数据库中，使用数据泵导入工具将该表空间导入到该数据库中。

　　这一步就使TS1和TS2表空间以及它们的数据可以在目标数据库中可用。  

　　请注意，Lora并没有从源数据库导出元数据。她只是在上面的impdp命令中指定参数NETWORK_LINK 的值为srcdb，即到源数据库的数据库链接。数据泵导入工具通过数据库链接从源数据库中获得所需的元数据，并在目标数据库中重新创建它们。  

　　7.最后，使源数据库中的TS1和TS2表空间成为可读写。

　　这一步使TS1和TS2表空间在源数据库中对用户立即可用。   

　　请注意，在前面讲的所有步骤中，最费时的是第4步，在这一步中要跨各系统移动数据文件。   

　　跨不同平台的挑战   

　　Lora知道，数据复制过程中的复杂因素之一就是源平台和目标平台经常不一致。例如，在Acme的环境中，当前数 据仓库位于运行Tru64 UNIX的HP服务器上，而建议的数据集市将部署在运行Linux和Windows的Intel硬件 上。   

　　在Oracle数据库10g出现之前，在Acme使用可移动表空间不是一个切实可行的方法。你不能移动表空间，除 非源数据库和目标数据库运行在同一个平台上。   

　　有了Oracle数据库10g，这一限制得到了极大的缓解。在移动表空间时，数据文件可以跨各操作系统任意复制。 在前面的例子中，数据文件可以从Tru64 UNIX复制到Linux或Windows，而目标数据库仍能识别它 们。   

　　但是，管理团队必须考虑另一种限制。默认情况下，只有两个操作系统具有相同的字节顺序（也被称为"endian- ness"）时才可能进行跨操作系统复制。在Acme的情况下，Tru64 UNIX、基于Intel的Linux和Windows都 使用little-endian字节顺序（低位在前），因此在它们之间进行文件复制是可能的。但是，有的团队成员提出了在有关数据仓库/数据集市的提案中 使用Solaris操作系统的想法。Solaris使用big-endian字节顺序（高位在前），这使得在数据库之间进行简单的文件复制成为不可 能。     

　　Lora解释说，Oracle提供了使用 Oracle Recovery Manager (RMAN)进行字节顺序转换的解决方案。她 描述了针对RMAN解决方案的一个测试，该测试根据前面讲到的移动表空间解决方案的7个步骤，并稍作修改来适 应Solaris到 Intel/Linux的环境。除了在第5步之前或之后额外增加一步以外，所有操作步骤都一样。在源(Solaris)数据库服务器上执行的额外这一步如 代码清单1中所示。   

　　用这些代码，可以从Solaris格式的/u01/oradata/ts1_01.dbf文件创建 Intel Linux格式的文件/u01/tts/TS1_34。注意最初的文件并没有被破坏；只是创建了一个可以被导入和传输到 Linux上的目标数据库中的新文件。

　　然后Lora讨论了对RMAN解决方案的一些修改。第一，为了提高性能，她可以指定PARALLELISM=子句来提高执行线程的数目。第二，她可以指定在不同的目录下以相同的文件名创建数据文件。这些修改如下：

　　这条命令用相同的文件名ts1_01.dbf但在/u01/tts目录下根据原始文件/u01/oradata/ts1_01.dbf创建一个转换后的数据文件。这种方法将所有转换后的文件放到一个位置，这样确定转移哪个文件就更简单了。

　　Lora还可以在目标(Linux)数据库服务器而不是在源服务器上执行变换。在这种情况下，将在Linux服务器上执行转换，如下所示：

　　这条命令通过用tslinux代替ts（换句话说，将ts1_1.dbf转换到Linux上的文件格式，新文件名为tslinux1_1.dbf）来创建文件。在数据库内，文件将用这个文件名。

　　Lora怎么知道哪个平台用哪种字节顺序呢？在数据字典视图上执行以下查询就会给出答案：   

　　数据泵导出与导入工具

　　选择可移动表空间的限制之一是在转移文件时源表空间必须是只读模式。在现实世界中，并不总是能满足这一要求。例如，在OLTP数据库中，可能对表要经常进行读写操作。

　　Lora提出的另一种方法是使用Oracle数据库10g中的数据泵实用工具来转移表空间。她对这种方法进行的测试包括移动TS1和TS2表空间内容的以下步骤：

　　1.创建一个目录对象来存放转储的文件。    

　　2.用数据泵导出工具导出数据。

　　这一步创建一个包含TS1和TS2表空间内容的文件/u01/dumps/ ts1_ts2.dmp。