案例:troubleshooting slow parse sql on 19.16

该案例来自东区某客户,该客户使用的数据库版本为19.16,在从11g升级到19c之后,不止一个sql出现解析异常慢的情况。并且解析过程中并未出现异常的等待。

选取一个sql做explain测试:

可以看到该sql非常复杂,表关联也非常多,光是解析就用了31秒,这肯定是无法忍受的。

因为没有异常等待事件,31秒都是on cpu的情况,所以分析方法一般都会去看看解析时候的short_stack。因为客户反映这个库升级19c之前在11g解析是非常快的,所以当时有想过遍历修改优化器参数和fix_control的方法来进行分析,不过仔细一想解析一次就要30s,遍历那么多优化器参数和fix_control不得跑到啥时候。

还是先做short_stack吧,通过short_stack可以看到堆栈信息为:

多执行几次short_stack,发现会在qkesEval_Int之后循环的去执行ldx*的函数。

另外short_stack似乎不太直观能反映在哪个函数上循环消耗了大量时间的情况。这种时候可以通过perf去跟踪解析函数在cpu上的消耗。

可以看到ldxsti、ldxsnf、ldxmfn的self值最高,总共达到了50%。分析具体堆栈从ldxnbeg往上看看

从perf record的输出可以看到,进入kkeEqJoinSel函数分析连接选择性之后,开始调用kkeutlCompHistActVals,这个函数与直方图有关系,之后就开始了循环ldxnbeg->ldxsti->ldxsnf->ldxmfn,ldx*函数的循环,ldxmfn的self最高,ldx*貌似与编译直方图值转换有关系。猜测是关联表个数过多,CBO评估join order的时候,会去排列组合各种连接顺序的情况,上限为”_optimizer_max_permutations“,如果这些关联条件上都存在直方图,就出现了案例中调用了大量ldx*函数的情况。

查看mos,并未发现任何有价值的文章。但是我还是猜测与关联字段上的直方图有关系。

查看sql发现关联字段都是ASQBH,且都存在混合直方图。这是一个编号类的字段,选择性都是不错的,直方图 没啥必要。

处理过程(删除掉关联字段上的直方图,并且设置收集统计信息默认不采集该字段直方图):

删除关联列直方图后解析时间就正常了。

近两年似乎喜欢上了systemtap、perf、gdb等诊断工具,对于一些比较需要对深入底层的问题的诊断尤其好使,让闭源的oracle的诊断也能像开源数据库的问题诊断一样深入。

over!

 

 

此条目发表在Oracle, Oracle troubleshooting分类目录。将固定链接加入收藏夹。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注