Oracle数据库性能问题通常都是由某些瓶颈引起的，所谓瓶颈就是数据不得不经过的一种流程或者路线，由于“该流程”不能迅速地处理数据，迫使通信速度“减慢”，进而增加了响应时间。

Oracle数据库可能会遇到来自外部的或者内部的瓶颈，甚至两方面都有。解决那些瓶颈的关键就是要找到根本原因和位置，这需要一定的DBA技能。另外，要首先从内部瓶颈开始处理，我们可以通过调整SQL语句，修改参数或者调整数据库本身来解决问题，这样无需花费较大开支。只有内部瓶颈确认识别后，DBA才应该考虑外部瓶颈。

通常，一个正常运转的Oracle数据库状态是这样的：每一个连接的进程要么忙于执行任务，要么在等待任务。这些“等待”的条件是会话在等待一些事件发生。等待的发生原因可能是多种多样的，从磁盘速度慢到锁定情况再到各种Oracle内部竞争都有可能引起等待。

潜在的数据库内部瓶颈

有几种情况会影响内部性能，它们是：缓冲区死锁——内部加锁和Latch锁引起竞争。

缓冲区忙等待——段头与数据缓冲竞争带来的瓶颈。

控制文件等待——Oracle更新控制文件非常频繁，会引起延时。

Latch锁和锁等待——等待来自串行访问latch的结果。

入队列等待——内部latch和锁竞争的征兆。

日志缓冲等待——诸如重做日志空间请求这类事件。

撤销段等待——撤销段可能引起串行等待。

然而，存在等待的流程并不总是瓶颈的迹象。等待可以是用户发起活动的简单情况，比如，咖啡时间休息或者关注其它不同的活动。尽管如此，仍然要谨慎检查等待流程背后的原因，以及它对响应时间的影响，数据库调优的真正目标是优化响应时间。

数据库操作的响应时间由两部分因素组成，执行时间加上等待时间，也就是说：响应时间=服务时间+等待时间。识别和解决等待时间的问题可能是个繁琐的过程，通常被称为基于等待的分析。基于等待分析的首要步骤之一就是找到等待特定事件的个数和解决每个等待所需的时间。DBA们可以利用这两部分信息来识别等待开始性能下降的数量级，进而引导他们进入识别瓶颈的下一阶段。

收集这些信息需要用到几个查询命令，并从数据库内部查询一些信息。基本信息可以从视图“V$SYSTEM_WAIT_CLASS”中得到。然而，那里只列出了等待时间和新等待类别的数量。DBA们还可以利用系统级别等待摘要获得数据库等待的宏观图像。那些摘要可以通过运行“$ORACLE_HOME/rdbms/admin”目录下的“awrrpt.sql”脚本生成。它会显示出在AWR快照之间指定时间间隔最耗时的五个事件。

要获得更多详细信息，需要建立一个查询，其中会包括像“WAIT_CLASS”，“TOTAL_WAITS”和“TIME_WAITED”这类对象，这些对象都来自于“V$SYSTEM_WAIT_CLASS”视图。返回的信息会帮助DBA们判断等待时间是由系统引起的，还是由于用户I/O等待引起的。

更好的情况是，DBA们可以求助于第三方工具，这些工具不仅可以识别内部瓶颈，还可以识别可以优化提高性能的SQL语句。市场上这类工具有几十种，选择一款优秀的第三方工具，关键是要确保该工具能集中处理构成整体响应时间延长的等待事件，不管是系统行为还是个别交易业务。

数据库外部瓶颈可能会非常棘手

外部瓶颈在识别时可能会有点棘手，主要是因为有些流程和通行过程是由Oracle以外的因素引起的。大部分外部瓶颈可以归结为几种不同的类型：CPU或者服务器性能，存储性能和基础设施性能。

识别那些外部瓶颈可能是比较艰难的过程，可能需要用到第三方工具，或者需要与网络管理员和其他IT人员协作完成。在识别外部瓶颈时有几个方面细节需要关注，优秀的第三方分析工具应该能发现它们。分析内容包括以下几方面：磁盘性能：监视分散的读操作，全表扫描，连续读取，索引指针等等。

CPU：按线程，总用量，峰值利用率，重要进程等等监视处理器。

网络：监视SQL*NET度量以及交通吞吐量，监视进程，协议性能，竞争，延时等等的服务质量。

对这些方面加强关注，DBA们就能对瓶颈是在哪里产生的这一问题有一个更好的认识，然后就可以提出瓶颈缓解计划并与其他IT涉众讨论了。

解决Oracle数据库性能问题可以简单地归结为：识别瓶颈并提出合适的处理方案来规避它们。我们面临的调整在于要知道检查哪里，并知道如何解读监控数据。