墨墨导读：怀晓明先生（网名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得住，要将事情漂亮得完成，看到效果的老板自然就不会存疑了。
对于意识到了但是没技术资源去做的情况，只能用其他资源来换取技术资源了，比如内部培养人才、找外包、从外部请和尚等等。
老外也有句谚语——“一天一个苹果，你就不需要医生了”，这说的也是预防为主。
我们转换下思路，如果提高了攻城狮们的开发水平，甚至是配备了专职的数据库开发工程师，那写出较高质量的SQL就不是什么难事儿。
这样就提前消除了多数性能方面的隐患，自然就降低了后期出现性能问题的概率，也免去了大量的请人做调优的成本，而提高攻城狮们的开发水平成本并不是特别高，何乐而不为？
ISO-9000告诉我们，质量是生产出来的，不是检测出来的，同样，高质量的SQL应该是开发写出来的，而不应总是通过DBA去调优出来。
无论公司是否意识到、是否有资源去做，提高开发技术尤其是数据库端的开发技术都是大势所趋，不去迎面解决问题而装鸵鸟是不可取的。
Oracle的开发和运维是一个系统性的工作。
简单说就是理论与实践充分结合，只懂理论和只会实践同样是不可取的，要学会用理论指导实践，通过实践验证理论，在实践过程中不断丰富理论知识，在理论指引下不断的提高实践能力。
就数据库开发而言，最好具备如下能力与素质：
1. 掌握SQL基础知识和数据库基本理论，
这会有助于你理解SQL是如何运作的，什么样的SQL会跑得更快。
这可以通过学习相关白皮书或者技术文档获得
2. 学会提问。
提问是一门艺术，无论学什么都需要掌握这门艺术。
3. SQL中高级知识
，这能让SQL成为你的有力工具。
这可以通过阅读官方文档，经常来itpub的数据库开发版块学习学习，来提高自己的水平。
学习时不要想当然，就像trim并不等于rtrim＋ltrim，认真读文档的人都知道。
4. 掌握至少一门相关的开发语言
，java、php等等都行，这有助于你从另一个视角来认识数据库开发。
5.一定的数学能力
，最好具备高中以上的数学知识。
良好的数学素养可以为你带来新的思路和方法，有助于提高开发能力，并能帮助你理解。
6.一定的科学素养。
类似于“某月有5个周五、周六和周日，这种现象823年才出现一次”的论调，一眼就要能看穿是假的（或者会通过程序去证伪），要知道1582年10月5日—14日这十天是不存在的等等。
总之，捷径是没有的，脚踏实地才能学得真知，做到以上几点，假以时日，成为高手并不是梦。
出处：墨天轮（https://www.modb.pro/db/7055，复制到网页中打开或者点击“阅读原文”）
扩展阅读
数据和云
ID：OraNews
如有收获，请划至底部，点击“在看”，谢谢！
云和恩墨大讲堂 | 一个分享交流的地方
长按，识别二维码，加入万人交流社群
请备注：云和恩墨大讲堂
转载：https://blog.csdn.net/enmotech/article/details/102480142
查看评论