生产环境：
源数据库：Windows Server + Oracle 11.2.0.1
目标数据库：SunOS + Oracle 11.2.0.3
1.确认迁移需求：源数据库cssf 用户所有表和数据迁移到目标数据库新建用户cssf_gt下,表空间为dbs_cssf_gt。
网络情况：数据库之间网络不通畅，不适合dblink应用场景。
数据量：小数据量级别，10G以下。
数据库字符集：两库相同。
采用方案：exp/imp一次迁移，导出的中间文件压缩后传输到目标端。
2.查看源数据库相关信息：
2.1确认数据库字符集
SQL> select userenv('language') from dual; USERENV('LANGUAGE') ---------------------------------------------------- SIMPLIFIED CHINESE_CHINA.ZHS16GBK
2.2确认需要迁移的表数量
SQL> show user User is "cssf" SQL> select count(*) from user_tables; COUNT(*) ---------- 141
2.3确认当前表都存储在哪些表空间
SQL> select distinct tablespace_name from user_tables; TABLESPACE_NAME ------------------------------ DBS_CSSF DBS_CSSF_HUB
3.迁移
3.1源数据库局域网内11.2.0.1客户端导出（导出文件压缩后传到目标数据库所在地局域网内）：
C:UsersAlfred>exp cssf/cssf@192.168.1.10/bj owner=cssf file='E:jingyucss f.dmp' log='E:jingyucssf.log' direct=y
3.2目标数据库建立表空间，创建用户并赋权
create tablespace DBS_CSSF_GT datafile '/home/oradata/JYZHAO/datafile/DBS_CSSF_GT.dbf' size 30G; create user cssf_gt identified by cssf_gt default tablespace DBS_CSSF_GT; grant dba to cssf_gt;
3.3目标数据库所在局域网内的web服务器上导入文件
C:UsersAdministrator>imp cssf_gt/cssf_gt@192.168.10.10/sh file='D:jingyu cssf.dmp' log='D:jingyuimpcssf.log' full=y Import: Release 11.2.0.1.0 - Production on 星期四 5月 22 17:45:30 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Produc tion With the Partitioning, OLAP, Data Mining and Real Application Testing options 经由常规路径由 EXPORT:V11.02.00 创建的导出文件 警告: 这些对象由 CSSF 导出, 而不是当前用户 已经完成 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集中的导入 . 正在将 CSSF 的对象导入到 CSSF_GT . . 正在导入表 "CFG_DISTRICT"导入了 189 行 ... . . 正在导入表 "WF_H_WORKITEM"导入了 0 行 即将启用约束条件... 成功终止导入, 没有出现警告。 C:UsersAdministrator>
3.4检查目标数据库导入的表信息
select distinct tablespace_name from user_tables;
select table_name, tablespace_name from user_tables;
发现虽然上面显示已经成功终止导入，且创建用户时已经指定默认表空间为DBS_CSSF_GT，但由于目标数据库本来有DBS_CSSF表空间，导致源数据库此表空间的表在目标数据库的表空间也是DBS_CSSF，而不是期望的DBS_CSSF_GT，不符合本次迁移要求。
4.解决思路：
4.1可以直接alter table修改表的表空间归属
select 'alter table '||table_name||' move tablespace dbs_cssf_gt;' from user_tables;
查询得到的sql复制执行即可。
move操作后一定要记得要重建表的索引。
select 'alter index '||index_name||' rebuild tablespace dbs_cssf_gt online;' from user_indexes where status = 'UNUSABLE' order by index_name;
这里move 遇到了一些问题，涉及篇幅较多，后期会单独发布一篇随笔。
4.2关注imp其他参数
没有找到适合的参数。
5.延伸：
在我的测试环境中（RHEL 6.4 + oracle 11.2.0.3），没有DBS_CSSF表空间的情况下，同样步骤用3.3的导入语句导入，大部分表会自动将表空间归属变更为DBS_CSSF_GT，但过程中部分表导入出现报错IMP-00017,IMP-00003,ORA-00959：
. . 正在导入表 "CSSF_INFC_SH_SUSPEND"导入了 0 行 IMP-00017: 由于 ORACLE 错误 959, 以下语句失败: "CREATE TABLE "CSSF_INTERFACE_ERROR_LOG" ("LOG_ID" VARCHAR2(40) NOT NULL ENA" "BLE, "FAULT_ID" VARCHAR2(50), "WF_SN" VARCHAR2(50), "CITY_ID" VARCHAR2(50)," " "ACCEPT_NUM" VARCHAR2(50), "ERROR_MSG" VARCHAR2(500), "EXCEPTION_CONTENT" " "CLOB, "DISPATCH_CONTENT" CLOB, "CREATETIME" DATE, "CURRENTTASKID" VARCHAR2(" "50), "CURRENTNEXTID" VARCHAR2(50), "INTERFACETYPE" VARCHAR2(20), "ISREPAIR"" " VARCHAR2(2), "REPAIRTIME" DATE) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS" " 255 STORAGE(INITIAL 65536 NEXT 8192 MINEXTENTS 1 FREELISTS 1 FREELIST GROU" "PS 1 BUFFER_POOL DEFAULT) TABLESPACE "DBS_CSSF" LOGGING NOCOMPRESS LOB ("EX" "CEPTION_CONTENT") STORE AS BASICFILE (TABLESPACE "DBS_CSSF" ENABLE STORAGE" " IN ROW CHUNK 8192 RETENTION NOCACHE LOGGING STORAGE(INITIAL 65536 NEXT 1" "048576 MINEXTENTS 1 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)) LOB" " ("DISPATCH_CONTENT") STORE AS BASICFILE (TABLESPACE "DBS_CSSF" ENABLE STO" "RAGE IN ROW CHUNK 8192 RETENTION NOCACHE LOGGING STORAGE(INITIAL 65536 NE" "XT 1048576 MINEXTENTS 1 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT))" IMP-00003: 遇到 ORACLE 错误 959 ORA-00959: 表空间 'DBS_CSSF' 不存在 . . 正在导入表 "CSSF_JCS_BHSYNC_RECORD"导入了 4 行
这是因为这些表包含了lob字段，解决方案有以下几种：
a.导入后根据日志将这些表单独建立,重新导入。
b.建立好所有需要的表空间,重新导入,导入后参照4.1做move操作,然后删掉新建的无用表空间。
6.总结：
EXP/IMP迁移，如果迁移的表在源数据库和目标数据库表空间不一样，需要注意这些表是否包含lob字段，如果有，先在目标数据库创建这些表，再执行导入操作。
同样的，对于分区表、分区索引等也是这样。
如果采用EXPDP/IMPDP迁移，则可以利用remap_tablespace参数轻松解决上述问题。
------------------------------------------------------------------------------------
免责声明：为保证商业安全，本案例涉及的相关IP地址和名称已做特殊处理。