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 Std Block 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(User rollbacks / (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-memory Sort %: 100.00
Library Hit %: 99.67 Soft Parse %: 96.82
Execute to Parse %: 80.93 Latch Hit %: 96.10
Parse CPU to Parse Elapsd %: 6.93 % Non-Parse CPU: 99.88
/* 实例的有效性,这部分值越接近100越好,分项内容详细说明如下:
1) Buffer Nowait %:在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用,可以在后面的等待事件中进一步确认。
2) Redo NoWait %:在Redo缓冲区获取Buffer空间的未等待比率。当redo buffer达到1M时,就需要写到redo log文件,所以一般当redo buffer设置超过1M,不太可能存在等待buffer空间分配的情况。当前,一般设置为2M的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设置的,PGA_AGGREGATE_TARGET则时针对所有的sesion的。
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)。本例中,差不多每execution 5次需要一次parse。所以如果系统Parses > Executions,就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或者语句效率存在问题,造成反复解析,reparse可能较严重,或者是可能同snapshot有关,通常说明数据库性能存在问题。
8) Latch Hit %:要确保>99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助后面的等待时间和latch分析来查找解决问题。
9) Parse CPU to Parse Elapsd %:计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%,意味着CPU等待时间为0,没有任何等待。
10) % Non-Parse CPU:计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的CPU时间过多。与PARSE_CPU相比,如果TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的工作。
Shared Pool Statistics 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 with executions>1非常接近,除非有某些查询任务消耗的内存没有规律。在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期,执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
小结:通过ORACLE的实例有效性统计数据,我们可以获得大概的一个整体印象,然而我们并不能由此来确定数据运行的性能。当前性能问题的确定,我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容,hit统计帮助我们发现和预测一些系统将要产生的性能问题,由此我们可以做到未雨绸缪。而wait事件,就是表明当前数据库已经出现了性能问题需要解决,所以是亡羊补牢的性质。
接下来,开始查看wait事件。
/* 报表头信息,数据库实例相关信息,包括数据库名称、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 Std Block 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(User rollbacks / (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-memory Sort %: 100.00
Library Hit %: 99.67 Soft Parse %: 96.82
Execute to Parse %: 80.93 Latch Hit %: 96.10
Parse CPU to Parse Elapsd %: 6.93 % Non-Parse CPU: 99.88
/* 实例的有效性,这部分值越接近100越好,分项内容详细说明如下:
1) Buffer Nowait %:在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用,可以在后面的等待事件中进一步确认。
2) Redo NoWait %:在Redo缓冲区获取Buffer空间的未等待比率。当redo buffer达到1M时,就需要写到redo log文件,所以一般当redo buffer设置超过1M,不太可能存在等待buffer空间分配的情况。当前,一般设置为2M的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设置的,PGA_AGGREGATE_TARGET则时针对所有的sesion的。
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)。本例中,差不多每execution 5次需要一次parse。所以如果系统Parses > Executions,就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或者语句效率存在问题,造成反复解析,reparse可能较严重,或者是可能同snapshot有关,通常说明数据库性能存在问题。
8) Latch Hit %:要确保>99%,否则存在严重的性能问题。当该值出现问题的时候,我们可以借助后面的等待时间和latch分析来查找解决问题。
9) Parse CPU to Parse Elapsd %:计算公式为:Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%,意味着CPU等待时间为0,没有任何等待。
10) % Non-Parse CPU:计算公式为:% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小,表示解析消耗的CPU时间过多。与PARSE_CPU相比,如果TOT_CPU很高,这个比值将接近100%,这是很好的,说明计算机执行的大部分工作是执行查询的工作,而不是分析查询的工作。
Shared Pool Statistics 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 with executions>1非常接近,除非有某些查询任务消耗的内存没有规律。在稳定状态下,总体上会看见随着时间的推移大约有75%~85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期,执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
小结:通过ORACLE的实例有效性统计数据,我们可以获得大概的一个整体印象,然而我们并不能由此来确定数据运行的性能。当前性能问题的确定,我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容,hit统计帮助我们发现和预测一些系统将要产生的性能问题,由此我们可以做到未雨绸缪。而wait事件,就是表明当前数据库已经出现了性能问题需要解决,所以是亡羊补牢的性质。
接下来,开始查看wait事件。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24492954/viewspace-767892/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24492954/viewspace-767892/