转自：http://bbs.chinaunix.net/viewthread.php?tid=915444&extra=page%3D1%26amp%3Bfilter%3Ddigest

虽然不完整,但看看还是很有好处的,关键是中文滴:em11:

(1) 调整的先后次序

1. Tune the design. -- Application designers

2. Tune the application. -- Application developers

3. Tune memory.

4. Tune I/O.

5. Tune contention.

6. Tune the operating system.

Statspack分析报告详解：

statspack 输出结果中必须查看的十项内容

  1、负载间档(Load profile)
  2、实例效率点击率(Instance efficiency hit ratios)
  3、首要的5个等待事件(Top 5 wait events)
  4、等待事件(Wait events)
  5、闩锁等待
  6、首要的SQL(Top sql)
  7、实例活动(Instance activity)
  8、文件I/O(File I/O)
  9、内存分配(Memory allocation)
  10、缓冲区等待(Buffer waits

1.报表头信息
数据库实例相关信息，包括数据库名称、ID、版本号及主机等信息。

STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
BLISSDB 4196236801 blissdb 1 9.2.0.4.0 NO BLISS
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 4 23-6月 -05 17:43:32 10 3.3
End Snap: 5 23-6月 -05 18:01:32 12 6.1
Elapsed: 18.00 (mins)

2.负载间档
该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分。

Redo size：每秒产生的重做日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。本例中平均每秒产生了430K左右的重做，每个事务品均产生了18M的重做。
Logical reads：平次每秒产生的逻辑读，单位是block。
block changes：每秒block变化数量，数据库事物带来改变的块数量。
Physical reads：平均每秒数据库从磁盘读取的block数。
Logical reads和Physical reads比较：大约有0.55%的逻辑读导致了物理I/O，平均每个事务执行了大约18万个逻辑读，在这个例子中，有一些大的事务被执行，因此很高的读取数目是可以接受的。
Physical writes：平均每秒数据库写磁盘的block数。
User calls：每秒用户call次数。
Parses和Hard parses：每秒大约1.12个解析，其中有4%为硬解析，系统每25秒分析一些SQL，都还不错。对于优化好的系统，运行了好几天后，这一列应该达到0，所有的sql在一段时间后都应该在共享池中。
Sorts：每秒产生的排序次数。
Executes：每秒执行次数。
Transactions：每秒产生的事务数，反映数据库任务繁重与否。

% Blocks changed per Read：说明46%的逻辑读是用于那些只读的而不是可修改的块，该系统只更新54%的块。
Rollback per transaction %：事务回滚的百分比。计算公式为：Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33个事务导致一个回滚。如果回滚率过高，可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来Undo Block的竞争。
3.实例命中率
该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要。

Buffer Nowait %：在缓冲区中获取Buffer的未等待比率，Buffer Nowait<99%说明，有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。
Redo NoWait %：在Redo缓冲区获取Buffer的未等待比率。
Buffer Hit %：数据块在数据缓冲区中的命中率，通常应在90%以上，否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size，但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）。如果一个经常访问的列上的索引被删除，可能会造成buffer hit 显著下降。如果增加了索引，但是它影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显著增高。如果命中率变化幅度很大，说明需要改变SQL模式。
In-memory Sort %：在内存中的排序率。
Library Hit %：主要代表sql在共享区的命中率，通常在95%以上，否则需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。
Soft Parse %：近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，那么就可能sql基本没有被重用。
Execute to Parse %：一个语句执行和分析了多少次的度量。在一个分析，然后执行语句，且再也不在同一个会话中执行它的系统中，这个比值为0。计算公式为：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。本例中，对于每个分析来说大约执行了2.1次。该值<0通常说明shared pool设置或效率存在问题，造成反复解析，reparse可能较严重,或者可是同snapshot有关，如果该值为负值或者极低，通常说明数据库性能存在问题。
Latch Hit %：要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。
Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。此处为11.4%，非常低，用于解析花费的每个CPU秒花费了大约8.77秒的wall clock时间，这说明花了很多时间等待一个资源。如果该比率为100%，意味着CPU时间等于经过的时间，没有任何等待。
% Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。
4.Shared Pool相关统计数据

Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分率太低，就浪费内存。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。
% SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语��在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在18分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有理由去执行它。
% Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。
在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
5.首要等待事件
常见等待事件说明：
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件。
TIMED_STATISTICS：=TRUE，等待事件按等待的时间排序，= FALSE，等待事件按等待的数量排序。
运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。
空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。

这里是比其他任何事件都能使速度减慢的事件。比较影响性能的常见等待事件：
db file scattered read：该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj)。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描，而且表比较小，把该表存人keep池。如果是大表经常进行全表扫描，那么应该是OLAP系统，而不是OLTP的。
db file sequential read：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整, DB_CACHE_SIZE可以决定该事件出现的频率。
db file sequential read：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来（如效率不高的sql），通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整，DB_CACHE_SIZE可以决定该事件出现的频率。
buffer busy wait：当缓冲区以一种非共享方式或者如正在被读入到缓冲时，就会出现该等待。该值不应该大于1%，确认是不是由于热点块造成（如果是可以用反转索引，或者用更小块大小）。
latch free：常跟应用没有很好的应用绑定有关。闩锁是底层的队列机制（更加准确的名称应���是互斥机制），用于保护系统全局区（SGA）共享内存结构闩锁用于防止对内存结构的并行访问。如果闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题都与使用绑定变量失败（库缓存闩锁）、生成重作问题（重执行分配闩锁）、缓存的争用问题(缓存LRU链) 以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。
log buffer space：日志缓冲区写的速度快于LGWR写REDOFILE的速度，可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。
logfile switch：通常是因为归档速度不够快，需要增大重做日志。
log file sync：当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG文件访在不同的物理磁盘上。
Wait time: 等待时间包括日志缓冲的写入和发送操作。
6.数据库用户程序发生的所有等待事件

7.数据库后台进程发生的等待事件

调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询，将可对系统性能产生5%到5000%的增益。

在报表的这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。

这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。

这部分告诉我们在这段时间中执行最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快，任何被执行几百万次的操作都将开始耗尽大量的时间。
9.实例活动

下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。

11.缓冲池

如果我们使用多缓冲池的功能，上面的报表会告诉我们缓冲池引起的使用故障。实际上这只是我们在报表的开头看到的信息的重复。
12．回滚段活动

一般期望活动在各回滚段间(除了SYSTEM回滚段外)均匀分布。在检查报表的这一部分时，报表标题也具有需要记住的最有用信息。尤其是，如果完全使用最佳设置时关于Optmal比Avg Active更大的建议。因为这是与DBA最有关的活动(I/O和回滚段信息)。

数据库的等待事件，发现前几名是：

发现前面的4项都是影响到数据库性能的问题：

这个等待时间是指等待oracle的前台的commit和rollback操作进程完成，有时候这个等待时间也会包括等待LGWR进程把一个会话事务的日志记录信息从日志缓冲区中写到磁盘上的重做日志文件中。因此当前台进程在等待这个事件的时候，LGWR进程同时也在等待事件log file parallel write。

理解什么造成这个等待事件的关键在于：对比这个等待事件和log file parallel write等待事件的平均等待时间：

l 如果他们的等待时间差不多，那么就是重做日志文件的I/O引起了这个等待事件，则需要调整重做日志文件的I/O，

l 如果log file parallel write等待事件的平均等待时间明显小于log file sync等待事件的等待时间，那么就是一些其他写日志的机制在commit和rollback操作时引起的等待，而不是I/O引起的等待。例如重做日志文件的latch竞争，会伴随出现latch free或者LGWR wait for redo copy等待事件

在V$SESSION_WAIT中，这个等待事件有3个参数：

代表在日志缓冲区中需要被写入到重做日志文件中的缓存数量，写入的同时会确认事务是否已经被提交，并且保留提交信息到实例意外中断前，因此必须等待LGWR将P1数量的缓存写入重做日志文件为止。

无用

无用

如果这个等待事件在整个等待事件中占了比较大的比重，可以从3个方面来进行调整

1. 调整LGWR进程时期具有更好的磁盘I/O吞吐量，例如不要将日志文件放在RAID5的磁盘上

2. 如果存在很多执行时间很短的事务，可以考虑将这些事务合并成一个批量事务以减少提交的次数，因为每次提交都需要确认相关的日志写入重做日志文件，因此使用批量事务来减少提交的次数是一种非常行之有效的减少I/O的方法

3. 产看是否有一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE选项，这样可以减少日志文件的产生

这个等待事件出现在党LGWR后台进程从日志缓冲区写日志信息到磁盘上的重做日志文件的时候。只有启用了异步I/O的时候，LGWR进程才会并行写当前日志组内的充作日志文件，否则LGWR指挥循环顺序逐个的写当前日志组重做日志文件。LGWR进程不得不等待当前日志组所有的重做日志文件成员全部写完，因此，决定这个等待事件的等待时间长短的主要因素是重做日志文件所在磁盘的I/O读写速度。

如果是当前LGWR进程写的速度不够快导致这个等待事件，可以通过查看一些和重做日志相关的统计值来判定当前的LGWR进程是否效率低下，具体的可以看 redo writes, redo blocks written, redo write time, rdo wastage, redo size等统计值，这些都是和LGWR进程性能直接相关的一些统计值。

在V$SESSION_WAIT中，这个等待事件的3个参数：

代表正在被写入的重做日志文件组中的重做日志文件号

代表需要写入重做日志组中每个重做日志文件的重做日志block数量

代表I/O请求次数，需要被写入的block会被分成多次分别请求

如果这个等待事件占用比较多的时间，可以做如下调整

1． 采用UNRECOVERABLE/NOLOGGING操作尽量减少重做日志的产生

2． 在保证不会同时对市重做日志文件的前提下，尽量减少重做日志组中的成员个数，减少每次写重做日志文件的时间

3． 除非在备份情况下，否则不要在江表空间置于热备份的模式下，因为在表空间处于热备���模式下会产生更多的重做日志文件

4． 对于使用LogMiner、Logical Standby或者Streams，在能够满足要求功能的前提下，尽量使用最低级别的追加日志以减少重做日志的产生

5． 尽量将同一个日志组内的重做日志文件分散到不同的硬盘上，减少并行写重做日志文件时产生的I/O竞争

6． 不要将重做日志文件置于RAID5的磁盘上，最好放在裸设备上。

7． 如果设置了归档模式，不要将归档日志的目的地设置为存放重做日志的磁盘上，避免引起I/O竞争

关于Log的这2个问题的总结

通过上述对Log这2个问题的描述，以及产生的原因，除了Log file sync可能有其他方面的因素引起的（Latch），主要还是磁盘和使用习惯

1． 磁盘由于这些都是写磁盘所引起的，所以只有从减少写磁盘（指数据库本身的角度，和下列提到的用户操作习惯不一样）和加快写磁盘来减少这些等待时间

a) 尽量不要在RAID5的磁盘上保存重做日志文件，RAID5写的速度属于比较慢的

b) 在安全性保证的基础上，减少重做日志组成员的个数

c) 同一个日志组中的不同成员放在不同的磁盘上，加速写的速度。

d) 对可以采用NOLOGGING/UNRECOVERABLE的操作，使用这些选项减少log的产生

e) 有归档的，不要将归档的和在线重做日志放在一个磁盘上

2． 使用习惯如果用户不断的进行commit或者rollback，这样必定引起一次log日志的写操作。因此可以通过一些统计信息判断是否每次的日志的写操作数据量很小，这样通过调节用户的操作，将大量的数据更新合并到一个事务中来，这样增加每次日志的操作量，减少对日志的不断调用，提高LGWR的写的效率。

这是一个非常常见的等待时间。当oracle从磁盘上读取多个block到不连续的���速缓存区的缓存中就会发生这个等待事件，Oracle一次最多能够读入的block数量由初始化参数DB_FILE_MULTIBLOCK_READ_COUND决定，这个时间一般伴随着全表扫描或者Fast Full Index 扫描一起出现。

在V$SESSION_WAIT中，这个等待事件的几个参数：

代表oracle的文件号

代表从这个文件中开始读取的block号

代表从这个block开始需要读取的block数量

一般从这个3个参数，就可以回头查询到是在读取数据库的哪个对象，然后分析对这个对象的操作来进行优化Sql语句。

如果这个等待事件占的比重比较厉害，可以通过以下方法来调整

方法一

找出执行全表扫描或者Fast Full index扫描的Sql语句，判断这些扫描是否是必要的，是否导致了比较差的执行计划，进行调整。

从oracle9i开始，提供了一个视图V$SQL_PLAN，可以通过它帮助我们找到那些全表扫描或者Fast Full Index扫描的Sql语句：

查找全表扫描的SQL语句

查找Fast Full index 扫描的Sql语句可以这样；

如果是Oracle8i的数据库，可以通过v$session_event视图中找到关于这个等待事件的进程sid，然后根据这个sid来跟踪相应会话的SQL

或者可以通过查看物理读取最多的SQL语句的执行计划，看是否里面包含了全表扫描和Fast Full Index扫描，可以通过以下语句获取物理读取最���的SQL语句

方法二：

有时候执行计划很好也会出现多block扫描的情况，这个时候可以通过调整Oracle数据库的多block的I/O，来设置一个合理的DB_FILE_MULTIBLOCK_READ_COUNT,使得尽量满足；

这个参数也不是设置的越大越好，设置这个参数之前需要了解一下应用的类型，如果是OLTP类型的，一般来说全表扫描较少，这个时候如果设置了比较大反而会降低数据库的性能，因为CBO在某些情况下会因为多block读取导致COST比较低从而错误的选用了全表扫描。

其他方法

还可以采用对表和索引使用分区、将缓存区的LRU末端的全表扫描和FastFullIndex扫描的block放入到Keep缓存池等方法来进行调节。