IMP-00003: ORACLE error 3113 encountered ORA-03113: end-of-file on communication channel
: following statement failed with ORACLE error 3113:
今天导数据，imp时出现错误：
- IMP-00017: following statement failed with ORACLE error 959:
- "CREATE TABLE "SYS_FORMFILEINFO" ("FPKID" NUMBER(22, 0) NOT NULL ENABLE, "FO"
- "RMTYPE" VARCHAR2(50), "FORMINFO" CLOB, "DESCRIPTION" VARCHAR2(200), "FORMNA"
- "ME" VARCHAR2(50), "FLASTUPDATE" DATE, "FTYPE" NUMBER(22, 0)) PCTFREE 10 PC"
- "TUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 65536 FREELISTS 1 FREELIST"
- " GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "SRM_STANDARD" LOGGING NOCOMPRESS"
- " LOB ("FORMINFO") STORE AS (TABLESPACE "SRM_STANDARD" ENABLE STORAGE IN RO"
- "W CHUNK 8192 PCTVERSION 10 NOCACHE LOGGING STORAGE(INITIAL 65536 FREELISTS"
- " 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT))"
- IMP-00003: ORACLE error 959 encountered
- ORA-00959: tablespace 'SRM_STANDARD' does not exist
- . . importing table "SYS_BUSINESS_GLIDE" 0 rows imported
- About to enable constraints...
表SYS_FORMFILEINFO 含有LOB字段，导入时出现IMP-00017，IMP-00003，ORA-00959。
为避免此错误，解决方案如下，
方法A:
在导入的数据库中建立与原数据库一样名称的tablespace(当然，只需要建立 有LOB字段的table相关的tablespace即可)
方法B
先在导入的数据库中手动建立带LOB的table，再用ignore=Y来导入
方法C
PLDEV的导入导出工具
因为我知道源库的连接信息，因此可以查到含有LOB字段表相关的表空间，也可以获取含LOB字段表的建表语句，我选择方法B解决此问题。
2
将exp逻辑备份文件导入到备库中时出现了错误，相关错误信息如下：
这是个很常见的导入警告，通常与数据库/客户端版本有关。
解决办法，就是在exp或imp时加上一个参数来禁用统计信息的导出/导入： statistics=none
1. Login as sys in the SQLPLUS and run the following sqls
$OH/rdbms/admin/dbmsread.sql
$OH/rdbms/admin/prvtread.plb
2. Retry the import.
Thanks!
为了使测试与生产数据保持一致，只需要导出数据的时候，可以将测试库的表truncate，保留其它如索引，trigger，constraints，grants等不用再重新导。
exp时候rows=y,其它全部选n，imp时候 rows=y ,其它n
ignore
是否忽略创建错误。
Oracle在恢复数据的过程中，当恢复某个表时，该表已经存在，
就要根据ignore参数的设置来决定如何操作。
若ignore=y，Oracle不执行CREATE TABLE语句，直接将数据
插入到表中，如果插入的记录违背了约束条件，比如主键约束，
则出错的记录不会插入，但合法的记录会添加到表中。
若ignore=n，Oracle不执行CREATE TABLE语句，同时也不会
将数据插入到表中，而是忽略该表的错误，继续恢复下一个表。
（当索引与数据rows要分两次导入时候，导入索引时候要指定ignore=y,否则索引导不进去。
当数据库中已经有要导入的表，并且表中已经存在一些数据时候，如果不覆盖这些数据，append导入数据到这个表，直接指定ignore=y即可）
当表中有long或者lob类型的字段时候，imp的时候对这个表单独imp，要加commit=n,导完一张表提交一次，这样会比加commit=y快。
对含有long或者lob类型字段的表imp时候，加了commit=y,由于long字段很大，数据缓冲很快就会满，每插入一行就会commit一次。导致很频繁的提交，imp会等待log file sync，导致导入很慢。
show parameter filesystemio_options --应该为setall
~~~~~~~~~~~~~~~~
导入导出BLOB数据
~~~~~~~~~~~~~~~~
可以用IMP/EXP
条件：
1.导入时要确保有该BLOB字段的列的表还未建起来
2.在EXP/IMP中参数中指定BUFFER到一定的值，内存必须足够容纳一次预取一行的数据量，有写LOB列可能达到2G
加快exp速度：
direct=y (常规路径导出使用sql select语句从表中取出数据，直接路径导出则将数据直接从硬盘读到pga然后写入导出文件）
recordlength=65535 (定义了export i/o缓冲的大小，类似于常规路径导出的buffer参数）
直接路径导出的限制：8i以及以下的版本不支持导出客户端和数据库的字符集转换，因此导出前要保证NLS_LANG参数设置正确；
815以及以下版本不支持导出含LOBs对象的表；不能使用query参数）
加快imp速度：
加大temp表空间。
sort_area_size 加大,注意这个参数是每个会话的大小
buffer=102400000 （定义了每一次读取导出文件的数据量）
commit=y (表示每个数据缓冲满了之后提交一次，而不是导完一张表提交一次，减少对系统回滚段等资源的消耗）
第一次导入数据，rows=y,indexes=n
第二次导入索引，rows=n,indexes=y
consistent如果指定为Y则所有导出的数据都是一致的，如果为N（为默认值）则只保证单个表中数据的一致性
imp导入时候总报回滚表空间无法扩展，指定commit=y ， 加大buffer 解决
统计信息的导出和导入：
EXP-00091: Exporting questionable statistics.
解决方法：exp的時候加了STATISTICS=NONE －－－－－－－－或者imp的时候指定RECALCULATE_STATISTICS=y
不导出统计信息，或者导入时候加上重新收集统计信息。
根本解决方法：
导出的时候重新设置环境变量
这个问题当前的环境变量NLS_LANG设置与数据库的不相同。
NLS_LANG=AMERICAN_AMERICA.数据库实际值
export NLS_LANG
第一遍导结构时导入一遍后,在导数据时会报ORA-20005错,显示该统计信息被锁定。加了statistics=none后暂时解决了这个问题
导入的时候一直报违反外键约束,触发器发生错误等。解决方法有二,一是在导数前手工disable掉所有的触发器和外键约束,二是直接全schema导入,不要分两遍导。
IMP-00058: ORACLE error 3113 encountered
ORA-03113: end-of-file on communication channel
如果第一次导入时，部分表没有导入，可以指定表名和owner来只导入部分表：
userid=username/password@dbname
file=(exp01.dmp,exp02.dmp,exp03.dmp,exp04.dmp,exp05.dmp,exp06.dmp,exp07.dmp,exp08.dmp,exp09.dmp,exp10.dmp,exp11.dmp,exp12.dmp,exp13.dmp,exp14.dmp,exp15.dmp,exp16.dmp,exp17.dmp,exp18.dmp,exp19.dmp,exp20.dmp,exp21.dmp,exp22.dmp,exp23.dmp,exp24.dmp,exp25.dmp,exp26.dmp,exp27.dmp,exp28.dmp,exp29.dmp,exp30.dmp,exp31.dmp,exp32.dmp,exp33.dmp,exp34.dmp,exp35.dmp,exp36.dmp,exp37.dmp,exp38.dmp,exp39.dmp,exp40.dmp,exp41.dmp,exp42.dmp,exp43.dmp,exp44.dmp,exp45.dmp)
fromuser=appdata
touser=hubei
tables=()
rows=y
commit=y
grants=n
indexes=n
constraints=n
RECALCULATE_STATISTICS=y
IGNORE=y
log=imp2.log
buffer=80000000
Import物化视图基表时导致严重的Latch Free
最近在使用imp恢复一个表的数据的时候，发现虽然imp数据到同一个库中的另外一个用户下的临时表，但是却导致了原用户下的该表上sql执行时都产生了非常多的latch free等待，严重影响到了应用的正常运行。
检查发现原用户下的表上LAST_DDL_TIME有变化，而最近也没得该表作什么DDL操作。而由于LAST_DDL_TIME更新了，导致对表上的所有sql都要重新解析，从而执行时都在等待latch free。
进行测试，发现如果exp时基表上没有mview log，则imp到另外用户下的临时表时不会对原表的LAST_DDL_TIME作修改，反之就会更新该时间，进而导致重新解析所有相关的SQL。
imp时如果dmp文件中带有mview log的创建语句，则在数据导入完成后会执行mview log数据的更新，但是由于本身mview log这个表不存在，所以就会提示错误信息：
ORA-06512: at line 1
IMP-00017: following statement failed with ORACLE error 942:
"BEGIN SYS.DBMS_SNAPSHOT_UTL.SYNC_UP_LOG('OWNER','TABLE NAME'); END;"
IMP-00003: ORACLE error 942 encountered
ORA-00942: table or view does not exist
ORA-06512: at "SYS.DBMS_SNAPSHOT_UTL", line 1589
ORA-06512: at line 1
在export/import中，经常遇到卷空间不足或者表空间不足的问题，不得不重新开始，浪费比较多的时间和人力。
9i及10g，对于export/import使用下面三个参数，可以在出现问题的时候，将export/import作业挂起来。等问题解决后，继续进行export/import，而不用重新开始。
RESUMABLE y 或者 n，控制是否作业可以继续
RESUMABLE_NAME 挂起作业名称
RESUMABLE_TIMEOUT 作业挂起多长时间后，中止作业。默认超时时间为7200秒,也就是2小时。
使用中，设置RESUMABLE=y，并给RESUMABLE_NAME一个名字，设置RESUMABLE_TIMEOUT为比较长的时间（我一半设置100个小时）。
在export/import过程中，定时查询dba_resumable视图，可以看到设置了resumable的作业信息。
如果作业没有挂起，ERROR_NUMBER 列为0，ERROR_MSG列为空。
当出现错误的时候，ERROR_NUMBER为相应的错误代码，ERROR_MSG为具体的错误信息。
根据ERROR_MSG信息，解决问题后，export/import作业会自动继续进行。
RESUMABLE=y
RESUMABLE_NAME=imp_lu001
RESUMABLE_TIMEOUT=720000
full imp之后，执行脚本授权，编译失效对象：
select object_type,count(*) from dba_objects where status='INVALID' group by object_type;
恢复所有的权限：
select 'grant ' ||privilege||' on ' || owner||'.'||table_name || ' to '|| grantee || ';' from dba_tab_privs;
select 'grant ' ||granted_role|| ' to '|| grantee || ';' from dba_role_privs;
select 'grant ' ||privilege|| ' to '|| grantee || ';' from dba_sys_privs;
select 'grant ' ||privilege||' on ' || owner||'.'||table_name || ' to '|| grantee || ' with grant option;' from dba_tab_privs where GRANTABLE='YES';
select 'grant ' ||granted_role|| ' to '|| grantee || ' with admin option;' from dba_role_privs where ADMIN_OPTION='YES';
select 'grant ' ||privilege||' to '|| grantee || ' with admin option;' from dba_sys_privs where ADMIN_OPTION='YES';
编译失效过程：
select 'alter '||OBJECT_TYPE||' '||OWNER||'.'||OBJECT_NAME||' compile;' from dba_objects where status='INVALID'
and object_type='PROCEDURE';
编译失效公共同义词：
select 'alter public '||OBJECT_TYPE||' '||OBJECT_NAME||' compile;' from dba_objects where status='INVALID' and
object_type='SYNONYM';
编译失效对象：
set linesize 151
set wrap on
set space 1
set feedback off
set timing off
set pause off
set term off
set heading off
set recsep off
set pagesize 0
set verify off
spool alt_pkg.sql
select 'PROMPT ALTER '||decode(object_type,'PACKAGE BODY','PACKAGE ',object_type||' ')
||owner||'.'||object_name ||' COMPILE'||decode(object_type,'PACKAGE BODY',' BODY;',';')||chr(10)
||'ALTER '||decode(object_type,'PACKAGE BODY','PACKAGE ',object_type||' ')
||owner||'.'||object_name ||' COMPILE'||decode(object_type,'PACKAGE BODY',' BODY;',';')
from dba_objects
where status ='INVALID'
order by object_type;
spool off
set feedback on
set timing on
set term on
set heading on
set recsep WRAP
set pagesize 14
set verify on
@@./alt_pkg
exit
１ 先根据appdata用戶下的view相关的同义词生成指向表的脚本同义词
spool 1.sql
create or replace public synonym '||synonym_name||' for '||owner||'.'||synonym_name||';' from dba_synonyms where table_owner='APPDATA' and table_name like '%_VW';
spool 2.sql
create or replace public synonym '||synonym_name||' for '||owner||'.'||table_name||';' from dba_synonyms where table_owner='appDATA' and table_name like '%_VW';
spool off
２ 创建指向表的同义词,运行１.sql
３ 重导applog用户，不导数据，导入表跟sequence的时候会报错，可以忽略
４ 重建appdata相关的公共同义词，运行２.sql
8i 每个版本的数据exp/imp 操作都会遇到这个问题，以下
是我们10g升级中规避这个问题的方法，还比较有效：
（1） 先导一次结构。
（2） 在applog用下建立被公有同义词指向view的同名的私有同义词，直接指向基表， (有公共同义词，有私有同义词，会先引用私有同义词）
提取脚本如下：
spool create_syn.sql
select 'create synonym applog.'||synonym_name||' for appdata.'||synonym_name||';' from dba_synonyms where table_owner='APPDATA' and wner='PUBLIC' and synonym_name<>table_name
and table_name in (select object_name from dba_objects where wner='APPDATA' and object_type='VIEW');
spool off
执行提取出来的脚本。
（3） 开始进行导入，应该不会遇到trigger创建失败的情形了。
（4） 导入完成 后，利用以下脚本抽取删除这些增加的私有同义词脚本，执行之。
spool drop_syn.sql
select 'drop synonym applog.'||synonym_name||';' from dba_synonyms where table_owner='appDATA' and wner='PUBLIC' and synonym_name<>table_name
and table_name in (select object_name from dba_objects where wner='appDATA' and object_type='VIEW');
spool off
--------------------------------------------------------------------------------
这次导库之后缺少很多trigger的原因是导入时报错ora－25001：
ORA-25001: cannot create this trigger type on views
需要到导入log文件查询是哪个表上的哪个trigger，进而查询和该表同名的公共或私有同义词是否指向了视图，指向了视图会导致无法在视图上创建trigger。
可能的原因是，在源数据库，该trigger是建立在table上的，建完trigger以后，创建了一个和该table同名的同义词，指向却是某个视图。
需要到源数据库拷贝trigger代码，在table前面加上owner.，绕过同义词，直接在table上创建该trigger。
经过在生产库查询，确实是因为源库上和这些trigger相关的表的公共同义词建立在了view上，这样导入的时候就不可避免的这些trigger导入不进去。
所以跨平台导测试库，即浪费时间，效果也不好。
5、
将Oracle 数据库中某个用户迁移到另外一个库上，迁移的数据量大小约 120GB 。如果采用 expdp 导出的话时间会很长，再加上导出的 DMP 文件拷贝和 impdp 导入数据的时间，不能满足要求。
这里采用 RMAN 的 CONVERT 功能和 exp/expdp 的 transport_tablespace 的功能。前者将用户所在的表空间的数据文件从一个数据库所在的系统平台中拷贝到另外一个数据库系统上，后者将表空间对应的 metadata 数据拷贝出来。
测试过程虽然顺利，但最后想到一个问题， rman 中的 catalog 记录的 copy 的文件已经被数据库实例占用的情况下，该记录如何删除掉？
后来想到 rman convert 方法，它将文件系统文件拷贝到 ASM 磁盘组，不在 catalog 中留记录。同时，这个方法免去了文件名称修改的操作，更简洁高效。
使用 convert 可以实现跨平台的数据迁移，这点在环境复杂的项目中非常有用。
首先，介绍一下环境。
源库是 redhat linux as 5 ，单数据库实例，文件系统格式保存数据文件，数据库版本为 10.2.0.4 。
目标库是 redhat linux as 5 ，两节点的 RAC ， ASM 格式保存数据文件，数据库版本为 10.2.0.4 。
可以使用 SELECT * FROM V$TRANSPORTABLE_PLATFORM; 检查这个版本上的表空间是否支持传输。结果当然是支持的。
其次，了解迁移的表空间和数据对象。
根据 dba_segments 查询到用户使用的哪些表空间，好决定要迁移的表空间。
在表空间确定了以后，如这里是 xxyy 。需要再根据表空间的 segment 都是哪些用户，如果不仅仅是要迁移的用户，还要将新的用户也找出来。
在目标库上提前将这些用户创建好。
这是因为我们采用的是表空间传输迁移数据，所以难免会有多的对象被迁移。根据实际情况权衡，决定是清理源头还是全部迁移。
表空间的 segment 的类型需要先分析一下。对于分区表、 IOT 表、 XMLType 对象等等不常见的，要先想想能不能用它迁移，这是第一点。
还有两点：一，目标库和源库的字符集要一致，否则请测试该方案；二、目标库不能有同名的表空间。
最后，开始正式迁移操作，步骤如下：
第一步，准备工作
校验表空间是否 self contained （注：不知道如何翻译，原文输出）
SQL> execute sys.dbms_tts.transport_set_check('XXYY', true);
SQL> select * from sys.transport_set_violations;
如果有记录，必须处理。
将表空间设置为只读状态。这点好理解，开始迁移了，就不能再写入数据到表空间了。
SQL> ALTER TABLESPACE XXYY READ ONLY;
第二步，使用 exp 导出表空间所有对象的 metadata
exp userid=\'sys/sys as sysdba\' file=tbs_exp.dmp log=tba_exp.log transport_tablespace=y tablespaces=XXYY
第三步，使用 rman 的 convert 将表空间的数据文件拷贝到文件系统上。
确定文件系统的平台名称
SQL> SELECT tp.platform_id,substr(d.PLATFORM_NAME,1,30), ENDIAN_FORMAT
2 FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
3 WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;
PLATFORM_ID SUBSTR(D.PLATFORM_NAME,1,30)
----------- ------------------------------------------------------------
ENDIAN_FORMAT
--------------
13 Linux x86 64-bit
Little
根据平台名称，拷贝出文件名称。
convert tablespace xxyy to platform="Linux x86 64-bit" FORMAT '/u01/oradata/servdb/%U';
测试操作过程如下
[oracle@xxtradedb1 servdb]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Apr 18 13:13:04 2012
Copyrigxx (c) 1982, 2007, Oracle. All rigxxs reserved.
connected to target database: SERVDB (DBID=3658273059)
RMAN> convert tablespace xxyy to platform="Linux x86 64-bit" FORMAT '/u01/oradata/servdb/%U';
Starting backup at 18-APR-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=347 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00035 name=/u01/oradata/servdb/datafile/xxyy01.dbf
^[converted datafile=/u01/oradata/servdb/data_D-SERVDB_I-3658273059_TS-XXYY_FNO-35_e1n8o3nc
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:10:55
Finished backup at 18-APR-12
第四步，将文件拷贝到目标库所在的系统上
这里使用 scp ，也可以使用 ftp ，那样会更快。
第五步，在目标库上建用户，导入数据
imp userid=\'sys/sys as sysdba\' file=tbs_exp.dmp log=tba_imp.log transport_tablespace=y datafiles='/dbbackup/servdb_rman/xxyy01.dbf'
第六步，检查表空间状态和调整表空间为读写
虽然目标库是 RAC ，文件又是保存在 ASM 上，但是也不是不能访问文件系统上的文件。
只是文件系统文件无法共享，所以，只能在一个节点上看到。
/dbbackup/servdb_rman@webdg1=>xxzq1$sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Apr 18 16:39:56 2012
Copyrigxx (c) 1982, 2007, Oracle. All Rigxxs Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
SQL> set linesize 300
SQL> col name format a50
SQL> r
1* select file#,name,status from v$datafile
FILE# NAME STATUS
---------- -------------------------------------------------- -------
1 +LOGDG/xxzq/system01.dbf SYSTEM
2 +LOGDG/xxzq/undotbs01.dbf ONLINE
3 +LOGDG/xxzq/sysaux01.dbf ONLINE
4 +LOGDG/xxzq/users01.dbf ONLINE
5 +LOGDG/xxzq/undotbs02.dbf ONLINE
6 +LOGDG/xxzq/tbs_yy01.dbf ONLINE
7 /dbbackup/servdb_rman/xxyy01.dbf ONLINE
7 rows selected.
这个结果表空间的数据在其他实例上也操作了，将导致系统宕机，因为其他实例根本不能读写到这个系统上的文件。
我们正常将是设置为读写状态。这是为了将文件从文件系统上迁移到 ASM 上。
SQL> alter tablespace xxyy read write;
如果不将表空间设置为读写状态，则对此表空间文件的 COPY 将出错。开始我也没设置为读写，所以报错了。
RMAN> backup as copy datafile '/dbbackup/servdb_rman/xxyy01.dbf' format '+LOGDG/xxzq/xxyy01.dbf';
Starting backup at 18-APR-12
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 04/18/2012 16:45:25
RMAN-20201: datafile not found in the recovery catalog
RMAN-06010: error while looking up datafile: /dbbackup/servdb_rman/xxyy01.dbf
RMAN> exit
设置为读写后，正常将数据文件拷贝一份到了 ASM 上。
backup as copy datafile '/dbbackup/servdb_rman/xxyy01.dbf' format '+LOGDG/xxzq/xxyy01.dbf';
第七步，将文件离线，在重命名就可以了。
SQL> alter database datafile '/dbbackup/servdb_rman/xxyy01.dbf' offline;
Database altered.
SQL> alter database rename file '/dbbackup/servdb_rman/xxyy01.dbf' to '+LOGDG/xxzq/xxyy01.dbf';
Database altered.
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+LOGDG/xxzq/system01.dbf
+LOGDG/xxzq/undotbs01.dbf
+LOGDG/xxzq/sysaux01.dbf
+LOGDG/xxzq/users01.dbf
+LOGDG/xxzq/undotbs02.dbf
+LOGDG/xxzq/tbs_yy01.dbf
+LOGDG/xxzq/xxyy01.dbf
7 rows selected.
SQL> alter database datafile 7 online;
alter database datafile 7 online
*
ERROR at line 1:
ORA-01113: file 7 needs media recovery
ORA-01110: data file 7: '+LOGDG/xxzq/xxyy01.dbf'
SQL> recover datafile 7;
Media recovery complete.
SQL> alter database datafile 7 online;
Database altered.
SQL> exit
迁移实际上到这步就结束了。
但最后想到一个问题。
我们将文件使用 copy 拷贝到了 asm 中，然后让实例使用了。
这时， rman 的 catalog 还是认为这个文件是它的一个拷贝，虽然不能删除，但始终是个芥蒂。
/dbbackup/servdb_rman@webdg1=>xxzq1$rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Apr 18 16:20:36 2012
Copyrigxx (c) 1982, 2007, Oracle. All rigxxs reserved.
connected to target database: XXZQ (DBID=485623294)
RMAN> list copy;
using target database control file instead of recovery catalog
specification does not match any archive log in the recovery catalog
List of Datafile Copies
Key File S Completion Time Ckp SCN Ckp Time Name
------- ---- - --------------- ---------- --------------- ----
3 7 A 18-APR-12 98532714754 18-APR-12 +LOGDG/xxzq/xxyy01.dbf
尝试使用 RMAN 的 switch 作数据文件重命名，但 rman 中还是有这个记录，不能除掉。
RMAN> switch datafile '/dbbackup/servdb_rman/xxyy01.dbf' to copy;
最后，想到一个方法。使用 convert 代替 copy 将数据文件复制到 ASM 中。 convert 操作是不在 catalog 中留记录的。
上面列的操作步骤在第四步之后就进行跳转。
第四步中将文件传输到文件系统中后，使用 rman convert 将文件复制一份到 ASM 磁盘组中。
这个 convert 功能在 rman catalog 中不保留记录，可以实现 ASM 和文件系统的文件相互转移。
方法如下：
convert datafile '/dbbackup/servdb_rman/xxyy01.dbf' format '+LOGDG/xxzq/xxyy01.dbf';
这个文件约 5GB ，所用时间为 35 秒。
RMAN> convert datafile '/dbbackup/servdb_rman/xxyy01.dbf' format '+LOGDG/xxzq/xxyy01.dbf';
Starting backup at 19-APR-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=105 instance=xxzq1 devtype=DISK
channel ORA_DISK_1: starting datafile conversion
input filename=/dbbackup/servdb_rman/xxyy01.dbf
converted datafile=+LOGDG/xxzq/xxyy01.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:35
Finished backup at 19-APR-12
第五步，在目标库上建用户，导入数据
imp userid=\'sys/sys as sysdba\' file=tbs_exp.dmp log=tba_imp.log transport_tablespace=y datafiles='+LOGDG/xxzq/xxyy01.dbf'
这个步骤和上述用的差别就是文件名称的差别。
第六步，检查表空间状态和调整表空间为读写
因为数据文件本身就在 ASM 磁盘组上， RAC 的两个节点都能访问得到该文件，所以我们先查查文件状态。
SQL> set linesize 300
SQL> col name format a50
SQL> r
1* select file#,name,status from v$datafile
FILE# NAME STATUS
---------- -------------------------------------------------- -------
1 +LOGDG/xxzq/system01.dbf SYSTEM
2 +LOGDG/xxzq/undotbs01.dbf ONLINE
3 +LOGDG/xxzq/sysaux01.dbf ONLINE
4 +LOGDG/xxzq/users01.dbf ONLINE
5 +LOGDG/xxzq/undotbs02.dbf ONLINE
6 +LOGDG/xxzq/tbs_yy01.dbf ONLINE
7 +LOGDG/xxzq/xxyy01.dbf ONLINE
7 rows selected.
所有文件都是 ONLINE 的状态。
我们将其设置为读写状态，这样用户就可以读写迁移过来的表空间中的所有对象了。
SQL> alter tablespace xxyy read write;
我们回到 RMAN 中，使用 list copy 检查一下文件有没有拷贝记录。
/u01/oracle/home@webdg1=>xxzq1$rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Thu Apr 19 09:46:23 2012
Copyrigxx (c) 1982, 2007, Oracle. All rigxxs reserved.
connected to target database: XXZQ (DBID=485623294)
RMAN> list copy;
using target database control file instead of recovery catalog
specification does not match any archive log in the recovery catalog
结果和我们想的一样，在 rman catalog 中没有任何记录。因此该方法应该是首选。
总结
对已大数据量的迁移工作，使用表空间传输的方法实现是效率比较高的一种方法。
exp/expdp 迁移 metadata ， rman convert 迁移数据文件。
他们的联合使用，可以支持跨平台、跨文件系统的迁移，这点在环境复杂的项目中非常有用。
