Oracle高效设计——Oracle技术丛书 (2008 年度畅销榜NO.2238 )

译者序： 本书是一本关于Oracle的高级手册，书中对Oracle的许多重要概念和特性进行了独到的讨论。它面向的是那些已经知道如何输入SQL语句、如何使用SQL*Plus的Oracle使用人员和开发人员。书中讲授了如何编写“好的”SQL，以及如何编写“好的”Oracle应用程序。 本书共10章及1个附录，各章及附录的内容如下。 第1章 构建应用程序的正确方法：讨论关于Oracle设计的最好方法的某些“软”问题。这些问题与系统设计、开发、测试、部署和维护有关，但它们并不是Oracle所特有的，只不过是从Oracle的角度提出而已。这一章是本书所有章节中涉及技术细节最少的一章，但可能是最重要的一章。 这一章中还对Oracle的各种文档进行了排序和简介，给希望进一步钻研Oracle的各类人员（如编程人员、DBA等）提供了需要阅读的书籍清单。 第2章 性能工具包：作者介绍了自己使用的工具并对为何使用这些工具做了一个概述。另外，还阐述了如何使用这些工具。 第3章 体系结构选择：介绍宏观层次上的体系结构选择，它可以帮助用户获得Oracle能够达到的可伸缩性和性能。该章不深入探讨Oracle服务器进程体系结构及内存结构，不介绍如何建立分区或并行处理，而是将主要精力集中在怎样或何时使用Oracle的这些特性上。 该章还讨论了Oracle体系结构对应用系统的作用，回答了“如何连接到数据库”、“分区能否使数据库运行得更快”等问题。 第4章 高效的管理：介绍作者认为对数据库管理非常有用的一些特性。如SPFILE、OMF、备份与恢复、字典管理的表空间（DMT）和本地管理的表空间（LMT）、ASSM、让Oracle自动管理回退段等。 第5章 语句处理：完整地介绍了Oracle怎样处理语句，详细讨论了主要语句类型（DDL、DML）的分析、优化和执行，包括查询语句的分析、优化和执行。讨论了绑定变量及其使用。最后，强调要尽可能地避免对语句进行分析。 第6章 从基于成本的优化程序获得最大输出：讨论了Oracle中两个不同的优化程序，说明为什么CBO目前值得重点考虑，特别是在Oracle9i Release 2之后的版本不再支持RBO的情况下更是如此。 该章讨论了两个对CBO影响最大的重要参数，它们分别是：OPTIMIZERINDEX COST ADJ和OPTIMIZERINDEXCACHING。该章中还介绍了影响CBO的许多其他参数，并举了许多例子。最后，介绍了10*!053跟踪事件，这是一个能帮助我们理解优化程序所做事情的工具。 第7章 高效的模式设计：应用系统将依赖其物理实现而生存或死亡。选择错误的数据结构会使性能达不到要求，灵活性受到限制。选择正确的数据结构，将会获得良好的性能。该章将考察设计模式时需要考虑的一些东西。然后集中精力讨论表类型、某些有用的索引类型以及压缩等内容。 第8章 高效的SQL：讨论提高查询效率的各种SQL技术，并指出，要想开发高效的SQL，必须对一些较深层次的SQL技术有所了解，如访问路径、连接、模式等。另外，为了开发高效的SQL，深刻理解要解决的问题是至关重要的。 第9章 高效的PL/SQL程序设计：讨论为什么应该考虑在应用程序中使用PL/SQL。然后介绍一些能提供高效、高性能PL/SQL代码的重要编程技术。 第10章 故障排除：介绍一些故障排除的经验和原则。 附录 设置和一些脚本：给出本书许多例子中都用到的BIGTABLE的建立脚本，以及作者经常使用的一些脚本（实用程序）。 参加本书翻译的主要成员有：钟鸣、郝玉洁。全书由刘晓霞同志审校。同时担任部分翻译及校对工作的还有常征、石永平、王君、张文、魏允韬、田晓涛、耿娜、何江华、梅刚、孙登峰、樊伟、李安娜、李晓军、苏秀玲、赵彦萍、马永良、张启斌等。 由于译者水平有限，书中难免有错误或不当之处，敬请读者批评指正。 译 者 2005年11月24日

　　本书读者群为Oracle的开发团队，即对整个系统性能有100%控制权的团体。这个团队包括数据建模人员、程序开发人员和DBA。一个流行的神话是DBA负责应用系统性能的方方面面，并且能完全控制系统的性能。可以用赛车来说明这种老观念的谬误。DBA好比赛车场修理处人员，他负责换轮胎，保证给车加满油并让它正常工作。如果你给这位赛车场修理处人员（DBA）一辆Lincoln Navigator（一种极为巨大的卡车），并告诉他你打算用这车去参加方程式大赛，结果会怎样呢？DBA可以保证这辆卡车跑得尽可能快，但他不能让这辆卡车在急转弯时还能保持每小时100多公里的速度。除非把车扔了重新设计制造，否则一旦车辆设计制造出来，DBA能做的事就很少了(这里的车就是应用程序)。 本书主要面向对如何用Oracle设计和建造具有可伸缩性的系统还没有把握的读者群。本书不是一本初学者指南。它是针对那些已经知道如何输入SQL语句、如何使用SQL*Plus的Oracle开发人员的。我们讲授如何编写“好的”SQL，但不讲授SQL基础知识。讲授如何编写“好的”Oracle应用程序，而不讲授如何编写应用程序。 再举一个例子来说明本书将会提供什么信息。假如开发人员是医生，应用程序是病人。有多种医生： 　　急诊室（ER）医生 这些医生对患者进行“筛选”，区分绝症病人与可以救治的病人，在路上进行急救保持病人尽可能长时间存活。他们将会收到吸烟、具有不良饮食习惯又不锻炼的心脏病人，并且要稳定这些病人的病情。 　　手术室（OR）医生 病人在经过筛选且ER医生做过临时性处理后，由OR医生接收。OR医生经过艰苦的手术不仅要挽救病人的生命，而且还要尽可能使他恢复正常。他们给心脏病人做搭桥手术，尽量清理病人的动脉。 　　物理治疗专家（PT） 在OR医生完成手术后，病人就开始了漫长且痛苦的康复过程（不必说花费昂贵），这时就是PT的事了。 　　预防医生 这些医生尽量使病人不打扰上述三种医生。他们劝病人停止抽烟、吃有益于健康的食品、加强锻炼，并且编制一个有很多步骤的程序帮助他们保持良好状态。如果他们工作得当，除非意外事故（比如车祸），否则病人将永远不会再打扰ER、OR或者PT医生。 目前还需要各种医生，因为确实会发生事故。但是，最重要的医生或许是最后面的这种预防医生，他们尽力让病人不需要其他三种医生。 本人相信（实际如此），大多数人和书最关注前三种医生。他们极相信“英雄”开发人员——ER或OR医生。或许正因为这一点，良好的设计和实现一般是吃力不讨好的事情。ER和OR把病人从死亡的边缘拉了回来，获得了所有的声誉（做一些奇迹般的事情，挽救系统也是这样）。他们在最后一刻被召集起来，努力挽救病人的生命，并且得到丰厚的报酬；另一方面，物理治疗专家就不那么幸运了，他们接手ER/OR医生处理过的系统，负责维持其运转。 我完全可以站在ER的立场说话，因为事实上我就是那些被召集起来并使系统好起来的“英雄”中的一员。我可以撰写这样一本书，确实，也有人曾经告诉我，应该写这样一本书，但我没有写。 　　因为我们所缺少的是包括预防医生培训在内的综合方法。这方面的书籍有一些，我喜欢的有Guy Harrison的《Oracle SQL High Performance Tuning，2nd Edition》（Prentice Hall, 2001）和Jonathan Lewis的《Practical Oracle 8i Building Efficient Databases》（Addison Wesley, 2001）。这些书籍，包括我自己的《Expert One on One Oracle》（Wrox Press, 2001），致力于消除对英雄的需求。请注意，消防人员在救火时是英雄，但我们都希望永远不要和他们打交道。 本书作为一个指南，提供了进行性能调整的所有结构和方法，讨论的内容包括： ●开始设计前的调整。 ●针对特定性能目标进行设计，并不断测试。 ●反复试验（保证每个功能项按要求工作，并了解软件的性能，许多性能问题与不了解数据库如何工作有直接的关系）。 ●实际的事故。研究ER/OR医生的角色，但这不是本书的最终目标之一。因为你所学到的作为一个预防医生的知识应该有助于限制那些更光彩的医生角色。 　　大多数书籍的重点完全放在如何当英雄上，本书则不然，本书的重点在于如何成为一个可靠的系统生产者。它着重建造一个完好的系统而不是修补破碎的系统。我们相信，时间会证明建造完好系统的人才是真正的英雄。

无封面