DBA日记第三部 像ORACLE一样思考

1 前言

每个来应聘DBA的人我都会问他们一个问题：“Oracle到底是什么？”，有些人会用数据库基础的理论来回答我：“数据库是数据的集合”，也有些人会感到茫然，不知道我问这个问题是什么意思。实际上很多Oracle DBA从来没有思考过这个问题。“Oracle就是Oracle，是一个产品，还能有什么意思呢？我不知道Oracle到底是什么也没有影响到我做一个合格的DBA”，很多人都会这么想。

实际上对于Oracle我们确实还需要重新去认识认识，每个DBA在学习Oracle的时候都往往注重于学习如何建库、如何管理、如何编程、如何优化。虽然说这也是学习Oracle数据库最为常见的一种方法，但是这样学习下去，我们总是在记忆一些枯燥的语法和脚本，虽然经过数年我们积累下了大量的经验，但是我们还是无法真正的理解Oracle，数据库升级了，系统变化了，我们就必须从头去学习。常年累月，我们总是在一次一次的循环往复的重复着同样的事情，直到我们筋疲力尽，对Oracle失去往日的激情，最终DBA成为一个职业，Oracle成为我们谋生的手段。

事实上，我们可以换一种方式来学习Oracle，让Oracle的精神融入DBA的血液中，让DBA像Oracle一样思考问题，Oracle作为我们的爱好，作为我们生活的一部分存在。对于大多数DBA来说，这也许只是一个乌托邦式的理想，对于绝大多数DBA来说，我们需要有一份工作，需要靠这份工作来生存，娶妻生子，享受生活。并不是所有的人希望让Oracle成为生活的一部分，这是很现实的，不过我们虽然可以仅仅把Oracle当做是生活的一部分，当做是谋生手段，但是我们也可以同时尝试了解更多的Oracle的本质，让我们像Oracle一样思考。

像Oracle一样思考虽然不能带给你更多的生活乐趣，但是通过这样的方式去学习和思考，我们会更加精确的了解Oracle的精髓，让我们在DBA的成长过程中少走弯路。10多年前我第一次接触JAVA的时候，感到十分头痛。不是自夸，10多年前，我是一个相当不错的C程序员，最高纪录是一天之内编写500多行复杂的代码，而且一次性编译通过，一次性测试通过，这样的记录的诞生是基于十分良好的过程思维能力的。不过当我这个自认为的编程高手第一次接触JAVA的时候，却感到十分吃力。我无法用面向对象的思想去编写程序，所以我学习JAVA的过程十分痛苦，几次学习，最后都放弃了。直到有一天我看到了一本英文的书籍《Thinking in JAVA》，通过这本书，我掌握了JAVA和面向对象设计、编程的主要思路。自从看了这本书之后，我再次面对JAVA程序的时候，发现一切都是那么的简单。很快我就掌握了JAVA编程。现在我虽然还仍然只是一个三流的JAVA程序员，不过粉丝网的一些修修补补的工作我完全能够胜任了，而且在一些和开发人员交流的时候，我也能够很快的理解他们的思路。

后来我总结了一下，在看《Thinking in JAVA》这本书之前，我在编写JAVA程序的时候，并没有理解面向对象编程的概念，只能是照猫画虎，拿着一个例子在上面修改，实际上我的编程风格还是面向过程的，因此写出来的代码质量很差。而通过《Thinking in JAVA》的阅读，我终于学会了硬面向对象的方法，用JAVA本身的思想去考虑问题，因此我能够更加准确的抓住问题的本质。我想，学习Oracle数据库也是这样，如果我们通过一个案例一个案例的去学习Oracle，那么我们将永远停留在表层上，哪怕我们干上10年20年DBA，也可能只能学到Oracle的一些皮毛，一旦碰到一个我们没有见到的案例，可能我们就会感到手足无措。

这些年里我接触过大量的DBA，我一般把这些DBA分为四大类。第一类DBA是经验型的，他们处理问题的主要方式取决于以往的经验，他们往往都有很好的习惯，会把每一个处理过的案例整理出来，今后再碰到这类案例的时候，他们会很快的解决问题。这类DBA随着工作时间的增长，他们的技术也会相应的提高。第二类DBA是理论型的，他们具有很深的理论基础，经常探讨一些“Oracle Internal Only”的高深问题，但是他们在某些方面的研究很深，比如他们能够很清晰的告诉你共享池分配的算法，告诉你checkpoint的工作原理，但是这些DBA往往缺乏实际的工作经验，他们研究Oracle但是很少有机会接触大型的数据库系统，因此他们实际解决问题的能力并不强。第三类DBA是技巧型的，他们并不注重理论的学习和经验的积累，他们在处理问题的时候往往能够利用metalink和谷歌百度之类的工具去搜索解决方案，这类DBA是我见到过的最多的，这类DBA处理问题的时候，往往取决于运气。第四类DBA是虚心请教型的，这类DBA无论碰到什么问题，甚至连错误信息都没有看明白，就开始到处叫“我的系统出问题了”，然后到处去问如何解决。

实际上，这四类DBA都是有缺陷的，第一类DBA可能经过多年的工作，有十分丰富的经验，处理问题的能力很强，而且对分析问题十分敏感，很容易抓到问题的关键，但是由于缺乏深入理解Oracle的理论，因此在碰到一些较为深入的问题的时候，在初期总是很难把握住问题的关键，虽然凭借着自身丰富的经验和问题分析排查能力，他们最终也能解决大部分的问题，但是很多时候问题解决后还是无法真正的弄明白为什么会解决问题，下一次碰到类似的问题，可能还是要花很大的代价。

第二类DBA在某些方面的理论知识很强，总是喜欢研究一些十分高深的原理性的东西，但是这类DBA的主要精力都放在了研究一些Oracle内部原理上了，他们没有更多的时间去实践，去把他们学到的理论融合到实践中去。这类DBA往往知识面较为狭窄，仅精通于自己研究比较深入的领域，在实际工作中也很难发挥出自身对理论研究的成果来。

第三类DBA实际上在我们的现实生活中是最常见的，“万事不明问百度，百度不明就抓瞎”，确实谷歌百度和Metalink能够帮助我们解决不少问题，但是这类DBA往往在问题解决后没有好好思考一下，为什么这个方法能够帮助我们解决问题，更没有认真总结和归纳一下，于是下一次碰到类似的问题，还是无法依靠自己的思考去解决问题，于是再google一把，也许这一次运气没有这么好了，google出来的资料不是上回的那个了，于是结果很可能是很悲惨的。

第四类DBA在我们现实生活中也经常出现，网络社会十分发达，打个电话或者在qq群里，msn里问问，也许就有人帮我解决问题，久而久之，这些人放弃了自己思考问题，碰到一点点小问题都首先问起再说。

看到这里，大家可能明白了，老白实际上说的不是四类DBA，而是DBA的四种性格，这四种性格可能会集中在某一个人身上，以老白学习DBA的经验来看，理论结合实践是十分重要的。在2000年前，老白虽然做了很多项目，也是很多人眼里的Oracle数据库高手，但是在2000年前，老白就是第一类DBA的典型，没有经过多少理论学习，几乎所有的Oracle数据库的技能都是从实践中获得的。虽然在实践中我总结出大量的经验，甚至有很多客户建议我写一本书，把我对Oracle的理解写出来。不过当我自信满满的开始写书的时候，我突然发现，我的一些知识需要进行确认，否则写出来就贻笑大方了。于是我开始大量的学习Oracle的一些理论知识，随着写书的过程的深入，我越发感到自身理论水平的不足。《Oracle数据库深度历险》这本书我写了3年，实际上2002年我就彻底放弃了出版这本书的念头，因为我发现我的理论知识确实还需要进一步的梳理，但是我并没有放弃写书，因为我发现通过写书，我更为系统的将Oracle的理论知识梳理了一遍，这次梳理是通过我以前的知识体系、工作经验，用Oracle Concepts的理论基础进行了一次完整的整合。通过这3年的写作，我终于完全疏通了Oracle的理论体系，好像一个练武术的人，终于打通了任督二脉，感到无比的畅快。

听老白说了这么一大通，是不是很多人都感觉到手脚发凉，难道成为一个合格的DBA有这么难吗？如果我没有打通任督二脉，就不算一个合格的DBA吗？实际上DBA成长的道路是很多的，并不一定要走老白这一条路，老白仅仅是根据自身的经历，通过这本书来帮助大家梳理Oracle的一些基础知识而已，还是那句话，如果Oracle是你的爱好，那么你无论花多大代价去研究它都是值得的，如果Oracle只是你职场生涯中的一个工作而已，那么只要你认真对待他就可以了，没必要像老白那样执着。

在这本书里，老白会把《Oracle数据库深度历险》中的一些内容，结合老白的实际工作经验，剖析起原理，并结合案例来说明这些理论知识如何在实践中实际应用，展现给大家，希望老白的这次写作经历，能够给大家带来一些帮助。