常见非空闲等待事件影响性能性能优化.docx
《常见非空闲等待事件影响性能性能优化.docx》由会员分享，可在线阅读，更多相关《常见非空闲等待事件影响性能性能优化.docx（22页珍藏版）》请在冰点文库上搜索。
常见非空闲等待事件影响性能性能优化
一些常见的非空闲等待事件有:
..dbfilescatteredread
..dbfilesequentialread
..bufferbusywaits
..freebufferwaits
..enque
..latchfree
..logfileparallelwrite
..logfilesync
下面结合AWR和statspack中的一些等待事件进行讲述。
--收集整理--
Top5WaitEvents
~~~~~~~~~~~~~~~~~Wait%Total
EventWaitsTime（cs）WtTime
---------------------------------------------------------------------------dbfilescatteredread26,87712,850
52.94
dbfileparallelwrite4723,674
15.13
logfileparallelwrite9751,560
6.43
directpathwrite1,5711,543
6.36
controlfileparallelwrite6521,290
5.31
-------------------------------------------------------------
1）..dbfilescatteredread:
DB文件分散读取。
--一次读取多个块--可能fullscan这个等待事件很常见，经常在top5中出现，这表示，一次从磁盘读数据进来的时候读了多于一个block的数据，而这些数据又被分散的放在不连续的内存块中，因为一次读进来的是多于一个block的。
通常来说我们可以认为是全表扫描类型的读，因为根据索引读表数据的话一次只读一个block，如果这个数字过大，就表明该表找不到索引，或者只能找到有限的索引，可能是全表扫描过多，需要检查sql是否合理的利用了索引，或者是否需要建立合理的索引。
当全表扫描被限制在内存时，它们很少会进入连续的缓冲区内，而是分散于整个缓冲存储器中。
尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要,是否可以通过建立合适的索引来减少对于大表全表扫描所产生的大规模数据读取。
对于经常使用的小表，应该尽量把他们pin在内存中，避免不必要的老化清除及重复读取。
2）..dbfilesequentialread:
DB文件连续读取。
--一次读取一块，单块，可能表的连接顺序不好，索引使用不好。
--sql优化
通常显示单个块的读取（通常指索引读取），表示的是读进磁盘的block被放在连续的内存块中。
事实上大部分基本代表着单个block的读入，可以说象征着IO或者说通过索引读入的比较多。
因为一次IO若读进多个的block，放入连续的内存块的几率是很小的，分布在不同block的大量记录被读入就会遇到此事件。
因为根据索引读数据的话，假设100条记录，根据索引，不算索引本身的读，而根据索引每个值去读一下表数据，理论上最多可能产生100buffergets，而如果是fulltablescan，则100条数据完全可能在一个block里面，则几乎一次就读过这个block了，就会产生这么大的差异。
这种等待的数目很多时，可能显示表的连接顺序不佳，或者不加选择地进行索引。
对于高级事务处理（high-transaction）、调整良好（welltuned）的系统，这一数值很大是很正常的，但在某些情况下，它可能暗示着系统中存在问题。
你应当将这一等待统计量与Statspack报告中的已知问题（如效率较低的SQL）联系起来。
检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。
DB_CACHE_SIZE也是这些等待出现频率的决定因素。
有问题的散列区域（Hash-area）连接应当出现在PGA内存中，但它们也会消耗大量内存，从而在顺序读取时导致大量等待。
它们也可能以直接路径读／写等待的形式出现。
表明有许多xx读取：
调优代码（特别是连接）
3）..FreeBufferWait:
释放缓冲区。
这种等待表明系统正在等待内存中的缓冲，因为内存中已经没有可用的缓冲空间了。
如果所有SQL都得到了调优，这种等待可能表示你需要增大DB_BUFFER_CACHE。
释放缓冲区等待也可能表示不加选择的SQL导致数据溢出了带有索引块的缓冲存储器，没有为等待系统处理的特定语句留有缓冲区。
这种情况通常表示正在执行相当多数量的DML（插入／更新／删除），并且可能说明DBWR写的速度不够快，缓冲存储器可能充满了相同缓冲器的多个版本，从而导致效率非常低。
为了解决这个问题，可能需要考虑增加检查点、利用更多的DBWR进程，或者增加物理磁盘的数量。
4）..BufferBusyWait:
缓冲区忙。
该等待事件表示正在等待一个以unshareable方式使用的缓冲区，或者表示当前正在被读入buffercache。
也就是当进程想获取或者操作某个block的时候却发现被别的进程在使用而出现等待。
一般来说BufferBusyWait不应大于1%。
检查缓冲等待统计部分（或V$WAITSTAT），看一下等待是否位于段头。
如果是，可以考虑增加自由列表（freelist，对于Oracle8iDMT）或者增加freelistgroups.其修改语法为：
SQL>altertablesp_itemstorage（freelists2）;
对于Oracle8i而言，增加freelist参数，在很多时候可以明显缓解等待，如果使用LMT，也就是LocalMangementTablespace，区段的管理就相对简单。
还可以考虑修改数据块的pctusedpctfree值，比如增大pctfree可以扩大数据的分布，在某种程度上就可以减少热点块的竞争。
如果这一等待位于undoheader，可以通过增加回滚段（rollbacksegment）来解决缓冲区的问题。
如果等待位于undoblock上，我们可能需要检查相关应用，适当减少大规模的一致性读取，或者降低一致性读取（consistentread）的表中的数据密度或者增大DB_CACHE_SIZE。
如果等待处于datablock，可以考虑将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布（可以增加pctfree值，扩大数据分布，减少竞争），以避开这个"热点"数据块，或者可以考虑增加表中的自由列表或使用本地化管理的表空间（LocallyManagedTablespaces）。
如果等待处于索引块，应该考虑重建索引、分割索引或使用反向键索引。
反向键索引在很多情况下，可以极大地缓解竞争，其原理有点类似于hash分区的功效。
反向键索引（reversekeyindex）常建在一些值是连续增长的列上，例如列中的值是由sequence产生的。
为了防止与数据块相关的缓冲忙等待，也可以使用较小的块：
在这种情况下，单个块中的记录就较少，所以这个块就不是那么"繁忙"；或者可以设置更大的pctfree,使数据扩大物理分布，减少记录间的热点竞争。
在执行DML（insert/update/delete）时，Oracle向数据块中写入信息，对于多事务并发访问的数据表，关于ITL的竞争和等待可能出现，为了减少这个等待，可以增加initrans，使用多个ITL槽。
从本质上讲，这个等待事件的产生仅说明了一个会话在等待一个Buffer（数据块），但是导致这个现象的原因却有很多种。
常见的两种是：
当一个会话视图修改一个数据块，但这个数据块正在被另一个会话修改时。
当一个会话需要读取一个数据块，但这个数据块正在被另一个会话读取到内存中时。
Oracle操作的最小单位是块（Block），即使你要修改一条记录，也需要对这条记录所在的这个数据块做操作。
当你对这个数据块做修改时，其他的会话将被阻止对这个数据块上的数据做修改（即使其他用户修改的不是当前用户修改的数据），但是可以以一致性的方式读取这个数据块（fromundo）。
当前的用户修改完这个数据块后，将会立即释放掉加在这个数据块上的排他锁，这样另一个会话就可以继续修改它。
修改操作是一个非常短暂的时间，这种加锁的机制我们叫Latch。
当一个会话修改一个数据块时，是按照以下步骤来完成的：
以排他的方式获得这个数据块（Latch）
修改这个数据块。
释放Latch。
Bufferbusywaits等待事件常见于数据库中存在的热快的时候，当多个用户频繁地读取或者修改同样的数据块时，这个等待事件就会产生。
如果等待的时间很长，我们在AWR或者statspack报告中就可以看到。
这个等待事件有三个参数。
查看有几个参数我们可以用以下SQL:
SQL>selectname,parameter1,parameter2,parameter3fromv$event_namewherename=''bufferbusywaits'';
NAMEPARAMETER1PARAMETER2PARAMETER3
--------------------------------------------------
bufferbusywaitsfile#block#class#
在下面的示例中，查询的方法和这个一样，所以其他事件对参数的查询将不做过多的说明。
File#:
等待访问数据块所在的文件id号。
Blocks：
等待访问的数据块号。
ID：
在10g之前，这个值表示一个等待时间的原因，10g之后则表示等待事件的类别。
5）..latchfree:
latch释放
latch是一种低级排队机制，用于保护SGA中共享内存结构。
latch就像是一种快速地被获取和释放的内存锁。
latch用于防止共享内存结构被多个用户同时访问。
如果latch不可用，就会记录latch释放失败（latchfreemiss）。
有两种与闩有关的类型：
立刻和可以等待。
假如一个进程试图在立刻模式下获得闩，而该闩已经被另外一个进程所持有，如果该闩不能立刻可用的话，那么该进程就不会为获得该闩而等待。
它将继续执行另一个操作。
大多数latch问题都与以下操作相关：
没有很好的是用绑定变量（librarycachelatch）、重作生成问题（redoallocationlatch）、缓冲存储器竞争问题（cachebuffersLRUchain），以及buffercache中的存在"热点"块（cachebufferschain）。
通常我们说，如果想设计一个失败的系统，不考虑绑定变量，这一个条件就够了，对于异构性极强的系统，不使用绑定变量的后果是极其严重的。
另外也有一些latch等待与bug有关，应当关注Metalink相关bug的公布及补丁的发布。
当latchmissratios大于
0.5%时，就应当研究这一问题。
Oracle的latch机制是竞争，其处理类似于网络里的CSMA/CD，所有用户进程争夺latch，对于愿意等待类型（willing-to-wait）的latch,如果一个进程在第一次尝试中没有获得latch,那么它会等待并且再尝试一次,如果经过_spin_count次争夺不能获得latch,然后该进程转入睡眠状态，持续一段指定长度的时间，然后再次醒来，按顺序重复以前的步骤.在8i/9i中默认值是_spin_count=2000。
如果SQL语句不能调整，在
8.1.6版本以上，Oracle提供了一个新的初始化参数:
CURSOR_SHARING，可以通过设置CURSOR_SHARING=force在服务器端强制绑定变量。
设置该参数可能会带来一定的副作用，对于Java的程序，有相关的bug，具体应用应该关注Metalink的bug公告。
6）..enque
enque是一种保护共享资源的锁定机制。
该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。
enque包括一个排队机制，即FIFO（先进先出）排队机制。
Enque等待常见的有ST、HW、TX、TM等。
STenque用于空间管理和字典管理的表空间（DMT）的分配。
对于支持LMT的版本，可以考虑使用本地管理表空间，对于Oracle8i，因为相关bug不要把临时表空间设置为LMT.或者考虑预分配一定数量的区。
HWenque指段的高水位标记相关等待；手动分配适当区段可以避免这一等待。
7）..LogBufferSpace:
xx缓冲空间
当你将日志缓冲（logbuffer）产生重做日志的速度比LGWR的写出速度快，或者是当日志转换（logswitch）太慢时，就会发生这种等待。
为解决这个问题，可以增大日志文件的大小，或者增加日志缓冲器的大小。
另外一个可能的原因是磁盘I/O存在瓶颈，可以考虑使用写入速度更快的磁盘。
8）..logfileswitch（archivingneed）
这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待可能是IO存在问题。
解决办法：
..可以考虑增大xx文件和增加xx组
..移动归档文件到快速磁盘
..调整log_archive_max_processes.
xx切换（检查点未完成）
当你的日志组都写完以后，LGWR试图写第一个logfile，如果这时数据库没有完成写出记录在第一个logfile中的dirty块时（例如第一个检查点未完成），该等待事件出现。
该等待事件说明你的日志组过少或者日志文件过小。
你可能需要增加你的日志组或日志文件大小。
10）..LogFileSwitch:
xx文件转换
所有的提交请求都需要等待"日志文件转换（必要的归档）"或"日志文件转换（chkpt.不完全）"。
确保归档磁盘未满，并且速度不太慢。
DBWR可能会因为输入/输出（I／O）操作而变得很慢。
你可能需要增加更多或更大的重做日志，而且如果DBWxR是问题症结所在的话，可能需要增加数据库书写器。
11）..logfilesync:
xx文件同步
12）..logfilesinglewrite
该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。
头块写单个进行，因为头块的部分信息是文件号，每个文件不同。
更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。
13）..logfileparallelwrite
从logbuffer写redo记录到redolog文件，主要指常规写操作（相对于logfilesync）。
如果你的Loggroup存在多个组成员，当flushlogbuffer时，写操作是并行的，这时候此等待事件可能出现。
尽管这个写操作并行处理，直到所有I/O操作完成该写操作才会完成（如果你的磁盘支持异步IO或者使用IOSLAVE，那么即使只有一个redologfilemember,也有可能出现此等待）。
这个参数和logfilesync时间相比较可以用来衡量logfile的写入成本。
通常称为同步成本率。
14）..controlfileparallelwrite:
控制文件并行写
当server进程更新所有控制文件时，这个事件可能出现。
如果等待很短，可以不用考虑。
如果等待时间较长，检查存放控制文件的物理磁盘I/O是否存在瓶颈。
多个控制文件是完全相同的拷贝，用于镜像以提高安全性。
对于业务系统，多个控制文件应该存放在不同的磁盘上，一般来说三个是足够的，如果只有两个物理硬盘，那么两个控制文件也是可以接受的。
在同一个磁盘上保存多个控制文件是不具备实际意义的。
减少这个等待，可以考虑如下方法：
..减少控制文件的个数（在确保安全的前提下）
..如果系统支持，使用异步IO
..转移控制文件到IO负担轻的物理磁盘
15）..controlfilesequentialread/controlfilesinglewrite
控制文件连续读/控制文件单个写。
对单个控制文件I/O存在问题时，这两个事件会出现。
如果等待比较明显，检查单个控制文件，看存放位置是否存在I/O瓶颈。
使用查询获得控制文件访问状态：
selectP1fromV$SESSION_WAITwhereEVENTlike'controlfile%'andSTATE='WAITING';解决办法：
..移动有问题的控制文件到快速磁盘
..如果系统支持，启用异步I/O
16）..directpathwrite:
直接路径写
该等待发生在，等待确认所有未完成的异步I/O都已写入磁盘。
你应该找到I/O操作频繁的数据文件，调整其性能。
也有可能存在较多的磁盘排序，临时表空间操作频繁，可以考虑使用Local管理表空间，分成多个小文件，写入不同磁盘或者裸设备。
17）..SQL*Netmessagefromdblink
该等待通常指与分布式处理（从其他数据库中SELECT）有关的等待。
这个事件在通过DBLINKS联机访问其他数据库时产生。
如果查找的数据多数是静态的，可以考虑移动这些数据到本地表并根据需要刷新，通过快照或者物化视图来减少跨数据库的访问，会在性能上得到很大的提高。
18）..slavewait:
从属进程等
SlaveWait是SlaveI/O进程等待请求，是一个空闲参数，一般不说明问题。
19）bufferlatch
内存中数据块的存放位置是记录在一个hash列表（cachebufferchains）当中的。
当一个会话需要访问某个数据块时，它首先要搜索这个hash列表，从列表中获得数据块的地址，然后通过这个地址去访问需要的数据块，这个列表Oracle会使用一个latch来保护它的完整性。
当一个会话需要访问这个列表时，需要获取一个Latch，只有这样，才能保证这个列表在这个会话的浏览当中不会发生变化。
产生bufferlatch的等待事件的主要原因是：
Bufferchains太长，导致会话搜索这个列表花费的时间太长，使其他的会话处于等待状态。
同样的数据块被频繁访问，就是我们通常说的热快问题。
产生bufferchains太长，我们可以使用多个bufferpool的方式来创建更多的bufferchains，或者使用参数DB_BLOCK_LRU_LATCHES来增加latch的数量，以便于更多的会话可以获得latch，这两种方法可以同时使用。
这个等待事件有两个参数：
Latchaddr：
会话申请的latch在SGA中的虚拟地址，通过以下的SQL语句可以根据这个地址找到它对应的Latch名称：
select*fromv$latcha,v$latchnamebwhere
addr=latchaddr--这里的latchaddr是你从等待事件中看到的值
anda.latch#=b.latch#;
chain#：
bufferchainshash列表中的索引值，当这个参数的值等于s0xffff时，说明当前的会话正在等待一个LRUlatch。
20）Controlfileparallelwrite
当数据库中有多个控制文件的拷贝时，Oracle需要保证信息同步地写到各个控制文件当中，这是一个并行的物理操作过程，因为称为控制文件并行写，当发生这样的操作时，就会产生controlfileparallelwrite等待事件。
控制文件频繁写入的原因很多，比如：
日志切换太过频繁，导致控制文件信息相应地需要频繁更新。
系统I/O出现瓶颈，导致所有I/O出现等待。
当系统出现日志切换过于频繁的情形时，可以考虑适当地增大日志文件的大小来降低日志切换频率。
当系统出现大量的controlfileparallelwrite等待事件时，可以通过比如降低控制文件的拷贝数量，将控制文件的拷贝存放在不同的物理磁盘上的方式来缓解I/O争用。
这个等待事件包含三个参数：
Files：
Oracle要写入的控制文件个数。
Blocks：
写入控制文件的数据块数目。
Requests：
写入控制请求的I/O次数。
21）.Controlfilesequentialread
当数据库需要读取控制文件上的信息时，会出现这个等待事件，因为控制文件的信息是顺序写的，所以读取的时候也是顺序的，因此称为控制文件顺序读，它经常发生在以下情况：
备份控制文件
RAC环境下不同实例之间控制文件的信息共享
读取控制文件的文件头信息
读取控制文件其他信息
这个等待事件有三个参数：
File#：
要读取信息的控制文件的文件号。
Block#：
读取控制文件信息的起始数据块号。
Blocks：
需要读取的控制文件数据块数目。
22）Dbfileparallelread
这是一个很容易引起误导的等待事件，实际上这个等待事件和并行操作（比如并行查询，并行DML）没有关系。
这个事件发生在数据库恢复的时候，当有一些数据块需要恢复的时候，Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操作。
这个等待事件包含三个参数：
Files：
操作需要读取的文件个数。
Blocks：
操作需要读取的数据块个数。
Requests：
操作需要执行的I/O次数。
23）.Dbfileparallelwrite
这是一个后台等待事件，它同样和用户的并行操作没有关系，它是由后台进程DBWR产生的，当后台进程DBWR想磁盘上写入脏数据时，会发生这个等待。
DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中，在这个批次作业完成之前，DBWR将出现这个等待事件。
如果仅仅是这一个等待事件，对用户的操作并没有太大的影响，当伴随着出现freebufferwaits等待事件时，说明此时内存中可用的空间不足，这时候会影响到用户的操作，比如影响到用户将脏数据块读入到内存中。
当出现dbfileparallelwrite等待事件时，可以通过启用操作系统的异步I/O的方式来缓解这个等待。
当使用异步I/O时，DBWR不在需要一直等到所有数据块全部写入到磁盘上，它只需要等到这个数据写入到一个百分比之后，就可以继续进行后续的操作。
这个等待事件有两个参数：
Requests：
操作需要执行的I/O次数。
Timeouts：
等待的超时时间。
24）Dbfilesinglewrite
这个等待事件通常只发生在一种情况下，就是Oracle更新数据文件头信息时（比如发生Checkpoint）。
当这个等待事件很明显时，需要考虑是不是数据库中的数据文件数量太大，导致Oracle需要花较长的时间来做所有文件头的更新操作（checkpoint）。
这个等待事件有三个参数：
File#:
需要更新的数据块所在的数据文件的文件号。
Block#：
需要更新的数据块号。
Blocks：
需要更新的数据块数目（通常来说
升级会员 