SQL执行时间受游标影响不准

sql的执行时间,我们往往可以通过ash中的sample时间,减去sql exec start,得出该sql执行的时间。有一个很不错的sql,可以看某个sql的历次执行时间,历次执行计划。

但是在使用游标的时候,如,在某个procedure中,有将sql的内容载入到游标,后续根据游标的每一行记录再做关联或别的操作。此时,在ash,甚至在sql monitor中去看,这个sql的执行时间都是有问题的。

看下面的这个例子:

注意,我们的procedure中,有个游标是做

做完之后,利用游标的结果再做

其他的insert runlog表只是用来打时间戳。

这种情况其实是一种比较常见的调优场景,我们一个package中不知道那段sql执行的时间最长?是在cursor阶段load的慢,还是已经load到游标中了,后续的循环执行的比较慢?

我们运行上面的已经准备好的代码:

注意,这里看到,仅仅是select的那个语句,显示竟然运行了3.62分钟。

我们同样去看sql monitor的结果,也是显示264秒:

注意看,上面的这个select的sql竟然执行了264s。

其实这是错误的,这个select的sql,只是执行了很短的时间,我们看看之前我们打的时间戳:

如果是那个select的游标是21:12:44开始,那么select结束时间应该是09.12.44.544000 PM,即不到1秒就结束了。后面的时间,只是利用游标在做别的事情。

因此,在生产场景,遇到类似这样的问题,其实可能不是游标select做的慢,而是和这个游标相关的后续的操作慢。大家在看ash或者sql monitor的时候,不要被这个迷惑了。

相关文章

发表评论

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

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据