Oracle数据泵单实例迁移全流程详解：从expdp到impdp

搞Oracle数据库搬迁绕不开的一个词就是数据泵Data Pump。单实例环境来回同步数据expdp导出、impdp导入这套组合我这些年用了不下几十次说它是最皮实的逻辑迁移方案不为过。别看这个标题“单实例环境使用数据泵Data Pump数据迁移”更像是文档里的章节名真正落地时从导出前的配置核对到导入后的无效对象编译每一步都可能让迁移计划晚点几小时。这篇文章就把我在多次单实例迁移实战中验证过的步骤、参数、坑全部摊开讲适合正在准备数据库搬迁或做同构环境刷数据的工程师参考。1. 场景确认与选型逻辑1.1 先搞清楚“单实例数据泵”解决什么问题很多人一看到“单实例环境”就开始写命令其实不对。得先确认你到底要迁什么。这个场景最常见的有三类一是整库迁移比如把某套业务库从旧的单实例服务器挪到新的单实例服务器数据库版本可能相同也可能不同二是schema级迁移比如把某个应用用户下的全部对象和数据搬到同库或异库这是做环境拆分、灰度割接时最高频的操作三是部分数据迁移只迁几张核心表或者按条件过滤的数据通常是为了搭建报表库、准实时查询库。单实例环境的含义也要说清楚源端和目标端都是独立的一个数据库实例没有RAC没有Data Guard。这决定了数据泵迁移时不用考虑集群并行、不用处理备用库的apply延迟整体逻辑要简单不少。但简单不等于能粗心单实例同样有大版本差异、字符集差异、表空间分布差异这些问题后面展开讲。数据泵这套工具从Oracle 10g开始就是官方主推的逻辑迁移手段替代了老掉牙的exp/imp。它的核心价值在于不要求源端和目标端硬件一致不依赖操作系统路径跨平台跨版本都能走只要两端数据库能正常跑数据就能以dmp文件为媒介搬过去。1.2 为什么选数据泵而不是物理迁移或同步工具做迁移方案时一定会有人问为什么不用冷备、热备、rman直接恢复这个问题我在方案评审时被问过很多次。物理备份的方式不是不行而是匹配不上单实例逻辑迁移的诉求。物理迁移要求目标端数据库版本大版本不能低于源端且操作系统平台最好一致否则数据文件恢复后要碰byte-order和版本兼容问题。数据泵则宽松得多版本方面可以通过version参数向下兼容字符集可以做转换表空间名不同可以重映射连用户名变了都能remap逻辑层的灵活性是物理手段给不了的。为什么不直接用OGG或增量同步工具因为这类工具是为持续同步设计的配置复杂度高需要额外的同步账号、抽取进程和网络端口在一次性搬迁的场景里属于杀鸡用牛刀。数据泵的定位就是“导出那一刻的快照”业务停写窗口内导一次、导完验证、直接切换没有持续链路需要维护。我的习惯是画一张简单的取舍对比表给决策者看迁移方式跨版本能力跨平台能力对象级迁移操作复杂度典型场景数据泵逻辑迁移强可指定version强与OS无关强中低单实例对单实例搬迁RMAN物理备份恢复弱需大版本兼容弱需同字节序无中同平台整库迁移冷备/热备弱弱无低同环境快速恢复OGG/同步工具强强中高持续同步、在线切换单实例搬迁时间窗口通常以小时计数据泵这种“导出归档、异地导入”的模式最匹配。它还能边导边观察日志出问题可以断点续跑不会像物理恢复那样失败了又得重拷几十GB数据。这一点在后面的实操里会体现得更明显。2. 导出前的盘点和准备工作2.1 源端和目标端的硬性条件核对导出之前我会先做一份“环境体检清单”这几项不过关后面一定会炸。数据库版本。源端版本要记录完整包括补丁级别。数据泵的dump文件理论上可以往相同或更高版本导入如果目标版本比源端低导出时必须用version参数限制生成的对象语法否则导入时很可能碰到创建对象失败的情况。我的经验是尽量让目标版本不低于源端省掉一大部分兼容性麻烦。平台与字节序。数据泵导出的dmp文件是逻辑格式跨平台天然支持不需要额外关心字节序。但如果你源端是Linux目标端是Windows导入后要注意路径相关对象比如目录对象、外部表定义、BFILE位置这些不会自动改写。字符集。这个是单实例迁移最容易被低估的坑。检查源库和目标库的SELECT parameter, value FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET);如果两端字符集不一致impdp时会隐式转码轻则告警重则因为目标库字符集容纳不下某些字符直接报ORA-12899。我的原则是既然是新环境尽量把目标库字符集规划成AL32UTF8彻底规避后续业务扩展的字符集瓶颈。空间估算。导出端要看dmp落盘空间导入端要看目标表空间剩余空间。更稳妥的做法是导入前先查一下源库里需要迁移的segment总量SELECT owner, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb FROM dba_segments WHERE owner APP_USER GROUP BY owner;按表、索引分开统计会更好因为导入时表和索引是分别创建、分别占用空间的索引空间至少要按源库的1.2倍预留因为并行导入时索引构建的临时排序空间也会占用临时表空间。2.2 迁移窗口和数据一致性策略数据泵导出的默认模式不是一致性快照如果导出过程中业务还在写数据dump文件里不同表可能处于不同时间点。正规做法是利用Oracle的闪回查询机制给导出指定一个SCN。在单实例环境里操作很简单先找业务方确认停写时间窗口在窗口开始后查询数据库当前SCNSELECT CURRENT_SCN FROM V$DATABASE;然后把这个SCN写进导出参数。注意业务必须在SCN记录之前就要停止写入否则还是会拿到导出过程中的数据。如果业务没法完全停写就尽量在夜间低峰期做同时用SCN保证导出内部一致这样至少不会出现外键子表有数据、父表没有数据的最坏情况。也有人喜欢用flashback_time但我更推荐SCN因为时间到SCN的映射偶尔会有偏差SCN更精确、更好在文档里记录。迁移记录里写明“本次导出SCN为xxx”后续如果要对数、复盘这就是唯一的基准点。2.3 目录对象、dump空间和参数文件数据泵必须在数据库里先建目录对象再把操作系统路径指向它。这个步骤看似基础翻车率其实很高。首先要保证操作系统层面ora用户对目录有读写权限其次要在数据库里创建CREATE OR REPLACE DIRECTORY DP_DIR AS /data/dp; GRANT READ, WRITE ON DIRECTORY DP_DIR TO app_user;检查目录是否生效SELECT owner_name, directory_name, directory_path FROM dba_directories WHERE directory_name DP_DIR;dump文件空间要提前算清楚。源库100GB数据压缩前dump可能就有80GB压缩后可能只有20GB。千万不要把空间算得太死我给自己的硬性标准是预留导出文件1.5倍的空间并且导出过程中随时用df -h观察。如果dump要跨网络传最好在导出端做完压缩再传省带宽、省时间。真正执行复杂迁移时我不建议把一长串参数堆在命令行里而是建议写parfile参数文件这样既方便留档也方便改一下参数重新执行。比如exp.par就专门存放导出参数执行时用expdp system/xxx parfileexp.par这样日志里能随时查看参数来历排查问题时不用猜。3. expdp导出实操把数据安全地装进dmp3.1 导出粒度与对象范围的选择导出粒度决定了整个迁移的复杂度。全库导出fully会带上系统对象、目录对象、dblink等一大批东西在单实例对单实例迁移中通常不是最优选择因为目标库有自己的系统环境、目录对象和dblink规划全部照搬反而引发冲突。我在单实例迁移里90%的情况用schemas参数指定应用schema比如只导app_user。范围明确相关的表、索引、约束、触发器、序列、物化视图、授权都会一起导出目标端重建后对象依赖关系也比较完整。如果只想迁几张核心表用tables参数指定表名。但要注意只用tables导出时表上的索引、约束等依赖对象可能不会一起导出需要额外用include参数点出来或者干脆接受“只导数据、目标端手动重建索引”的方案。我自己的习惯是除非表极大、通过分区按片迁移否则凡是要迁移业务表尽量连schema一起导省得后续补对象补到怀疑人生。3.2 并行度、压缩和一致性参数怎么定并行度是数据泵性能的关键也是新手最容易乱拍脑袋的地方。并行度的设置要结合CPU核数和dump文件数量。数据泵的并行是进程级并行每个并行进程处理不同的对象或不同的数据分片。如果用parallel4dumpfile最好写成%U通配形式directoryDP_DIR dumpfileSMP_%U.dmp logfileEXP_SMP.log schemasapp_user parallel4 compressionALL flashback_scn123456789 status300%U会按并行度生成SMP_01.dmp、SMP_02.dmp等多个文件多进程同时写不会互相锁文件。并行度一般取CPU核数的一半左右或者参考主机负载。我之前在16核的单实例环境上跑过parallel8IO能压满如果数据库主机还跑着业务parallel4到6更稳妥太高了容易把IO打爆反而拖慢导出。compression参数用来压缩dump文件。ALL表示元数据和数据都压缩前提是源库有Oracle企业版压缩组件。压缩会吃掉CPU换来的是更小的文件体积和更短的网络传输时间。我的经验是本地磁盘空间充足、跨网络传输距离短开METADATA_ONLY就够跨机房、跨城市迁移直接开ALL能省一半甚至更多的数据量。一致性快照通过flashback_scn实现这个参数和并行压缩不冲突可以同时使用。需要注意的一个细节如果设置了flashback_scn那么导出开始时Oracle会在undo里维护一份SCN点的一致性视图undo_retention期间的数据不能被覆盖。如果源库写压力大、SCN点又很老导出过程中可能出现ORA-01555快照过旧。解决办法是尽量让业务停写窗口和导出开始时间接近或者在导出前临时增大undo_retention并保证undo表空间足够宽裕。3.3 导出过程的监控与中断处理数据泵作业可以实时查看状态。我自己跑长任务时习惯用status参数比如status300表示每300秒输出一次进度到日志外加屏幕上也能看到。如果执行命令的终端断了也别慌数据泵作业是数据库侧的任务不会因为终端断开就杀掉。想要主动查询任务进度可以用SELECT job_name, state, operation, status FROM dba_datapump_jobs;或者执行expdp时按CtrlC进入交互模式输入status查看详情。交互模式里还能stop_job把任务暂停下次用attachjobname重新拉起来继续跑如果确认任务报废了再输入kill_job彻底删除。这里有一个我踩过好几回的坑不要在一个正在跑的job上直接kill -9杀会话否则容易留下残余进程和半截文件下次重新导出反而因为同名文件存在产生冲突。稳妥流程是先CtrlC进入交互用stop_jobimmediate正常停掉再决定是续跑还是重导。导出成功的标志是日志最后出现“Job ... successfully completed”如果只看到“completed with errors”说明有不影响主流程的对象失败必须打开日志逐条排查。4. impdp导入实操让数据在目标库安家4.1 导入前的目标库准备导入端准备这块重点不是执行命令而是把目标库的“地基”打好。我见过太多人直接跑impdp跑到一半报ORA-01950没有表空间配额或者ORA-00959表空间不存在才想起来用户还没建好。目标库先建表空间大小参照源库统计同时打开自动扩展CREATE TABLESPACE TGT_DATA DATAFILE /u01/oracle/oradata/TSTDB/tgt_data01.dbf SIZE 32G AUTOEXTEND ON NEXT 8G MAXSIZE UNLIMITED;临时表空间也一样按最大排序需求留足。然后建用户。如果目标库用户名和源库一致直接建同名的如果不一致导入时用remap_schema重映射。建用户时至少要授权连接和资源角色还有导入操作需要的权限。数据泵导入本身通常用system账号跑但目标schema对应的业务用户不能缺。导入前再把目录对象搭好dump文件传到目标服务器。传输过程我习惯生成一份md5校验尤其是跨网络传输超大dump时哪怕一个字节损坏导入到中间阶段报错排查成本远高于起步前那十几秒钟的校验时间。4.2 重映射与对象处理的关键参数两个环境表空间名不一致、用户名不一致都是单实例迁移的常态。impdp提供了remap_schema和remap_tablespace这两个王牌参数directoryDP_DIR dumpfileSMP_%U.dmp logfileIMP_SMP.log schemasapp_user parallel4 remap_schemaapp_user:target_user remap_tablespaceAPP_DATA:TGT_DATA table_exists_actionSKIP status300remap_schema的作用是把dump里的app_user所有对象全部转成target_user。注意这里不只是数据归属变化序列、同义词、授权关系都会跟着映射非常省心。remap_tablespace则是把APP_DATA表空间下的对象全部重建到TGT_DATA适合目标库表空间命名规范不同的情况。table_exists_action这个参数要特别小心。默认情况下如果目标库已经有同名的表impdp会报ORA-39151并跳过该表不会覆盖。显式指定SKIP只是把跳过行为明确化适合导数据时目标表已经存在且结构一致的情况。指定REPLACE会先drop再重建如果目标表有数据会全部清掉非明确需求不要用。指定APPEND则是往已有表里追加数据主键冲突时照样报错。我的做法是导入前目标schema尽量清空重置然后用默认行为导入宁可让重复对象报错也不要因为REPLACE误删数据。另一个很实用的参数是transformsegment_attributes:n。它可以在导入时忽略dump文件里记录的存储属性、表空间属性全部改用目标库的表空间默认配置。配合remap_tablespace一起用能避免很多目标库存储参数不兼容的报错。我通常在跨版本导入时加上它让表、索引使用目标库默认的区管理和段空间管理方式对后续运维更友好。4.3 先结构后数据还是全量一次导小数据量直接一把梭命令跑完就完事。但数据量一上来比如几百GB的库我还是建议分阶段导入先只导结构再导数据最后补索引约束。好处是结构问题在早期就暴露不会等到数据导了一半才发现某张表的表空间不存在、某列类型不兼容再回头重导。分阶段做法 第一步用contentmetadata_only只导入结构contentmetadata_only第二步用contentdata_only只导入数据contentdata_only第三步如果第二步没用include排除索引和约束通常结构和数据合并导入后索引也会建好。但为了提升第二阶段速度我习惯在metadata_only阶段先用exclude排除索引和约束等数据导完再单独补索引。补充索引和约束时不需要重新打开全部dump用sqlfile参数先从dump里生成对应SQL脚本人工过一遍再执行更稳妥。sqlfile不会实际执行DLL只是把对象创建语句写到文件里。我用它来预检要导入的对象定义确认没有乱码、没有不兼容语法再放行到生产。4.4 导入过程的常见策略pre-check导入前建议先用sqlfile模式做一次全文对象预检。命令sqlfilePRE_IMP.sql生成脚本后重点看几类东西表空间引用是否有源库才有的名字、用户引用是否匹配remap后的目标用户、列类型定义里有没有目标版本不支持的写法、CLOB/BLOB所在的lob表空间是否被正确映射。这个步骤也就多花几分钟但可以把导入时的报错从几十个降到零。导入期间的监控和导出一样用dba_datapump_jobs查询job状态。如果中途发现并行度设置不合理按CtrlC进入交互模式stop_job后再用parallel不同的参数重新attach继续不必全部推翻重来。不过要提醒一句中途改并行度对效率有损耗最好开工前根据目标库CPU核数决定好不要导一半频繁调整。5. 导入后的专项验证与收尾5.1 数据行数、对象个数的核对方法导入日志显示成功并不等于数据就正确。每次迁移割接我都坚持做一遍独立于数据泵日志的对数检查。最基础的行数比对。在源库和目标库分别跑以下统计按表维度对比SELECT owner, table_name, num_rows FROM dba_tables WHERE owner APP_USER ORDER BY table_name;注意num_rows是统计信息里的估算值不是精确行数。如果导入时保留了统计信息这个值基本能和源库对齐如果导入时选择重新收集统计信息num_rows会来自新库的收集结果本质上也是一种估算。真要精确对大表用COUNT()采样对比几张大表即可全表COUNT()除非表很小否则别在生产上跑。对象个数的对比同样重要。我会统计表、索引、约束、触发器、序列、物化视图、同义词、包、存储过程、函数、类型等各类对象数量源端和目标端分别查SELECT object_type, COUNT(*) FROM dba_objects WHERE owner APP_USER GROUP BY object_type ORDER BY object_type;两边数量不一致时优先排查missing objects然后回到导入日志里搜对应对象名确认是不是被SKIP了。5.2 无效对象编译和依赖修复导入后的对象状态往往有零星INVALID尤其是跨版本迁移和使用了remap_schema的场景大量包、视图、函数会因为依赖对象的owner变化而失效。先查SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status INVALID GROUP BY owner, object_type;单实例环境通常直接用Oracle自带的并行编译工具处理EXEC UTL_RECOMP.RECOMP_PARALLEL(4);编译完成后再查一遍INVALID对象如果还有残留就需要逐一查看具体报错。常见的原因是权限缺失或者依赖的同义词没有同步导入。比如某个包A引用另一个schema下的包B而remap_schema只处理了目标schema内的对象引用跨schema依赖别忘了手工授权。5.3 序列、外键、触发器等容易被忽略的部分序列这个问题非常典型因为expdp/impdp不会自动拉高序列值。数据导过去后业务主键是用序列生成的而序列可能还是从1开始这就会导致应用插入数据时直接主键冲突。每次迁移我都要手动处理SELECT MAX(id) FROM target_user.biz_table; -- 假设最大id是800000 ALTER SEQUENCE target_user.seq_biz_id INCREMENT BY 1 START WITH 800001 RESTART;Oracle 12c以上可以直接ALTER SEQUENCE target_user.seq_biz_id RESTART START WITH 800001;关键是找到业务核心表的主键生成序列逐个核对。外键和触发器的启停状态也要检查。impdp默认会试着重建约束和触发器但状态可能是DISABLE或者在导入中途被临时禁用。导入完成后执行SELECT owner, constraint_name, status FROM dba_constraints WHERE ownerTARGET_USER AND constraint_typeR AND statusENABLED; SELECT owner, trigger_name, status FROM dba_triggers WHERE ownerTARGET_USER AND statusENABLED;把发现的DISABLED对象逐一确认并启用。5.4 业务联调与割接时的注意事项技术侧验证做完真正决定迁移成败的是业务联调。给应用一个只读账号连到目标库跑一遍核心链路查数据、写数据、跑报表有条件就把源端和目标端并行挂一段时间做对比。割接那一刻有几个细节我每次都会再确认一次一是应用连接串是否指向新库如果是改了DNS或负载均衡先清缓存再切二是目标库是否开了归档模式切换后有没有定期备份的规划三是迁移用的临时账号、目录对象是否回收避免留下后门权限。切完之后至少观察一个完整业务周期确认没有慢查询、没有锁等待再宣布迁移完成。6. 高频报错与排查技巧6.1 目录、权限、作业状态相关ORA-39087目录对象名称无效和ORA-39002操作无效这俩经常一起出现本质是directory参数写的名字在dba_directories里不存在。先查目录再确认操作系统目录存在且db进程有权限。还有一个隐蔽场景目录对象名大小写。如果不带双引号Oracle默认大写你写的DP_DIR没问题如果建目录时用了小写如“dp_dir”查询时必须用双引号匹配参数文件里也得注意。ORA-31603对象不存在多半是schemas参数里指定了目标数据库里不存在的用户。导入前先用dba_users确认源schema名称拼写正确别把用户名前后的空格复制进去了。导入时报ORA-31684对象已存在时不要盲目加table_exists_actionREPLACE跑一轮先搞清楚是哪类对象重复。如果是序列、同义词这些小对象可以直接drop后重导如果是大表确认目标表是否可放弃再考虑替换。6.2 表空间和存储相关ORA-39111源表空间在目标库不存在是单实例迁移最常见的问题之一。看到这个错误先确认表空间名是否真的需要保留。如果目标库有等价表空间只是名字不同用remap_tablespace如果目标库压根没有对应表空间先建好或改成直接transformsegment_attributes:n忽略段属性。ORA-01652、ORA-01653是目标表空间空间不足一个针对临时段一个针对数据段。这类问题都出在准备阶段没算清楚。我在前面强调过按源库segment总量估算这里再补充一点CLOB/BLOB的lob段和索引段占用要单独看避免只看表和索引普通段大小。ORA-01950无表空间配额相对好解决给目标用户授权足够配额或者直接GRANT UNLIMITED TABLESPACE。如果公司安全规范不允许无限配额就按源库各表空间的实际使用量手动分配合适额度。6.3 字符集、编码与乱码字符集问题最烦人因为它不是报错而是静默产生乱码。导入后抽查几张含中文的表逻辑上先看能不能正常显示再检查长度是否符合预期。如果源库是ZHS16GBK目标库是AL32UTF8一般可以无损转换反过来从AL32UTF8往ZHS16GBK转遇到生僻字会直接ORA-12899或截断这是规划目标库字符集时就要规避的问题。6.4 并行性能与中断续跑导得慢绝大多数是并行度没对上。一台8核的机器开parallel16线程切换比干活还多速度反而上不去。我用一个朴素的判断标准CPU核数的1/2到3/4之间试跑观察主机负载和磁盘IO曲线如果IO已经是瓶颈再加并行也无济于事。作业中断恢复的关键是知道job还在不在。只要dba_datapump_jobs里能看到job就有救。我常用的恢复方式是expdp或impdp加attach参数进入交互模式输入restart重新激活或者用start_job继续。如果状态变成NOT RUNNING且日志没有明显错误多半是终端的会话被杀导致主控进程失联用attach重新接管一般能恢复。有一点必须提醒中断后恢复读取的是已生成的dump文件中断前写了一半的文件如果再被其他进程写容易损坏所以恢复前先确认没有并列的作业进程在同时操作同一组dump文件。如果dump文件本身损坏任何恢复手段都救不回来只能在源库重新导出一遍这也是我前面坚持做md5校验的原因。根据我个人操盘几十次单实例迁移的经验最值钱的建议其实就一句话数据泵迁移不怕慢怕的是不检查、不验证。导出前花半小时盘点环境导入后花一小时对数、编译、查序列这半小时和一小时能省掉后面一整夜的割接返工。你可以先把这套流程跑通一个小库试一次把每一步该核对的项目列成清单正式迁移时按清单打勾比临时查文档、翻报错靠谱得多。