filesperset 是 oracle data pump 中限制 dump 文件集内最大文件序号的参数，仅对含 %u 的 dumpfile 生效，不控制每通道文件数；其值须 ≥ parallel，否则报 ora-39079。
filesperset 是什么，为什么它不直接控制“每个通道的文件数”
filesperset 是 oracle data pump（expdp/impdp）中用于控制导出/导入过程中“每个 dump 文件集（dumpfile set）内最多包含多少个 dump 文件”的参数，不是按通道（parallel worker）划分的。很多人误以为设成 filesperset=5 就能让每个并行进程只写 5 个文件——其实不是。并行通道（由 parallel 指定）各自独立写入，filesperset 只在 dumpfile 列表用通配符（如 dump_%u.dmp）时，限制自动生成的文件序号上限，避免无限创建。
常见错误现象：PARALLEL=8 + DUMPFILE=dump_%U.dmp + FILESPERSET=2，结果仍生成了 16 个文件（8 个通道各写了 2 个），但第 3 个文件（dump_03.dmp）根本不会被任何通道写入——因为 FILESPERSET=2 把可用序号锁死在 01–02。
- 它只对带
%U的DUMPFILE名生效；纯静态名（如dump1.dmp,dump2.dmp）完全无视该参数 - 它的值必须 ≥
PARALLEL，否则部分并行进程启动失败，报错：ORA-39079: unable to allocate channel because FILESPERSET limit exceeded - 实际每个通道写的文件数，取决于数据量、块大小、压缩率，以及是否触发文件切换（
FILESIZE限制）
想让多通道负载更均衡？重点调 FILESIZE 和 PARALLEL，不是 FILESPERSET
真正影响各通道写入文件数量和大小分布的，是 FILESIZE 和数据分片逻辑。Data Pump 在并行模式下会按对象（如表分区、LOB 段）或行组切分任务，但若单个对象极大（比如一张 2TB 的未分区表），所有数据仍可能被分配给一个通道处理，造成严重倾斜。
- 显式设置
FILESIZE=2G（推荐 1–4G 区间），能强制在达到阈值时新建文件，间接促使多个通道都有机会创建新文件 -
PARALLEL值不宜超过 CPU 核心数 × 1.5；过高反而因争抢 I/O 和内存导致整体变慢 - 确保源表已合理分区（range/list/hash），Data Pump 才能按分区分发任务；否则加再高的
PARALLEL也没用 - 避免混合使用大对象（LOB）和普通列：LOB 默认不并行读取，会拖慢整个通道，建议先导出非 LOB 部分，再单独处理 LOB
FILESPERSET 的典型误配场景和修复方式
最常踩的坑是把 FILESPERSET 当成“每通道文件上限”，然后设得过小，导致任务卡住或报错。
错误配置示例：expdp user/pwd PARALLEL=6 DUMPFILE=dump_%U.dmp FILESPERSET=3
问题：6 个通道需要至少 6 个唯一文件名（%U 从 01 开始递增），但 FILESPERSET=3 只允许 01/02/03，第 4 个通道尝试写 dump_04.dmp 时失败。
- 修复方法一：删掉
FILESPERSET（默认不限制），让系统按需生成文件 - 修复方法二：设为 ≥
PARALLEL的值，例如FILESPERSET=10 - 修复方法三：不用
%U，改用显式列表：DUMPFILE=dump1.dmp,dump2.dmp,dump3.dmp,dump4.dmp,dump5.dmp,dump6.dmp，此时FILESPERSET完全无效，但你能精确控制文件名和数量
监控并行通道实际负载：别只看文件数，要看 V$SESSION_LONGOPS 和日志
文件数量平均 ≠ 工作量均衡。一个通道可能在写 10 个 100MB 的小文件（快），另一个在写 1 个 5GB 的大文件（慢），但文件数看起来更“平衡”。真实瓶颈往往藏在 I/O 等待或内存不足里。
- 实时查各通道进度：
SELECT opname, sofar, totalwork, units FROM V$SESSION_LONGOPS WHERE opname LIKE 'EXPORT%' AND totalwork > 0 - 检查是否发生频繁文件切换：
tail -f /path/to/expdp.log中搜Starting "USER"."SYS_EXPORT_SCHEMA_0后面的Wrote行，观察不同通道的写入节奏 - 如果某通道长时间没新
Wrote日志，且V$SESSION显示其EVENT是direct path write或enq: KO - fast object checkpoint，大概率是磁盘吞吐或 checkpoint 压力所致，和FILESPERSET无关
真正难调的从来不是参数名，而是你不知道哪个通道在等 I/O、哪个在刷 buffer、哪个卡在归档日志切换上。文件数只是表象，得钻进运行时状态里看。
