前言

笔者在写这本书的时候，翻看了很多当前国内数据库方面的书籍，发现写性能优化的书并不多，特别是从工作经验和思路上来讨论性能方面的书，更是少之又少，这些因素让笔者思考要写这样一本书，这也算是这本书的一个定位。

在这本书里，你将会学到笔者在性能优化方面的一些思路和思考，一些故障处理的方法和原则，这些东西是笔者在实践中长期积累的心得体会，在笔者看来，掌握处理问题的方法和分析问题的思路在日常工作中显得更为重要，当你掌握了一些处理问题的基本思路之后，剩下的工作就是去Google或者阅读参考书了。

本书的一个特点是，凡是作者提到的观点，都尽可能地使用一些例子来证明它，这样看起来更有说服力一些。

为什么会出现数据库的性能问题

性能问题是最近几年来DBA们越来越关注的一个数据库技术领域，归根结底，造成它的原因是最近几年信息化进程的飞速发展，导致了很多系统的用户数量猛增，数据库中存储的数据量亦成几何级数激增，数据库作为数据处理和存储的最终受体，将必然直接承担这种变化导致的性能下降。因此在人们对信息的依赖性越来越强的时候，对信息使用的效率也变得越来越关注，这样数据库的性能优化问题就日益严重地压在DBA的身上。

什么时候需要对性能进行干预

itpub.net是国内最早的一个专业讨论Oracle数据库技术的论坛，目前在国内数据库方面已经相当有知名度，笔者是2001年注册的，算是最早的会员之一。目前仍然会经常上去看看，由于工作内容的关系，我比较关注性能方面的帖子，发现以下一类的帖子经常有很多，比如：

1. 我是一个DBA，我现在手头有一个数据库，我该从哪里进行性能优化呢？

2. 这是我的数据库的一个Statspack，我该如何优化？

通常对于第一个问题，我是很少回答的，并不是不屑于回答，实在是没有办法回答，如果我回答说，“你怎么知道你的数据库需要优化？”又担心这种没有实际意义的回答带有说教意味，打击别人的积极性，所以通常看看而已。实际上我是想说，对于一个DBA来讲，当你拿到一个数据库的时候，你首先需要做的是用最短的时间来了解一下跑在这个库上的是一个什么系统，比如是在线事务（OLTP）系统还是在线分析（OLAP）系统，这对于你做出性能上的判断至关重要，如果连系统都不了解，真不知道该如何去优化它，这就好比说，要设计一辆汽车，如果连用户对汽车的喜好都弄不清楚，如何能设计出一个取悦于用户的车呢？

对于第二个问题，像是比第一个具体一些，因为帖子作者已经提供了一个性能数据报告，但我仍然觉得通过这些数据没有办法准确地判断数据库是否有性能问题。比如你是一个医生，我让一个人站在你的面前测心率，结果是50 次/分钟，你是不是可以断定他有问题，需要安装心脏起搏器呢？实际上是不需要，因为我知道他是一个运动员，这样的心率是正常的，而医生不知道，所以他在做出诊断之前需要详细了解站在自己面前的应诊者的所有详细信息，来作为他做出判断的依据。

下面贴出一个来自于我使用过的数据库性能报告中的一部分：

许多人看到这个数据一定会大声说：

“嘿，你的数据库性能好差，buffer hit只有66%，不知道是谁设计的这个系统，赶紧加大data buffer的尺寸！”

诚然，这个数据的确显示数据库的内存命中率低得可怜，但是我想告诉你的是，这是一个在线分析（OLAP）系统的数据库，运行着很多非常大的查询，每个查询搜索的范围都在上亿条记录以上，那这个结果不是很正常吗？我们需要把几亿条数据缓存到内存里提供给这种每天可能只运行几次的查询吗？你可以同意，但是你的老板是不会同意的，这样做的成本太高了，而且完全没有必要，因为它只是一个报表系统，对数据库的响应时间要求不高，所以我们当然可以让这个查询直接到磁盘上去搜索数据，这也就是为什么在这样的系统里，buffer hit比例很低，但却是一个完全可以接受的值的原因。

笔者认为，只有数据库的性能已经影响到业务的正常工作或者用户已经无法满意于这种性能时，我们才应该考虑来优化它，对于绝大多数系统，数据库的安全和稳定才是最重要的。

FAST=TRUE？

这是很多人追求的目标，它的意思是，在Oracle数据库中，通过调整性能参数的值，就可以让数据库运转得飞快。

实际上这不过是句玩笑，它本身是一句反话，却让很多人误入歧途。我看到很多人，包括一些DBA，凡涉及性能优化，必定谈及性能参数的修改，这实在是一个误区，他把性能参数值的修改对数据库性能的正面影响人为地放大了很多倍，实际上恰恰相反，很多时候修改这些参数产生的却是副作用，原因很简单，Oracle给一个参数一个默认值是让它最大限度地适用于每个数据库，所以它几乎是最优的，当然，绝对有个别数据库需要适当调整，但我认为那是个例，并且，很多时候，修改这些参数的人，他们修改的理由并不是非常充分，不过是想修改一下看看运气而已。

本书的内容

以下是本书各个章节的内容简介。

第1章 引起数据库性能问题的因素

这一章主要讨论一些引起数据库性能问题的因素，包含了系统架构、软件代码、数据库设计、存储设计等话题。

第2章 锁和阻塞

在这一章里，将介绍Oracle数据库中锁的起因及由锁引起的性能问题—阻塞，并将讨论常见的几种阻塞的起因。

第3章Latch和等待

这一章讨论Latch，它是Oracle中比锁更轻量级的一种串行机制。热块或是SQL未绑定变量是最常见的导致Latch等待的原因，这一章将对这些成因及解决方法进行论述。

第4章 优化器

优化器是SQL执行中最核心的部分，如果要分析SQL的性能，就不能不了解Oracle优化器的机制，这一章，我们就带你走进Oracle优化器—CBO的世界。

第5章 执行计划

当我们分析一条SQL语句的性能时，最先做的事情大概就是分析它的执行计划了。

所以，如果连执行计划都看不懂，那SQL调优根本无从谈起。在这一章，我们将讨论CBO（基于成本的优化器）执行计划相关的内容。

第6章 Hint

Hint指通过人为的方式来约束SQL的执行计划，让它按照我们希望的方式来执行，以达到我们需要的目的—改善性能或者仅仅是试验以对比SQL的执行性能。

这一章将讨论Oracle数据库中的大多数Hint。

第7章 分析及动态采样

对象采样分析是CBO（基于成本的优化器）的灵魂和核心，CBO如果没有了对象的分析数据，就好像一个医生不使用病人的病历来确定病人的病一样危险—那是一种没有依据的、盲目的行为。

在这一章里，我们将详细讨论Oracle中和对象分析相关的内容。

第8章 并行执行

这一章讨论一个和性能关系极大的技术—并行执行。

在OLAP（在线分析系统）或者是数据仓库系统中，并行技术使用得非常普遍，在合适的条件下，并行执行将会使SQL的执行效率大幅度提升。

第9章 变量绑定

这一章将详细讨论一个在性能优化领域经常被谈到的话题—变量绑定。

那么，是不是在任何时候变量绑定都是必需的呢？答案是否定的，在这一章中将给出答案。

第10章 SQL_TRACE和10046事件

SQL_TRACE和10046 事件是会话级非常有用的两个工具，它们可以捕获会话当中SQL执行的详细信息，其中10046事件还可以获得SQL绑定变量的信息及发生的等待事件。

这一章将详细讨论这两个工具。

第11章 10053事件

这一章将详细讨论10053事件，它是一个很有用处的工具，当你发现一条SQL总是选择错误的执行计划，而你又百思不得其解的时候，也许你应该去生成一个10053事件的trace文件，看看CBO究竟是如何做出这样的执行计划的。

第12章 性能视图和性能参数

本章讨论一些Oracle数据库的性能视图和性能参数。

性能视图相对于SQL_TRACE来说，可以让我们更直接地获取一些性能数据，帮助我们判断数据库是否出现了性能问题。

而性能参数则让我们能够有机会选择一种最适合自己系统的某个参数值，以最大程度地满足当前系统的需要。

第13章 性能报告

本章介绍了常用的几个性能分析工具及性能报告，包括AWR，STATSPACK和ASH，其中以AWR性能报告作为重点介绍的对象。

本章以一个来自于现实生产数据库的AWR报告为题材，来讨论AWR报告的阅读方式，并最终判断出系统的性能所在；STATSPACK介绍了它的安装方法和如何生成报告；ASH也是以一个来自实际生产数据库的性能报告进行性能分析。

这部分会列出一些常见的等待事件、引起它们的原因及一些内部的机制，可以作为大家在处理性能问题时的一个参考部分。

附录A 常见的等待事件

后记 关于数据库的学习方法

这一部分是作者对如何学习Oracle的一个心得分享，对于Oracle初学者来说，正确的学习方法非常重要，它可以使你少走很多弯路。

如果初学者对于Oracle数据库的学习方法有兴趣，这部分可以作为本书的第一部分来阅读。

本书的读者对象

1. 本书适合Oracle DBA或者和Oracle相关的开发人员。

2. 本书的读者需要有一定的Oracle基础，比如你应该知道什么叫做表，什么叫做索引等。

约定

1. 本书示例使用的Oracle版本是10gr2。

2. 本书自创了一个术语—段对象。

这个词大家可能看着有那么一点陌生。作者的意思是，在Oracle数据库中，凡是分配了存储空间的，都称为段，所以段并不一定指的是表，也可能是表的一个分区，还可能是索引、大对象（LOB），或是IOT（索引表），物化视图等。在书中有时候需要描述这些对象时，单独说某个表，或者一个索引，都不能完全概括，所以就统称为段对象。

3. 几个未作翻译的术语Extent，Latch和Bind peeking。

Extent：我看有些书翻译为“分区”，说实话，在Oracle里面，一提到分区，可能99%以上的人会认为是partition，还有的书翻译为“范围”，这个就更让人匪夷所思，所以在书中这个单词就没有翻译，相信大家也懂。

Latch：有的书翻译成“闩”，有的翻译成“锁存”，我总觉得还是不翻译好，只要大家知道它是Oracle里一种类似于锁的保证一些操作串行化的技术就好了。

Bind peeking：翻译成“变量窥视”或是“变量窥探”都非常不对头，所以干脆也不翻译。

本书的目的

笔者从事Oracle DBA的工作已经超过10年，对数据库的理解也一直在改变，就目前来看，我觉得最难的东西不是技术本身，而是什么时候该用什么技术。比如说要使用变量绑定，这非常容易，如果你不会，Google一下，差不多几分钟时间你就会了。可是，这个系统究竟该不该使用变量绑定，我想你Google一天或者一个星期也不一定有答案。原因是每个系统都是独立的，都有自己的业务特点，这需要技术人员根据自己系统的业务特点来度身定做符合自己系统的技术特性。

让读者在每一个技术面前先停下来思考一下，这个技术究竟在什么时候应该用，什么时候不应该用，这是笔者写本书的最终目的。