转【statspack】报告性能分析
===========================================================
【statspack】报告性能分析
===========================================================
作者: wyyhzc(http://wyyhzc.itpub.net)
发表于: 2005.01.05 23:55
分类: oracle
出处: http://wyyhzc.itpub.net/post/2879/12870
---------------------------------------------------------------
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
sampleDB 1510734843 samp2 2 9.2.0.5.0 YES CRM_DB2
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 15 31-Dec-04 17:21:27 1,813
1.2
End Snap: 186 07-Jan-05 19:00:06 2,640
1.1
Elapsed: 10,178.65
(mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 4,096M
Std Block Size:
8K
Shared Pool Size: 1,024M
Log Buffer:
10,000K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size:（重做大小） 60,385.02 106,343.96
Logical reads: （逻辑读） 3,222.65 5,675.40
Block changes: （块改变） 319.38 562.45
Physical reads: （物理读） 191.78 337.74
Physical writes: (物理写) 15.11 26.62
User calls: （用户下用） 6.88 12.12
Parses: （软解析） 13.51 23.80
Hard parses: （硬解析） 2.63 4.64
Sorts: （排序） 3.26 5.75
Logons: 0.01 0.02
Executes: 26.76 47.12
Transactions: 0.57
% Blocks changed per Read: （每次读时的块改变） 9.91
Recursive Call %:
92.49
Rollback per transaction %: （每一个事务的回滚） 0.34
Rows per Sort:
108.91
蓝色的部分是负载简档，他可以帮助我们识别负载和正在执行的活动类型。在这个例子中，记录的活动包括大量的逻辑和物理活动。
在负载简档中查询一下的信息：
1） 重做数据块的增加、块更新的频繁，以及每次读操作％BLOCKS的增加，这些意味着DML（插入、更新、删除）活动的增加
2） 档sql语句不是在共享池中运行，就出现硬解析。硬解析率超过100次/秒就意味着绑定变量的使用效率不高，应当使用cursor_sharing初始化参数；或者说明共享池的大小存在问题。
3） 当sql语句是在共享池中运行，就会出现软解析。软解析超过300次/秒就意味着应用程序的效率不高，语句被反复的解析，而不是对每一个只解析一次，以保证高大的效率。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.96
Redo NoWait %:
100.00
Buffer Hit %: 94.10
In-memory Sort %:
100.00
Library Hit %: 90.34
Soft Parse %:
80.51
Execute to Parse %: 49.50
Latch Hit %:
99.90
Parse CPU to Parse Elapsd %:
% Non-Parse CPU:
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 65.50 88.15
% SQL with executions>1: 14.49 19.30
% Memory for SQL w/exec>1: 35.60 53.45
粉色的数据代表实例的效率：
1） Buffer Nowait 不应该低于99%，这是一个对特定缓冲区的请求的命中率。
2） Buffer Hit 应该不低于99% 对一个对特定缓冲区的请求的命中率。并且缓存区位于内存中，而无需物理磁盘的IO操作。
3） Library Hit 应该改于 95％，较低的库缓冲区的命中率意味着sql语句被过早的推出了缓冲区（可能室缓冲区太小了，当然太大了也不行）
4） Soft Parse 不应低于95％，如果低于80％意味着sql没有被有效的重用。
5） Latch Hit 低于95％通常意味着大的大问题。
6） Memory Usage 代表有88。5％的共享池内存再用。
7） Sql with executions > 1:表示共享池sql语句只有19。30％被重用，说明应用程序内的共享游标需要进一步的提高使用效率，高效的使用绑定变量的方法。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 84,392,563 508,425 83.51
sbtbackup 195 32,926 5.41
enqueue 141,839 17,062 2.80
global cache cr request 62,292,379 14,346 2.36
db file scattered read 2,723,918 8,085 1.33
-------------------------------------------------------------
红色的代表前五个首要的等待事件（下面是一些常见的问题，这一部分是很重要的）
1） DB file scatter read：这通常意味着等待与全表扫描有关。该指数的数量过大说明缺少扫描或者限制使用索引。这种情况也可能是正常的，因为全表扫描可能比索引扫描效率更高。当你看到这些等待的时候,需要通过检查确定全表扫描是否必须的（缓存较小的表）
2） DB file sequential read：这通常是指单一的数据块读操作（例如，索引的读取）。该值过大说明表的连接顺序恨糟糕。或者使用了非选择性的索引。DB_CACHE_SIZE也是一个决定性的因素，它将决定这些等待的出现的频率；散列区域的连接引起的问题应当体现在PGA内存中，但他们会贪婪的侵占内存，直至使顺序读操作有大量的等待出现。(优化连接)
3） Buffer busy wait 当一个缓冲区以一种非共享方式被使用，或者在被读入缓存的时候，就会出现该种等待。不应该高于1％
4） Latch free：闩锁是底层的队列机制，用于保护系统的全局区（SGA）的内存结构。
5） Enqueue 入列是保护共享资源的一种锁机制.这种锁保护共享资源。例如一条记录中的数据，以防止两个人同时更新相同的数据。如果你有外键，必须要为外键建立索引，以避免常见的锁定的问题。
6） Logfile Switch 所有的提交操作均要等待日志文件切换（归档所需要的）或者日志文件切换的不完整
7） Log buffer space 增加日志缓冲区；为重做日志使用更快的磁盘
8） Log file sync 一次提交更多的记录；为撤销日志使用更快的磁盘
9） Ldle event 忽略
Cluster Statistics for DB: sampleDB Instance: samp2 Snaps: 15 -186
Global Cache Service - Workload Characteristics
-----------------------------------------------
Ave global cache get time (ms): 0.0
Ave global cache convert time (ms): 0.0
Ave build time for CR block (ms): 0.0
Ave flush time for CR block (ms): 0.0
Ave send time for CR block (ms): 0.0
Ave time to process CR block request (ms): 0.0
Ave receive time for CR block (ms): 0.0
Ave pin time for current block (ms): 0.0
Ave flush time for current block (ms): 0.0
Ave send time for current block (ms): 0.0
Ave time to process current block request (ms): 0.0
Ave receive time for current block (ms): 0.0
Global cache hit ratio: 6.5
Ratio of current block defers: 0.0
% of messages sent for buffer gets: 6.4
% of remote buffer gets: 0.3
Ratio of I/O for coherence: 1.0
Ratio of local vs remote work: 18.0
Ratio of fusion vs physical writes: 0.0
Global Enqueue Service Statistics
---------------------------------
Ave global lock get time (ms): 0.0
Ave global lock convert time (ms): 0.0
Ratio of global lock gets vs global lock releases: 1.0
GCS and GES Messaging statistics
--------------------------------
Ave message sent queue time (ms): 0.0
Ave message sent queue time on ksxp (ms): 0.0
Ave message received queue time (ms): 0.0
Ave GCS message process time (ms): 0.0
Ave GES message process time (ms): 0.0
% of direct sent messages: 37.7
% of indirect sent messages: 48.2
% of flow controlled messages: 14.1
-------------------------------------------------------------
GES Statistics for DB: sampleDB Instance: samp2 Snaps: 15 -186
Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------
dynamically allocated gcs resourc 0 0.0 0.0
dynamically allocated gcs shadows 0 0.0 0.0
flow control messages received 85 0.0 0.0
flow control messages sent 53 0.0 0.0
gcs ast xid 24 0.0 0.0
gcs blocked converts 587,212 1.0 1.7
gcs blocked cr converts 2,517,525 4.1 7.3
gcs compatible basts 129 0.0 0.0
gcs compatible cr basts (global) 69,413 0.1 0.2
gcs compatible cr basts (local) 3,496,338 5.7 10.1
gcs cr basts to PIs 0 0.0 0.0
gcs cr serve without current lock 0 0.0 0.0
gcs error msgs 0 0.0 0.0
gcs flush pi msgs 53,808 0.1 0.2
gcs forward cr to pinged instance 0 0.0 0.0
gcs immediate (compatible) conver 3,970,829 6.5 11.5
gcs immediate (null) converts 11,807,428 19.3
