基本信息

單機，從老環境遷移到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并沒有相關文獻可以參考。解決也是靠靈光一現。

{統計信息會影響導出的分片邏輯}

學習原理，積累工具；孵化思路，下筆有道