Oracle 9i & 10g编程艺术-深入数据库体系结构——序(转)

“Think”（思考）。1914年，Thomas J. Watson先生加入后来成为IBM的公司时，带来了这样一个简简单单的座右铭。后来，这成为每一位IBM员工的训词，不论他们身居何职，只要需要做出决策，并利用自己的才智完成所承担的工作，就要把“Think“谨记于心。一时间，”Think“成为一个象征、一个标志，屡屡出现在出版物上，人们把它写在日历上提醒自己，而且不仅在IBM内部，就连其他一些公司的IT和企业管理者的办公室墙上也悬挂着这个牌匾，甚至《纽约客》杂志的漫画里都有它的身影。”Think“在1914年是一个很好的观念，即使在今天也同样有着重要的意义。

“Think different“（不同凡想）是20世纪90年代苹果公司在其旷日持久的宣传活动中提出的一个口号，想借此重振公司的品牌，更重要的是，想改变人们对技术在日常生活中作用的看法。苹果公司的口号不是”think differently“（换角度思考，暗含如何去思考），而是把”different“用作动词”think“的宾语，暗含该思考些什么（与”think big“句式相同）。这个宣传活动强调的是创造性和有创造性的人，暗示苹果电脑在支持重新和艺术成就方面与之不同。

我在1981年加入Oracle公司（那时还叫Relational Software公司）时，包含了关系模型的数据库系统还是一种新兴技术。开发人员、程序员和队伍逐渐壮大的数据库管理员都在学习采用规范化方法的数据库设计原则。在此之后出现了非过程性的SQL语言。尽管人们对它很陌生，但无不为其强大的能力所折服，因为利用SQL语言能有效地管理数据，而以前同样的工作需要进行非常辛苦地编程才能完成。那时要思考的东西很多，现在也依然如此。这些新技术不仅要求人们学习新的概念和方法，还要以新的思想来思考。不论是过去还是现在，做到了这一点的人最终都大获成功，他们能最大限度地利用数据库技术，为企业遇到的问题建立有效的创新性解决方案。

想一想SQL数据库语言吧，历史上是Oracle首次推出了商业化的SQL实现。有了SQL，应用设计人员可以利用一种非过程性语言（或称“描述性语言“）管理行集（即记录集），而不必使用传统的过程性语言编写循环（一次只能处理一条记录）。刚开始接触SQL时，我发现自己必须”转45°“考虑问题，以确定如何使用诸如联结和子查询之类的集合处理操作来得到我想要的结果。那时，集合处理对大多数人来说还是全新的概念，不仅如此，这也是非过程性语言的概念，也就是说，你只需指定想要的结果，而无需指出如何得到这些结果。这种新技术确实要求我”换角度思考“，当然也使我有机会”不同凡想“。

集合处理比一次处理一条记录要高效得多，所以如果应用程序能以这种方式充分利用SQL，就能比那些没有使用集合处理的应用程序表现得更出色。不过，遗憾的是，应用程序的性能往往都不尽如人意。实际上，大多数情况下，最能直接影响整体性能的是应用程序设计，而不是Oracle参数设置或其他配置选项。所以，应用程序开发人员不仅要学习数据库特性和编程接口的详细内容，还要掌握新的思路，并在应用程序中适当地使用这些特性和接口。

在Oracle社区中，关于如何对系统调优以得到最佳的性能（或者如何最佳地使用各种Oracle特性）有许多“常识“。这种原本明智的”常识“有时却演变成为一种”传说“甚至”神话“，这是因为开发人员和数据库管理员可能不加如何批判地采纳这些思想，或者不做如何思考就盲目扩展它们。

举一个例子，比如说这样一个观点：“如果一个东西很好，那么更多——更多些——会更好。“这种想法很普通，但一般并不成立。以Oracle的数组接口为例，它允许开发人员只用一个系统调用就能插入或获取多行记录。显然，能减少应用程序和数据库之间传递的网络消息数当然很好。但是再想想看，到达某个”临界“点后，情况可能会改变。一次获取100行比一次获取1行要好得多，但是如果一次获取1000行而不是100行，这对于提供整体性能通常意义并不大，特别是考虑到内存需求时更是如此。

再来看另一个不加判断就采纳的例子，一般主张关注系统设计或配置中有问题的地方，而不是最有可能改善性能的方面（或者是能提高可靠性、可用性或增强安全性的方面）。请考虑一个系统调优的“常识“：要尽可能提高缓冲区的命中率。对于某些应用，要尽量保证所需数据在内存中，这会最大限度地提高性能。不过，对于大多数应用，最好把注意力放在它的性能瓶颈上（我们称之为”等待状态“），而不要过分强调某些系统级指标。消除应用程序设计中那些导致延迟的因素，就能得到最佳的性能。

我发现，将一个问题分解为多个小部分再逐个加以解决，是一种很好的应用程序设计方法。采用这种方式，往往能极好地、创造性地使用SQL解决应用需求。通常，只需一条SQL语句就能完成许多工作，而你原来可能认为这些工作需要编写复杂的过程性程序才能实现。如果能充分利用SQL的强大能力一次处理一个行集（可能并行处理），这不仅说明你是一个高效率的游泳池开发人员，也说明应用程序能以更快的速度运行！

一些最佳实践取决于（或部分取决于）事实的真实性，有时，随着事实的改变，这些最佳实践可能不再适用。请考虑一句古老的格言：“要得到最好的性能，应当把索引和数据放在单独的表空间中。“我经常发现许多数据库管理员都恪守着这个观点，根本不考虑如今磁盘的速度和容量已经大为改观，也不考虑给定工作负载的特殊要求。要评价这个”规则“是否合适，应该考虑这样一个事实：Oracle数据库会在内存中缓存最近经常使用的数据库块（通常这些块属于某个索引）。还有一点需要考虑：对于给定的请求，Oracle数据库会顺序使用索引和数据块，而不是同时访问。这说明，所有并发用户实际上应该都会执行涉及索引好数据的I/O操作，而且每块磁盘上都会程序I/O操作。可能你会出于管理方面的原因（或者根据你的个人喜好）将索引和数据块分置于不同的表空间中，但就不能说这样做是为了提高性能。（Thomas Kyte在Ask Tom网站 http://asktom.oracle.com上对这个主题做了深入的分析，有关文章可以在”index data table space“中查到。）从中我们可以得到一个教训，要根据事实做出决定，而且事实必须是当前的、完备的。

不论我们的计算机速度变得多快，数据库变得多复杂，也不管编程工具的能力如何，人类的智慧和一套正确的“思考原则“仍是无可替代的。所以，对于应用中使用的技术，尽管学习其细节很重要，但更重要的是，应该知道如何考虑适当地使用这些技术。

Thomas Kyte是我认识的最聪明的人之一，他在Oracle数据库、SQL、性能调优和应用设计方面具有渊博的学识。我敢肯定，Thomas绝对是“Think“和”Think different“这两个口号不折不扣的追随者。有位中国的智者说过”授人以鱼，为一饭之惠；授人以渔，则终身受用“，显然Thomas对此深以为然。Thomas很乐于把自己的Oracle知识与大家共享，但他并不是只是罗列问题的答案，而是尽力帮助大家学会如何思考和推理。

在Thomas的网站（http://asktom.oracle.com）上、发言稿中以及书中，他其实不断鼓励人们在使用Oracle数据库设计数据库应用时要“换角度思考“。他从不墨守成规，而坚持通过实例，用事实证明。Thomas采用一种注重实效的简单方法来解决问题，按照他的建议和方法，你将成为更高效的开发人员，能开发出更好、更快的应用。

Thomas的这本书不仅介绍Oracle的诸多特性，教你使用这些特性，还反映了以下简单的观点：

不要相信神话，要自己思考。
不要墨守成规，所有人都知道的事情其实很可能是错的！
不要相信传言，要自己测试，根据经过证明的示例做出决定。
将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。
如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。
理解理想和现实之间的差距。
对于公司制定的未加证实的技术标准，要敢于提出质疑。
要针对当前需求从大局考虑怎样做最好。
要花时间充分地思考。

Thomas建议，不要只是把Oracle当作一个黑盒。你不只是在Oracle中放入和取出数据。他会帮助你理解Oracle是如何工作的，如何充分利用它强大的能力。通过学习如何深思熟虑地、创造性地应用Oracle技术，你会更快、更好地解决大多数应用设计问题。

通过阅读这本书，你会了解到Oracle数据库技术的许多新动态，还会掌握应用设计的一些重要概念。如果你确实领会了这些思想，相信你肯定也会对所面对的难题“换角度思考”。

IBM的Watson曾经说过：“自始以来，每一个进步都源自于思考。仅仅因为‘没有思考’，就造成全世界白白浪费了无数资金。”Thomas和我都赞同这种说法。学完这本书后，利用你掌握的知识和技术，希望你能为这个世界（至少能为你的企业）节省无数资金，把工作干得更出色。

Ken Jacobs

Oracle公司产品战略部（服务器技术）副总裁