（已有39条评价）基本信息
- 原书名：Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions, Second Edition [
- 原出版社： Apress
- 作者： (美)Thomas Kyte
- 译者： 苏金国 王小振
- 丛书名： 图灵程序设计丛书 数据库
- 出版社：人民邮电出版社
- ISBN：9787115244857
- 上架时间：2011-1-5
- 出版日期：2011 年1月
- 开本：16开
- 页码：706
- 版次：2-1
- 所属分类：计算机 > 数据库 > Oracle
编辑推荐
久负盛名的Oracle经典
世界顶级专家Thomas Kyte力作
Ask Tom！解决你所有的Oracle疑难杂症
相关推荐:
《收获,不止Oracle》
《Oracle索引技术》
《Oracle 高性能SQL引擎剖析:SQL优化与调优机制详解》
《Oracle Database 11g性能优化攻略》
《DBA的思想天空 : 感悟Oracle数据库本质》
内容简介
作译者
Thomas Kyte Oracle公司核心技术集团副总裁。从5.1.1c版本开始使用Oracle，自7.0.9版本发布就一直任职于Oracle公司，帮助Oracle数据库用户设计和构建系统，或者对系统进行重构和调优。此前曾是一位系统集成师，主要为美国军方和政府部门的客户构建大规模的异构数据库和应用。长期主持Oracle Magazine “Ask Tom”专栏，热心回答困扰全世界Oracle开发人员和DBA的各种问题。除本书外，还著有广受好评的《Oracle专家高级编程》和《Oracle高效设计》。
目录
第1章 开发成功的Oracle应用 1
1.1 我的方法 2
1.2 黑盒方法 3
1.3 开发数据库应用的正确（和不正确）方法 10
1.3.1 了解Oracle体系结构 11
1.3.2 理解并发控制 19
1.3.3 多版本控制 22
1.3.4 数据库独立性 28
1.3.5 怎么能让应用运行得更快 42
1.3.6 DBA与开发人员的关系 44
1.4 小结 45
第2章 体系结构概述 46
2.1 定义数据库和实例 47
2.2 SGA和后台进程 52
2.3 连接Oracle 54
2.3.1 专用服务器 54
2.3.2 共享服务器 56
2.3.3 TCP/IP连接的基本原理 57
2.4 小结 59
第3章 文件 60
1.1 我的方法 2
1.2 黑盒方法 3
1.3 开发数据库应用的正确（和不正确）方法 10
1.3.1 了解Oracle体系结构 11
1.3.2 理解并发控制 19
1.3.3 多版本控制 22
1.3.4 数据库独立性 28
1.3.5 怎么能让应用运行得更快 42
1.3.6 DBA与开发人员的关系 44
1.4 小结 45
第2章 体系结构概述 46
2.1 定义数据库和实例 47
2.2 SGA和后台进程 52
2.3 连接Oracle 54
2.3.1 专用服务器 54
2.3.2 共享服务器 56
2.3.3 TCP/IP连接的基本原理 57
2.4 小结 59
第3章 文件 60
译者序
Oracle Database 11g的推出让关注Oracle的人欣喜万分，不过也不免有些担心，因为此前还没有合适的书系统而深入地介绍这个新版本。要想学习和掌握它的诸多新特性，只能从Oracle手册入手，而数万页的11g手册不免让人心存畏惧，从中挑出对新特性的描述更需要一双“火眼金睛”。
好消息！在本书第1版出版时隔4年后，Thomas Kyte及时了解了大家的这一迫切需求，根据他的实战经验以及人们最关心的问题对这本书做了全面补充和调整，以涵盖11g最受关注的多项特性。例如11g引入dbms_parallel_execute包来帮助自动实现原来需要人工实现的并行化，以及引入PSQ来控制并行度，限制资源的过度使用，从而进一步改进并行化的实现。11g还增加了对递归调用子查询的支持，来避免原先令人费解的connect by语法。另外通过闪回数据归档支持长期闪回查询，这意味着查询几个月前甚至几年前的数据不再是奇谈。延迟段创建特性的引入更让我们看到了Oracle对于性能的“锱珠必较”和精益求精。所有这些内容都在这一版中得以体现，Tom还专门增加了一章来讨论Oracle中的数据加密。相信你的问题都能在这一版中得到解答。
这一版仍沿袭了上一版的叙事风格，Tom通过轻松交流的方式，让你从具体的例子、具体的实践中了解技术细节，在知道“怎样做”的同时还能理解“为什么这样做”。还特别根据读者对上一版内容的反馈，在文中追加了大量注解，另外还利用注解强调了11g与9i/10g的区别。相信你已经迫不及待地想要翻开下一页了，那么，进入Tom的Oracle世界吧！
很高兴上一版出版后得到了读者的青睐，能够让更多中国读者领略Tom的这一力作，这让我们也倍感自豪。对于第2版的翻译，我们同样不敢马虎，尽量减少歧义，希望能让读者更轻松地阅读和理解。不过由于水平有限，译文肯定有不当之处，敬请批评指正。
好消息！在本书第1版出版时隔4年后，Thomas Kyte及时了解了大家的这一迫切需求，根据他的实战经验以及人们最关心的问题对这本书做了全面补充和调整，以涵盖11g最受关注的多项特性。例如11g引入dbms_parallel_execute包来帮助自动实现原来需要人工实现的并行化，以及引入PSQ来控制并行度，限制资源的过度使用，从而进一步改进并行化的实现。11g还增加了对递归调用子查询的支持，来避免原先令人费解的connect by语法。另外通过闪回数据归档支持长期闪回查询，这意味着查询几个月前甚至几年前的数据不再是奇谈。延迟段创建特性的引入更让我们看到了Oracle对于性能的“锱珠必较”和精益求精。所有这些内容都在这一版中得以体现，Tom还专门增加了一章来讨论Oracle中的数据加密。相信你的问题都能在这一版中得到解答。
这一版仍沿袭了上一版的叙事风格，Tom通过轻松交流的方式，让你从具体的例子、具体的实践中了解技术细节，在知道“怎样做”的同时还能理解“为什么这样做”。还特别根据读者对上一版内容的反馈，在文中追加了大量注解，另外还利用注解强调了11g与9i/10g的区别。相信你已经迫不及待地想要翻开下一页了，那么，进入Tom的Oracle世界吧！
很高兴上一版出版后得到了读者的青睐，能够让更多中国读者领略Tom的这一力作，这让我们也倍感自豪。对于第2版的翻译，我们同样不敢马虎，尽量减少歧义，希望能让读者更轻松地阅读和理解。不过由于水平有限，译文肯定有不当之处，敬请批评指正。
前言
过去我一直在开发Oracle软件，并与其他Oracle开发人员一同工作，帮助他们构建可靠、健壮的基于Oracle数据库应用程序。在这个过程中积累了一些经验，正是这些经验赋予我灵感，才有了本书中的内容。这本书实际上反映了我每天做了些什么，汇集了我所看到的人们每天遇到的问题。
本书涵盖了我认为最重要的一些内容，即Oracle数据库及其体系结构。我也可以写一本书名类似的其他方面的书，向你解释如何用一种特定的语言和体系结构开发应用程序。例如，我可以告诉你如何使用JSP（JavaServer Pages）与EJB（Enterprise JavaBeans）通信，EJB又如何使用JDBC与Oracle通信。不过，归根结底，最后还是要了解Oracle数据库及其体系结构（本书介绍的内容），才能成功地构建这样一个应用程序。要想成功地使用Oracle进行开发，我认为有些内容你必须了解，而不论你是一位使用ODBC的Visual Basic程序员、使用EJB和JDBC的Java程序员，还是使用DBI Perl的Perl程序员，这本书都会介绍这些通用的知识。本书并不推崇哪一种特定的应用体系结构，在此没有比较三层结构和客户/服务器结构孰优孰劣。我们只是讨论数据库能做什么，另外关于数据库如何工作，我们还会指出你必须了解哪些内容。由于数据库是所有应用体系结构的核心，所以这本书适用面很广。
顾名思义，本书的重点是数据库体系结构，并强调数据库本身如何工作。我会深入地分析Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库和实例的进程。然后讨论一些重要的数据库主题，如锁定、并发控制、事务、redo和undo，还会解释为什么了解这些内容很重要。最后，我们再来分析数据库中的物理结构，如表、索引和数据类型，并介绍哪些技术能最优地使用这些物理结构。
本书内容
如果开发的选择余地很大，则会带来一些问题，其中一个问题是有时很难确定哪种选择最能满足特定需求。每个人都希望灵活性尽可能大（有尽可能多的选择），同时又希望能简单明了，换句话说，希望尽量容易。Oracle为开发人员提供的选择几乎无穷无尽。没有人会说“这在Oracle中做不到”，而只会说“在Oracle中你想用多少种不同的方法来实现”。希望这本书能帮你作出正确的选择。
如果你不只是想知道做何选择，还想了解有关Oracle特性和功能的一些原则和实现细节，这本书就很适合你。例如，Oracle有一个很棒的特性，称为并行执行（parallel execution）。Oracle文档会告诉你如何使用这个特性，并说明它到底能做什么。不过，Oracle文档没有告诉你应该在什么时候用这个特性，更重要的是没有指出什么时候不该使用这个特性。另外，文档一般没有提供特性的实现细节，如果你不清楚，可能会因此而困扰（我指的不是bug，而是说你可能很想知道这个特性如何工作，以及为此是怎样具体设计的，但从文档中找不到答案）。
在本书中，我不仅会尽力阐明各个特性如何工作，还会指出什么情况下要考虑使用某个特性或实现，并解释为什么。我认为，理解“怎么做”固然很重要，但理解“什么时候做”和“为什么这样做”（以及“什么时候不做”和“为什么不做”）也同样重要！
读者对象
本书面向那些使用Oracle作为数据库后端开发应用程序的人员。专业Oracle开发人员如果想了解如何在数据库中完成某些工作，同样可以参考本书。本书相当实用，所以DBA也会对书中的许多内容感兴趣。书中大部分例子都使用SQL*Plus来展示关键特性，所以如果想通过本书来了解如何开发一个很酷的GUI，可能不能如愿。不过，从这本书中，你将知道Oracle数据库如何工作，它的关键特性能做些什么，以及什么时候应该（和不应该）使用这些特性。
如果你想事半功倍地使用Oracle，如果你想了解使用现有特性的新方法，如果你想知道这些特性在真实世界中如何应用（不只是展示如何使用特性，而是首先分析为什么要用这个特性），就请阅读本书。作为技术经理，如果你手下的开发人员在开发Oracle项目，你可能也会对本书感兴趣。从某种程度上讲，技术经理也要懂数据库，而且要知道这对于成功至关重要。如果技术经理想安排员工进行适当的技术培训，或者想确保员工了解他们应该掌握的技术，就可以利用本书来“充电”。
要想更好地学习本书的内容，要求具备以下能力。
了解SQL。不要求你能编写最棒的SQL代码，但是如果用过SQL，对SQL有实战经验，这会很有帮助。
掌握PL/SQL。这不是一个必要的前提，但是有助于你“领会”书中的例子。例如，本书不会教你怎样编写一个FOR循环，或者如何声明一个记录类型，这些内容可以参考Oracle文档和许多相关的图书。不过，这并不是说你从本书中学不到PL/SQL的知识。不是这样的。通过阅读本书，你会对PL/SQL的许多特性相当熟悉，而且会学到一些新方法，还会注意到你以前以为不存在的一些包和特性。
接触过某种第三代语言（third-generation language，3GL），如C或Java。我相信，如果你能阅读3GL语言编写的代码，或者编写过这种代码，肯定能顺利地阅读和理解本书中的例子。
熟悉Oracle Concepts手册。
最后再说两句，由于Oracle文档实在太庞大了，这让很多人都有些畏惧。如果你刚开始读Oracle Concepts手册，或者还没有看过，那我可以告诉你，这个手册绝对是一个很好的起点。它大约有400页（我知道页数是因为我编写了一部分，并且编辑了每一页），涉及你需要知道的许多重要的Oracle概念。其中不会涵盖每一个技术细节（Oracle文档提供了技术细节，不过它有10 000页到20 000页之多），但你能从中学到所有重要的概念。这个手册涉及以下主题（这里所列的并不完整）：
数据库中的结构，数据如何组织和存储；
分布式处理；
Oracle的内存体系结构；
Oracle的进程体系结构；
本书涵盖了我认为最重要的一些内容，即Oracle数据库及其体系结构。我也可以写一本书名类似的其他方面的书，向你解释如何用一种特定的语言和体系结构开发应用程序。例如，我可以告诉你如何使用JSP（JavaServer Pages）与EJB（Enterprise JavaBeans）通信，EJB又如何使用JDBC与Oracle通信。不过，归根结底，最后还是要了解Oracle数据库及其体系结构（本书介绍的内容），才能成功地构建这样一个应用程序。要想成功地使用Oracle进行开发，我认为有些内容你必须了解，而不论你是一位使用ODBC的Visual Basic程序员、使用EJB和JDBC的Java程序员，还是使用DBI Perl的Perl程序员，这本书都会介绍这些通用的知识。本书并不推崇哪一种特定的应用体系结构，在此没有比较三层结构和客户/服务器结构孰优孰劣。我们只是讨论数据库能做什么，另外关于数据库如何工作，我们还会指出你必须了解哪些内容。由于数据库是所有应用体系结构的核心，所以这本书适用面很广。
顾名思义，本书的重点是数据库体系结构，并强调数据库本身如何工作。我会深入地分析Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库和实例的进程。然后讨论一些重要的数据库主题，如锁定、并发控制、事务、redo和undo，还会解释为什么了解这些内容很重要。最后，我们再来分析数据库中的物理结构，如表、索引和数据类型，并介绍哪些技术能最优地使用这些物理结构。
本书内容
如果开发的选择余地很大，则会带来一些问题，其中一个问题是有时很难确定哪种选择最能满足特定需求。每个人都希望灵活性尽可能大（有尽可能多的选择），同时又希望能简单明了，换句话说，希望尽量容易。Oracle为开发人员提供的选择几乎无穷无尽。没有人会说“这在Oracle中做不到”，而只会说“在Oracle中你想用多少种不同的方法来实现”。希望这本书能帮你作出正确的选择。
如果你不只是想知道做何选择，还想了解有关Oracle特性和功能的一些原则和实现细节，这本书就很适合你。例如，Oracle有一个很棒的特性，称为并行执行（parallel execution）。Oracle文档会告诉你如何使用这个特性，并说明它到底能做什么。不过，Oracle文档没有告诉你应该在什么时候用这个特性，更重要的是没有指出什么时候不该使用这个特性。另外，文档一般没有提供特性的实现细节，如果你不清楚，可能会因此而困扰（我指的不是bug，而是说你可能很想知道这个特性如何工作，以及为此是怎样具体设计的，但从文档中找不到答案）。
在本书中，我不仅会尽力阐明各个特性如何工作，还会指出什么情况下要考虑使用某个特性或实现，并解释为什么。我认为，理解“怎么做”固然很重要，但理解“什么时候做”和“为什么这样做”（以及“什么时候不做”和“为什么不做”）也同样重要！
读者对象
本书面向那些使用Oracle作为数据库后端开发应用程序的人员。专业Oracle开发人员如果想了解如何在数据库中完成某些工作，同样可以参考本书。本书相当实用，所以DBA也会对书中的许多内容感兴趣。书中大部分例子都使用SQL*Plus来展示关键特性，所以如果想通过本书来了解如何开发一个很酷的GUI，可能不能如愿。不过，从这本书中，你将知道Oracle数据库如何工作，它的关键特性能做些什么，以及什么时候应该（和不应该）使用这些特性。
如果你想事半功倍地使用Oracle，如果你想了解使用现有特性的新方法，如果你想知道这些特性在真实世界中如何应用（不只是展示如何使用特性，而是首先分析为什么要用这个特性），就请阅读本书。作为技术经理，如果你手下的开发人员在开发Oracle项目，你可能也会对本书感兴趣。从某种程度上讲，技术经理也要懂数据库，而且要知道这对于成功至关重要。如果技术经理想安排员工进行适当的技术培训，或者想确保员工了解他们应该掌握的技术，就可以利用本书来“充电”。
要想更好地学习本书的内容，要求具备以下能力。
了解SQL。不要求你能编写最棒的SQL代码，但是如果用过SQL，对SQL有实战经验，这会很有帮助。
掌握PL/SQL。这不是一个必要的前提，但是有助于你“领会”书中的例子。例如，本书不会教你怎样编写一个FOR循环，或者如何声明一个记录类型，这些内容可以参考Oracle文档和许多相关的图书。不过，这并不是说你从本书中学不到PL/SQL的知识。不是这样的。通过阅读本书，你会对PL/SQL的许多特性相当熟悉，而且会学到一些新方法，还会注意到你以前以为不存在的一些包和特性。
接触过某种第三代语言（third-generation language，3GL），如C或Java。我相信，如果你能阅读3GL语言编写的代码，或者编写过这种代码，肯定能顺利地阅读和理解本书中的例子。
熟悉Oracle Concepts手册。
最后再说两句，由于Oracle文档实在太庞大了，这让很多人都有些畏惧。如果你刚开始读Oracle Concepts手册，或者还没有看过，那我可以告诉你，这个手册绝对是一个很好的起点。它大约有400页（我知道页数是因为我编写了一部分，并且编辑了每一页），涉及你需要知道的许多重要的Oracle概念。其中不会涵盖每一个技术细节（Oracle文档提供了技术细节，不过它有10 000页到20 000页之多），但你能从中学到所有重要的概念。这个手册涉及以下主题（这里所列的并不完整）：
数据库中的结构，数据如何组织和存储；
分布式处理；
Oracle的内存体系结构；
Oracle的进程体系结构；
序言
第 1 版 序
“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行要好得多，但是如果一次获取1 000行而不是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的诸多特性，教你使用这些特性，还反映了以下简单的观点。
不要相信神话，要自己思考。
不要墨守成规，所有人都知道的事情其实很可能是错的！
不要相信传言，要自己测试，根据经过证明的示例作出决定。
将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。
如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。
“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行要好得多，但是如果一次获取1 000行而不是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的诸多特性，教你使用这些特性，还反映了以下简单的观点。
不要相信神话，要自己思考。
不要墨守成规，所有人都知道的事情其实很可能是错的！
不要相信传言，要自己测试，根据经过证明的示例作出决定。
将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。
如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。
媒体评论
“本书能够帮助你发挥Oracle技术的最大能量……毋庸置疑，这是最重要的Oracle图书之一，绝对值得拥有。”
——Ken Jacobs
Oracle公司产品策略部（服务器技术）副总裁，公认的DBA博士
“真是一本绝妙的书，包含大量关于Oracle技术的真知灼见。”
——Sean Hull
——Ken Jacobs
Oracle公司产品策略部（服务器技术）副总裁，公认的DBA博士
“真是一本绝妙的书，包含大量关于Oracle技术的真知灼见。”
——Sean Hull
书摘
对于开发数据库软件，我有一套很简单的哲学，这是我多年以来一直信守的准则。口如果可能，尽量利用一条SQL语句完成工作。无论你是否相信，这几乎总是行之有效的方法。口如果无法用一条SQL语句完成，就通过PL/SQL实现。（不过，尽可能少用PL/SQL）要知道，代码越多，bug越多l代码越少，bug越少。
口如果在PL/SQL中也无法做到，可以试试使用Java存储过程来实现。不过，有了OracleDatabase9f及以上版本后，如今需要这样做的可能性极小。
口如果用Java还办不到，那就在c外部例程中实现。如果速度要求很高，或者要使用采用c编写的第三方API，就常常使用这种做法。
口如果在c外部例程中还无法实现，就该好好想想有没有必要做这个工作了。
在这本书中，你会看到我是怎样将上述思想付诸实践的。我会使用PL/sQL和PL/sQL中的对象类型来完成SQIL本身办不到的事情。PL/SQL发展至今已经有很长时间了，它经历了长达二十多年的调整和优化。实际上，OracleDatabase10g编译器本身就首次重写为一个优化编译器。你会发现，没有哪种语言能像PL/SQL这样与sQL如此紧密地耦合，也没有哪种语言得到如此优化，可以与SQL更好地交互。在PL/sQL中使用sQL是一件相当自然的事情，而在几乎所有其他语言（从VisualBasic到Java）中，使用SQL都很麻烦。对于这些语言来说，使用SQL绝对没有“自然”的感觉，它不是这些语言本身的扩展。如果PL/SQL还无法做到（这在当前数据库版本中相当少见），我们会使用Java。有时，如果c是唯一的选择，或者需要C才能提供的高速度，我们也会用c来完成工作。随着本地Java编译（nativeJavacompilation）的闪亮登场（可以把Java.字节码转换为具体平台上特定于操作系统的对象码），你会发现，在许多情况下，Java.与C的运行速度相差无几。所以，需要用到c的情况越来越少。
1.2 黑盒方法
根据我个人的第一手经验（这表示，在学习软件开发时我自己也曾犯过错误），我对基于数据库的软件开发为什么如此频繁地遭遇失败有一些看法。先来澄清一下，这里提到的这些项目可能一般不算失败，但是启用和部署所需的时间比原计划多出许多，原因是需要大幅重写，重新建立体系结构，或者需要充分调优。我个人把这些延迟的项目称为“失败”，因为它们原本可以按时完成（甚至可以更快完成）。
……
口如果在PL/SQL中也无法做到，可以试试使用Java存储过程来实现。不过，有了OracleDatabase9f及以上版本后，如今需要这样做的可能性极小。
口如果用Java还办不到，那就在c外部例程中实现。如果速度要求很高，或者要使用采用c编写的第三方API，就常常使用这种做法。
口如果在c外部例程中还无法实现，就该好好想想有没有必要做这个工作了。
在这本书中，你会看到我是怎样将上述思想付诸实践的。我会使用PL/sQL和PL/sQL中的对象类型来完成SQIL本身办不到的事情。PL/SQL发展至今已经有很长时间了，它经历了长达二十多年的调整和优化。实际上，OracleDatabase10g编译器本身就首次重写为一个优化编译器。你会发现，没有哪种语言能像PL/SQL这样与sQL如此紧密地耦合，也没有哪种语言得到如此优化，可以与SQL更好地交互。在PL/sQL中使用sQL是一件相当自然的事情，而在几乎所有其他语言（从VisualBasic到Java）中，使用SQL都很麻烦。对于这些语言来说，使用SQL绝对没有“自然”的感觉，它不是这些语言本身的扩展。如果PL/SQL还无法做到（这在当前数据库版本中相当少见），我们会使用Java。有时，如果c是唯一的选择，或者需要C才能提供的高速度，我们也会用c来完成工作。随着本地Java编译（nativeJavacompilation）的闪亮登场（可以把Java.字节码转换为具体平台上特定于操作系统的对象码），你会发现，在许多情况下，Java.与C的运行速度相差无几。所以，需要用到c的情况越来越少。
1.2 黑盒方法
根据我个人的第一手经验（这表示，在学习软件开发时我自己也曾犯过错误），我对基于数据库的软件开发为什么如此频繁地遭遇失败有一些看法。先来澄清一下，这里提到的这些项目可能一般不算失败，但是启用和部署所需的时间比原计划多出许多，原因是需要大幅重写，重新建立体系结构，或者需要充分调优。我个人把这些延迟的项目称为“失败”，因为它们原本可以按时完成（甚至可以更快完成）。
……
