Oracle 9i & 10g编程艺术：深入数据库体系结构(09年度畅销榜TOP50)(08年度畅销榜TOP50)
点击看大图基本信息
编辑推荐
被china-pub会员评为“2007年我最喜爱的十大技术图书”之一
久负盛名的Oracle经典
世界顶级专家Thomas Kyte力作
Oracle DBA和开发人员必备
推荐阅读
内容简介回到顶部↑
本书是一本有关oracle 9i和10g体系结构数据库的权威书籍，涵盖了所有最重要的oracle体系结构特性，包括文件、内存结构和进程，锁和锁存，事务、并发和多版本，表和索引，数据类型，以及分区和并行，并充分利用具体的例子来介绍每个特性，不仅讨论了各个特性是什么，还说明了它是如何工作的，如何使用这个特性来实现软件，以及有关的常见陷阱。
本书面向从事oracle数据库应用的所有开发人员或dba。
无论你是程序员还是dba，要创建和管理稳定、高质量的oracle系统，归根结底都需要理解oracle数据库的体系结构。
本书是讲述oracle数据库毋庸置疑的权威指南，凝聚了世界顶尖的oracle专家thomas kyte数十年的宝贵经验和大量真知灼见。书中深入地分析了oracle数据库体系结构，包括文件、内存结构以及构成oracle数据库和实例的底层进程，然后讨论了一些重要的数据库主题，如锁定、并发控制、事务、重做和撤销，还解释了这些内容的重要性。最后，分析了数据库中的物理结构，如表、索引和数据类型，并介绍哪些技术能最优地使用这些物理结构。
在介绍每个特性时，作者都充分利用具体的例子来说明，不仅讨论了各个特性是什么，还说明了它如何工作，如何使用它来实现软件，并涵盖了相关的常见陷阱。
本书能够帮助你发挥oracle技术的最大潜力。……毋庸置疑，这是最重要的oracle书籍之一，绝对值得拥有。
— ken jacobs， 产品战略部（服务器技术）副总裁，oracle公司
本书面向从事oracle数据库应用的所有开发人员或dba。
无论你是程序员还是dba，要创建和管理稳定、高质量的oracle系统，归根结底都需要理解oracle数据库的体系结构。
本书是讲述oracle数据库毋庸置疑的权威指南，凝聚了世界顶尖的oracle专家thomas kyte数十年的宝贵经验和大量真知灼见。书中深入地分析了oracle数据库体系结构，包括文件、内存结构以及构成oracle数据库和实例的底层进程，然后讨论了一些重要的数据库主题，如锁定、并发控制、事务、重做和撤销，还解释了这些内容的重要性。最后，分析了数据库中的物理结构，如表、索引和数据类型，并介绍哪些技术能最优地使用这些物理结构。
在介绍每个特性时，作者都充分利用具体的例子来说明，不仅讨论了各个特性是什么，还说明了它如何工作，如何使用它来实现软件，并涵盖了相关的常见陷阱。
本书能够帮助你发挥oracle技术的最大潜力。……毋庸置疑，这是最重要的oracle书籍之一，绝对值得拥有。
— ken jacobs， 产品战略部（服务器技术）副总裁，oracle公司
作译者回到顶部↑
本书提供作译者介绍
Thomas Kyte是Oracle公司核心技术集团的副总裁，从Oracle 7.0.9版本开始就一直任职于Oracle公司，不过，其实他从5.1.5c版本就开始使用Oracle了。 在Oracle公司，Kyte专门负责Oracle数据库，他的任务是帮助使用Oracle数据库的客户，并与他们共同设计和构建系统，或者对系统进行重构和调优。在进入Oracle公司之前，Kyte是一名系统集成人员，主要为美国军方和政府部门的客户构建大规模、异构数据库。
Thomas Kyte就是主持Oracle Magazine Ask Tom专栏和Oracle公司同名在线论坛的那个Tom，他通过这.. << 查看详细
Thomas Kyte就是主持Oracle Magazine Ask Tom专栏和Oracle公司同名在线论坛的那个Tom，他通过这.. << 查看详细
目录回到顶部↑
第1章 开发成功的oracle应用 1
1.1 我的方法 2
1.2 黑盒方法 4
1.3 开发数据库应用的正确（和不正确）方法 8
1.3.1 了解oracle体系结构 8
1.3.2 理解并发控制 14
1.3.3 多版本 19
1.3.4 数据库独立性？ 25
1.3.5 “怎么能让应用运行得更快?” 41
1.3.6 dba与开发人员的关系 45
1.4 小结 46
第2章 体系结构概述 47
2.1 定义数据库和实例 48
2.2 sga和后台进程 53
2.3 连接oracle 56
2.3.1 专用服务器 56
2.3.2 共享服务器 57
2.3.3 tcp/ip连接的基本原理 58
2.4 小结 61
第3章 文件 63
1.1 我的方法 2
1.2 黑盒方法 4
1.3 开发数据库应用的正确（和不正确）方法 8
1.3.1 了解oracle体系结构 8
1.3.2 理解并发控制 14
1.3.3 多版本 19
1.3.4 数据库独立性？ 25
1.3.5 “怎么能让应用运行得更快?” 41
1.3.6 dba与开发人员的关系 45
1.4 小结 46
第2章 体系结构概述 47
2.1 定义数据库和实例 48
2.2 sga和后台进程 53
2.3 连接oracle 56
2.3.1 专用服务器 56
2.3.2 共享服务器 57
2.3.3 tcp/ip连接的基本原理 58
2.4 小结 61
第3章 文件 63
译者序回到顶部↑
每个人都可能有自己的学习套路。学习一个新工具时，有些人可能只是找一本入门书，粗略地翻翻就浅尝辄止，并相信实践出真知；有些人更喜欢系统地研习文档，对每个细节精雕细刻；有些人喜欢收集一些独门密技；有些人喜欢亲身尝试书上的基本用例……。每种方法都有可取之处，但我相信，真正的学习应该是“参考＋实践”。盲目实践会频繁遇到本来可以避免的陷阱和失败，耽于参考又会成为纸上谈兵，无法得到真才实学。
学习Oracle时，很多书和资料都很有参考价值，特别是Oracle文档，更是全面地提供了我们想了解的信息。但是文档中没有实战用例，没有告诉我们哪些可行或者哪些不可行，什么情况下可行或者什么情况下不可行，为什么可行或者为什么不可行，它只是“公事公办”为你呈上厚厚的一摞文字，告诉你情况就是这样，你自己看着办吧。Thomas Kyte的这本书正好弥补了这一点，他使用大量实际的例子来解释所阐述的概念，由浅入深地传授实战技术。如果你喜欢Oracle，需要更多地了解Oracle，这本书绝对值得一读。
本书第1章强调不要把数据库当成一个黑盒，讨论了开发人员必须了解的数据库的基本特性和功能。第2章提供了一个创建Oracle数据库的绝好例子，从中你将深入地了解数据库和实例的概念。第3章介绍了各种类型的文件，特别是重做日志文件、闪回日志文件等。第4章关于内存，具体介绍了一些新选项，如何使用这些选项，以及要注意哪些问题。第5章讨论各个进程的功能。第6章至第8章分别介绍锁和闩、多版本以及事务。这几章是本书的精华，而且也是理解Oracle的关键所在。第9章讨论redo和undo，解释了它们分别是什么，并指出如何避免各种可能出现的错误。第10章介绍了各种类型的表，其中最重要的是堆组织表、索引组织表、临时表和外部表。你能从这一章中了解到改善性能的一些技巧。第11章讨论了有关索引的问题。第12章涵盖了Oracle中的各种数据类型。第13章讨论了分区，这一章开场白里就提出警告——不要把分区当作一个提速开关，并在接下来的内容中详细分析了分区的有关问题。第14章介绍了并行执行，如并行DML、并行DDL等。这里作者给出了自己从实际经验中总结的许多见解，指出并行DDL是Oracle并行执行的闪光点。最后一章介绍了数据的加载和卸载，不仅详细说明了常用的SQL*Loader工具，还解释了如何用外部表加载数据。尽管外部表从很大程度上优于SQL*Loader，但使用外部表并没有完全摒弃SQL*Loader，而且完全可以利用SQL*Loader来为外部表生成CREATE语句。
在Oracle领域中，大概无人不识Thomas Kyte，也无人不知他的Expert One-on-One Oracle。本书是该书的全新改版，涵盖了Oracle9i和10g，并专门介绍了最重要的Oracle体系结构特性。翻译这样一本巨著，确实让我们很有压力，所以我们不敢马虎，尽力用准确、贴切的语言表述出作者的原意。但是由于水平有限，译文肯定有不当之处，敬请批评指正。
译者
2006年7月
学习Oracle时，很多书和资料都很有参考价值，特别是Oracle文档，更是全面地提供了我们想了解的信息。但是文档中没有实战用例，没有告诉我们哪些可行或者哪些不可行，什么情况下可行或者什么情况下不可行，为什么可行或者为什么不可行，它只是“公事公办”为你呈上厚厚的一摞文字，告诉你情况就是这样，你自己看着办吧。Thomas Kyte的这本书正好弥补了这一点，他使用大量实际的例子来解释所阐述的概念，由浅入深地传授实战技术。如果你喜欢Oracle，需要更多地了解Oracle，这本书绝对值得一读。
本书第1章强调不要把数据库当成一个黑盒，讨论了开发人员必须了解的数据库的基本特性和功能。第2章提供了一个创建Oracle数据库的绝好例子，从中你将深入地了解数据库和实例的概念。第3章介绍了各种类型的文件，特别是重做日志文件、闪回日志文件等。第4章关于内存，具体介绍了一些新选项，如何使用这些选项，以及要注意哪些问题。第5章讨论各个进程的功能。第6章至第8章分别介绍锁和闩、多版本以及事务。这几章是本书的精华，而且也是理解Oracle的关键所在。第9章讨论redo和undo，解释了它们分别是什么，并指出如何避免各种可能出现的错误。第10章介绍了各种类型的表，其中最重要的是堆组织表、索引组织表、临时表和外部表。你能从这一章中了解到改善性能的一些技巧。第11章讨论了有关索引的问题。第12章涵盖了Oracle中的各种数据类型。第13章讨论了分区，这一章开场白里就提出警告——不要把分区当作一个提速开关，并在接下来的内容中详细分析了分区的有关问题。第14章介绍了并行执行，如并行DML、并行DDL等。这里作者给出了自己从实际经验中总结的许多见解，指出并行DDL是Oracle并行执行的闪光点。最后一章介绍了数据的加载和卸载，不仅详细说明了常用的SQL*Loader工具，还解释了如何用外部表加载数据。尽管外部表从很大程度上优于SQL*Loader，但使用外部表并没有完全摒弃SQL*Loader，而且完全可以利用SQL*Loader来为外部表生成CREATE语句。
在Oracle领域中，大概无人不识Thomas Kyte，也无人不知他的Expert One-on-One Oracle。本书是该书的全新改版，涵盖了Oracle9i和10g，并专门介绍了最重要的Oracle体系结构特性。翻译这样一本巨著，确实让我们很有压力，所以我们不敢马虎，尽力用准确、贴切的语言表述出作者的原意。但是由于水平有限，译文肯定有不当之处，敬请批评指正。
译者
2006年7月
前言回到顶部↑
过去我一直在开发Oracle软件，并与其他Oracle开发人员一同工作，帮助他们构建可靠、健壮的应用程序。在这个过程中积累了一些经验，正是这些经验赋予我灵感，才有了本书中的内容。这本书实际上反映了我每天做了些什么，汇集了我所看到的人们每天遇到的问题。
本书涵盖了我认为最重要的一些内容，即Oracle数据库及其体系结构。我也可以写一本书名类似的其他方面的书，向你解释如何用一种特定的语言和体系结构开发应用程序。例如，我可以告诉你如何使用 JavaServer Pages（JSP）与Enterprise JavaBeans（EJB）通信，EJB再如何使用JDBC与Oracle通信。不过，归根结底，你最后还是要了解Oracle数据库及其体系结构（本书介绍的内容），才能成功地构建这样一个应用程序。要想成功地使用Oracle进行开发，我认为有些内容你必须了解，而不论你是一位使用ODBC的Visual Basic程序员、使用EJB和JDBC的Java程序员，还是使用DBI Perl的Perl程序员，这本书都会介绍这些通用的知识。本书并不推崇哪一种特定的应用体系结构，在此没有比较三层结构和客户/服务器结构孰优孰劣。我们只是讨论了数据库能做什么，另外关于数据库如何工作，我们还会指出你必须了解哪些内容。由于数据库是所有应用体系结构的核心，所以这本书适用面很广。
在编写本书时，我对Expert One-on-One Oracle一书中关于体系结构的章节做了全面修订和更新，并补充了大量新的内容。Expert One-on-One Oracle一书所基于的版本是Oracle 8.1.7，在此之后又推出了3个版本——两个Oracle9i版本和Oracle数据库10g Release 1，这也是写这本书时的Oracle发行版本。因此，有许多新的功能和新的特性需要介绍。
如果针对9i和10g更新Expert One-on-One Oracle，那么需要补充的内容太多了，那本书原本篇幅较多，再加太多内容就会很难处理。出于这个考虑，我们决定分两本书来介绍。这是其中的第一本，第二本书暂定名为Expert Oracle Programming 。
顾名思义，本书的重点是数据库体系结构，并强调数据库本身如何工作。我会深入地分析Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库（database）和实例（instance）的底层进程。然后讨论一些重要的数据库主题，如锁定、并发控制、事务、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手册，或者还没有看过，那我可以告诉你，这个手册绝对是一个很好的起点。它大约有700页，涉及了你需要知道的许多重要的Oracle概念。其中不会涵盖每一个技术细节（Oracle文档提供了技术细节，不过它有10 000~20 000页之多），但你能从中学到所有重要的概念。
这个手册涉及以下主题（这里所列的并不完整）：
·数据库中的结构，数据如何组织和存储；
本书涵盖了我认为最重要的一些内容，即Oracle数据库及其体系结构。我也可以写一本书名类似的其他方面的书，向你解释如何用一种特定的语言和体系结构开发应用程序。例如，我可以告诉你如何使用 JavaServer Pages（JSP）与Enterprise JavaBeans（EJB）通信，EJB再如何使用JDBC与Oracle通信。不过，归根结底，你最后还是要了解Oracle数据库及其体系结构（本书介绍的内容），才能成功地构建这样一个应用程序。要想成功地使用Oracle进行开发，我认为有些内容你必须了解，而不论你是一位使用ODBC的Visual Basic程序员、使用EJB和JDBC的Java程序员，还是使用DBI Perl的Perl程序员，这本书都会介绍这些通用的知识。本书并不推崇哪一种特定的应用体系结构，在此没有比较三层结构和客户/服务器结构孰优孰劣。我们只是讨论了数据库能做什么，另外关于数据库如何工作，我们还会指出你必须了解哪些内容。由于数据库是所有应用体系结构的核心，所以这本书适用面很广。
在编写本书时，我对Expert One-on-One Oracle一书中关于体系结构的章节做了全面修订和更新，并补充了大量新的内容。Expert One-on-One Oracle一书所基于的版本是Oracle 8.1.7，在此之后又推出了3个版本——两个Oracle9i版本和Oracle数据库10g Release 1，这也是写这本书时的Oracle发行版本。因此，有许多新的功能和新的特性需要介绍。
如果针对9i和10g更新Expert One-on-One Oracle，那么需要补充的内容太多了，那本书原本篇幅较多，再加太多内容就会很难处理。出于这个考虑，我们决定分两本书来介绍。这是其中的第一本，第二本书暂定名为Expert Oracle Programming 。
顾名思义，本书的重点是数据库体系结构，并强调数据库本身如何工作。我会深入地分析Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库（database）和实例（instance）的底层进程。然后讨论一些重要的数据库主题，如锁定、并发控制、事务、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手册，或者还没有看过，那我可以告诉你，这个手册绝对是一个很好的起点。它大约有700页，涉及了你需要知道的许多重要的Oracle概念。其中不会涵盖每一个技术细节（Oracle文档提供了技术细节，不过它有10 000~20 000页之多），但你能从中学到所有重要的概念。
这个手册涉及以下主题（这里所列的并不完整）：
·数据库中的结构，数据如何组织和存储；
序言回到顶部↑
“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 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的诸多特性，教你使用这些特性，还反映了以下简单的观点：
·不要相信神话，要自己思考。
·不要墨守成规，所有人都知道的事情其实很可能是错的！
·不要相信传言，要自己测试，根据经过证明的示例做出决定。
·将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。
·如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。
·理解理想和现实之间的差距。
加载中...
