单机，从老环境迁移到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并没有相关文献可以参考。解决也是靠灵光一现。
{统计信息会影响导出的分片逻辑}
学习原理，积累工具；孵化思路，下笔有道