expdp导出分区表缓慢排查(Streams AQ: waiting for messages in the queue )

基本信息

单机,从老环境迁移到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并没有相关文献可以参考。解决也是靠灵光一现。

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值