房屋租赁网站开发需求分析,平面设计接单报价表,网盘网站开发,天气预报网站怎么做基本信息
单机#xff0c;从老环境迁移到19.19。之前的导出速度接受范围内。硬件是提升的
导出使用了压缩#xff0c;加密#xff0c;并行64进程#xff0c;表分区约90个#xff0c;无lob字段。
现象
导出开始时能并行导出#xff08;并行约45个#xff0c;没起到64…基本信息
单机从老环境迁移到19.19。之前的导出速度接受范围内。硬件是提升的
导出使用了压缩加密并行64进程表分区约90个无lob字段。
现象
导出开始时能并行导出并行约45个没起到64个怀疑跟分区较少有关然后所有dump在70m左右时只有一个dump开始持续增长。
dmdw进程有正常启动worker数量也是45个。
空闲的worker事件为Streams AQ: waiting for messages in the queue
导出开始时没有报出estimate blocks的信息
尝试增加large pool依旧无法并行
尝试调整access_methodextnernal_table依旧无法并行
尝试增加lstream pool依旧无法并行
尝试增加aq_tm_processes依旧无法并行
转机
观察只在干活的worker导出进度发现其一直在顺序导出分区part 110 part 111 part112这样。
联想到没有estimate blocks的信息怀疑导出是机械性的分片操作导致有数据的分区集中在干活的worker上。
查看分区的行数发现大部分分区都没有填充的统计信息。
收集该表的统计信息然后重新正常导出导出并行拉到20左右多个dump在均衡增长。parallel在单个worker上有3的并行度
总结
巨大的知识性盲点。mos并没有相关文献可以参考。解决也是靠灵光一现。
{统计信息会影响导出的分片逻辑} 学习原理积累工具孵化思路下笔有道
