开发中常见的Oracle三大故障与调优方法

出处:墨天轮(https://www.modb.pro/db/7055,复制至浏览器,即可查看)
本文为原创文章,如有转载,请标明出处从 。
导读:怀晓明先生(网名lastwinner),是具有多年数据库开发与项目管理经验的数据库专家 。曾获得第一届ITPUB较佳建议奖,在多个大型IT企业多年的工作历练中,积累了丰富的系统架构设计经验 。合著作品有《剑破冰山——ORACLE开发艺术》、《Oracle DBA手记2》 。
 
我们知道在平时的Oracle开发工作中我们有时候会遇到些BUG,我曾经碰到过的BUG大致分为三类:
1. 出现ora-00600,ora-03113,ora-07445等错误,导致程序无法执行
2. 执行计划错误,导致很长时间才出结果
3. 由于执行计划错误而给出了错误的结果
第一类很让人无语,明明写的代码没有任何问题,但Oracle就是报这几个错误中的一个 。这一般是Oracle的bug导致的,少部分是执行计划错误导致的 。一般在生产环境中碰到这样的问题,只能认栽,通常只能换个方式来实现同样的功能,要不然就得换开发方案,但这样的开发成本就会很高了 。如果在开发环境中碰到,还可以通过给数据库打补丁来解决这类问题(如果Oracle发布了的话,不过在生产环境上,补丁不是随便就可以打上的,一定要打的话,必须先做充分的测试) 。
 
第二类很使人无奈,不过还好,为什么说“还好”?因为,这至少还能出来正确的结果嘛!这一般可以通过给数据库打补丁、修改参数、添加强制提示等方法来解决这类问题 。比如我曾经碰到过Oracle10.2.0.5在linux 64bit下出的full outer join的bug(类似于官方给出的bug2927071),一个full outerjoin出来结果需要两三分钟,而通过修改参数
后,改变了原先不正确的执行计划,结果一秒内就哗哗哗的出来了,经验证结果也是正确的 。
alter session set "_optimizer_native_full_outer_join"=force; 
第三类是最悲催的,可以说直叫人生不如死 。为什么这么说?第一类bug碰到的话,Oracle会报错,起码能提醒你此路不通;第二类bug碰到的话,起码你本能的可以感觉到这里有问题,就算你没意识到,结果也是正确的,对吧?但这第三类bug,我从9i到10g都碰到过,明明写的SQL没任何问题,但Oracle偏偏就给你错误的结果,还好每次都因细心发现了,及时调整了技术方案,才没导致更大的问题发生 。
 
碰到这些bug并不就意味着你很倒霉,事实上,换个角度看,首先要恭喜你,因为这说明你的sql水平已经达到了一个较高的程度了;倘若你能意识到不对劲,那说明你足够敏锐;再若你还能找到解决办法,那你就很厉害啦!
至于如何识别、解决开发过程中碰到的这类bug,这个话题比较大比较深,以后有机会我再和大家分享 。但在这里我需要指明的是,其实很多最终结果不正确的程序,多数都是因为代码本身的问题导致的,而因为Oracle Bug导致的问题只占极少的部分 。
关于Oracle的优化,俗话说“树挪死,人挪活”,咱不能因为一块石头堵在前面就非得把它炸开才能前行,绕过去往前走也是一种方法,对吧?
做系统优化其实也一样 。系统的性能提升是涉及到方方面面的,从网络、操作系统、数据库、应用服务器到程序,都有提升的空间 。现在很多人都知道,最该优化的部分是攻城狮们开发的程序,比如拿数据库的性能问题占比举例,有可靠的统计数据指出,70%的问题出在攻城狮编写的SQL上 。而在这现象背后更根本的还在于,没有可胜任数据库开发工作的攻城狮!一旦出现系统性能问题,大家第一反应就是去找调优高手来优化SQL,久而久之,这就成了一个习惯 。就好像平常不注意预防疾病,反正病了就找大夫治疗,而你也许不知道在未来某一天,面对焦急的亲属,白衣天使也会无奈的摇摇头,摘下口罩,叹了口气轻声道:“我们已经尽力了,你们准备后事吧……”
 
很多公司,包括专门做IT的公司在内,的确是没有意识到提高开发技术可以有效的提高系统性能,这个现象的本质关键是老板们没意识到提高开发技术其实是可以降低开发和后期运营维护成本的,这笔账算清楚了,老板自然愿意投入资源来提高工程师们的开发技能 。通常不是技术出身的老板是意识不到的,这就需要技术管理者“晓之以理,动之以情”说服老板投入资源 。当然,老板投入资源后,技术管理者必须hold得住,要将事情漂亮得完成,看到效果的老板自然就不会存疑了 。


推荐阅读