半夜两点，机房的风扇声比平时更刺耳。我盯着屏幕上刚退回的impdp日志，一行ORA-39083下面跟着十几张表创建失败，而客户给的停机窗口只剩四个小时。那次是我第一次在生产环境里独立完成一次 Oracle 数据泵全库迁移，之前我只会用老式的exp/imp，结果几百 GB 的数据跑了一宿没跑完，还因为序列没跟着走导致应用报错。从那以后，我把 Oracle 数据泵 expdp/impdp 这套工具彻底啃了一遍，前后在十几个项目里做过库间迁移、单表抽取、跨版本升级、异地容灾演练，踩过的坑能写满两页纸。
这篇东西就是把我这些年攒下来的实操经验摊开来讲。如果你是要给老系统做一次整库搬迁，或者只是想把几张业务表从生产库同步到测试库，又或者刚装完 Oracle 连DIRECTORY都不知道怎么写，下面这些内容基本能覆盖你 90% 的场景。我会从"为什么现在都推荐数据泵"讲起，一路讲到具体命令、参数取舍、报错排查，中间会穿插我自己真实跑过的参数和踩过的坑，命令你直接复制改改就能用。
1. 先搞清楚数据泵解决的是什么问题
1.1 exp/imp 和数据泵的本质差异
老式的exp/imp是客户端工具，数据要经过客户端这条链路：数据库把数据读出来，通过网络吐给 exp 客户端进程，客户端再写成本地文件。这条链路里客户端进程是瓶颈，而且它是一次会话单线程跑，导出大表时你只能干等着。更麻烦的是 exp 出来的文件可移植性差，字符集、版本、平台稍有不同就出各种 ORA 错误。
数据泵不一样，它是数据库内部的服务器端工具。你在客户端敲一条expdp命令，真正干活的是数据库里一个叫 Data Pump 的后台作业，数据在服务器本地内存和磁盘之间流动，只有命令控制和日志通过网络传回客户端。这个设计带来的直接好处是：可以并行、可以断点续跑、可以只导元数据、可以跨库直连搬运。我实测过一个 200GB 左右的库，老 exp 跑到天亮才出 60%，换成 expdp 加parallel=8，四十多分钟收工。
还有一点经常被忽略：数据泵的元数据是基于 Oracle 自己的 XML 对象描述生成的，比老 exp 的 DDL 拼接方式更完整。分区表、约束、索引、权限、同义词、甚至审计策略这些东西，只要参数配对，基本能原样搬过去。老 exp 经常丢东西，比如序列的当前值、外键的延迟属性，迁完应用就出问题。
1.2 目录对象：绕不开的第一道门槛
很多人第一次用数据泵被卡住，都卡在同一个地方：DIRECTORY。数据泵作业跑在数据库服务器上，它读写的路径必须是数据库服务器视角下的路径，而不是你客户端机器的路径。你没法像 exp 那样把 dump 文件往自己笔记本上一扔了事。
所以数据库里引入了一个叫"目录对象"的东西，它本质上是一条指向服务器某个绝对路径的别名。你建好之后，expdp里写directory=MY_DIR，数据库就知道该去哪个物理目录找文件和写文件。如果目录对象指向的路径在服务器上不存在，或者 Oracle 进程账号没有写权限，你会直接收到ORA-39070，作业根本起不来。
提示：目录对象名是数据库对象，大小写不敏感，但物理路径是操作系统级别的，Linux 区分大小写，Windows 不区分。跨平台迁移时这一点必须提前确认。
这里有个常见误解：以为建了目录对象就万事大吉。实际上还得给用户授READ、WRITE权限，否则一样报ORA-39002。我在一个客户现场见过 DBA 反复重建目录对象，折腾两小时，最后发现是权限没授。
2. 环境准备与目录对象配置实操
2.1 谁才有资格跑数据泵
数据泵作业创建时，数据库会在当前用户下建一张作业主表，作业过程中还会用到临时段、读数据字典。所以跑数据泵的账号至少需要CREATE TABLE权限，实际生产里我一般直接用一个拥有EXP_FULL_DATABASE/IMP_FULL_DATABASE角色的账号，或者干脆用 DBA。因为整库、多 schema 导出必须要有这些角色，单 schema 导出你用自己的业务账号加CREATE TABLE也能跑，但一旦涉及导出别人 schema 的对象就会报权限不足。
-- 给普通用户授最小权限组合 grant create session, create table to APPUSER; grant read, write on directory DP_DIR to APPUSER; -- 整库导出还需要 grant exp_full_database to APPUSER; grant imp_full_database to APPUSER;别图省事把所有权限一股脑全给业务账号，这在等保场景下是硬伤。导出权限本身很敏感，能把整库数据拖走，所以生产环境我通常单独建一个迁移专用账号，用完就锁。
2.2 创建目录对象并验证读写
先在操作系统层面建目录，再进数据库建目录对象，顺序不能反：
# 服务器上，用 oracle 账号操作 mkdir -p /data/dump chown oracle:oinstall /data/dump chmod 750 /data/dump-- 数据库里执行 create or replace directory DP_DIR as '/data/dump'; select * from dba_directories where directory_name = 'DP_DIR';验证能不能写，最笨但最有效的办法是拿它跑一次最小作业：
expdp APPUSER/password@orcl directory=DP_DIR dumpfile=test.dmp logfile=test.log tables=DUAL content=metadata_onlyDUAL表存在于任何库里，用content=metadata_only只导元数据，几秒钟就能跑完。如果这一步过了，后面的整库导出就稳了一半。
2.3 开工前必须确认的几个参数
真正动手前，我会先查三件事：数据库版本、字符集、可用空间。
select banner_full from v$version; select * from nls_database_parameters where parameter in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET'); select tablespace_name, sum(bytes)/1024/1024/1024 as gb from dba_data_files group by tablespace_name;版本决定了你能不能加某些参数，比如VERSION参数是 10g 之后才有的，TRANSFORM里的某些选项也是分版本的。字符集决定了导出文件和目标库能不能对齐，这个后面单独讲。空间则是被最多人低估的：expdp默认会把数据落到目录路径，你可以用ESTIMATE_ONLY=Y先估算体积而不真正导出：
expdp APPUSER/password@orcl directory=DP_DIR schemas=APPUSER estimate_only=y它会告诉你大致需要多少字节，把这个数乘以 1.2 作为目录路径的预留空间比较稳妥，因为日志、临时文件和%U多文件都会额外占用。
3. 导出（expdp）全流程拆解
3.1 四种导出模式怎么选
数据泵的导出模式基本覆盖了所有需求，但选错模式是最常见的低效来源。
| 模式 | 对应参数 | 适用场景 | 注意点 |
|---|---|---|---|
| 全库 | full=y | 整库搬迁、灾备演练 | 需要EXP_FULL_DATABASE，会带上系统 schema 对象 |
| Schema | schemas=APPUSER | 单业务系统迁移 | 最常用，可多 schema 逗号分隔 |
| 表空间 | tablespaces=APP_TS | 按存储维度抽取 | 需要EXP_FULL_DATABASE，元数据耦合多 |
| 表 | tables=T1,T2 | 单表同步、临时抽数 | 不会自动带依赖的索引和序列 |
我个人的习惯是：整库迁移用full=y，业务系统搬迁用schemas，临时取数才用tables。用tables的时候一定记得把indexes、constraints、grants都带上，或者干脆用exclude反向排除，避免导出来的表是"光秃秃"的。
3.2 PARALLEL、COMPRESSION、CONTENT 三个关键参数
parallel是数据泵的加速核心，它控制并发的工作进程数。设多少合适？不是越大越好。我的经验值是对齐两个数字：CPU 核心数的一半，以及数据文件的数量。假设一台机器 16 核，主表空间的 datafile 有 8 个，那parallel=8就很合适。设成 32 反而会互相抢 I/O，性能不升反降。
compression有两个常用取值：all和data_only。all连元数据一起压缩，文件更小；data_only只压数据。压缩会消耗 CPU，导出慢一点，但省磁盘也省网络。如果你后面要通过网络把文件搬走，压缩非常值得。我一般生产用compression=all。
content决定导出内容：all是数据和元数据都导，data_only只导数据，metadata_only只导结构。做结构比对、DDL 审查的时候用metadata_only特别方便，文件小、跑得快，还能直接看 XML 内容。
3.3 一条可以直接抄的导出命令
这是我常年用的模板，多文件名用%U自动编号，配合parallel会生成多个文件，单文件用filesize控制大小：
expdp APPUSER/password@orcl \ directory=DP_DIR \ dumpfile=appuser_%U.dmp \ logfile=appuser_exp.log \ schemas=APPUSER \ parallel=8 \ filesize=2G \ compression=all \ content=all \ exclude=statistics \ flashback_time=systimestamp \ job_name=exp_appuser逐条解释一下我的取舍。exclude=statistics是因为统计信息可以在目标库重新收集，导过去反而可能因为数据分布不同导致执行计划异常。flashback_time让整个导出基于一个一致性时间点，避免了"A 表导出时是 100 行，B 表导出时 A 表已经涨到 200 行"这种不一致。job_name显式命名是为了后面能attach上去看进度。
跑完后日志里会有一段汇总，你会看到导出的对象数、行数、耗时、每秒吞吐。养成看日志的习惯，我见过不少人导出报了一堆ORA-31684的警告却不看，结果导入时才发现少了几十张表。
3.4 导出体积估算与空间规划
除了estimate_only，我还会用字典表做交叉验证：
select sum(bytes)/1024/1024/1024 as gb from dba_segments where owner = 'APPUSER';这个是段占用的实际空间，包含索引和碎片，通常比实际数据大。把两个数放在一起看，取个中间值来规划目录空间。还有一个细节：filesize=2G并不是硬上限，数据泵会以接近这个值为界切分文件，所以最后可能生成一个 1.7G 的文件加一个 0.4G 的文件，不要觉得奇怪。如果目标存储上有单文件大小限制（比如某些对象存储），filesize是必须设的。
注意：
parallel和filesize一起用时，生成的 dump 文件个数不会刚好等于 parallel 数，文件是动态分配的。别用脚本按文件名去拼文件个数，容易出错。
4. 导入（impdp）全流程拆解
4.1 REMAP_SCHEMA 与 REMAP_TABLESPACE 的典型用法
导入最大的坑不是命令写错，而是把数据直接灌回了源 schema，把生产库覆盖了。所以只要做迁移，我一定会先加remap_schema：
impdp SYSTEM/password@target \ directory=DP_DIR \ dumpfile=appuser_%U.dmp \ logfile=appuser_imp.log \ remap_schema=APPUSER:APPUSER_NEW \ remap_tablespace=APP_TS:APP_TS_NEW \ table_exists_action=skip \ parallel=8 \ job_name=imp_appuserremap_schema=源:目标会把所有对象的归属改写。remap_tablespace=源:目标同理，处理表空间名字不一样的情况。这两个参数可以写多组，用逗号隔开。有一个容易踩的点：如果目标 schema 在目标库里已经存在，导入不会自动建用户，你得先手工建好并授好权限，否则会报用户不存在或者权限不足。
4.2 导入前的对象清理顺序
导入到已有数据的库，顺序很关键。正确的做法是先删干净再导，而不是硬覆盖：
-- 以 APPUSER_NEW 为例 drop user APPUSER_NEW cascade; create user APPUSER_NEW identified by "Passw0rd#2024" default tablespace APP_TS_NEW; grant connect, resource to APPUSER_NEW; grant unlimited tablespace to APPUSER_NEW;drop user ... cascade会把该用户下所有对象包括表、索引、视图、序列全部清掉，比一个个删省事。
4.3 表已存在时 TABLE_EXISTS_ACTION 怎么选
这个参数有四个取值，行为差异很大：
| 取值 | 行为 | 适用场景 |
|---|---|---|
skip | 跳过已存在的表，不导数据 | 补差量、只想导新表 |
append | 保留原数据，追加导入 | 增量合并，注意主键冲突 |
truncate | 先截断再插数据，保留表结构 | 全量覆盖数据 |
replace | 删表重建，连索引约束一起重建 | 结构也要更新 |
replace看起来最省事，但它会重建表，如果表上有其他对象依赖（比如物化视图、外键），操作会失败或者依赖失效。我一般在测试库用replace，在生产库用truncate或者干脆先drop user cascade。
4.4 大数据量导入的加速技巧
导入阶段能做的优化比导出多。第一，把索引和约束先排掉，导完数据再建：
impdp ... exclude=index,constraint \ transform=disable_archive_logging:ytransform=disable_archive_logging:y是 11g 之后的一个利器，能在导入期间关闭重做日志写入（前提是数据库开了归档但你有权限），大数据量导入能快三到五成。第二，parallel同样适用于导入，且导入的并行更容易吃满 I/O。第三，如果目标库就是源库的两份拷贝，直接开sqlfile=check.sql只生成 SQL 不执行，先审查一遍 DDL 再决定跑不跑：
impdp ... sqlfile=check.sql这个技巧在我们做敏感系统迁移时帮了大忙，生成的 SQL 可以先过一遍人工和合规审查，确认没有意外对象再执行。
5. 版本兼容与跨平台迁移的坑
5.1 版本兼容矩阵要背下来
数据泵有一条铁律：导出的 dump 文件，只能被同版本或更高版本的数据库导入，不能导入到更低版本。11.2.0.4 导出的文件，能进 12c、19c，但进不了 10.2。反过来，19c 导出的文件进不了 11g。如果你非要从高版本往低版本搬，就得在导出时加version参数：
expdp ... version=11.2.0.4这个参数会让导出的元数据按照指定版本生成，但要注意，如果源库里用了低版本不具备的新特性（比如 12c 的隐藏列、19c 的 JSON 类型），version参数也救不了，这些对象会在导入时报错。
-- 检查库里有没有高版本特性对象 select owner, object_name, object_type from dba_objects where object_type in ('TYPE','PROCEDURE') and owner not in ('SYS','SYSTEM') order by owner, object_type;5.2 字符集不一致导致的乱码
字符集问题通常不报错，但数据会悄悄变样。源库ZHS16GBK，目标库AL32UTF8，导入时中文字符可能变成问号或者被截断。根本原因是同一个中文字符在 GBK 里占 2 字节，在 UTF8 里占 3 字节，原本varchar2(10)的字段在目标库就放不下了。
判断方法很简单，导入前比对两边：
select * from nls_database_parameters where parameter = 'NLS_CHARACTERSET';如果目标库字符集是源库的超集，一般没问题；如果源是 GBK 目标是 UTF8，字段宽度最好按 1.5 倍以上预留在目标库的 DDL 里，或者用transform=segment_attributes之类的参数配合手工调整 DDL。我处理过一个案例，客户库字段全是varchar2(20)，从 GBK 迁到 UTF8 后，原本 9 个汉字的地址被截成了 6 个，直接成了脏数据，最后靠手工改 DDL 重建表才解决。
5.3 导入完成后怎么验证
导入成功不等于数据正确。我固定做三层校验：
-- 第一层：对象数量对比 select object_type, count(*) from dba_objects where owner='APPUSER' group by object_type; -- 第二层：表行数对比（对行数有统计信息的表） select table_name, num_rows from dba_tables where owner='APPUSER' and num_rows is not null; -- 第三层：空间占用对比 select sum(bytes)/1024/1024 as mb from dba_segments where owner='APPUSER';对象数量对不上，说明有对象没导过来；行数对不上，可能有表被跳过；空间差太多，可能有索引没建。我还会对几个核心业务表跑一次count(*)做抽样确认，这些表通常不大但最关键，值得花几分钟。
6. 常见报错与排查速查表
6.1 目录与权限类报错
| 报错 | 含义 | 处理方式 |
|---|---|---|
ORA-39002 | 操作无效 | 通常和目录权限、参数拼写有关，先看完整堆栈 |
ORA-39070 | 无法打开日志文件 | 目录对象路径在服务器不存在或没写权限 |
ORA-39087 | 目录名无效 | 目录对象名拼错或未创建 |
ORA-39145 | 目录对象未指定 | 命令里漏了directory= |
这几个错误高度集中在目录这一环。我的排查顺序是：先select * from dba_directories确认目录对象在不在，再登上服务器ls -ld /data/dump看权限，最后确认 Oracle 进程账号能不能写进去。这三步走完，99% 的目录问题都能定位。
6.2 作业相关的报错
ORA-31626 job does not exist一般出现在attach一个已经结束或被清理的作业，或者作业主表被误删。ORA-31684是常见的警告，表示某个对象类型已存在被跳过，通常不影响结果，但如果是关键对象就要留意。ORA-39083是对象创建失败，日志里会跟着一条更具体的错误，比如表空间不存在、字段类型不支持，需要往下一步看。
作业异常中断后，经常会在字典里留下残留主表：
select job_name, state from dba_datapump_jobs;如果有NOT RUNNING状态的记录，对应的主表可以手工删掉，否则下次同名作业起不来：
drop table SYSTEM.SYS_EXPORT_SCHEMA_01;6.3 长事务与一致性读相关
导出时间过长时，可能撞上ORA-01555 snapshot too old。原因是导出作业基于一致性读，如果 UNDO 空间或undo_retention不足以支撑这么长的读事务，旧数据就被覆盖了。解决办法是导出前调大 UNDO 表空间，或者临时提高undo_retention：
alter system set undo_retention = 10800 scope=both;如果是 11g 及以上，还可以用flashback_time把导出绑到一个短时间窗口，减少长时间一致性读的压力，但根本解法还是给足 UNDO。
6.4 字段长度与类型相关
ORA-12899 value too large for column是最典型的字符集迁移后遗症，前面讲过。还有一种是源库用了LONG类型，高版本导入时可能转换成CLOB，如果业务代码里对类型做了硬编码判断就会出问题。遇到这种，导入前可以用sqlfile生成 DDL 先看一眼，把有疑问的字段挑出来提前评估。
7. 生产环境里的实战经验
7.1 用参数文件 + Shell 做定时导出
命令太长直接写在 crontab 里容易出错，我习惯把参数写进 parfile：
# /home/oracle/scripts/exp_appuser.par directory=DP_DIR dumpfile=appuser_%U.dmp logfile=appuser_exp_%DATE%.log schemas=APPUSER parallel=6 filesize=2G compression=all exclude=statisticsShell 脚本里按日期生成文件名，跑完检查日志关键字：
#!/bin/bash export ORACLE_SID=orcl DATE=$(date +%Y%m%d) expdp APPUSER/password@orcl parfile=/home/oracle/scripts/exp_appuser.par if grep -q "successfully completed" appuser_exp_${DATE}.log; then echo "导出成功" else echo "导出失败，请检查日志" | mail -s "expdp告警" dba@example.com fi这套组合我在好几个客户那儿跑了两年多，稳定性比想象中好。关键是日志要按日期归档，不然几天就堆满了目录。
7.2 停机窗口内的迁移节奏
真正做整库迁移，时间安排比参数更重要。我一般的节奏是：迁移前一周做一次全量演练，把每个阶段耗时记下来；窗口开始后先停应用、锁写、跑一次最终增量导出；导出完成后立刻在目标库导入，导入期间源库保持只读；导入完成做数据比对，比对通过再切流量。
这里有个我踩过的坑：第一次做迁移时我导完就没管源库，结果窗口里业务又写了几万条数据进去，导入完成后两边对不上，只能回滚重来。后来学乖了，导出前先alter system enable restricted session或者把应用连接断开，确保导出期间数据静止。
7.3 网络链路直接搬运
如果源库和目标库之间网络条件好，其实可以省掉 dump 文件落地这一步，用network_link直接搬：
impdp SYSTEM/password@target \ directory=DP_DIR \ network_link=SRC_LINK \ remap_schema=APPUSER:APPUSER_NEW \ logfile=net_imp.log \ parallel=4SRC_LINK是目标库上一个指向源库的数据库链路。这种方式不需要中间存储，但完全依赖网络稳定性，网络一抖动作业就可能挂掉。所以我只在同机房、网络质量可控的场景下用，跨机房还是老老实实落地再传文件，可控性更强。
这些年做下来，我对数据泵最深的一点体会是：它对参数的容忍度很高，但对环境的容忍度很低。参数写错了顶多慢一点，可目录、权限、字符集、版本这些东西一旦对不齐，它会用一堆 ORA 报错把你堵在门口。所以每次动手前花二十分钟做环境体检，比事后排查三小时划算得多。另外，养成"先估量、再演练、后正式"的习惯，我见过太多人第一次就敢在生产库上敲impdp不加remap_schema，那个画面我现在想起来还替他们捏把汗。
