Oracle数据泵（Data Pump）是数据库逻辑备份和迁移的核心工具，但很多人在使用expdp/impdp时发现，即使服务器有几十个CPU核心，导出速度依然上不去。关键就在PARALLEL参数。这个参数控制着数据泵并行执行的worker进程数量，但它的生效机制远不止“数字越大越快”这么简单。理解并行度如何与dumpfile、表分布、I/O能力相互作用，才能真正让数据泵跑出应有的速度。
并行度参数的工作原理与常见误区
数据泵的PARALLEL参数指定了用于执行导出或导入任务的并行工作进程数。每个worker进程可以独立处理一个表分区、一个子查询或者一个数据文件。但并行度并不是在所有阶段都生效。在导出元数据、创建表结构、重建索引、收集统计信息等阶段，数据泵通常只使用单个主进程，只有实际的数据行迁移阶段才会启动多个worker并行处理。
一个常见的误区是认为PARALLEL的值只要不超过CPU核数就可以随意设置。实际上，如果导出写入的是单个dumpfile文件，那么即使设置PARALLEL=8，所有worker最终都要向同一个文件写入数据，文件I/O会成为瓶颈，并行效果大打折扣。数据泵的官方建议是：当使用并行度大于1时，应该同时使用多个dumpfile文件，让每个worker可以写入不同的文件，避免写锁竞争。例如expdp ... dumpfile=exp_%U.dmp parallel=4中的%U会自动生成多个文件，每个文件对应一个worker。
另外，并行度还受到数据泵内部队列和内存分配的影响。每个worker会占用一定的PGA内存，如果设置过高可能导致内存不足或大量换页，反而拖慢速度。一般建议并行度不超过CPU核数的2倍，但最合适的值往往需要通过实际测试来确定。
导出场景下的并行度设置实战
对于导出操作，假设需要导出一个包含多个大表（每个表超过10GB）的schema。如果使用默认的parallel=1，数据泵只会启动一个worker逐个表处理，耗时可能长达数小时。而设置parallel=4并配合多个dumpfile，可以同时处理4个表，前提是这些表之间没有过多的依赖关系（例如外键约束不会在数据导出阶段阻塞并行）。
以下是一个典型的并行导出命令示例：
expdp system/password DIRECTORY=dpump_dir1 \ DUMPFILE=exp_full_%U.dmp \ LOGFILE=exp_full.log \ SCHEMAS=HR,OE,SH \ PARALLEL=4 \ FILESIZE=5G
这里使用了%U占位符，数据泵会根据PARALLEL值自动生成4个独立的dumpfile文件，每个文件最大5GB，避免单个文件过大。实际导出时，数据泵会先扫描表列表，将大表拆分成多个子任务分配给不同的worker。例如某张表特别大，数据泵内部会根据表的分区或数据块范围进行并行切分，这就是所谓的“并行度对单表也有效”的原因。
但需要注意，如果表之间存在主外键关系，导出时虽然不校验约束，但元数据导出阶段需要一次性读取所有相关约束定义，这部分的串行开销无法通过并行度消除。因此对于包含大量约束和索引的schema，并行度带来的提升可能低于预期。
导入场景下的并行度考量与性能陷阱
导入（impdp）比导出更复杂，因为除了数据行加载，还要处理索引创建、约束启用、统计信息收集等后续步骤。如果设置parallel=4进行导入，数据泵会使用4个worker并行加载数据行，但索引重建通常是在数据加载完成后由主进程串行执行的。这意味着并行度对纯数据加载阶段有明显加速，但对索引创建阶段没有帮助。
一个典型的性能陷阱是：在导入大表时设置了很高的并行度，却忽略了EXCLUDE=INDEX或者EXCLUDE=STATISTICS选项。比如某次导入一张包含5个复合索引的大表，设置PARALLEL=8后数据加载只用了20分钟，但索引重建用了2个小时。这是因为索引重建默认由单进程完成，且需要大量排序和I/O。此时应该考虑使用SQLFILE参数先生成DDL，手动并行创建索引，或者使用TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y等技术减少索引创建开销。
导入命令示例：
impdp system/password DIRECTORY=dpump_dir1 \ DUMPFILE=exp_full_%U.dmp \ LOGFILE=imp_full.log \ SCHEMAS=HR,OE,SH \ PARALLEL=4 \ EXCLUDE=STATISTICS \ TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y
上面的命令排除了统计信息的导入，可以在数据加载完成后统一用DBMS_STATS并行收集统计信息。同时禁用归档日志可以显著减少导入过程中的redo生成量，提升数据加载速度。
另一个需要注意的点是：导入时的并行度与dumpfile数量也需要匹配。如果导出时用了4个文件，导入时PARALLEL=4并且指定了所有文件，数据泵会尝试将不同的文件分配给不同的worker。但如果只指定了一个dumpfile，即使PARALLEL=8，数据泵阅读文件时仍然是串行读取头部信息，并行加载的效果也会受限。
如何确定适合自己环境的并行度数值
没有放之四海皆准的并行度数值，但可以通过以下步骤找到较优值。首先确认服务器CPU核数和可用内存，以及数据泵操作涉及的磁盘类型（本地SSD、SAN存储、普通机械盘）。一般建议并行度的初始值设为CPU核数的一半，例如16核服务器先试PARALLEL=8。然后进行一次小规模测试导出，观察操作系统层面的I/O利用率和CPU使用率。如果CPU使用率接近100%而I/O等待较少，说明可以进一步增大并行度；如果I/O等待比例很高，说明磁盘已经成为瓶颈，继续加大并行度不会再有提升，甚至可能因为I/O争用而变慢。
还可以通过AWR报告或v$session_longops视图观察数据泵worker的实际活跃程度。在导出过程中查询v$session_longops可以看到各个并行worker处理的行数和耗时，如果发现某些worker早早完成而其他worker还在忙碌，说明任务切分不够均匀，可能需要调整并行度或使用ACCESS_METHOD=DIRECT_PATH等选项。
对于超大表（单表超过100GB），可以考虑使用REMAP_PARALLEL或者利用分区交换技术，先按分区导出再并行导入。数据泵的PARALLEL参数对分区表特别有效，因为每个分区可以被独立处理，几乎可以线性扩展。
并行度与系统资源消耗的平衡
盲目提高并行度可能带来副作用。每个并行worker都会占用一定的PGA内存，如果设置PARALLEL=16而PGA总量只有2GB，每个worker分配到的内存会很小，导致排序和哈希操作频繁写临时表空间，性能反而下降。另外，并行度太高也会增加数据库的CPU上下文切换开销，以及数据泵主进程与worker之间的通信成本。
建议在设置并行度时同时调整STREAMS_POOL_SIZE和PGA_AGGREGATE_TARGET参数，为数据泵分配足够的缓冲空间。可以使用以下查询监控数据泵任务的内存和I/O使用情况：
SELECT sid, serial#, opname, target, sofar, totalwork,
units, start_time, time_remaining
FROM v$session_longops
WHERE opname LIKE 'Data Pump%'
ORDER BY start_time DESC;
另外，如果数据库开启了并行执行（parallel_degree_policy=AUTO），可能会与数据泵的PARALLEL产生叠加效应，导致总的并行进程数远超预期。在这种情况下，建议通过ALTER SYSTEM SET parallel_degree_policy=MANUAL;临时关闭自动并行，避免资源过度竞争。
总之，Oracle数据泵的并行度设置需要结合表结构、文件数量、硬件能力和导入导出阶段综合考虑。合理使用PARALLEL配合多文件、分区技术以及后续步骤的优化，可以让数据泵的速度提升数倍。但不要迷信高并行度，实测和监控才是找到最优配置的唯一途径。