当前位置:Gxlcms > mysql > 一次“峰回路转”的troubleshooting经历

一次“峰回路转”的troubleshooting经历

时间:2021-07-01 10:21:17 帮助过:32人阅读

某天,用户现场人员找到我,说应用的某个功能一点就报错,在数据库上直接跑功能对应的SQL也报错,SQL大致如下: 后来向他们要了alert.log和trace files,通过分析,确定为用户数据库版本的一个bug(Bug 9894940 ),要解决该bug,要么升级,而且还是大版本升

某天,用户现场人员找到我,说应用的某个功能一点就报错,在数据库上直接跑功能对应的SQL也报错,SQL大致如下:

\

后来向他们要了alert.log和trace files,通过分析,确定为用户数据库版本的一个bug(Bug 9894940 ),要解决该bug,要么升级,而且还是大版本升级,要么workaround,心中窃喜,幸好还提供了一个workaround,就是关掉一个隐含参数,评估该参数对系统影响不大,且可以在线修改,于是告诉用户:

\

用户很快就修改好了,于是我信心满满的说,你们试试吧,结果他们试了很多次,还是不行,这些真是有点摸不着头脑,难道我定位这个bug错了,因为用户的这个版本不是10G的最终稳定版本,涉及的bug会多些,定位错了也是有可能的,虽然不太相信自己分析错了,但用户那边火上房般的催。。。,没办法,想个其他办法解决吧。既然该bug是因为执行计划导致的,那么就想办法改变执行计划吧,考虑不展开view,加hint:no_merge改变了执行计划,并成功绕过了bug,因此,SQL改成了:

\

试了下,性能比之前稍差,但用户表示可以接受,毕竟总比不能用强,而且性能也不是差很多,于是,用户协调研发改程序,然后发补丁修正该问题,然后,说了些感谢之类的话。因加hint前后的执行计划很长,达上百行,这里就不贴出了。
本以为问题该解决了,没想到第二天,用户的现场和研发人员又找到我评理,了解了下,才知道,原来研发懒得改程序,后来试了下,说原来的SQL也不报错了,而且用户应用点击该功能也不再报错,而现场人员希望研发按照我说的修改程序,并尽快打上补丁,说如果不修改,担心会不稳定,说不定什么时候又不行了。结果,他们双方都坚持自己的观点,相持不下,后来找到我,问问怎么办?我让他们取了原SQL的计划,看了下,和之前一模一样,没发生什么变化,又让他们试了多次,说应用和直接跑SQL都不报错了,开始有些纳闷儿,后来忽然想到昨天修改的那个参数,难道是那个参数当时没起作用,后来起了作用?考虑再三,建议用户先不改程序,继续观察再说。

唉,高科技就是高科技啊,连数据库都懂得耍花招了,修改了参数,要拖到第二天才起作用。该问题至今已有近半年时间,没再发生问题。

人气教程排行