2. 应用优化
    下面我们从技术的角度入手，来探讨数据库优化方面的问题。通常作为优化Oracle系统的人，或者是DBA，其实很多时候对应用并不很了解甚至可以说是完全不了解，更不要说对应用程序代码的了解。事实上呢，一个系统运行的快或者慢相信大家都明白，第一重要的是数据库的设计，然后是应用的设计， SQL语句的编写，最后才是数据库参数的调整和硬件、网络的问题，等等。所以在我们不了解一个系统的时候来优化数据库应用不是一个轻松的容易的事情。那么我们第一步应该怎么做呢？

通常有两类方法：
    其中一个方法就是我们常用的，使用statspack来进行诊断系统的瓶颈所在。在statspack中oracle给出了几乎涵盖oracle大部分重要内容的信息。
    另外一种方式，就是trace session。假如某个session运行很慢或者某个用户的某个查询很慢，那么这个时候我们可以通过trace session的方式来诊断到底是慢在哪里，看究竟执行计划是怎样的，然后在user_dump_dest下根据该session的进程号或者线程号可以找到一个产生的trace文件。通过使用tkprof格式化文件之后我们就可以看见很多的统计信息，这里包括了执行计划、parse/fetch等步骤消耗cpu的时间。通常我们是观察query模式下的consistent gets来首先看sql是否使用了索引，然后看执行计划是不是正常，是不是有调整的余地。当然如果您没有实际做过的话，这些内容说起来很抽象。这是在不了解应用和程序下针对特定session的诊断和调整过程。

    trace session的方式是一种自下而上的方法，从sql入手；而statspack是自顶向下的方法，也就是从宏观上先诊断数据库的瓶颈在哪里，然后从瓶颈入手来做调整，这个习惯上又可以称为通过等待事件（wait event）入手的方法。

2.1 使用statspack
    statspack是一个性能诊断工具，首先发布于Oracle8.1.6版本，在8.1.7版本中功能得到加强。Statspack除了查找实例中的性能问题外，还可以查找应用程序中高负荷的SQL语句，很容易确定Oracle 数据库的瓶颈所在，并且记录数据库性能状态。
在数据库中Statspack 的脚本位于$ORACLE_HOME/RDBMS/ADMIN 目录下，对于ORACLE8.1.6,是一组以stat 开头的文件；对于ORACLE8.1.7,是一组以sp 开头的文件。

    在Statspack 发布之前，我们通常能够使用诊断数据库的工具是两个脚本UTLBSTAT.SQL 和UTLESTAT.SQL，BSTAT/ESTAT 是一个非常简单的性能诊断工具。UTLBSTAT 获得开始时很多V$视图的快照，UTLESTAT 通过先前的快照和当前视图生成一个报表。

    该报表实际上相当于statspack 中的两个采样点。
Statspack 通过连续的采样，能够给我们提供至关重要的趋势分析数据。这是一个巨大的进步。能够使用Statspack 的环境我们就尽量不要使用BSTAT/ESTAT 的方式来诊断数据库问题。

2.1.1 安装statapack
§ 步骤一：
为了能够顺利安装和运行Statspack ，首先需要设置以下两个系统参数：
1. job_queue_processes
为了能够建立自动任务，执行数据收集，该参数需要大于0。你可以在初试化参数文件中修改该参数(使该参数在重起后以然有效)。
该参数可以在系统级动态修改(重起后失效)。

SQL> alter system set job_queue_processes = 6;
System altered

在Oracle9i 当中，可以指定范围，如 both,这样该修改在当前及之后保持有效(仅当你使用spfile 时，如果在9i 中仍然使用pfile，那么更改方法同8i 相同):

SQL> alter system set job_queue_processes = 6 scope=both;
System altered