5.首要等待事件
常见等待事件说明：
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件。
TIMED_STATISTICS：=TRUE，等待事件按等待的时间排序，= FALSE，等待事件按等待的数量排序。
运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。
空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
常见等待事件说明：
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件。
TIMED_STATISTICS：=TRUE，等待事件按等待的时间排序，= FALSE，等待事件按等待的数量排序。
运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。
空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 22,154 259 62.14
CPU time 49 11.67
log file parallel write 2,439 26 6.30
db file parallel write 400 22 5.32
SQL*Net message from dblink 4,575 15 3.71
-------------------------------------------------------------
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 22,154 259 62.14
CPU time 49 11.67
log file parallel write 2,439 26 6.30
db file parallel write 400 22 5.32
SQL*Net message from dblink 4,575 15 3.71
-------------------------------------------------------------
这里是比其他任何事件都能使速度减慢的事件。比较影响性能的常见等待事件：
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: 等待时间包括日志缓冲的写入和发送操作。
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.数据库用户程序发生的所有等待事件
Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> 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)
-> 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
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 22,154 0 259 12 886.2
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
SQL*Net message from dblink 4,575 0 15 3 183.0
SQL*Net more data from dblin 64,490 0 13 0 2,579.6
control file parallel write 416 0 5 13 16.6
db file scattered read 456 0 5 11 18.2
write complete waits 9 0 5 568 0.4
control file sequential read 370 0 5 13 14.8
log buffer space 126 0 4 34 5.0
free buffer waits 11 1 3 313 0.4
log file switch completion 13 0 2 188 0.5
log file sync 90 0 1 8 3.6
log file sequential read 10 0 0 16 0.4
latch free 17 6 0 8 0.7
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
SQL*Net more data to client 173 0 0 0 6.9
SQL*Net message to dblink 4,575 0 0 0 183.0
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
db file single write 5 0 0 0 0.2
SQL*Net break/reset to clien 5 0 0 0 0.2
async disk IO 15 0 0 0 0.6
SQL*Net message from client 789 0 3,290 4170 31.6
virtual circuit status 36 36 1,082 30069 1.4
wakeup time manager 34 34 1,034 30403 1.4
SQL*Net message to client 791 0 0 0 31.6
SQL*Net more data from clien 30 0 0 0 1.2
-------------------------------------------------------------
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 22,154 0 259 12 886.2
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
SQL*Net message from dblink 4,575 0 15 3 183.0
SQL*Net more data from dblin 64,490 0 13 0 2,579.6
control file parallel write 416 0 5 13 16.6
db file scattered read 456 0 5 11 18.2
write complete waits 9 0 5 568 0.4
control file sequential read 370 0 5 13 14.8
log buffer space 126 0 4 34 5.0
free buffer waits 11 1 3 313 0.4
log file switch completion 13 0 2 188 0.5
log file sync 90 0 1 8 3.6
log file sequential read 10 0 0 16 0.4
latch free 17 6 0 8 0.7
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
SQL*Net more data to client 173 0 0 0 6.9
SQL*Net message to dblink 4,575 0 0 0 183.0
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
db file single write 5 0 0 0 0.2
SQL*Net break/reset to clien 5 0 0 0 0.2
async disk IO 15 0 0 0 0.6
SQL*Net message from client 789 0 3,290 4170 31.6
virtual circuit status 36 36 1,082 30069 1.4
wakeup time manager 34 34 1,034 30403 1.4
SQL*Net message to client 791 0 0 0 31.6
SQL*Net more data from clien 30 0 0 0 1.2
-------------------------------------------------------------
7.数据库后台进程发生的等待事件
Background Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> ordered by wait time desc, waits desc (idle events last)
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
control file parallel write 406 0 5 13 16.2
control file sequential read 258 0 4 16 10.3
db file sequential read 19 0 1 51 0.8
log buffer space 24 0 0 9 1.0
log file sequential read 10 0 0 16 0.4
latch free 14 6 0 9 0.6
db file scattered read 6 0 0 14 0.2
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
rdbms ipc message 7,339 3,337 3,172 432 293.6
pmon timer 373 373 1,083 2903 14.9
smon timer 3 3 924 ###### 0.1
-------------------------------------------------------------
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
control file parallel write 406 0 5 13 16.2
control file sequential read 258 0 4 16 10.3
db file sequential read 19 0 1 51 0.8
log buffer space 24 0 0 9 1.0
log file sequential read 10 0 0 16 0.4
latch free 14 6 0 9 0.6
db file scattered read 6 0 0 14 0.2
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
rdbms ipc message 7,339 3,337 3,172 432 293.6
pmon timer 373 373 1,083 2903 14.9
smon timer 3 3 924 ###### 0.1
-------------------------------------------------------------
8.TOP SQL
调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询，将可对系统性能产生5%到5000%的增益。
SQL ordered by Gets for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
1,230,745 1 1,230,745.0 27.5 16.39 60.69 1574310682
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
1,230,745 1 1,230,745.0 27.5 16.39 60.69 1574310682
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151
143,702 1 143,702.0 3.2 1.75 18.66 3978122706
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1
在
报表的这一部分，通过Buffer
Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer
Gets)包括被这个代码块执行的所有SQL语句的Buffer
Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。
SQL ordered by Reads for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> End Disk Reads Threshold: 1000
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
3,587 1 3,587.0 13.9 0.17 5.13 3342983569
Module: PL/SQL Developer
select min(curtime),max(curtime) from city_day_cal
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
3,587 1 3,587.0 13.9 0.17 5.13 3342983569
Module: PL/SQL Developer
select min(curtime),max(curtime) from city_day_cal
1,575 1 1,575.0 6.1 1.75 18.66 3978122706
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1
Module: PL/SQL Developer
insert into city_day_cal select * from rptuser.city_day_cal@db151 where curtime between to_date('200501','yyyymm') and to_date('
200502','yyyymm')-1
这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。
SQL ordered by Executions for DB: BLISSDB Instance: blissdb Snaps: 4 -5
-> End Executions Threshold: 100
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
748 748 1.0 0.00 0.00 3371479671
select t.name, (select owner_instance from sys.aq$_queue_table_
affinities where table_objno = t.objno) from system.aq$_queue
_tables t where t.name = :1 and t.schema = :2 for update skip lo
cked
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
748 748 1.0 0.00 0.00 3371479671
select t.name, (select owner_instance from sys.aq$_queue_table_
affinities where table_objno = t.objno) from system.aq$_queue
_tables t where t.name = :1 and t.schema = :2 for update skip lo
cked
442 1,142 2.6 0.00 0.00 1749333492
select position#,sequence#,level#,argument,type#,charsetid,chars
etform,properties,nvl(length, 0), nvl(precision#, 0),nvl(scale,
0),nvl(radix, 0), type_owner,type_name,type_subname,type_linknam
e,pls_type from argument$ where obj#=:1 and procedure#=:2 order
by sequence# desc
select position#,sequence#,level#,argument,type#,charsetid,chars
etform,properties,nvl(length, 0), nvl(precision#, 0),nvl(scale,
0),nvl(radix, 0), type_owner,type_name,type_subname,type_linknam
e,pls_type from argument$ where obj#=:1 and procedure#=:2 order
by sequence# desc
这
部分告诉我们在这段时间中执行最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能
是很有用的。或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的
飞快，任何被执行几百万次的操作都将开始耗尽大量的时间。
[@more@]
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/18921899/viewspace-1017700/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
Statspack分析报告详解(2)
下一篇：
Statspack分析报告详解(4)
请登录后发表评论
登录
全部评论
