欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

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

程序员文章站 2024-01-17 08:19:22
...

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

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

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

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

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

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

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

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

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