基本信息

单机，从老环境迁移到19.19。之前的导出速度接受范围内。硬件是提升的

导出使用了压缩，加密，并行64进程，表分区约90个，无lob字段。

现象

导出开始时能并行导出（并行约45个，没起到64个怀疑跟分区较少有关），然后所有dump在70m左右时，只有一个dump开始持续增长。

dm，dw进程有正常启动，worker数量也是45个。

空闲的worker事件为Streams AQ: waiting for messages in the queue 

导出开始时没有报出estimate blocks的信息

尝试增加large pool，依旧无法并行

尝试调整access_method=extnernal_table，依旧无法并行

尝试增加lstream pool，依旧无法并行

尝试增加aq_tm_processes，依旧无法并行

转机

观察只在干活的worker导出进度，发现其一直在顺序导出分区（part 110 part 111 part112这样）。

联想到没有estimate blocks的信息，怀疑导出是机械性的分片操作，导致有数据的分区集中在干活的worker上。

查看分区的行数，发现大部分分区都没有填充的统计信息。

收集该表的统计信息，然后重新正常导出，导出并行拉到20左右，多个dump在均衡增长。parallel在单个worker上有3的并行度

总结

巨大的知识性盲点。mos并没有相关文献可以参考。解决也是靠灵光一现。

{统计信息会影响导出的分片逻辑}

学习原理，积累工具；孵化思路，下笔有道