后来向他们要了alert.log和trace files，通过分析，确定为用户数据库版本的一个bug（Bug 9894940 ），要解决该bug，要么升级，而且还是大版本升级，要么workaround，心中窃喜，幸好还提供了一个workaround，就是关掉一个隐含参数，评估该参数对系统影响不大，且可以在线修改，于是告诉用户：
用户很快就修改好了，于是我信心满满的说，你们试试吧，结果他们试了很多次，还是不行，这些真是有点摸不着头脑，难道我定位这个bug错了，因为用户的这个版本不是10G的最终稳定版本，涉及的bug会多些，定位错了也是有可能的，虽然不太相信自己分析错了，但用户那边火上房般的催。。。，没办法，想个其他办法解决吧。既然该bug是因为执行计划导致的，那么就想办法改变执行计划吧，考虑不展开view，加hint：no_merge改变了执行计划，并成功绕过了bug，因此,SQL改成了：
试了下，性能比之前稍差，但用户表示可以接受，毕竟总比不能用强，而且性能也不是差很多，于是，用户协调研发改程序，然后发补丁修正该问题，然后，说了些感谢之类的话。因加hint前后的执行计划很长，达上百行，这里就不贴出了。
本以为问题该解决了，没想到第二天，用户的现场和研发人员又找到我评理，了解了下，才知道，原来研发懒得改程序，后来试了下，说原来的SQL也不报错了，而且用户应用点击该功能也不再报错，而现场人员希望研发按照我说的修改程序，并尽快打上补丁，说如果不修改，担心会不稳定，说不定什么时候又不行了。结果，他们双方都坚持自己的观点，相持不下，后来找到我，问问怎么办？我让他们取了原SQL的计划，看了下，和之前一模一样，没发生什么变化，又让他们试了多次，说应用和直接跑SQL都不报错了，开始有些纳闷儿，后来忽然想到昨天修改的那个参数，难道是那个参数当时没起作用，后来起了作用？考虑再三，建议用户先不改程序，继续观察再说。
唉，高科技就是高科技啊，连数据库都懂得耍花招了，修改了参数，要拖到第二天才起作用。该问题至今已有近半年时间，没再发生问题。