说在前面，很容易被忽略的几个点：在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。尤其需要注意的就是时间段，eygle就说过，离开了时间的statspck将是毫无意义的。
STATSPACK report for
/* 报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息
DB Name DB Id Instance Inst Num Release Cluster Host
----------------------- ------------ -------- ----------- ------- ------------
ORA92 1924035339 ora92 1 9.2.0.6.0 NO jsdxh_db02
Snap Id Snap Time Sessions Curs/Sess Comment
--------- -------------------------- --------- -------------------
Begin Snap: 13 14-Jul-07 00:18:52 274 55,345.0
End Snap: 14 14-Jul-07 00:32:55 272 55,823.8
Elapsed: 14.05(mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 5,120M StdBlock Size: 8K
Shared Pool Size: 400M Log Buffer: 2,048K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 422,086.46 4,706.23
Logical reads: 23,200.54 258.68
Block changes: 3,080.59 34.35
Physical reads: 31.46 0.35
Physical writes: 104.38 1.16
User calls: 409.32 4.56
Parses: 227.20 2.53
Hard parses: 7.22 0.08
Sorts: 213.87 2.38
Logons: 0.85 0.01
Executes: 1,191.32 13.28
Transactions: 89.69
/* 下面详细说明Load Profile各项含义
1) Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。
2) Logical reads:平决每秒产生的逻辑读的block数。Logical Reads=Consistent Gets + DB Block Gets
3) Block changes:每秒block变化数量，数据库事物带来改变的块数量。
4) Physical reads:平均每秒数据库从磁盘读取的block数。
5) Physical writes:平均每秒数据库写磁盘的block数。
6) User calls:每秒用户调用次数。
7) Parses:每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。 软解析每秒超过300次意味着你的"应用程序"效率不高，没有使用绑定变量，调整session_cursor_cache。
8) Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，或者说共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。
9) Sorts:每秒产生的排序次数。
10) Logons:
11) Executes:每秒执行次数。
12) Transactions:每秒产生的事务数，反映数据库任务繁重与否。
% Blocks changed per Read: 13.28 Recursive Call %: 80.21
Rollback per transaction %: 0.03 Rows per Sort: 2.84
/* Load Profile 续
1) % Blocks changed per Read：在每一次逻辑读中更改的块的百分比。
2) Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(Userrollbacks / (user commits + user rollbacks) ,4)* 100% 。
3) Recursive Call %:递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。
4) Rows per Sort:平均每次排序操作的行数。
Instance Efficiency Percentages(Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.98 Redo NoWait %: 100.00
Buffer Hit %: 99.87 In-memorySort %: 100.00
Library Hit %: 99.67 Soft Parse %: 96.82
Execute to Parse %: 80.93 Latch Hit %: 96.10
Parse CPU to ParseElapsd %: 6.93 % Non-Parse CPU: 99.88
/* 实例的有效性，这部分值越接近100越好，分项内容详细说明如下：
1) Buffer Nowait %：在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%。否则可能有热块争用，可以在后面的等待事件中进一步确认。
2) Redo NoWait %：在Redo缓冲区获取Buffer的未等待比率。
3) Buffer Hit %：数据块在数据缓冲区中的命中率，通常应在95%以上。否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的db file sequential read），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查top buffer get SQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查top physical reads SQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。
4) In-memory Sort %：在内存中的排序率。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意SORT_AREA_SIZE是针对每个session设置的。
5) Library Hit %：STATEMENT在共享区的命中率，通常应该保持在95%以上，否则需要要考虑：加大共享池；使用绑定变量；修改cursor_sharing等参数。
6) Soft Parse %：sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，那么就可以认为sql基本没有被重用。
7) Execute to Parse %：一个语句执行和分析了多少次的度量。计算公式为：Execute to Parse =100* (1 - Parses/Executions)。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。本例中，差不多每execution 5次需要一次parse。该值<0通常说明sharedpool设置或者语句效率存在问题，造成反复解析，reparse可能较严重,或者可是同snapshot有关，通常说明数据库性能存在问题。
8) Latch Hit %：要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。
9) Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parsetime cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU时间等于经过的时间，没有任何等待。
10) % Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。
Shared PoolStatistics Begin End
------ ------
Memory Usage %: 32.87 33.12
% SQL with executions>1: 80.00 82.69
% Memory for SQL w/exec>1: 77.62 80.70
1) Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分率太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。
2) % SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有去执行。
3) % Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL withexecutions>1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
小结：通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，然而我们并不能由此来确定数据运行的性能。当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------------------- ----------- --------
CPU time 361 54.14
log file sync 74,324 101 15.22
enqueue 729 88 13.28
db file sequentialread 7,303 65 9.76
SQL*Net message fromdblink 482 20 3.05
/* oracle等待事件是衡量oracle运行状况的重要依据及指示，等待事件分为两类：空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序，=FALSE那么事件按等待的数量排序。运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
对于常见的等待事件，说明如下：
1) db file scattered read：该事件通常与全表扫描或者fast full index scan有关。因为全表扫描是被放入内存中进行的进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散(scattered)读入Buffer Cache中。该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物，可能很多是全表扫描操作(不管怎样，这部分信息都是值得我们注意的)。
2) db file sequential read：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕（没有正确选择驱动行源），或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整。
3) buffer busy wait：当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。该值不应该大于1%。当出现等待问题时，可以检查缓冲等待统计部分(或V$WAITSTAT)，确定该等待发生在什么位置：
a) 如果等待是否位于段头(Segment Header)。这种情况表明段中的空闲列表（freelist）的块比较少。可以考虑增加空闲列表(freelist，对于Oracle8i DMT)或者增加freelist groups(在很多时候这个调整是立竿见影的(alter tablesp_item strorage(freelists 2))，在8.1.6之前，这个freelists参数不能动态修改;在8.1.6及以后版本，动态修改feelists需要设置COMPATIBLE至少为8.1.6)。也可以增加PCTUSED与PCTFREE之间距离（PCTUSED-to-pctfree gap），其实就是说降低PCTUSED的值，尽快使返回freelist列表被重用。如果支持自动段空间管理（ASSM），也可以使用ASSM模式。
b) 如果这一等待位于undo header，可以通过增加回滚段(rollback segment)来解决缓冲区的问题。
c) 如果等待位于undo block上，我们需要增加提交的频率；使用更大的回滚段，降低一致读所选择的表中数据的密度；增大DB_CACHE_SIZE。
d) 如果等待处于data block，表明出现了hot block，可以考虑如下方法解决：①将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增大pctfree值，扩大数据分布，减少竞争)，以避开这个"热点"数据块。②也可以减小数据块的大小，从而减少一个数据块中的数据行数，降低数据块的热度，减小竞争；③检查对这些热块操作的SQL语句，优化语句。④增加hot block上的initrans值。但注意不要把initrans值设置的过于高了，通常设置为5就足够了。因为增加事务意味着要增加ITL事务槽，而每个ITL事务槽将占用数据块中24个字节长度。默认情况下，每个数据块或者索引块中是ITL槽是2个，在增加initrans的时候，可以考虑增大数据块所在的表的PCTFREE值，这样Oracle会利用PCTFREE部分的空间增加ITL slot数量，最大达到maxtrans指定。
e) 如果等待处于index block，应该考虑重建索引、分割索引或使用反向键索引。为了防止与数据块相关的缓冲忙等待，也可以使用较小的块，在这种情况下，单个块中的记录就较少，所以这个块就不是那么"繁忙"。或者可以设置更大的PCTFREE,使数据扩大物理分布，减少记录间的热点竞争。在执行DML(insert/update/ delete)时，Oracle向数据块中写入信息，对于多事务并发访问的数据表，关于ITL的竞争和等待可能出现，为了减少这个等待，可以增加initrans，使用多个ITL槽。在Oracle9i 中，引入了一个新概念:ASSM(Segment Space Management Auto)。通过这个新特性Oracle使用位图来管理空间使用。
4) latch free：当闩锁丢失率高于0.5%时，需要调整这个问题。详细的我们在后面的Latch Activity forDB部分说明。
5) Enqueue 队列是一种锁，保护一些共享资源，防止并发的DML操作。队列采用FIFO策略，注意latch并不是采用的FIFO机制。比较常见的有3种类型的队列：ST队列，HW队列，TX4队列。
ST Enqueue的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法：1）将字典管理的表空间改为本地管理模式 2）预先分配分区或者将有问题的字典管理的表空间的next extent设置大一些。
HW Enqueue是用于segment的HWM的。当出现这种等待的时候，可以通过手工分配etents来解决。
TX4 Enqueue等待是最常见的等待情况。通常有3种情况会造成这种类型的等待：1）唯一索引中的重复索引。解决方法：commit或者rollback以释放队列。 2）对同一个位图索引段（bitmap index fragment）有多个update，因为一个bitmap index fragment可能包含了多个rowid，所以当多个用户更新时，可能一个用户会锁定该段，从而造成等待。解决方法同上。3）有多个用户同时对一个数据块作update，当然这些DML操作可能是针对这个数据块的不同的行，如果此时没有空闲的ITL槽，就会产生一个block-level锁。解决方法：增大表的initrans值使创建更多的ITL槽；或者增大表的pctfree值，这样oracle可以根据需要在pctfree的空间创建更多的ITL槽；使用smaller block size，这样每个块中包含行就比较少，可以减小冲突发生的机会。
6) Free Buffer：这个等待事件表明系统正在等待内存中的可用空间，这说明当前Buffer 中已经没有Free 的内存空间。如果应用设计良好，SQL 书写规范，充分绑定变量，那这种等待可能说明Buffer Cache 设置的偏小，你可能需要增大DB_BUFFER_CACHE。该等待也可能说明DBWR 的写出速度不够，或者磁盘存在严重的竞争，可以需要考虑增加检查点、使用更多的DBWR进程，或者增加物理磁盘的数量,分散负载，平衡IO。
7) Log file single write：该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。
8) log file parallel write：从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo log和data的数据文件位于不同的磁盘中。
9) log buffer space：日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。
10) logfile switch：通常是因为归档速度不够快。表示所有的提交(commit)的请求都需要等待"日志文件切换"的完成。Log file Switch 主要包含两个子事件:
log file switch (archiving needed) 这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待。出现该等待，可能表示io 存在问题。解决办法:①可以考虑增大日志文件和增加日志组；②移动归档文件到快速磁盘；③调整log_archive_max_processes。
log file switch (checkpoint incomplete) 当日志组都写完以后，LGWR 试图写第一个log file，如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成)，该等待事件出现。该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。为解决该问题，你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小。
11) log file sync：当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上。
12) DB File Parallel Write：改善IO性能
13) Direct Path Read：一般直接路径读取是指将数据块直接读入PGA中。一般用于排序、并行查询和read ahead操作。这个等待可能是由于I/O造成的。使用异步I/O模式或者限制排序在磁盘上，可能会降低这里的等待时间。
14) direct path write：直接路径写该等待发生在，系统等待确认所有未完成的异步I/O 都已写入磁盘。对于这一写入等待，我们应该找到I/O 操作最为频繁的数据文件(如果有过多的排序操作，很有可能就是临时文件)，分散负载，加快其写入操作。如果系统存在过多的磁盘排序，会导致临时表空间操作频繁，对于这种情况，可以考虑使用Local管理表空间，分成多个小文件，写入不同磁盘或者裸设备。
15) control file parallel write：当server 进程更新所有控制文件时，这个事件可能出现。如果等待很短，可以不用考虑。如果等待时间较长，检查存放控制文件的物理磁盘I/O 是否存在瓶颈。
多个控制文件是完全相同的拷贝，用于镜像以提高安全性。对于业务系统，多个控制文件应该存放在不同的磁盘上，一般来说三个是足够的，如果只有两个物理硬盘，那么两个控制文件也是可以接受的。在同一个磁盘上保存多个控制文件是不具备实际意义的。减少这个等待，可以考虑如下方法:①减少控制文件的个数(在确保安全的前提下)。②如果系统支持，使用异步IO。③转移控制文件到IO 负担轻的物理磁盘。
16) control file sequential read
control file single write ：控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时，这两个事件会出现。如果等待比较明显，检查单个控制文件，看存放位置是否存在I/O 瓶颈。
常见的一些IDLE wait事件举例：
dispatcher timer
lock element cleanup
Null event
parallel query dequeue wait
parallel query idle wait - Slaves
pipe get
PL/SQL lock timer
pmon timer- pmon
rdbms ipc message
slave wait
smon timer
SQL*Net break/reset to client
SQL*Net message from client
SQL*Net message to client
SQL*Net more data to client
virtual circuit status
client message
SQL*Net message from client
下面是关于这里的常见的等待事件和解决方法的一个快速预览
| 等待事件 | 一般解决方法 |
| Sequential Read | 调整相关的索引和选择合适的驱动行源 |
| Scattered Read | 表明出现很多全表扫描。优化code，cache小表到内存中。 |
| Free Buffer | 增大DB_CACHE_SIZE，增大checkpoint的频率，优化code |
| Buffer Busy Segment header | 增加freelist或者freelistgroups |
| Buffer Busy Data block | 隔离热块；使用反转索引；使用更小的块；增大表的initrans |
| Buffer Busy Undo header | 增加回滚段的数量或者大小 |
| Buffer Busy Undo block | Commit more；增加回滚段的数量或者大小 |
| Latch Free | 检查具体的等待latch类型，解决方法参考后面介绍 |
| Enqueue–ST | 使用本地管理的表空间或者增加预分配的盘区大小 |
| Enqueue–HW | 在HWM之上预先分配盘区 |
| Enqueue–TX4 | 在表或者索引上增大initrans的值或者使用更小的块 |
| Log Buffer Space | 增大LOG_BUFFER，改善I/O |
| Log File Switch | Archive destination slow or full; add more or larger redo logs |
| Log file sync | Commit more records at a time; use faster redo log disks; use raw devices |
| Write complete waits | Add database writers; checkpoint more often; buffer cache too small |
-------------------------------------------------------------
Wait Events for DB: ORA92 Instance: ora92 Snaps: 13 -14
->s - second
->cs - centisecond - 100th of a second
->ms - millisecond - 1000th of a second
->us - microsecond - 1000000th of a second
->ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------------------- ---------- ---------- ------ --------
log file sync 74,324 0 101 1 1.0
enqueue 729 0 88 121 0.0
db file sequentialread 7,303 0 65 9 0.1
SQL*Net message fromdblink 482 0 20 42 0.0
db file parallelwrite 725 0 14 19 0.0
db file scatteredread 2,415 0 6 3 0.0
process startup 8 0 4 440 0.0
latch free 1,307 1,300 2 1 0.0
log file parallelwrite 67,042 0 2 0 0.9
control filesequential read 269 0 1 3 0.0
single-taskmessage 24 0 1 33 0.0
control fileparallel write 325 0 1 2 0.0
buffer busywaits 3,368 0 1 0 0.0
log file switchcompletion 19 0 0 20 0.0
direct pathread 288 0 0 0 0.0
LGWR wait for redocopy 1,032 0 0 0 0.0
SQL*Net more data toclient 1,390 0 0 0 0.0
kksfbc childcompletion 1 1 0 10 0.0
log file sequentialread 2 0 0 5 0.0
direct pathwrite 128 0 0 0 0.0
library cachepin 14 0 0 0 0.0
SQL*Net more datafrom dblin 4 0 0 0 0.0
log file singlewrite 2 0 0 1 0.0
SQL*Net message todblink 482 0 0 0 0.0
buffer deadlock 30 30 0 0 0.0
SQL*Net message fromclient 436,773 0 143,221 328 5.8
jobq slave wait 2,688 1,664 6,688 2488 0.0
wakeup timemanager 27 27 791 29297 0.0
SQL*Net message toclient 436,772 0 0 0 5.8
-------------------------------------------------------------
Background Wait Events for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> ordered bywait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------------------- ---------- ---------- ------ --------
db file parallelwrite 725 0 14 19 0.0
log file parallelwrite 67,044 0 2 0 0.9
control filesequential read 186 0 1 4 0.0
control fileparallel write 325 0 1 2 0.0
db file scatteredread 38 0 0 7 0.0
direct pathread 288 0 0 0 0.0
LGWR wait for redocopy 1,032 0 0 0 0.0
db file sequentialread 3 0 0 6 0.0
log file sequentialread 2 0 0 5 0.0
direct pathwrite 128 0 0 0 0.0
log file singlewrite 2 0 0 1 0.0
rdbms ipcmessage 63,167 1,061 4,970 79 0.8
smon timer 3 3 879 ###### 0.0
pmon timer 292 292 823 2819 0.0
-------------------------------------------------------------
这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。
在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets perexec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。
另外说明一点：大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100％的时候，很多时候就是SQL语句造成的，这时候我们可以分析一下这里逻辑读大的SQL。
SQL ordered by Gets for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> End BufferGets Threshold: 10000
-> Note thatresources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQLcode. As individual SQL
statements are also reported, it is possibleand valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) HashValue
--------------------------- -------------- ------ -------- --------- ----------
13,367,435 171 78,172.1 68.3 259.36 353.19 3790040751
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN P_DXH_DEALOVERTIMEDXHREC; :mydate
:= next_date; IFbroken THEN :b := 1; ELSE :b := 0; END IF; END
;
8,232,840 171 48,145.3 42.1 161.10 250.10 1881561609
UPDATE T_DXH_OPENDETECT SET NOTIFYFLAG = :B2 WHERENEXTNOFIFYTIM
E <= SYSDATE AND HASDXHREC = 1 AND NOTIFYFLAG + 0= 1AND ROWNUM
<= :B1
4,161,788 170 24,481.1 21.3 84.28 82.97 3037553707
UPDATE T_DXH_OPENDETECT SET NOTIFYFLAG = :B2 WHERENEXTNOFIFYTIM
E <= SYSDATE AND HASDXHREC = 0 AND DETECTTYPE >= 1AND NOTIFYFLA
G + 0 = 1 AND ROWNUM<= :B1
2,059,012 21,504 95.8 10.5 5.92 241.61 1725988165
Module: Das.exe
beginP_DXH_AddSms(I_CALLERNO=>:V001,I_CALLEENO=>:V002,I_CALLTY
PE=>:V003,I_DXHHFLAG=>:V004,O_RET=>:V005);end;
975,610 48,861 20.0 5.0 0.27 5.80 947217968
Module: Das.exe
SELECT T.AREAID FROMT_DXH_MOBILE S, T_DXH_AREA T WHERE S.MOBILE
SEGMENT = SUBSTR(:B1 ,1,7) AND T.AREACODE = S.AREACODEAND ROWNU
M = 1
900,092 3,029 297.2 4.6 1.37 8.35 1192159506
Module: SvcProcessor.exe
beginP_DXH_GETDETECTSMSTOSEND(O_DATASET=>:R000C000); end;
882,673 3,029 291.4 4.5 0.95 6.10 2317765928
Module: SvcProcessor.exe
UPDATE/*+index(T_DXH_OpenDetect IX_DXH_OD_NEXTSENDTIME) */ T_DX
H_OPENDETECT SET LOCKFLAG = :B2 , NOTIFYFLAG = 1,SENDDATE = SYS
DATE, SENDCOUNT =SENDCOUNT + 1 WHERE NOTIFYFLAG = 0 AND NEXTSEN
DDATE <= SYSDATEAND ROWNUM <= :B1
618,728 10 61,872.8 3.2 1.65 1.66 161612394
Module: SQL*Plus
select:"SYS_B_0",CALLEENO,COUNT(*) from t_dxh_dxhreclog where c
alltime>=to_date(:"SYS_B_1",:"SYS_B_2")and calltime<to_date(:"S
YS_B_3",:"SYS_B_4")and callerno=:"SYS_B_5" group by calleEno
570,936 13,252 43.1 2.9 2.10 26.23 1742600444
Module: SvcProcessor.exe
beginp_dxh_UpdateDeliverStatus(:V00001,:V00002,:V00003,:V00004)
; end;
417,166 30,650 13.6 2.1 2.68 31.47 3303409220
SQL ordered by Gets for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End BufferGets Threshold: 10000
-> Note thatresources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQLcode. As individual SQL
statements are also reported, it is possibleand valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) HashValue
--------------------------- -------------- ------ -------- --------- ----------
Module: SvcProcessor.exe
beginP_DXH_UPDATESUBMITSTATUS(:V00001,:V00002,:V00003,:V00004);
end;
374,751 11,186 33.5 1.9 0.68 7.95 1153666271
Module: Das.exe
INSERT INTOT_DXH_OPENDETECT (SERIALNO, SMID, SERVICEID, PID, SM
SCONTENT, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR,FEETYPE, FEEUS
ERTYPE, FEECODE,SPID, SENDDATE, SENDCOUNT, NEXTSENDDATE, MSGRES
ULT, MSGTYPE, SUBMITSTATUS, NOTIFYFLAG, LOCKFLAG,INSERTTIME, RE
CEIVESTATUS,RECEIVETIME, DETECTRECEIVETIME, AREAID, NEXTNOFIFYT
330,986 3,030 109.2 1.7 0.85 4.46 2610976985
Module: SvcProcessor.exe
beginP_DXH_GETSMSTOSEND(O_DATASET=>:R000C000);end;
325,777 497 655.5 1.7 3.39 5.48 1393749192
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN P_DXH_INTERGETSMSTOSEND; :mydate
:= next_date; IFbroken THEN :b := 1; ELSE :b := 0; END IF; END;
313,902 3,029 103.6 1.6 0.58 2.35 2436320767
Module: SvcProcessor.exe
UPDATE T_DXH_MT SETLOCKFLAG = :B2 , NOTIFYFLAG = 1, SENDDATE =
SYSDATE, SENDCOUNT = SENDCOUNT + 1 WHERE NOTIFYFLAG = 0AND NEXT
SENDDATE <=SYSDATE AND ROWNUM <= :B1
269,272 27,543 9.8 1.4 4.97 219.41 3767315403
Module: Das.exe
BEGINSYS.DBMS_DESCRIBE.DESCRIBE_PROCEDURE(:object_name,:res1,:r
es2,:overload,:position,:level,:argument,:datatype,:default,:in_
out,:length,:precision,:scale,:radix,:spare);END;
248,497 2,944 84.4 1.3 0.29 5.24 4221142634
Module: Aplogic.exe
begin P_DXH_AddSms(:1, :2, :3, :4, :5); end;
212,406 30,701 6.9 1.1 0.42 3.99 93692607
Module:SvcProcessor.exe
UPDATE T_DXH_MT TSET SMID = :B2 , SUBMITSTATUS = 1, MSGRESULT =
'SUCCESS' WHERE SERIALNO = :B1
207,490 10,732 19.3 1.1 1.89 3.00 2508881723
DELETE FROM T_DXH_DXHREC WHERE NOTIFYFLAG = :B2 ANDPARTCOL = SU
BSTR(:B1 , -3, 2)
184,941 10,732 17.2 0.9 3.18 6.68 3086225498
INSERT INTO T_DXH_DXHRECLOG (CALLERNO, CALLEENO, CALLTIME,NOTIF
YFLAG, LOCKFLAG, SMSTYPE, AREAID, LOGDATE) SELECTCALLERNO, CALL
SQL ordered by Gets for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End BufferGets Threshold: 10000
-> Note thatresources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQLcode. As individual SQL
statements are also reported, it is possibleand valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------------------- -------------- ------ -------- --------- ----------
EENO, CALLTIME, NOTIFYFLAG, LOCKFLAG, SMSTYPE, AREAID,TO_CHAR(C
ALLTIME, 'MMDD') FROM T_DXH_DXHREC WHERE NOTIFYFLAG =:B2 AND PA
RTCOL = SUBSTR(:B1 ,-3, 2)
181,918 9,883 18.4 0.9 2.49 2.70 964009871
INSERT INTO T_DXH_MT (SERIALNO, SMID, SERVICEID, PID,SMSCONTENT
, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR, FEETYPE,FEEUSERTYPE,
FEECODE, SPID,SENDDATE, SENDCOUNT, NEXTSENDDATE, MSGRESULT, MSG
TYPE, SUBMITSTATUS, NOTIFYFLAG, LOCKFLAG, INSERTTIME,RECEIVESTA
TUS, RECEIVETIME,AREAID, DETECTRECEIVETIME) VALUES (F_DXH_GETSE
174,531 30,628 5.7 0.9 0.20 3.76 270039726
Module: SvcProcessor.exe
UPDATET_DXH_OPENDETECT T SET SMID = :B2 , SUBMITSTATUS = 1, MSG
RESULT = 'SUCCESS'WHERE SERIALNO = :B1
169,625 171 992.0 0.9 1.13 1.18 187968648
UPDATE T_DXH_OPENDETECT SET NEXTNOFIFYTIME = SYSDATE +:B2 / 24,
HASDXHREC = 0,NOTIFYFLAG = 1 WHERE NOTIFYFLAG = :B1
159,189 10,732 14.8 0.8 1.58 1.91 801000427
UPDATE T_DXH_DXHREC SET NOTIFYFLAG = :B3 WHERE CALLEENO= :B1 AN
D CALLERNO = :B2 AND NOTIFYFLAG + 0 = 0 AND PARTCOL =SUBSTR(:B1
-------------------------------------------------------------
SQL ordered by Reads for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End Disk ReadsThreshold: 1000
这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。当我们的系统如果存在I/O瓶颈时，需要关注这里I/O操作比较多的语句。
CPU Elapsd
Physical Reads Executions Reads per Exec %TotalTime (s) Time (s) Hash Value
--------------------------- -------------- ------ -------- --------- ----------
4,187 24 174.5 15.8 0.79 52.99 1895519470
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN p_dxh_tmp_importUserInfo2(500); :
mydate := next_date;IF broken THEN :b := 1; ELSE :b := 0; END I
F; END;
1,299 171 7.6 4.9 259.36 353.19 3790040751
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN P_DXH_DEALOVERTIMEDXHREC; :mydate
:= next_date; IFbroken THEN :b := 1; ELSE :b := 0; END IF; END
;
790 171 4.6 3.0 161.10 250.10 1881561609
UPDATE T_DXH_OPENDETECT SET NOTIFYFLAG = :B2 WHERENEXTNOFIFYTIM
E <= SYSDATE AND HASDXHREC = 1 AND NOTIFYFLAG + 0= 1AND ROWNUM
<= :B1
647 3 215.7 2.4 0.78 5.51 12941550
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN P_DXH_JOB_MOVES; :mydate := next_
date; IF broken THEN:b := 1; ELSE :b := 0; END IF; END;
538 21,504 0.0 2.0 5.92 241.61 1725988165
Module: Das.exe
beginP_DXH_AddSms(I_CALLERNO=>:V001,I_CALLEENO=>:V002,I_CALLTY
PE=>:V003,I_DXHHFLAG=>:V004,O_RET=>:V005);end;
534 190 2.8 2.0 0.05 3.89 379637043
UPDATET_DXH_DXHUSER_1 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
492 170 2.9 1.9 0.05 3.87 254199787
UPDATET_DXH_DXHUSER_5 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
458 171 2.7 1.7 0.07 3.33 3691304462
UPDATET_DXH_DXHUSER_4 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
451 159 2.8 1.7 0.07 3.71 3024470367
UPDATET_DXH_DXHUSER_3 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
444 155 2.9 1.7 0.06 3.04 2349171246
UPDATET_DXH_DXHUSER_7 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
419 147 2.9 1.6 0.08 2.85 2514739762
UPDATET_DXH_DXHUSER_2 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
410 143 2.9 1.5 0.05 3.23 2512493074
UPDATET_DXH_DXHUSER_6 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
SQL ordered by Reads for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End Disk ReadsThreshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %TotalTime (s) Time (s) Hash Value
--------------------------- -------------- ------ -------- --------- ----------
408 10,732 0.0 1.5 3.18 6.68 3086225498
INSERT INTO T_DXH_DXHRECLOG (CALLERNO, CALLEENO,CALLTIME, NOTIF
YFLAG, LOCKFLAG, SMSTYPE, AREAID, LOGDATE) SELECTCALLERNO, CALL
EENO, CALLTIME, NOTIFYFLAG, LOCKFLAG, SMSTYPE, AREAID,TO_CHAR(C
ALLTIME, 'MMDD')FROM T_DXH_DXHREC WHERE NOTIFYFLAG = :B2 AND PA
RTCOL = SUBSTR(:B1 ,-3, 2)
399 142 2.8 1.5 0.08 3.18 1822739468
UPDATET_DXH_DXHUSER_9 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
383 24,439 0.0 1.4 0.29 7.00 1578554344
Module: Das.exe
SELECT DETECTCOUNT,DETECTTYPE, HASDXHREC FROM T_DXH_OPENDETECT
WHERE DESTADDR = :B1
365 128 2.9 1.4 0.05 2.86 4054447418
UPDATET_DXH_DXHUSER_0 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
343 3 114.3 1.3 0.15 2.77 1663365422
INSERT INTO T_DXH_EXCEPTIONMT (SERIALNO, SMID,SERVICEID, SMSCON
TENT, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR, FEETYPE,FEEUSERTY
PE, FEECODE, SPID, SENDDATE, MSGRESULT, MSGTYPE,SUBMITSTATUS, N
OTIFYFLAG, LOCKFLAG,INSERTTIME, RECEIVESTATUS, RECEIVETIME, ARE
AID,DETECTRECEIVETIME) SELECT SERIALNO, SMID, SERVICEID, SMSCON
287 13,252 0.0 1.1 2.10 26.23 1742600444
Module: SvcProcessor.exe
beginp_dxh_UpdateDeliverStatus(:V00001,:V00002,:V00003,:V00004)
; end;
263 1 263.0 1.0 0.02 0.27 3587907089
select file#,block#, ts# from seg$ where type# = 3
209 77 2.7 0.8 0.02 1.63 1676881149
UPDATET_DXH_DXHUSER_8 SET OPENTIME = :v_OPENTIME, CLOSETIME =
:v_CLOSETIME, ENABLE = :v_ENABLE WHERE CALLERNO =:v_CALLERNO
208 11,186 0.0 0.8 0.68 7.95 1153666271
Module: Das.exe
INSERT INTOT_DXH_OPENDETECT (SERIALNO, SMID, SERVICEID, PID, SM
SCONTENT, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR,FEETYPE, FEEUS
ERTYPE, FEECODE,SPID, SENDDATE, SENDCOUNT, NEXTSENDDATE, MSGRES
ULT, MSGTYPE, SUBMITSTATUS, NOTIFYFLAG, LOCKFLAG,INSERTTIME, RE
CEIVESTATUS, RECEIVETIME,DETECTRECEIVETIME, AREAID, NEXTNOFIFYT
184 3 61.3 0.7 0.13 1.48 2557997856
INSERT INTO T_DXH_MTLOG (SERIALNO, SMID, SERVICEID,SMSCONTENT,
REPORTFLAG, ORGADDR, DESTADDR, FEEADDR, FEETYPE,FEEUSERTYPE, FE
ECODE, SPID, SENDDATE, MSGRESULT, MSGTYPE, SUBMITSTATUS,NOTIFYF
LAG, LOCKFLAG,INSERTTIME, RECEIVESTATUS, RECEIVETIME, AREAID, D
ETECTRECEIVETIME, LOGDATE) SELECT SERIALNO, SMID,SERVICEID, SMS
SQL ordered by Readsfor DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End Disk ReadsThreshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %TotalTime (s) Time (s) Hash Value
--------------------------- -------------- ------ -------- --------- ----------
165 698 0.2 0.6 0.17 3.46 4199359299
Module: SvcProcessor.exe
INSERT INTOT_DXH_EXCEPTIONMT (SERIALNO, SMID, SERVICEID, SMSCON
TENT, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR, FEETYPE,FEEUSERTY
PE, FEECODE, SPID,SENDDATE, MSGRESULT, MSGTYPE, SUBMITSTATUS, N
-------------------------------------------------------------
SQL ordered by Executions forDB: ORA92 Instance: ora92 Snaps: 13 -14
-> End ExecutionsThreshold: 100
这部分告诉我们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快，任何被执行几百万次的操作都将开始耗尽大量的时间。
CPU per Elap per
Executions Rows Processed Rows perExec Exec (s) Exec (s) Hash Value
--------------------------- ---------------- ----------- ---------- ----------
102,491 0 0.0 0.00 0.00 1053795750
Module: Das.exe
COMMIT
48,861 38,275 0.8 0.00 0.00 947217968
Module: Das.exe
SELECT T.AREAID FROMT_DXH_MOBILE S, T_DXH_AREA T WHERE S.MOBILE
SEGMENT = SUBSTR(:B1 ,1,7) AND T.AREACODE = S.AREACODEAND ROWNU
M = 1
30,701 18,715 0.6 0.00 0.00 93692607
Module: SvcProcessor.exe
UPDATE T_DXH_MT TSET SMID = :B2 , SUBMITSTATUS = 1, MSGRESULT =
'SUCCESS' WHERE SERIALNO = :B1
30,650 30,634 1.0 0.00 0.00 3303409220
Module: SvcProcessor.exe
beginP_DXH_UPDATESUBMITSTATUS(:V00001,:V00002,:V00003,:V00004);
end;
30,628 11,986 0.4 0.00 0.00 270039726
Module: SvcProcessor.exe
UPDATET_DXH_OPENDETECT T SET SMID = :B2 , SUBMITSTATUS = 1, MSG
RESULT = 'SUCCESS'WHERE SERIALNO = :B1
27,561 113,578 4.1 0.00 0.00 3921651930
Module: Das.exe
SELECTARGUMENT,OVERLOAD#,POSITION# POSITION,TYPE# TYPE,NVL(CHAR
SETID,0) CHARSETID,NVL(CHARSETFORM,0) CHARSETFORM,NVL(DEFAULT#,0
)DEFAULT#,NVL(IN_OUT,0) IN_OUT,NVL(LEVEL#,0) LEVEL#,NVL(LENGTH,
0) LENGTH,NVL(PRECISION#,0) PRECISION,NVL(SCALE,0)SCALE,NVL(RAD
IX,0)RADIX,DECODE(TYPE#,1,NVL(SCALE,0),96,NVL(SCALE,0),0) CHARL
27,543 27,533 1.0 0.00 0.01 3767315403
Module: Das.exe
BEGINSYS.DBMS_DESCRIBE.DESCRIBE_PROCEDURE(:object_name,:res1,:r
es2,:overload,:position,:level,:argument,:datatype,:default,:in_
out,:length,:precision,:scale,:radix,:spare);END;
27,534 27,555 1.0 0.00 0.00 3186030150
Module: Das.exe
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = '
NLS_NCHAR_CHARACTERSET'
27,514 27,537 1.0 0.00 0.00 2343617164
Module: Das.exe
SELECT STATUS FROM OBJ$ WHERE OBJ# = :b1
25,570 25,574 1.0 0.00 0.00 3582307764
Module: Das.exe
SELECTSEQ_DXH_MSGID.NEXTVAL FROM DUAL
25,107 25,094 1.0 0.00 0.00 1793731645
Module: Das.exe
SQL ordered byExecutions for DB: ORA92 Instance:ora92 Snaps: 13 -14
-> End ExecutionsThreshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
--------------------------- ---------------- ----------- ---------- ----------
SELECT MSGCONTENT FROM T_DXH_MSGCONTENT WHERE ID = 2
25,105 25,106 1.0 0.00 0.00 3132728303
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 71
25,091 25,107 1.0 0.00 0.00 4111923832
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 72
24,610 24,616 1.0 0.00 0.00 3675044126
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 68
24,604 24,612 1.0 0.00 0.00 31299260
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 69
24,598 24,609 1.0 0.00 0.00 3167526355
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 67
24,595 24,612 1.0 0.00 0.00 2528525706
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 70
24,441 24,423 1.0 0.00 0.00 1602405543
Module: Das.exe
SELECT SERVICEID,ORGADDR, FEETYPE, FEEUSERTYPE, FEECODE, CORPID
, REPORTFLAG FROMT_DXH_FEESETUP WHERE FEEID = 3
24,439 12,994 0.5 0.00 0.00 1578554344
Module: Das.exe
SELECT DETECTCOUNT,DETECTTYPE, HASDXHREC FROM T_DXH_OPENDETECT
WHERE DESTADDR = :B1
24,432 24,436 1.0 0.00 0.00 1730113823
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 64
24,177 0 0.0 0.00 0.00 1890674192
Module: Das.exe
INSERT INTOT_DXH_NM_REGISTERINFO (LOGTIME, USERCOUNT, TOTALDXHU
SER, TOTALDXHHUSER, DXHCALLINGCOUNT,DXHHCALLINGCOUNT,DEALEDCALL
ING,DXHSENDCOUNT)SELECT TRUNC(SYSDATE, 'DD'), USERCOUNT, TOTALD
XHUSER, TOTALDXHHUSER, :B3 , :B2 , 1, :B1 FROMT_DXH_NM_REGISTER
INFO WHERE LOGTIME =TRUNC(SYSDATE - 1, 'DD')
24,163 0 0.0 0.00 0.00 2770580725
Module: Das.exe
UPDATET_DXH_NM_REGISTERINFO T SET DEALEDCALLING = DEALEDCALLING
+ 1, DXHCALLINGCOUNT = DXHCALLINGCOUNT + :B3 ,DXHHCALLINGCOUNT
=DXHHCALLINGCOUNT + :B2 , DXHSENDCOUNT = DXHSENDCOUNT + :B1 WH
ERE T.LOGTIME =TRUNC(SYSDATE, 'DD')
SQL ordered byExecutions for DB: ORA92 Instance:ora92 Snaps: 13 -14
-> End ExecutionsThreshold: 100
CPU per Elap per
Executions Rows Processed Rows perExec Exec (s) Exec (s) Hash Value
--------------------------- ---------------- ----------- ---------- ----------
21,504 21,505 1.0 0.00 0.01 1725988165
Module: Das.exe
beginP_DXH_AddSms(I_CALLERNO=>:V001,I_CALLEENO=>:V002,I_CALLTY
PE=>:V003,I_DXHHFLAG=>:V004,O_RET=>:V005);end;
15,112 15,093 1.0 0.00 0.00 3531895589
Module: Das.exe
INSERT INTOT_DXH_DXHRECLOG (CALLERNO, CALLEENO, NOTIFYFLAG, SMS
TYPE, AREAID, LOGDATE) VALUES (:B4 , :B3 , 1, :B2 , :B1, TO_CHA
R(SYSDATE, 'MMDD'))
13,260 0 0.0 0.00 0.00 1611111058
Module: SvcProcessor.exe
UPDATET_DXH_NM_REGISTERINFO T SET DXHSENDSUCCESS = DXHSENDSUCCE
SS + :B2 , DXHHSENDSUCCESS = DXHHSENDSUCCESS + :B1 WHERET.LOGTI
ME = TRUNC(SYSDATE,'DD')
13,252 13,242 1.0 0.00 0.00 1742600444
Module: SvcProcessor.exe
beginp_dxh_UpdateDeliverStatus(:V00001,:V00002,:V00003,:V00004)
; end;
13,249 0 0.0 0.00 0.00 1786302984
Module: SvcProcessor.exe
INSERT INTOT_DXH_NM_REGISTERINFO (LOGTIME, USERCOUNT, TOTALDXHU
SER, TOTALDXHHUSER, DXHSENDSUCCESS, DXHHSENDSUCCESS)SELECT TRUN
C(SYSDATE, 'DD'),USERCOUNT, TOTALDXHUSER, TOTALDXHHUSER, :B2 ,
:B1 FROM T_DXH_NM_REGISTERINFO WHERE LOGTIME =TRUNC(SYSDATE - 1
, 'DD')
13,192 13,179 1.0 0.00 0.00 706097155
Module: SvcProcessor.exe
SELECTTO_NUMBER(NVL(CONFIGVALUE, '5')) FROM T_DXH_CONFIG WHERE
ID = 66
13,191 13,215 1.0 0.00 0.00 4903229
Module: SvcProcessor.exe
SELECTNVL(CONFIGVALUE, '3') FROM T_DXH_CONFIG WHERE ID = 65
11,186 11,186 1.0 0.00 0.00 1153666271
Module: Das.exe
INSERT INTOT_DXH_OPENDETECT (SERIALNO, SMID, SERVICEID, PID, SM
SCONTENT, REPORTFLAG, ORGADDR, DESTADDR, FEEADDR,FEETYPE, FEEUS
ERTYPE, FEECODE,SPID, SENDDATE, SENDCOUNT, NEXTSENDDATE, MSGRES
-------------------------------------------------------------
在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。
SQL ordered by Parse Calls forDB: ORA92 Instance: ora92 Snaps: 13 -14
-> End ParseCalls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------------------ -------- ----------
61,404 30,650 32.06 3303409220
Module: SvcProcessor.exe
begin P_DXH_UPDATESUBMITSTATUS(:V00001,:V00002,:V00003,:V00004);
end;
27,565 27,543 14.39 3767315403
Module: Das.exe
BEGINSYS.DBMS_DESCRIBE.DESCRIBE_PROCEDURE(:object_name,:res1,:r
es2,:overload,:position,:level,:argument,:datatype,:default,:in_
out,:length,:precision,:scale,:radix,:spare);END;
26,528 13,252 13.85 1742600444
Module: SvcProcessor.exe
beginp_dxh_UpdateDeliverStatus(:V00001,:V00002,:V00003,:V00004)
; end;
21,507 21,504 11.23 1725988165
Module: Das.exe
beginP_DXH_AddSms(I_CALLERNO=>:V001,I_CALLEENO=>:V002,I_CALLTY
PE=>:V003,I_DXHHFLAG=>:V004,O_RET=>:V005);end;
6,060 3,030 3.16 2610976985
Module: SvcProcessor.exe
beginP_DXH_GETSMSTOSEND(O_DATASET=>:R000C000);end;
6,058 3,029 3.16 1192159506
Module: SvcProcessor.exe
beginP_DXH_GETDETECTSMSTOSEND(O_DATASET=>:R000C000); end;
4,199 4,174 2.19 2467761965
Module: Aplogic.exe
select:"SYS_B_0" from dual
3,370 1,685 1.76 1396673393
Module:SvcProcessor.exe
beginp_dxh_UpdateRate(:V00001,:V00002); end;
3,095 3,095 1.62 4151926656
Module:SvcProcessor.exe
SELECT ' ' FROM DUAL
2,944 2,944 1.54 4221142634
Module: Aplogic.exe
begin P_DXH_AddSms(:1, :2, :3, :4, :5); end;
1,978 1,978 1.03 3716207873
update seq$ setincrement$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10where obj#=:
1
1,780 102,491 0.93 1053795750
Module: Das.exe
COMMIT
SQL ordered by ParseCalls for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End ParseCalls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------------------ -------- ----------
1,661 1,661 0.87 140223014
Module: SvcProcessor.exe
SELECT SERIALNO,PID, SERVICEID, SMSCONTENT, REPORTFLAG, ORGADDR
, DESTADDR, FEEADDR, FEETYPE, FEEUSERTYPE, FEECODE, SPIDFROM T_
DXH_OPENDETECT WHERELOCKFLAG = :B1
1,302 1,302 0.68 1083917835
Module: SvcProcessor.exe
SELECT SERIALNO,PID, SERVICEID, SMSCONTENT, REPORTFLAG, ORGADDR
, DESTADDR, FEEADDR, FEETYPE, FEEUSERTYPE, FEECODE, SPIDFROM T_
DXH_MT WHERELOCKFLAG = :B1
708 704 0.37 1356713530
selectprivilege#,level from sysauth$ connect by grantee#=prior
privilege# andprivilege#>0 start with (grantee#=:1 or grantee#=
1) andprivilege#>0
702 702 0.37 297937389
update sys.job$ setthis_date=:1 where job=:2
702 660 0.37 1003729976
alter session setNLS_LANGUAGE='SIMPLIFIED CHINESE' NLS_TERRITOR
Y='CHINA'NLS_CURRENCY='RMB' NLS_ISO_CURRENCY='CHINA' NLS_NUMERI
C_CHARACTERS='.,'NLS_DATE_FORMAT='DD-MON-RR' NLS_DATE_LANGUAGE=
'SIMPLIFIED CHINESE'NLS_SORT='BINARY'
702 702 0.37 4075357577
update sys.job$ setfailures=0, this_date=null, flag=:1, last_da
te=:2, next_date = greatest(:3, sysdate), total=total+(sysdate
-nvl(this_date,sysdate))where job=:4
687 681 0.36 2594425492
select u1.user#,u2.user#, u3.user#, failures, flag, interval#,
what, nlsenv, env, field1 from sys.job$ j, sys.user$ u1, sys
.user$ u2, sys.user$ u3 where job=:1 and (next_date < sysdate o
r :2 != 0) and lowner = u1.name and powner = u2.name andcowner
= u3.name
675 674 0.35 60189110
SELECT SEQ_DXH_OPENUSERFLAG.NEXTVAL FROM DUAL
675 669 0.35 1114559152
SELECT MSGCONTENT FROM T_DXH_MSGCONTENT WHERE ID = 3
675 650 0.35 1310393569
SELECT CONFIGVALUE FROM T_DXH_CONFIG WHERE ID = 14
675 25,107 0.35 1793731645
Module: Das.exe
SELECT MSGCONTENTFROM T_DXH_MSGCONTENT WHERE ID = 2
675 664 0.35 2188761566
SELECT CONFIGVALUE FROM T_DXH_CONFIG WHERE ID = 15
SQL ordered by ParseCalls for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End ParseCalls Threshold: 1000
% Total
Parse Calls Executions Parses Hash Value
------------------------ -------- ----------
675 25,105 0.35 3132728303
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 71
675 644 0.35 3278526165
SELECT CONFIGVALUE FROM T_DXH_CONFIG WHERE ID = 61
675 25,091 0.35 4111923832
Module: Das.exe
SELECT CONFIGVALUEFROM T_DXH_CONFIG WHERE ID = 72
504 498 0.26 432182003
SELECT MSGCONTENT FROM T_DXH_MSGCONTENT WHERE ID = 5
504 503 0.26 1334536481
DELETE FROM T_DXH_OPENDETECT WHERE NOTIFYFLAG = :B1
504 497 0.26 1393749192
DECLARE jobBINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN :=FALSE; BEGIN P_DXH_INTERGETSMSTOSEND; :mydate
:= next_date; IFbroken THEN :b := 1; ELSE :b := 0; END IF; END;
504 501 0.26 3346244369
SELECT DESTADDR, AREAID, RECEIVETIME FROMT_DXH_OPENDETECT WHERE
NOTIFYFLAG = :B1ORDER BY SUBSTR(DESTADDR, -3, 2)
504 502 0.26 3447363181
UPDATE T_DXH_OPENDETECT SET NOTIFYFLAG = :B2 WHERERECEIVESTATUS
= 1 AND NOTIFYFLAG+0 = 1 AND ROWNUM <= :B1
504 504 0.26 3927614519
INSERT INTO T_DXH_NM_REGISTERINFO (LOGTIME, USERCOUNT,TOTALDXHU
SER, TOTALDXHHUSER, DXHSENDCOUNT, DXHHSENDCOUNT) SELECTTRUNC(SY
SDATE, 'DD'), USERCOUNT, TOTALDXHUSER, TOTALDXHHUSER,:B2 , :B1
FROMT_DXH_NM_REGISTERINFO WHERE LOGTIME = TRUNC(SYSDATE - 1, 'D
D')
-------------------------------------------------------------
SQL ordered by Sharable Memoryfor DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End SharableMemory Threshold: 1048576
Sharable Mem (b) Executions % Total Hash Value
---------------------------- ------- ------------
1,115,384 15,112 0.2 3531895589
Module: Das.exe
INSERT INTOT_DXH_DXHRECLOG (CALLERNO, CALLEENO, NOTIFYFLAG, SMS
TYPE, AREAID, LOGDATE) VALUES (:B4 , :B3 , 1, :B2 , :B1, TO_CHA
R(SYSDATE, 'MMDD'))
-------------------------------------------------------------
SQL ordered by Version Countfor DB: ORA92 Instance: ora92 Snaps: 13 -14
-> End VersionCount Threshold: 20
Version
Count Executions Hash Value
-------------------- ------------
30 15,112 3531895589
Module: Das.exe
INSERT INTOT_DXH_DXHRECLOG (CALLERNO, CALLEENO, NOTIFYFLAG, SMS
TYPE, AREAID, LOGDATE) VALUES (:B4 , :B3 , 1, :B2 , :B1, TO_CHA
R(SYSDATE, 'MMDD'))
-------------------------------------------------------------
Instance Activity Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
这部分数据主要是从V$SYSSTAT表中统计出来的，一些条目的详细内容会在后面逐条标注。
Statistic Total per Second per Trans
--------------------------------------------------- -------------- ------------
CPU used by thissession 36,055 42.8 0.5
CPU used when callstarted 9,526 11.3 0.1
CR blockscreated 9,509 11.3 0.1
DBWR buffersscanned 12,962 15.4 0.2
DBWR checkpointbuffers written 87,437 103.7 1.2
DBWRcheckpoints 1 0.0 0.0
DBWR free buffersfound 12,700 15.1 0.2
DBWR lru scans 116 0.1 0.0
DBWR make freerequests 124 0.2 0.0
DBWR summed scandepth 12,962 15.4 0.2
DBWR transactiontable writes 23 0.0 0.0
DBWR undo blockwrites 18,974 22.5 0.3
PX local messagesrecv'd 0 0.0 0.0
PX local messagessent 0 0.0 0.0
SQL*Net roundtripsto/from client 436,777 518.1 5.8
SQL*Net roundtripsto/from dblink 482 0.6 0.0
active txn countduring cleanout 8,651 10.3 0.1
backgroundcheckpoints completed 2 0.0 0.0
backgroundcheckpoints started 1 0.0 0.0
background timeouts 1,288 1.5 0.0
branch nodesplits 6 0.0 0.0
buffer is not pinnedcount 2,170,225 2,574.4 28.7
buffer is pinnedcount 2,694,289 3,196.1 35.6
bytes received viaSQL*Net from c 35,743,183 42,400.0 472.8
bytes received viaSQL*Net from d 123,793 146.9 1.6
bytes sent viaSQL*Net to client 25,187,619 29,878.6 333.1
bytes sent viaSQL*Net to dblink 76,754 91.1 1.0
calls to getsnapshot scn: kcmgss 1,533,555 1,819.2 20.3
calls to kcmgas 149,646 177.5 2.0
calls to kcmgcs 10,190 12.1 0.1
change writetime 762 0.9 0.0
cleanout - number ofktugct calls 13,095 15.5 0.2
cluster key scanblock gets 424 0.5 0.0
cluster keyscans 202 0.2 0.0
commit cleanoutfailures: block l 1 0.0 0.0
commit cleanoutfailures: buffer 18 0.0 0.0
commit cleanoutfailures: callbac 63 0.1 0.0
commit cleanoutfailures: cannot 2,087 2.5 0.0
commit cleanouts 643,505 763.4 8.5
commit cleanoutssuccessfully com 641,336 760.8 8.5
commit txn countduring cleanout 35,188 41.7 0.5
consistent changes 63,943 75.9 0.9
consistentgets 16,616,758 19,711.5 219.8
由consistent gets，dbblock gets和physical reads，我们也可以计算得到buffer hit ratio，计算的公式如下： buffer hit ratio =100*(1-physical reads /(consistent gets+ db block gets))，例如在这里，我们可以计算得到：buffer hit ratio = 99.86
consistent gets -examination 1,168,584 1,386.2 15.5
current blocksconverted for CR 0 0.0 0.0
cursor authentications 2 0.0 0.0
data blocksconsistent reads - un 63,873 75.8 0.8
db blockchanges 2,596,938 3,080.6 34.4
db block gets 2,941,398 3,489.2 38.9
deferred (CURRENT)block cleanout 130,783 155.1 1.7
dirtybuffers inspected 166 0.2 0.0
dirty buffers inspected: This is thenumber of dirty (modified) data buffers that were aged out on the LRU list. Avalue here indicates that the DBWR is not keeping up. You may benefit by addingmore DBWRs.If it is greater than 0, consider increasing the database writes.
enqueue conversions 485 0.6 0.0
enqueuedeadlocks 0 0.0 0.0
enqueue releases 318,825 378.2 4.2
enqueue requests 318,825 378.2 4.2
enqueuetimeouts 0 0.0 0.0
Instance Activity Statsfor DB: ORA92 Instance: ora92 Snaps: 13 -14
Statistic Total per Second per Trans
--------------------------------------------------- -------------- ------------
enqueue waits 728 0.9 0.0
exchange deadlocks 30 0.0 0.0
execute count 1,004,280 1,191.3 13.3
freebuffer inspected 188 0.2 0.0
这个值包含dirty，pinned，busy的buffer区域，如果freebuffer inspected - dirty buffers inspected - buffer is pinned count的值还是比较大，表明不能被重用的内存块比较多，这将导致latch争用，需要增大buffer cache。
free bufferrequested 116,422 138.1 1.5
hot buffers moved tohead of LRU 17,750 21.1 0.2
immediate (CR) blockcleanout app 1,916 2.3 0.0
immediate (CURRENT)block cleanou 81,385 96.5 1.1
index fast fullscans (full) 0 0.0 0.0
index fetch bykey 335,907 398.5 4.4
index scanskdiixs1 692,053 820.9 9.2
leaf node 90-10splits 418 0.5 0.0
leaf nodesplits 1,941 2.3 0.0
logons cumulative 716 0.9 0.0
messages received 67,830 80.5 0.9
messages sent 67,830 80.5 0.9
no buffer to keeppinned count 0 0.0 0.0
no work - consistentread gets 14,240,381 16,892.5 188.4
opened cursorscumulative 84,306 100.0 1.1
parsecount (failures) 6,074 7.2 0.1
parsecount (hard) 6,090 7.2 0.1
parsecount (total) 191,531 227.2 2.5
parse time cpu 44 0.1 0.0
parse timeelapsed 635 0.8 0.0
physical reads 26,524 31.5 0.4
physical readsdirect 288 0.3 0.0
physical writes 87,993 104.4 1.2
physical writesdirect 128 0.2 0.0
physical writes noncheckpoint 29,010 34.4 0.4
pinned buffersinspected 0 0.0 0.0
prefetch clients -default 0 0.0 0.0
prefetchedblocks 16,550 19.6 0.2
prefetched blocksaged out before 0 0.0 0.0
process lastnon-idle time 0 0.0 0.0
recursive calls 1,398,277 1,658.7 18.5
recursive cpuusage 27,349 32.4 0.4
redo blockswritten 749,639 889.3 9.9
redo bufferallocation retries 13 0.0 0.0
redo entries 1,343,828 1,594.1 17.8
redo log spacerequests 19 0.0 0.0
redo log space waittime 38 0.1 0.0
redo orderingmarks 0 0.0 0.0
redo size 355,818,888 422,086.5 4,706.2
redo synch time 10,483 12.4 0.1
redo synchwrites 74,372 88.2 1.0
redo wastage 15,765,096 18,701.2 208.5
redo write time 6,171 7.3 0.1
redo writer latchingtime 3 0.0 0.0
redo writes 67,055 79.5 0.9
rollback changes -undo records a 250 0.3 0.0
rows fetched viacallback 310,070 367.8 4.1
session connecttime 0 0.0 0.0
session cursor cachecount 1,818 2.2 0.0
session cursor cachehits 168,798 200.2 2.2
session logicalreads 19,558,052 23,200.5 258.7
session pgamemory 549,909,680 652,324.7 7,273.4
Instance ActivityStats for DB: ORA92 Instance: ora92 Snaps: 13 -14
Statistic Total per Second per Trans
--------------------------------------------------- -------------- ------------
session pga memorymax 1,185,992,768 1,406,871.6 15,686.5
session ugamemory 3,015,076,014,672############## ############
session uga memorymax 175,484,416 208,166.6 2,321.0
shared hash latchupgrades - no w 675,962 801.9 8.9
shared hash latchupgrades - wait 3,460 4.1 0.1
sorts (disks) 0 0 0
磁盘排序一般不能超过5％。如果超过5％，需要设置参数PGA_AGGREGATE_TARGET或者 SORT_AREA_SIZE，注意，这里SORT_AREA_SIZE是分配给每个用户的，PGA_AGGREGATE_TARGET则是针对所有的session的一个总数设置。
sorts (memory) 180,293 213.9 2.4
内存中的排序数量
sorts (rows) 511,574 606.9 6.8
所有排序的总行数
summed dirty queuelength 430 0.5 0.0
switch current tonew buffer 59,534 70.6 0.8
table fetch byrowid 2,094,274 2,484.3 27.7
这是通过索引或者where rowid=语句来取得的行数，当然这个值越大越好。
table fetchcontinued row 408 0.5 0.0
这是发生行迁移的行。
table scan blocksgotten 299,249 355.0 4.0
table scan rowsgotten 1,912,851 2,269.1 25.3
table scans (longtables) 0 0.0 0.0
longtables就是表的大小超过buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一个数据库的大表扫描过多，那么db file scattered read等待事件可能同样非常显著。如果tablescans (long tables)的per Trans值大于0，你可能需要增加适当的索引来优化你的SQL语句。
table scans (shorttables) 143,830 170.6 1.9
short tables是指表的长度低于buffer chache 2％（2％是有隐含参数_SMALL_TABLE_THRESHOLD定义的，这个参数在oracle不同的版本中，有不同的含义。在9i和10g中，该参数值为2％，在8i中，该参数值为20个blocks，在v7中，该参数为5个blocks）的表。这些表将优先使用全表扫描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的计算方法如下（9i,8K）： (db_cache_size/8192)*2％。
注意：_SMALL_TABLE_THRESHOLD参数修改是相当危险的操作。
transactionrollbacks 70 0.1 0.0
transaction tablesconsistent rea 0 0.0 0.0
transaction tablesconsistent rea 0 0.0 0.0
user calls 345,054 409.3 4.6
user commits 75,587 89.7 1.0
user rollbacks 19 0.0 0.0
workarea executions- optimal 247,121 293.1 3.3
write clones createdin backgroun 0 0.0 0.0
write clones createdin foregroun 25 0.0 0.0
-------------------------------------------------------------
Tablespace IO Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
->ordered by IOs(Reads + Writes) desc
下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。
在这里主要关注Av Rd(ms)列(reads per millisecond)的值，一般来说，大部分的磁盘系统的这个值都能调整到14ms以下，oracle认为该值超过20ms都是不必要的。如果该值超过1000ms，基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######，可能是你的系统存在严重的I/O问题，也可能是格式的显示问题。
当出现上面的问题，我们可以考虑以下的方法：
1）优化操作该表空间或者文件的相关的语句。
2）如果该表空间包含了索引，可以考虑压缩索引，是索引的分布空间减小，从而减小I/O。
3）将该表空间分散在多个逻辑卷中，平衡I/O的负载。
4）我们可以通过设置参数DB_FILE_MULTIBLOCK_READ_COUNT来调整读取的并行度，这将提高全表扫描的效率。但是也会带来一个问题，就是oracle会因此更多的使用全表扫描而放弃某些索引的使用。为解决这个问题，我们需要设置另外一个参数OPTIMIZER_INDEX_COST_ADJ=30（一般建议设置10－50）。
关于OPTIMIZER_INDEX_COST_ADJ＝n：该参数是一个百分比值，缺省值为100，可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST<FULL SCAN COST时，oracle会选择使用索引。在具体设置的时候，我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引，而实际它确走全表扫描，可以对比这两种情况的执行计划不同的COST，从而设置一个更合适的值。
5）检查并调整I/O设备的性能。
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------------- ------- ------------ -------- ---------- ------
ICD_DXH_IDX
3,869 5 8.6 1.0 36,701 44 1,180 0.1
ICD_DXH_DAT
2,572 3 9.7 1.0 16,545 20 1,076 0.2
UNDOTBS1
16 0 86.9 1.0 19,084 23 283 0.0
ICD_DXH_HISIDX
689 1 30.8 1.0 14,953 18 108 0.0
ICD_DXH_HISDAT
2,756 3 7.9 7.3 1,082 1 3 0.0
PERFSTAT
215 0 6.0 1.0 193 0 0 0.0
SYSTEM
55 0 11.5 5.0 17 0 717 0.1
INDX
1 0 40.0 1.0 1 0 0 0.0
TOOLS
1 0 40.0 1.0 1 0 0 0.0
USERS
1 0 40.0 1.0 1 0 0 0.0
-------------------------------------------------------------
File IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14
->ordered byTablespace, File
Tablespace Filename
----------------------------------------------------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
--------------------- ------ ------- ------------ -------- ---------- ------
ICD_DXH_DAT /dev/rlv_data001
377 0 9.4 1.0 1,640 2 321 0.2
/dev/rlv_data002
327 0 9.0 1.0 1,630 2 169 0.0
/dev/rlv_data003
313 0 10.0 1.0 1,718 2 87 0.0
/dev/rlv_data004
357 0 9.9 1.0 1,661 2 86 0.0
/dev/rlv_data005
400 0 11.5 1.0 1,627 2 128 0.2
/dev/rlv_data006
389 0 8.5 1.0 6,700 8 126 0.0
/dev/rlv_data007
409 0 9.6 1.0 1,569 2 159 0.7
ICD_DXH_HISDAT /dev/rlv_data021
164 0 6.4 7.8 2 0 0
/dev/rlv_data022
164 0 4.8 7.8 2 0 0
/dev/rlv_data023
164 0 4.6 7.8 2 0 0
/dev/rlv_data024
164 0 5.0 7.8 2 0 0
/dev/rlv_data025
164 0 4.9 7.8 2 0 0
/dev/rlv_data026
164 0 4.8 7.8 2 0 0
/dev/rlv_data027
164 0 4.9 7.8 2 0 0
/dev/rlv_data028
164 0 4.8 7.8 110 0 0
/dev/rlv_data029
164 0 6.6 7.8 92 0 0
/dev/rlv_data030
164 0 4.7 7.8 2 0 0
/dev/rlv_data031
164 0 4.9 7.8 2 0 0
/dev/rlv_data032
164 0 4.6 7.8 2 0 0
/dev/rlv_data033
4 0 110.0 1.0 221 0 0
/dev/rlv_data034
5 0 88.0 1.0 2 0 0
/dev/rlv_data035
7 0 64.3 1.0 300 0 3 0.0
/dev/rlv_data036
164 0 4.9 7.8 55 0 0
/dev/rlv_data037
5 0 90.0 1.0 1 0 0
/dev/rlv_data038
5 0 90.0 1.0 109 0 0
/dev/rlv_data039
…
-------------------------------------------------------------
Buffer Pool Statistics for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> Standard blocksize Pools D: default, K: keep, R: recycle
-> Default Poolsfor other block sizes: 2k, 4k, 8k, 16k, 32k
这里将buffer poll细分，列举default、keep、recycle三种类型的buffer的详细情况。
Free Write Buffer
Number of Cache Buffer Physical Physical Buffer Complete Busy
P Buffers Hit % Gets Reads Writes Waits Waits Waits
--- ---------- ---------------- ----------- ---------- ------- -------- ------
D 635,200 99.9 19,556,815 26,990 88,450 0 0 3,368
-------------------------------------------------------------
Instance Recovery Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> B: Beginsnapshot, E: End snapshot
Targt Estd LogFile Log Ckpt Log Ckpt
MTTR MTTR Recovery Actual Target Size Timeout Interval
(s) (s) Estd IOs Redo Blks Redo Blks Redo Blks Redo Blks Redo Blks
- ----- --------------- ---------- ---------- ---------- ---------- ----------
B 300 70 54311 452198 450720 450720 1224858
E 300 69 53127 452947 450720 450720 1472619
-------------------------------------------------------------
Buffer Pool Advisory for DB:ORA92 Instance: ora92 End Snap: 14
-> Only rows withestimated physical reads >0 are displayed
-> ordered byBlock Size, Buffers For Estimate (default block size first)
Size for Size Buffers for Est Physical Estimated
P Estimate (M) Factr Estimate Read Factor Physical Reads
--- ----------------- ---------------- ------------- ------------------
D 512 .1 63,520 9.85 245,880,558
D 1,024 .2 127,040 5.41 134,932,093
D 1,536 .3 190,560 3.38 84,471,707
D 2,048 .4 254,080 2.41 60,240,471
D 2,560 .5 317,600 1.86 46,399,611
D 3,072 .6 381,120 1.54 38,365,243
D 3,584 .7 444,640 1.32 33,017,978
D 4,096 .8 508,160 1.18 29,353,901
D 4,608 .9 571,680 1.07 26,763,133
D 5,120 1.0 635,200 1.00 24,962,078
D 5,632 1.1 698,720 0.95 23,661,399
D 6,144 1.2 762,240 0.91 22,672,122
D 6,656 1.3 825,760 0.88 21,902,502
D 7,168 1.4 889,280 0.85 21,277,585
D 7,680 1.5 952,800 0.83 20,755,944
D 8,192 1.6 1,016,320 0.81 20,331,009
D 8,704 1.7 1,079,840 0.80 19,949,127
D 9,216 1.8 1,143,360 0.78 19,563,065
D 9,728 1.9 1,206,880 0.77 19,226,351
D 10,240 2.0 1,270,400 0.76 18,948,622
-------------------------------------------------------------
这是oracle的对buffer的大小设置建议。从advisory的数据看，当然buffer是越大，物理读更小，随着buffer的增大，对物理读的性能改进越来越小。当前buffer 设置为5,120M。
Buffer waitStatistics for DB: ORA92 Instance:ora92 Snaps: 13 -14
-> ordered bywait time desc, waits desc
Tot Wait Avg
Class Waits Time (s) Time (ms)
----------------------------- ---------- ---------
data block 3,086 0 0
undo block 196 0 0
undo header 87 0 0
1st level bmb 3 0 0
2nd level bmb 1 0 0
这里的buffer等待往往带来datablock的比较大的等待。
-------------------------------------------------------------
PGA Aggr Target Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> B: Beginsnap E: End snap (rows dentified with Bor E contain data
which is absolute i.e. not diffed over theinterval)
-> PGA cache hit% - percentage of W/A (WorkArea) data processed only in-memory
-> Auto PGATarget - actual workarea memory target
-> W/A PGAUsed - amount of memory used for allWorkareas (manual + auto)
-> %PGA W/AMem - percentage of PGA memoryallocated to workareas
-> %Auto W/AMem - percentage of workarea memorycontrolled by Auto Mem Mgmt
-> %Man W/AMem - percentage of workarea memoryunder manual control
PGA Cache Hit % W/A MB Processed Extra W/A MBRead/Written
------------------------------- -------------------------
100.0 2,421 0
这一部分主要展现的是PGA使用的情况，我们可以根据具体的情况通过设置参数PGA_AGGREGATE_TARGET来调整PGA的值。
%PGA %Auto %Man
PGA Aggr Auto PGA PGA Mem W/A PGA W/A W/A W/A Global Mem
Target(M) Target(M) Alloc(M) Used(M) Mem Mem Mem Bound(K)
- ------------------ ---------- ---------- ------ ------ ------ ----------
B 500 354 216.3 0.0 .0 .0 .0 25,600
E 500 355 214.4 0.0 .0 .0 .0 25,600
-------------------------------------------------------------
PGA Aggr TargetHistogram for DB: ORA92 Instance:ora92 Snaps: 13 -14
-> OptimalExecutions are purely in-memory operations
Low High
Optimal Optimal Total Execs Optimal Execs 1-Pass ExecsM-Pass Execs
------- --------------------- ------------- ------------ ------------
8K 16K 246,058 246,058 0 0
16K 32K 104 104 0 0
32K 64K 1 1 0 0
64K 128K 3 3 0 0
128K 256K 2 2 0 0
256K 512K 2 2 0 0
512K 1024K 1 1 0 0
2M 4M 4 4 0 0
-------------------------------------------------------------
PGA Memory Advisory for DB: ORA92 Instance: ora92 End Snap: 14
-> When usingAuto Memory Mgmt, minimally choose a pga_aggregate_target value
where Estd PGA Overalloc Count is 0
EstdExtra Estd PGA Estd PGA
PGA Target Size W/A MB W/A MB Read/ Cache Overalloc
Est (MB) Factr Processed Written toDisk Hit % Count
---------- ----------------------- ---------------- -------- ----------
63 0.1 4,398,132.4 17,448.1 100.0 34,943
125 0.3 4,398,132.4 4,267.6 100.0 47
250 0.5 4,398,132.4 435.8 100.0 0
375 0.8 4,398,132.4 382.9 100.0 0
500 1.0 4,398,132.4 0.0 100.0 0
600 1.2 4,398,132.4 0.0 100.0 0
700 1.4 4,398,132.4 0.0 100.0 0
800 1.6 4,398,132.4 0.0 100.0 0
900 1.8 4,398,132.4 0.0 100.0 0
1,000 2.0 4,398,132.4 0.0 100.0 0
1,500 3.0 4,398,132.4 0.0 100.0 0
2,000 4.0 4,398,132.4 0.0 100.0 0
3,000 6.0 4,398,132.4 0.0 100.0 0
4,000 8.0 4,398,132.4 0.0 100.0 0
-------------------------------------------------------------
Enqueue activity for DB:ORA92 Instance: ora92 Snaps: 13 -14
-> Enqueue statsgathered prior to 9i should not be compared with 9i data
-> ordered byWait Time desc, Waits desc
关于Enqueue，我们在等待事件里面已经作了比较详尽的描述，这里只是对等待事件的一个展开描述，分项的含义请参考在等待事件的说明。
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------------------ ----------- ----------- ------------- ------------
TX 81,127 81,263 0 674 134.32 91
SQ 2,032 2,032 0 53 .25 0
HW 107 107 0 1 2.00 0
-------------------------------------------------------------
从9i开始，回滚段一般都是自动管理的，一般情况下，这里我们不需要太重点关注。
在这里，主要关注pct waits，如果出现比较多的pct waits，那就需要增加回滚段的数量或者增大回滚段的空间。
另外，观察一下各个回滚段使用的情况，比较理想的是各个回滚段上Avg Active比较均衡。
Rollback Segment Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
->A high valuefor "Pct Waits" suggests more rollback segments may be required
->RBS stats maynot be accurate between begin and end snaps when using Auto Undo
managment, as RBS may be dynamically createdand dropped as needed
Trans Table Pct Undo Bytes
RBS No Gets Waits Written Wraps Shrinks Extends
-------------------- ------- --------------- -------- -------- --------
0 4.0 0.00 0 0 0 0
1 67,197.0 0.00 52,642,136 7 0 7
2 16,647.0 0.00 12,321,446 2 0 2
3 9,179.0 0.00 7,032,792 8 0 8
4 8,004.0 0.00 6,735,562 3 0 2
5 7,748.0 0.00 6,428,610 3 0 0
6 7,848.0 0.00 5,847,978 6 0 3
7 7,825.0 0.00 6,115,490 6 0 6
8 7,878.0 0.00 6,782,332 5 0 4
9 8,119.0 0.00 7,708,258 8 0 5
10 7,634.0 0.00 5,493,894 5 0 6
11 7,645.0 0.00 6,633,562 1 0 0
12 7,624.0 0.00 4,911,454 5 0 5
13 7,514.0 0.00 6,006,992 0 0 0
14 7,656.0 0.00 5,171,854 6 0 6
-------------------------------------------------------------
Rollback SegmentStorage for DB: ORA92 Instance:ora92 Snaps: 13 -14
->Optimal Sizeshould be larger than Avg Active
RBS No Segment Size Avg Active Optimal Size Maximum Size
--------------------- --------------- --------------- ---------------
0 385,024 59,380 385,024
1 176,283,648 6,272,394 176,283,648
2 92,397,568 3,103,770 92,397,568
3 54,648,832 1,317,711 116,514,816
4 47,308,800 1,769,136 520,216,576
5 38,920,192 3,437,158 92,397,568
6 34,725,888 3,251,782 93,446,144
7 64,086,016 2,344,243 100,786,176
8 41,017,344 3,139,717 130,146,304
9 41,017,344 1,793,144 113,369,088
10 57,794,560 1,822,037 109,174,784
11 36,823,040 838,860 36,823,040
12 50,454,528 719,518 50,454,528
13 52,551,680 429,400 52,551,680
14 45,211,648 967,324 45,211,648
-------------------------------------------------------------
Undo Segment Summary for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> Undo segmentblock stats:
-> uS - unexpiredStolen, uR - unexpired Released, uU - unexpired reUsed
-> eS -expired Stolen, eR - expired Released, eU - expired reUsed
Undo Undo Num Max Qry Max Tx Snapshot Out ofuS/uR/uU/
TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU
---- ------------------------ -------- ---------- -------- ------ -------------
1 13,853 ########## 56 1 0 0 0/0/0/0/0/0
-------------------------------------------------------------
Undo Segment Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> ordered byTime desc
Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/
End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU
------------ -------------------- ------- -------- ------- ------ -------------
14-Jul 00:28 13,853 ######## 56 1 0 0 0/0/0/0/0/0
-------------------------------------------------------------
Latch Activity for DB:ORA92 Instance: ora92 Snaps: 13 -14
->"GetRequests", "Pct Get Miss" and "Avg Slps/Miss" arestatistics for
willing-to-wait latch get requests
->"NoWaitRequests", "Pct NoWait Miss" are for no-wait latch get requests
->"PctMisses" for both should be very close to 0.0
Latch是一种低级排队机制，用于保护系统全局区(SGA)共享内存结构闩锁用于防止对内存结构的并行访问。latch是一种快速地被获取和释放的内存锁。用于防止共享内存结构被多个用户同时访问。如果latch不可用，就会记录latch free miss 。有两种类型的latch:willing to wait和（immediate）not willing to wait。
对于愿意等待类型(willing-to-wait)的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch, 然后该进程转入睡眠状态，百分之一秒之后醒来，按顺序重复以前的步骤.在8i/9i中默认值是_spin_count=2000。睡眠的时间会越来越长。
对于不愿意等待类型(not-willing-to-wait)的latch，如果该闩不能立可用的话，那么该进程就不会为获得该闩而等待。它将继续执行另一个操作。
大多数latch问题都与以下操作相关:
没有很好的是用绑定变量(library cache latch和shared pool cache)、重作生成问题(redo allocationlatch)、缓冲存储竞争问题(cache buffers LRU chain)，以及buffer cache中的存在"热点"块(cache buffers chain)。
另外也有一些latch等待与bug有关，应当关注Metalink相关bug的公布及补丁的发布。
当latch miss ratios大于0.5%时，就需要检查latch的等待问题。
如果SQL语句不能调整，在8.1.6版本以上，Oracle提供了一个新的初始化参数: CURSOR_SHARING可以通过设置CURSOR_SHARING = force在服务器端强制绑定变量。设置该参数可能会带来一定的副作用，对于Java的程序，有相关的bug，具体应用应该关注Metalink的bug公告。
下面对几个重要类型的latch等待加以说明：
1) latch free：当‘latch free’在报告的高等待事件中出现时，就表示可能出现了性能问题，就需要在这一部分详细分析出现等待的具体的latch的类型，然后再调整。
2) cache buffers chain：cbc latch表明热块。为什么这会表示存在热块？为了理解这个问题，cbc的作用。首先我们需要理解，ORACLE对buffer cache管理是以hash链表的方式来实现的（oracle称为buckets，buckets的数量由_db_block_hash_buckets定义）。cbc latch就是为了保护buffer cache而设置的。当有并发的访问需求时，cbc会将这些访问串行化，当我们获得cbc latch的控制权时，就可以开始访问数据，如果我们所请求的数据正好的某个buckets中，那就直接从内存中读取数据，完成之后释放cbc latch，cbc latch就可以被其他的用户获取了，cbc latch获取和释放是非常快速的，所以这种情况下就不会存在等待。但是如果我们请求的数据在内存中不存在，就需要到物理磁盘上读取数据，这相对于latch来说就是一个相当长的时间了，当找到对应的数据块时，如果有其他用户正在访问这个数据块，并且数据块上也没有空闲的ITL槽来接收本次请求，就必须等待。在这过程中，我们因为没有得到请求的数据，就一直占有cbclatch，其他的用户也就无法获取cbc latch，所以就出现了cbc latch等待的情况。所以这种等待归根结底就是由于数据块比较hot的造成的。
3) cache buffers lru chain：该latch用于扫描buffer的LRU链表。三种情况可导致争用：1）buffercache太小 ；2）buffer cache的过度使用，或者太多的基于cache的排序操作；3）DBWR不及时。解决方法：查找逻辑读过高的statement，增大buffer cache。
4) Library cache and shared pool 争用：
library cache是一个hash table，我们需要通过一个hash buckets数组来访问（类似buffer cache）。library cache latch就是将对library cache的访问串行化。当有一个sql（或者PL/SQL procedure，package，function，trigger）需要执行的时候，首先需要获取一个latch，然后library cache latch就会去查询library cache以重用这些语句。在8i中，library cache latch只有一个。在9i中，有7个child latch，这个数量可以通过参数_KGL_LATCH_ COUNT修改（最大可以达到66个）。当共享池太小或者语句的reuse低的时候，会出现‘shared pool,’ ‘library cachepin,’ or ‘library cache’ latch的争用。解决的方法是：增大共享池或者设置CURSOR_SHARING=FORCE|SIMILAR，当然我们也需要tuning SQL statement。为减少争用，我们也可以把一些比较大的SQL或者过程利用DBMS_SHARED_POOL.KEEP包来pinning在shared pool中。
shared pool内存结构与buffer cache类似，也采用的是hash方式来管理的。共享池有一个固定数量的hash buckets，通过固定数量的library cache latch来串行化保护这段内存的使用。在数据启动的时候，会分配509个hash buctets，2*CPU_COUNT个library cache latch。当在数据库的使用中，共享池中的对象越来越多，oracle就会以以下的递增方式增加hash buckets的数量：509,1021,4093,8191,32749,65521,131071,4292967293。我们可以通过设置下面的参数来实现_KGL_BUCKET_COUNT，参数的默认值是0，代表数量509，最大我们可以设置为8，代表数量131071。
我们可以通过x$ksmsp来查看具体的共享池内存段情况，主要关注下面几个字段：
KSMCHCOM—表示内存段的类型
ksmchptr—表示内存段的物理地址
ksmchsiz—表示内存段的大小
ksmchcls—表示内存段的分类。recr表示arecreatable piece currently in use that can be a candidate for flushing whenthe shared pool is low in available memory; freeabl表示当前正在使用的，能够被释放的段； free表示空闲的未分配的段； perm表示不能被释放永久分配段。
降低共享池的latch 争用，我们主要可以考虑如下的几个事件：
1、使用绑定变量
2、使用cursor sharing
3、设置session_cached_cursors参数。该参数的作用是将cursor从shared pool转移到pga中。减小对共享池的争用。一般初始的值可以设置为100，然后视情况再作调整。
4、设置合适大小的共享池
5) Redo Copy：这个latch用来从PGA中copyredo records到redo log buffer。latch的初始数量是2*COU_OUNT，可以通过设置参数_LOG_SIMULTANEOUS_COPIES在增加latch的数量，减小争用。
6) Redo allocation：该latch用于redo log buffer的分配。减小这种类型的争用的方法有3个：
增大redo log buffer
适当使用nologging选项
避免不必要的commit操作
7) Row cache objects：该latch出现争用，通常表明数据字典存在争用的情况，这往往也预示着过多的依赖于公共同义词的parse。解决方法：1）增大sharedpool 2）使用本地管理的表空间，尤其对于索引表空间
| Latch事件 | 建议解决方法 |
| Library cache | 使用绑定变量; 调整shared_pool_size. |
| Shared pool | 使用绑定变量; 调整shared_pool_size. |
| Redo allocation | 减小 redo 的产生； 避免不必要的commits. |
| Redo copy | 增加 _log_simultaneous_copies. |
| Row cache objects | 增加shared_pool_size |
| Cache buffers chain | 增大 _DB_BLOCK_HASH_BUCKETS ； make it prime. |
| Cache buffers LRU chain | 使用多个缓冲池；调整引起大量逻辑读的查询 |
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
-------------------------------------- ------ ------ ------ ------------ ------
Consistent RBA 67,061 0.0 0 0
FIB s.o chainlatch 4 0.0 0 0
FOB s.o listlatch 240 0.0 0 0
SQL memory managerlatch 1 0.0 0 281 0.0
SQL memory managerworka 296,916 0.0 0.0 0 0
active checkpointqueue 1,340 0.0 0 0
cache bufferhandles 2,980 0.0 0.0 0 0
cache bufferschains 44,382,255 5.4 0.0 0 93,328 0.0
cache buffers lruchain 148,064 0.0 0.0 0 131,731 0.0
channel handle poollatc 30 0.0 0 0
channel operationsparen 627 0.0 0 0
checkpoint queuelatch 463,732 0.0 0.0 0 85,528 0.0
child cursor hashtable 36,633 0.0 0 0
dml lockallocation 450,770 1.0 0.0 0 0
dummyallocation 1,434 1.1 0.0 0 0
enqueue hashchains 638,884 0.3 0.0 0 0
enqueues 233,476 0.2 0.0 0 0
event grouplatch 14 0.0 0 0
global tx hashmapping 264 0.0 0 0
hash table columnusage 5 0.0 0 14 0.0
job workq parentlatch 0 0 1,191 8.6
job_queue_processespara 182 0.0 0 0
ktm global data 3 0.0 0 0
kwqit: protectwakeup ti 27 0.0 0 0
lgwr LWN SCN 67,123 0.0 0.0 0 0
library cache 4,755,237 1.1 0.0 0 0
library cache load lock 274 0.0 0 0
library cachepin 3,867,684 0.2 0.0 0 0
library cache pinalloca 470,588 0.3 0.0 0 0
list of blockallocation 19,378 0.0 0 0
loader state objectfree 84 0.0 0 0
longop free listparent 1 0.0 0 0
messages 212,197 0.1 0.0 0 0
mostly latch-freeSCN 67,390 0.0 0.0 0 0
multiblock readobjects 4,601 0.0 0 0
ncodef allocationlatch 14 0.0 0 0
object statsmodificatio 25 0.0 0 0
post/wait queue 128,656 0.0 0.0 0 74,194 0.2
processallocation 14 0.0 0 14 0.0
process groupcreation 30 0.0 0 0
redo allocation 1,477,895 0.2 0.0 0 0
redo copy 0 0 1,344,659 0.1
redo writing 203,129 0.0 0.0 0 0
row cache enqueuelatch 21,995 0.1 0.0 0 0
row cacheobjects 30,913 1.9 0.0 0 0
sequence cache 122,787 0.3 0.0 0 0
sessionallocation 499,051 0.4 0.0 0 0
session idlebit 901,267 0.0 0.0 0 0
sessionswitching 14 0.0 0 0
session timer 291 0.0 0 0
Latch Activity forDB: ORA92 Instance: ora92 Snaps: 13 -14
->"GetRequests", "Pct Get Miss" and "Avg Slps/Miss" arestatistics for
willing-to-wait latch get requests
->"NoWaitRequests", "Pct NoWait Miss" are for no-wait latch get requests
->"PctMisses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
-------------------------------------- ------ ------ ------ ------------ ------
shared pool 2,819,295 0.1 0.0 0 0
sim partitionlatch 0 0 252 0.0
simulator hash latch 1,046,772 0.0 0.0 0 0
simulator lrulatch 596 0.0 0 15,390 5.7
sort extentpool 17 0.0 0 0
spilled msgs queueslist 27 0.0 0 0
transactionallocation 3,207 0.4 0.0 0 0
transaction branchalloc 62 0.0 0 0
undo globaldata 286,249 0.1 0.0 0 0
user lock 1,432 0.6 0.0 0 0
-------------------------------------------------------------
Latch Sleep breakdown for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> ordered bymisses desc
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
---------------------------------------- ----------- ----------- ------------
cache bufferschains 44,382,255 2,408,704 1,302 0/0/0/0/0
library cache 4,755,237 51,183 5 51178/5/0/0/
0
sessionallocation 499,051 2,050 1 2049/1/0/0/0
-------------------------------------------------------------
Latch Miss Sources for DB: ORA92 Instance: ora92 Snaps: 13 -14
-> only latcheswith sleeps are shown
-> ordered byname, sleeps desc
NoWait Waiter
Latch Name Where Misses Sleeps Sleeps
-------------------------------------------------- ------- ---------- --------
cache bufferschains kcbgtcr: kslbegin excl 0 859 741
cache bufferschains kcbchg: kslbegin: bufsnot 0 217 139
cache bufferschains kcbgcur: kslbegin 0 135 130
cache bufferschains kcbrls: kslbegin 0 58 188
cache bufferschains kcbgtcr: fast path 0 11 3
cache bufferschains kcbbic2 0 3 0
cache bufferschains kcbnlc 0 3 3
cache buffers chains kcbget: pin buffer 0 3 1
cache bufferschains kcbget: exchange rls 0 3 2
cache bufferschains kcbchg: kslbegin: call CR 0 3 70
cache bufferschains kcbzwb 0 1 0
library cache kglpnc: child 0 3 2
library cache kglic 0 1 0
library cache kglupc: child 0 1 0
sessionallocation ksuxds: not usersession 0 1 0
-------------------------------------------------------------
Dictionary Cache Stats for DB:ORA92 Instance: ora92 Snaps: 13 -14
->"Pct Misses" should be very low (< 2% in most cases)
->"CacheUsage" is the number of cache entries being used
->"PctSGA" is the ratio of usage toallocated size for that cache
Get Pct Scan Pct Mod Final
Cache Requests Miss Reqs Miss Reqs Usage
------------------------------------- ------ ------- ----- -------- ----------
dc_database_links 528 0.0 0 0 2
dc_histogram_defs 22 86.4 0 0 4,295
dc_object_ids 69 29.0 0 0 403
dc_objects 233 36.1 0 0 895
dc_profiles 705 0.0 0 0 1
dc_rollback_segments 3,911 0.0 0 0 233
dc_segments 187 1.1 0 12 5,778
dc_sequences 1,978 0.0 0 1,978 9
dc_tablespace_quotas 12 0.0 0 12 4
dc_tablespaces 458 0.0 0 0 11
dc_user_grants 120 0.0 0 0 18
dc_usernames 56 0.0 0 0 12
dc_users 3,674 0.0 0 0 20
-------------------------------------------------------------
Library Cache Activity for DB:ORA92 Instance: ora92 Snaps: 13 -14
->"PctMisses" should be very low
/* 库缓存详细信息
pct miss应该不高于1％
Reloads /pin requests <1％，否则应该考虑增大SHARED_POOL_SIZE。
pin requests： 缓存中的执行的时间.
reloads：在执行阶段发生library cache misses导致重新载入.
invalidations：相关的对象被修改，导致对象无效 .
If the PINHITRATIO is less than 0.95 when the report isrun for an extended period of time, the SHARED_POOL_SIZE is probably too smallfor your best system performance. If the reloads are greater than 1 percent,this also points to a SHARED_POOL_SIZE that is too small
注：这里的几个概念不是很清楚，另外重载率和PINHITRATIO的计算方法也不明确，需要确认。
Get Pct Pin Pct Invali-
Namespace Requests Miss Requests Miss Reloads dations
--------------------------- ------ -------------- ------ ---------- --------
BODY 1,699 0.0 1,699 0.0 0 0
INDEX 54 0.0 54 0.0 0 0
SQL AREA 5,665 0.0 1,497,193 0.4 6,086 0
TABLE/PROCEDURE 92,424 0.1 429,557 0.1 0 0
TRIGGER 1,412 0.0 1,412 0.0 0 0
-------------------------------------------------------------
Shared Pool Advisory for DB: ORA92 Instance: ora92 End Snap: 14
-> Note there isoften a 1:Many correlation between a single logical object
in the Library Cache, and the physicalnumber of memory objects associated
with it. Therefore comparing the number of Lib Cache objects (e.g. in
v$librarycache), with the number of LibCache Memory Objects is invalid
Estd
Shared Pool SP Estd Estd Estd Lib LC Time
Sizefor Size Lib Cache Lib Cache Cache Time Saved Estd Lib Cache
Estim (M) Factr Size (M) Mem Obj Saved (s) Factr Mem Obj Hits
----------- --------------- ------------ ------------ ------- ---------------
224 .5 97 55,129 10,514,328 1.0 807,719,425
272 .7 112 68,387 10,514,329 1.0 807,719,480
320 .8 113 68,787 10,514,329 1.0 807,719,485
368 .9 113 68,787 10,514,329 1.0 807,719,485
416 1.0 113 68,787 10,514,329 1.0 807,719,485
464 1.1 113 68,787 10,514,329 1.0 807,719,485
512 1.2 113 68,787 10,514,329 1.0 807,719,485
560 1.3 113 68,787 10,514,329 1.0 807,719,485
608 1.5 113 68,787 10,514,329 1.0 807,719,485
656 1.6 113 68,787 10,514,329 1.0 807,719,485
704 1.7 113 68,787 10,514,329 1.0 807,719,485
752 1.8 113 68,787 10,514,329 1.0 807,719,485
800 1.9 113 68,787 10,514,329 1.0 807,719,485
848 2.0 113 68,787 10,514,329 1.0 807,719,485
-------------------------------------------------------------
SGA Memory Summary for DB:ORA92 Instance: ora92 Snaps: 13 -14
SGA regions Size in Bytes
----------------------------------------------
DatabaseBuffers 5,368,709,120
Fixed Size 754,760
Redo Buffers 2,371,584
Variable Size 3,137,339,392
----------------
sum 8,509,174,856
-------------------------------------------------------------
SGA breakdown difference for DB: ORA92 Instance: ora92 Snaps: 13 -14
Pool Name Begin value End value % Diff
------------------------------------ ---------------- ---------------- -------
java free memory 33,554,432 33,554,432 0.00
large free memory 16,777,216 16,777,216 0.00
shared 1M buffer 1,056,768 1,056,768 0.00
shared Checkpointqueue 4,106,240 4,106,240 0.00
shared DML lock 944,208 944,208 0.00
sharedFileIdentificatonBlock 224,960 224,960 0.00
sharedFileOpenBlock 7,517,528 7,517,528 0.00
shared KGK heap 7,000 7,000 0.00
shared KGLSheap 2,107,496 2,181,456 3.51
shared KQR L PO 1,238,072 1,329,208 7.36
shared KQR M PO 5,342,976 5,353,728 0.20
shared KQR S SO 4,616 4,616 0.00
shared KQR X PO 5,152 5,152 0.00
shared KSXR pendingmessages que 853,952 853,952 0.00
shared KSXR receivebuffers 1,034,000 1,034,000 0.00
shared MTTRadvisory 930,024 930,024 0.00
shared PL/SQLDIANA 1,344,784 1,344,784 0.00
shared PL/SQLMPCODE 1,265,048 1,265,048 0.00
shared PL/SQLPPCODE 397,192 397,192 0.00
shared PL/SQLSOURCE 45,896 45,896 0.00
shared PLS non-libhp 2,088 2,088 0.00
shared PXsubheap 25,976 25,976 0.00
shared TemporaryTables State Ob 262,408 262,408 0.00
shared UNDO INFOSEGMENTED ARRAY 216,784 216,784 0.00
shared branch 394,400 394,400 0.00
shared channelhandle 260,392 260,392 0.00
shared character setobject 387,200 387,200 0.00
sharedconstraints 275,152 275,152 0.00
shareddb_block_hash_buckets 22,751,504 22,751,504 0.00
shareddb_handles 1,160,000 1,160,000 0.00
shared dictionarycache 3,229,952 3,229,952 0.00
shared enqueue 1,833,832 1,833,832 0.00
shared enqueueresources 674,480 674,480 0.00
shared errors 256,840 256,840 0.00
shared eventstatistics per sess 12,499,760 12,499,760 0.00
shared fixedallocation callback 1,176 1,176 0.00
shared freememory 337,893,784 336,596,200 -0.38
shared joxs heapinit 4,240 4,240 0.00
shared kglsim hashtable bkts 1,396,736 1,396,736 0.00
shared kglsimsga 137,544 137,544 0.00
shared krvxrr 253,056 253,056 0.00
shared ksm_file2sgaregion 370,496 370,496 0.00
shared ktlbk stateobjects 651,240 651,240 0.00
shared library cache 18,874,720 19,164,808 1.54
shared message poolfreequeue 748,880 748,880 0.00
sharedmiscellaneous 20,833,464 20,886,376 0.25
sharedparameters 61,120 61,120 0.00
shared partitioningd 2,188,008 2,188,008 0.00
sharedprocesses 1,304,000 1,304,000 0.00
shared qmpsconnections 468,520 468,520 0.00
shared replicationsession stats 335,920 335,920 0.00
shared session paramvalues 7,522,944 7,468,032 -0.73
shared sessions 2,987,920 2,987,920 0.00
shared sim memoryhea 5,316,184 5,316,184 0.00
SGA breakdown difference for DB: ORA92 Instance: ora92 Snaps: 13 -14
Pool Name Beginvalue End value % Diff
------ ---------------------------------------------- ---------------- -------
shared sim traceentries 786,432 786,432 0.00
shared sql area 24,756,248 25,586,968 3.36
shared tabledefiniti 7,720 10,648 37.93
shared tracebuffer 1,785,856 1,785,856 0.00
sharedtransaction 1,967,696 1,967,696 0.00
shared triggerdefini 3,040 3,040 0.00
shared triggerinform 1,712 1,712 0.00
shared triggersource 1,144 1,144 0.00
buffer_cache 5,368,709,120 5,368,709,120 0.00
fixed_sga 754,760 754,760 0.00
log_buffer 2,360,320 2,360,320 0.00
-------------------------------------------------------------
Resource Limit Stats for DB: ORA92 Instance: ora92 End Snap: 14
-> only rows withCurrent or Maximum Utilization > 80% of Limit are shown
-> ordered byresource name
Current Maximum Initial
Resource Name Utilization Utilization Allocation Limit
------------------------------------------ ------------ ---------- ----------
parallel_max_servers 0 5 6 6
-------------------------------------------------------------
init.ora Parameters for DB: ORA92 Instance: ora92 Snaps: 13 -14
End value
Parameter Name Begin value (if different)
-------------------------------------------------------------- --------------
aq_tm_processes 1
background_dump_dest /opt/oracle/app/oracle/admin/ora9
compatible 9.2.0.0.0
control_files /dev/rlv_ctrl1, /dev/rlv_ctrl2,/
core_dump_dest /opt/oracle/app/oracle/admin/ora9
cursor_sharing SIMILAR
db_block_size 8192
db_cache_size 5368709120
db_domain
db_file_multiblock_read_count8
db_name ora92
fast_start_mttr_target 300
hash_join_enabled TRUE
instance_name ora92
java_pool_size 33554432
job_queue_processes 10
large_pool_size 16777216
lock_sga TRUE
log_buffer 2097152
log_checkpoint_interval 0
log_checkpoint_timeout 1800
open_cursors 1000
pga_aggregate_target 524288000
pre_page_sga TRUE
processes 1000
query_rewrite_enabled FALSE
remote_login_passwordfile EXCLUSIVE
session_cached_cursors 50
sga_max_size 8509174856
shared_pool_size 419430400
sort_area_size 524288
spfile /dev/rlv_spfile
star_transformation_enabled FALSE
timed_statistics TRUE
undo_management AUTO
undo_retention 10800
undo_tablespace UNDOTBS1
user_dump_dest /opt/oracle/app/oracle/admin/ora9
workarea_size_policy AUTO
-------------------------------------------------------------
End of Report
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
