本文永久地址：https://www.askmac.cn/archives/oracle-部分等待事件列表.html
| 名字 | 待机项目的意思 | 单位 | 原因与对策 | 推荐处理方法 | |
| alter system set mts_dispatchers | 会话是由语句ALTER SYSTEM SET MTS_DISPATCHERS = <string>来发行，会使得dispatcher启动待机。 | 1/100 秒 | 确认dispatcher信息。启动dispatcher时启动必须的dispatcher | dispatcher最合适的数量->1:250用户左右。推荐每个dispatcher使用率保存在50%以下， | 确认连接数 select name,owned from v$dispatcher; 使用率 select name,(busy/(busy+idle)) * 100 “%busy” from v$dispatcher; |
| batched allocate scn lock request | 某个会话中使得分割在其他的系统变更编号（SCN）待机。 由于进程，在获得SCN的待机时，前台进程超时的情况下，前台会获得SCN。 |
1 秒 | 基本没有（其他的进程的Allocate等待） | ||
| BFILE check if exists | 会话为了检测是否存在外部large对象（LOB）而 待机。 | exists call的总计耗费时间 | BFILE的处理调查(OS File的存在检测） | ||
| BFILE check if open | 会话会检测，外部large对象(LOB）是否启动而待机。 | isopen call的合计耗费时间 | BFILE的处理调查 | ||
| BFILE closure | 会话在外部大对象(LOB）被关闭位置都会待机。 | close call的总计耗费时间 | BFILE的处理调查(File的Close等待） | ||
| BFILE get length | 会话为了检测外部大对象（LOB）的尺寸，会使得call待机。 | 为了检测LOB尺寸的call的总计耗费时间 | BFILE的处理调查(File长度调查等待） | ||
| BFILE get name object | 会话为了搜索或者生成外部大对象（LOB），会使得call待机。 | 外部文件名的制成完成位置的总计耗费时间 | BFILE的处理调查(File制成等待） | ||
| BFILE get path object | 会话会为了生成与搜索外部大对象（LOB）的外部路径名，而使得call待机。 | 外部路径制成为止的总计耗费时间。 | BFILE的处理调查(PATH制成等待） | ||
| BFILE internal seek | 直到外部大对象（LOB）的指定位置call完成为止都会待机。 | 完成搜索位置的合计搜索时间。 | BFILE的处理调查（搜索等待） | ||
| BFILE open | 会话会为了检测外部大对象（LOB）是否被启动而待机。 | isopen call的总计耗费时间 | BFILE的处理调查（File被启动为止都持续等待） | ||
| BFILE read | 会话直到从外部大对象（LOB）读取完成为止都会待机。 | 读取完成为止的总计耗费时间 | BFILE的处理调查（读取等待） | ||
| buffer busy waits | 缓冲区都变得可用为止都会待机。这个项目在以下两种情况下都会发生。第一个是其他的会话正在缓冲区高速缓存中读取缓冲区。（因此，会话直到完成为止都会待机）。 另一个是缓冲区高速缓存变成了非互换模式（换言之，有其他的会话正在变更缓冲区的情况）。 |
标准待机时间是1秒。 | 确认v$waitstat/x$kcbfwait ，对于到底是哪个块的等待。v$session_waitのfile#,block#也是可行的。请考虑从/V$WAITSTAT中获得各等级等待的次数，由此考虑对策。 | select * from v$waitstat where count != 0; 段头竞争： freelistやExtentの拡張についてのチェック 数据库的竞争： 行数/block,freelist,block_buffer(hit率)的检查 |
File的竞争情况 select d.name,k.count,k.time from v$datafile d,x$kcbfwait k where indx + 1 = file# and count !=0 |
| buffer deadlock | Oracle 实际上不会使得这个项目待机。只是单纯地使得前台CPU Surrender而已。因此这个项目发生的可能性非常小。 这并不是使得应用发生的死循环。这是由于cache layer造成的死循环。cache layer一定时间内无法获得既定的模式的缓冲区。 |
0 秒 | 基本没有 | ||
| buffer for checkpoint | 因为这是变更缓冲区的进程，无法执行缓冲区的检查点。因此，待机后，DBWR会在此扫描缓冲区高速缓存整体。这是数据库关闭途中或者用户执行本地检查点之后发生的，在这种状况下，数据库无法关闭。从id buffer busy wait 项目、会话中各种各样位置开始被call。Flag会话是为了获得这个块的内部flag。 | 1 秒 | 本地检查点等待（DBShutdown时）/获得变更缓冲区的会话信息 | select s.sid from v$session s,v$transaction t where s.saddr = t.SES_ADDR; | |
| buffer latch | 会话会使得缓冲区高速缓存连锁latch待机。主要是通过转储routine来使用。 | 1 秒 | 确认参数latch addr，指定latch的名字（发生BUFFER中的同一个hash chain竞争） | cache buffers chains latch等待时，确认同一个块中的集中访问 | select lh.name from v$latchholder lh,v$session_wait sw where lh.laddr=sw.p1raw; |
| buffer read retry | 这个项目仅仅会在实例用共享模式（Parallel Server ）进行mount时发送。读取缓冲区途中，内容会被变更。这意味着发生了以下两种情况之一。被储存在块内的版本编号，以及顺序编号现在不一致。块会被再次读取。（最多可以失败3次）之后，被认为是破损的块会对trace文件进行转储。 | 读取的消耗时间 | 确认trace有没有被输出(OPS环境） | 从File#,block#开始确认对应块是否损坏。 | SELECT * FROM dba_extents WHERE FILE_ID = file_id AND block_id BETWEEN BLOCK_ID AND (BLOCK_ID + BLOCKS – 1); file_id ：发生错误的文件编号 block_id :发生错误的块编号 一旦确认对象、analyze table … validate structure cascade; |
| checkpoint completed | 会话直到检查点完成位置都会待机。这经常在关闭数据库或者本地检查点时发生。 | 5 秒 | 检查点不会完结，明示Chekpoint完结等待（检查DBWR/LGWR相关内容） | ||
| checkpoint range buffer not saved | 在范围检查点处理中，可以判别缓冲区是否未保存，是否被没有被写入。有以下两种情况。 写入补丁为空，范围检查点处理中，会话初次使其待机时，会话会使得这个项目待机。 current范围检查点处理在异常终止之后，为了完成处理会开始新建的处理。 |
10 毫秒 | 基本没有（范围处理检查点等待） | ||
| control file parallel write | 这个项目是会话将所有的控制文件写入到物理块时发送，发生这种情况的条件如下所示： 会话开始控制文件事务时（在控制文件commit之前，为防会话崩溃，请将控制文件更新到最新的状态。） 会话在控制文件中commit事务是，变更控制文件中的一般entry，新建的值被写入到所有的控制文件中的情况。 |
完成对所有的控制文件的写入所需要的时间 | 基本没有（对控制文件的写入/控制文件事务时） | ||
| control file sequential read | 从控制文件开始的读取。这回在以下所示的情况中发生。 制成控制文件的备份时 共享控制文件的信息（实例之中）时 从控制文件开始读取其他的块时 读取header block时 |
读取的耗费时间 | 基本没有（从控制文件开始的读取） | 比平均Disk I/O花费时间更多的情况。请考虑变更控制文件的位置 | |
| control file single write | 这个待机信号是控制文件的共享信息写入到磁盘时发送。这是1个队列被被1个队列(CF）保护时，1次只向数据库整体发送1个会话。 | 写入的耗费时间 | 基本没有（对控制文件的写入/获得CF队列OPS环境） | 比平均Disk I/O花费时间更多的情况。请考虑变更控制文件的位置 | |
| conversion file read | 这个项目在数据库的6到7的版本变更中，制成版本7控制文件时发生。 | 读取耗费时间 | 基本没有（仅限控制文件版本变更制６->７ ALTER DATABASE CONVERT时） |
||
| db file parallel read | 恢复时的项目。恢复时需要变更的数据库块从数据库开始并行读入。 | 直到所有的I/O完结为止的待机时间 | DiskI/O的检查（恢复出来的读入等待） | ||
| db file parallel write | 这个项目发生的原因是DBWR 。这表示DBWR正在并行执行文件和块的写入。参数requests 是表示执行中的I/O的实际数量。将最后的I/O写入磁盘的话待机就会终结。 | 所有的I/O完结的待机时间 | DBWR/DiskI/O的检查（DBWR写入中） | 确认发生write complete wait 确认DiskI/O时间（对应File余比其他文件慢时->重新配置数据文件） |
|
| db file scattered read | 虽然与db file sequential read 相似，但这个项目中会话还是读取多个数据块。 | 执行所有的I/O所需要的待机时间 | 全表扫描性能检查（多个数据块读入中） | 增加multi_block_read_count(直到最大值） 考虑之后磁盘数文件数stripe幅度 |
|
| db file sequential read | 会话会依次从数据库执行读取，待机。 这个项目也可以在重新构造文件、转储数据库文件头、以及获得数据文件头时使用。 |
执行I/O所需要的待机时间 | 单一块访问的性能检查 | 使其高速缓存（调查高速缓存命中率）IO的高速化 | |
| db file single write | 这个项目在文件头写入就会被使用。。 | I/O执行所需要的待机时间 | 文件头的访问检查 | ||
| DFS db file lock | 这个项目仅仅在Oracle Parallel Server中的DBWR 发生。 各个实例各自的DBWR保持着各个文件上的global锁定的共享状态。想让文件online的实例会从global lock模式开始到排他模式进行阶段性的变换。这时，在文件变得online之前，为了让SGA与控制文件同步的信号就会发送到其他实例中。这个锁定的名字就是DF。 |
在循环内是1 秒 | File的在线处理 OPS:DF锁定global锁定检查 |
可以处理等待较多的Enqueue | select * from x$ksqst where ksqstwat != 0; |
| DFS lock handle | 会话会使得global锁定要求待机。锁定处理用于识别global锁定。使用这个锁定处理的话，就可以在这个锁定处理上进行其他操作。（变更以及接触等未来的操作可以使其变得可以识别）。global锁定由DLM来管理。 | 循环里的待机时间是0.5秒 | global锁定类型模式request的检查 | 确认是否依赖于其他的Waitevent | |
| direct path read | 直接路径处理中的数据会读入非同期的数据库文件。这个处理是直接 会话的某个阶段中，需要磁盘中未处理的非一致I/O处理完成。这个处理在直接读入时，因为即使没有储存未处理的加载要求的slot也是需要这个处理的（也有1次加载由多个I/O构成的情况） |
10 秒 | 非一致IO的检查点读入处理的检查 非一致的I/O等待比实际的I/O等待要短 |
||
| direct path write | 直接路径处理中的数据被非同期地写入到数据库文件中。在会话的某个阶段，需要完成所有磁盘的未处理的非同期I/O的处理。这个处理在直接写入过程中，因为即使没有储存未处理的加载要求的slot也是需要这个处理的（也有1次加载由多个I/O构成的情况） | 10 秒 | 非一致IO的检查点读入处理的检查 非一致的I/O等待比实际的I/O等待要短 |
||
| descriptor address | 对于会话现在正在待机的未处理直接I/O的I/O的context pointer first dba 记述符所参考的context中的最旧的I/O的dba。Block cnt记述符所参考的context中有效的缓冲区的数量。 |
||||
| dispatcher shutdown | 即时的或者一般的崩溃的情况发生之前，所有的dispatcher都需要在待机以防崩溃。向dispatcher发送信号的话，发生崩溃的会话直到被dispatcher停止为止。这个项目 都会待机。 | 1 秒 | MTS连接用户会话检查 dispatcher的检查 |
alert.log/trace的检查 时间耗费较多时请减少dispatcher 进程 | |
| dispatcher timer | 这里基本上dispatcher处于理想状态，展示怎样的工作会被移交而待机。 | 60 秒 | 基本没有 | ||
| duplicate cluster key | 新建cluster key时，可能会发生竞争。在发现其他进程在往索引块中写入其cluster key时，会话待机后再次执行。就会检测出比再试行更有效的cluster key | 0.01 秒 | 制成cluster key处理检查，竞争检查。 | ||
| enqueue | 会话中本地队列正在待机。待机时间根据队列名各自不同。 | 根据队列名各自不同 | 等待队列的检查与应对。 | SELECT sid,chr(bitand(p1,-16777216)/16777215)|| chr(bitand(p1, 16711680)/65535) “Lock”, to_char( bitand(p1, 65535) ) “Mode” FROM v$session_wait WHERE event = ‘enqueue’; | |
| file identify | 识别文件所需要的时间。被识别的文件之后就可以打开了。 | 基本没有 | |||
| file open | 打开文件所需要的时间 | 基本没有 | |||
| free buffer waits | 这个项目会在以下情况发生。 取得所有的缓冲区被中断的情况。以前读取专业的文件现在变成了读写两用的文件了。现有的缓冲区因为没有与锁定要素。因此直到完成无效化为止，缓冲区高速缓存，不会对数据块地址进行分割。 会话因为移动了之前使用完毕的队列，现在正在使用完成的队列满了的时候，就需要写入到最先写完。会话使这个项目待机后，会再次试着搜索可以执行的缓冲区。无法搜索到可以使用的缓冲区时，oracle待机1秒后会再次试着执行获得缓冲区。 |
1 秒 | 缓冲区使用情况检查（使用完成/检查完成） | 确认访问集中的文件->DiskI/O的改善 LRU latch等待确认->DB_BLOCK_BUFFER的增加 |
|
| free global transaction table entry | 会话会使得global事务表（被分散数据库选项使用）中的可以使用的slot待机。1秒待机后就会重新试行。 | 1 秒 | DISTRIBUTED_TRANSACTION参数检查 | 确认DISTRIBUTED_TRANSACTIONS参数是否过大（所使用的分散事务数量通过以下设定可以限制） | |
| free process state object | 在制成进程时使用。会话会扫描进程表，搜索可以使用的进程slot。无法检测出slot时，PMON为了检测出进程表内所有的进程是否还活跃，会公布。有无效进程时，PMON会删去这些进程，新建进程会使得进程slot变得可用。之后，待机中的进程会重新扫描进程表，检查新建slot。 | 1 秒 | 新建进程信息/连接进程信息检查 | 偶尔发生时，请增加PROCESSES（同时通过会话数以及并行度来估计PROCESS数量） | |
| global cache freelist wait | 解除可能的锁定，要求一个新的锁定。如果锁定因素是ping的话，就可以使用了。 | 获得锁定操作对锁定要素进行ping的时间 | Ping状况・PCM锁定数・PCM锁定状况检查（可以解压的锁定） | 确认gc_releasable_locks 与 db_block_buffer 相同还是超过了。select * from v$ping select * from v$lock_activity |
|
| global cache lock busy | 会话为了将缓冲区从共享current状态变成排他current状态都会待机。 | 1 秒 | Ping状况・PCM锁定活跃度/锁定element的检查 | gc_files_to_locks设定确认（PCM锁定的最优化） | |
| global cache lock cleanup | PMON 在global缓冲区锁定操作时，锁定访问完成前台进程后的执行锁定context的clean up操作就会待机。 | 1 秒 | PCMロック相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | 从P3获得LE Number->从v$lock_element 获得 LE的Index与lass | |
| global cache lock null to s | 会话用file#以及block#来识别的块的NULL模式开始共享的锁定变更就会待机。 | 1 秒 | 与DFS lock handle等待相同・PCM锁定相关式子检查 | ||
| global cache lock null to x | 会话用file#以及block#来识别的块的NULL模式开始排他的锁定变更就会待机。 | 1 秒 | PCM锁定相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | ||
| global cache lock open null | 会话用file#以及block#来识别块的NULL模式中的获得锁定就会待机。 | 1 秒 | PCM锁定相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | ||
| global cache lock open s | 会话用file#以及block#来识别块的共享模式中的获得锁定就会待机。 | 1 秒 | PCM锁定相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | ||
| global cache lock open x | 会话用file#以及block#来识别块的排他模式中的获得锁定就会待机。 | 1 秒 | PCM锁定相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | ||
| global cache lock s to x | 会话用file#以及block#来识别的块的从共享模式到排他模式的变更会待机 | 1 秒 | PCM锁定相关式子检查(v$lock_element,v$lock_activity,v$resource_limit,v$false_ping,v$file_ping,v$ping） | ||
| inactive session | 这个项目的使用目的有两个。 切换会话，指定了超时时间时，被指定的时间会在待机后连续解除会话。 删除会话， KILL SESSION或者内部要求。会话为了删除自己，指定之后，直到会话终止位置，最多待机一分钟。 |
1 秒 | 确认会话信息 | select * from v$session where sid= session#(p1); | |
| inactive transaction branch | 会话会使得其他会话正在使用的事务brunch待机。 | 1 秒 | 确认事务信息 | select * from v$session s,v$transaction t where s.saddr = t.ses_addr; | |
| index block split | 索引块中的索引key在搜索时，发现索引块被分割了。 Oracle直到分割完成为止待机之后，会再次试行key搜索。 |
没有待机时间 | 确认索引构成信息 | 检查索引中变深的项目 重新构造level４以上的索引 |
|
| instance recovery | 会话直到SMON完成实例恢复、事务恢复或者、sort段clean up为止都待机。 | 根据恢复所需的时间不同而不同 | 实例恢复信息确认(P1=0的实例恢复，此外是v$rollstat的usn列值) | Alert.log/trace的检查 | |
| instance state change | 会话直到SOMN禁止/可以使用为止都会待机。这经常在ALTER DATABASE OPEN 或者CLOSE 中发生。 | 基本没有（实例恢复信息，启动停止时） | |||
| io done | 会话直到完成为止都会待机或者直到可以使用发行I/O要求的slave process为止都待机。这个项目会在不支持非同期I/O的平台上发生。 | 50 毫秒 | I/O等待 | ||
| kcl bg acks | 会话直到完成后台LCK进程执行完成为止都会待机。比如以下的处理： 锁定恢复 锁定的初始化（启动） 锁定终止（崩溃） |
10 秒 | LCK相关信息确认(LCK进程处理等待） | Alert.log/trace的检查 | |
| latch activity | 这个项目可以作为判断是否需要删除latch的进程的一部分来使用。 | 0.05 ～0.1 秒 | 检查是否DEAD进程所保持的没有LATCH。 select lh.name “Latch NAME”,lh.sid “SESSION ID”,s.status “STATUS”,lh.pid “PROSESS ID” from v$latchholder lh,v$session s where lh.sid = s.sid and lh.pid = process#(p3); |
||
| latch free | 进程会使得现在状态是busy的latch待机（由其他进程保持）。 | 最大2秒 | latch等待/指定等待的latch会话 | select lh.sid “SESSION ID”,lh.pid “PROSESS ID”,lh.name “Latch NAME” from v$latchholder lh where lh.LADDR = address(p1raw); | 确认拥有latch的会话的操作。 |
| library cache load lock | 会话会试行加载数据库对象的加载锁定的搜索。 为了其他进程不会加载同一进程，加载锁定经常以排他模式来获得。加载锁定状态是busy时，会话直到锁定可以使用为止都会使得这个项目待机。 |
3 秒（PMON 中1 秒） | 加载锁定等待(Parse时)・指定会话 | select s.SID SID,l.TYPE TYPE,decode(l.LMODE, 0,’–‘,1,’NONE’,2,’RS’,3,’RX’,4,’S’,5,’RSX’,6,’X’) HLD,decode(l.REQUEST,0,’–‘,1,’NONE’,2,’RS’,3,’RX’,4,’S’,5,’RSX’,6,’X’) REQ,l.CTIME CTIME,l.BLOCK BLOCK,o.OBJECT_NAME OBJECT_NAME from DBA_OBJECTS o,V$LOCK l,V$SESSION s where l.SID = s.SID and l.ID1 = o.OBJECT_ID(+) and s.username is not null and l.addr = “lock address”(p2raw); | 确认确保了锁定的会话 |
| library cache lock | 这个项目可以控制library高速缓存的多个客户端之间的并行性。由此，为了获得对象处理的锁定，有以下好处。 客户端可以防止其他的客户端访问同一个对象。 客户端可以长时间保持依赖性（比如其他的客户端就无法变更相应对象）。这个锁定还有发现library高速缓存中对象位置的功能。 |
3 秒（PMON 中1 秒） | 指定对象处理锁定等待对象会话 | 并列Analyze时请注意！（没有解决方法） select w.sid “SID”, k.user_name “USERNAME”, k.kglnaobj “OBJECT_NAME”,do.type,do.locks,do.pins from v$session_wait w, x$kgllk k,v$db_object_cache do where w.event = ‘library cache lock’ and w.p1raw = k.kgllkhdl and k.kglnaobj = do.name; |
|
| library cache pin | 这个项目用于管理library高速缓存的并行性。如果确保object的话，heap就会在内存中被加载。客户端要变更或者检查对象的话需要客户端在锁定后获得确认。 | 3 秒（PMON 中1 秒） | 确认library高速缓存中的获得等待/确认library高速缓存的命中率 确认对象会话 没用的路径・SHARED_POOLのPageout PL/SQLブ请注意锁定每次的加载/解析 |
SELECT distinct b.username,b.sid,decode(a.KGLPNMOD,0,’Non’,2,’Share’,3,’EX’) “MODE”,decode(a.KGLPNREQ,0,’Non’,2,’Share’,3,’EX’) “REQUEST”,c.KGLOBTYP,c.KGLNAOBJ FROM SYS.x$kglpn a,v$session b,SYS.x$kglob c,v$session_wait sw WHERE a.KGLPNUSE = b.saddr and sw.p1raw = a.kglpnhdl and sw.event = ‘library cache pin’ and a.KGLPNHDL = c.KGLHDADR; | |
| lock manager wait for remote message | 锁定管理会使得同样结构中的remote lock manager的信息待机。 | 待机实际经过时间 | 锁定管理从remote开始的信息等待 | ||
| log buffer space | 会话向日志缓冲区写入数据的速度，因为超过了LGWR的写出速度，所以锁定缓冲区中的区域太小的话就需要扩大，或者考虑移动到Striped disks等高速磁盘中。 | 一般是1 秒 日志切换完成待机时是5 秒 |
LGWR写出等待/日志缓冲区扩大/日志文件的高速化 | ||
| log file parallel write | 从日志缓冲区写入redo记录。 | 物理性I/O （写入）完成所需要的时间 | 从日志缓冲区向disk写入等待（Log FileI/O确认・移动到RAW中效果也不错) | 确认v$SYSTEM_EVENT的平均时间 | |
| log file sequential read | 从这个日志文件开始的读取直到返回为止都会待机。这个项目是在从日志文件开始的redo记录读取中被使用。 | 物理性I/O （读取）完成所需要的时间 | 从日志文件开始的读取等待(影响Log FileI/O确认/恢复时间) | ||
| log file single write | 这个日志文件的写入完成为止都会待机。这个项目在日志文件头的更新中会被使用到。在增加日志文件成员以及顺序编号时，会发送信号。 | 物理性I/O （写入）完成所需要的时间 | 从日志缓冲区向disk写入等待(Log FileI/O确认) | 确认v$SYSTEM_EVENT的平均时间/使其成为redo专用disk | |
| log file switch (archiving needed) | LGWR 的switch地址的日志因为还没有被归档。日志switch就会待机。检查警报文件，确认是否有归档写入失败导致归档终止。要提高归档的速度的话，请考虑追加归档进程或者将归档文件写入到Striped disks中。 | 1 秒 | 归档终止等待/确认归档错误/提高归档速度(disk/process) | ||
| log file switch (checkpoint incomplete) | 会话因为无法在接下来的日志中wrapping，所以日志switch就会待机。这是因为日志检查点没有完结。 | 1 秒 | session向接下来的日志的移动等待/日志文件的数量、调整尺寸、调整检查点参数(checkpoint处理的高速化） | ||
| log file switch (clearing log file) | 由于CLEAR LOGFILE 命令，或者由于恢复、或者由于被执行的日志文件被删除，或者日志正在被删除等原因，日志switch出现待机。 | 1 秒 | 基本没有(删除不需要的日志的等待) | ||
| log file switch completion | 完成日志switch待机。 | 1 秒 | 日志switch等待/日志文件的数量、尺寸、检查点参数的调整 | ||
| log file sync | 想commit用户会话的话，需要在redo日志文件中刷新会话的redo信息。用户会话为了在redo日志文件中写入日志缓冲区，会转存LGWR。如果LGWR写入完成的话，LGWR就会转写用户会话。 | 包含日志缓存的写入以及转写的时间。 | 从日志缓冲区向磁盘的写入等待/减少commit，LGWR处理的高速化。 | ||
| log switch/archive | 作为ALTER SYSTEM ARCHIVE LOG CHANGE scn的一部分命令来使用。 会话直到current log都被归档为止都会待机。 |
最多10秒 | 归档终结等待/确认归档错误，归档高速化（其他节点） | ||
| on-going SCN fetch to complete | 其他的会话会将SCN进行fetch。会话本身会直到这个SCN fetch完成为止都会待机。 | 1 秒 | 其他会话的SCN fetch等待 | ||
| parallel execution create server | 并行执行slave制成时或者开始时会被使用。 | 被要求的并行执行slave全部开始所需要的时间。 | 并行进程制成/开始等待（确认并行度/确认min进程) | ||
| parallel execution dequeue wait | 进程在并行执行时使得信息待机。 | 一般都在较短时间内完成。 | 从QC开始的执行命令等待/确认参数(p1:reason) | select reason from x$kxfpsds where indx = “reason(p1)”; | |
| parallel execution qref latch | 各个并行执行进程中，有并行执行qref latch。操作缓冲区队列之前，需要获得这个latch。 | 最多待机1秒 | qref latch获得等待/latch(PROCESS QUEUE REFERENCE)指定所有者 | select lh.pid,lh.sid,s.username,lh.name from v$latchholder lh,v$session s where lh.sid = s.sid and lh.name=’process queue reference’; | |
| parallel execution server shutdown | 一般或者突发性崩溃时，并行执行slave会为了完全崩溃而转记。经过10秒后会把活跃的所有并行执行slave都删除。 | 最多待机0.5秒 | 并行进程终结等待/崩溃等待 | ||
| parallel execution signal server | 这个项目仅在排他模式中发生。查询Coordinator对于查询slave会发送出现故障的信号。 | 0.5 秒 | 错误发生等待/参数确认(error) | ||
| pending global transaction | (s)这个项目仅在测试中发生。会话直到保留的交易被删除为止都会待机。 | 30 秒 | 基本没有（等待最后的事务被删除的等待） | ||
| pipe get | 会话会使用pipe来接收信息。直到pipe timer时间终结为止都会待机。 | 5秒的启动时间 | pipe开始的接收等待/确认pipe timer | ||
| pipe put | 会话会使得pipe发送timer时间终结，直到pipe中的区域可以使用为止都会待机。 | 5 秒的启动时间 | 对pipe的发送等待/确认pipe timer | ||
| PL/SQL lock timer | 这个项目是经过DBMSLOCK.SLEEP procedure或者USERLOCK.SLEEP procedure 被call。一般而言，这个项目会在用户制成的procedure中发生。 | 待机时间1/100 秒为单位 | 基本没有(SLEEP procedure执行中） | ||
| pmon rdomain attach | 这是PMON主要的待机项目。PMON处于理想状态时，这个项目就会待机。 | 基本没有 | |||
| pmon timer | 这是PMON主要的待机项目。PMON处于理想状态是这个项目会待机。 | 最多3秒 | 基本没有 | ||
| process startup | 多线程服务器（共享服务器）、dispatcher、或者其他的后台进程的启动就会待机。 | 最多待机1秒 | MTS进程dispatcher等进程启动等待/确认参数(多发时会增加最小进程数) | prompt dispatcher status(number) select name “NAME”, network “PROTOCOL”,status “STATUS”, (busy/(busy + idle)) * 100 “%TIME BUSY”,OWNED from v$dispatcher; select paddr,type,queued,wait,totalq,decode(totalq,0,0,wait/totalq) “AVG WAIT” from v$queue; prompt shared_server status (number) select name “NAME”, paddr,requests,(busy/(busy + idle)) * 100 “%TIME BUSY”,status from v$shared_server; select maximum_connections “MAX CONN”,servers_started “STARTED”, servers_terminated “TERMINATED”,servers_highwater “HIGHWATER” from v$mts; |
|
| queue messages | 会话直到接收信息，使其出列为止，都会以空白的OLTP队列待机（高级队列）。 | 由参数wait time来觉得 | 直到可以出列为止的等待/参数(queueid,process#,waittime)的确认 | select * from v$aq; | |
| rdbms ipc message | 这个项目会在后台进程（LGWR 、DBWR 、LCK0 ）中使用。 后台进程是理想状态，为了执行某些工作的IPC信息表示从前台进程发送正在待机。 |
最多3秒 | 基本没有 | ||
| rdbms ipc message block | 这个项目表示所有的信息块都正在被使用，信息块直到可以使用为止都会待机。 | 最多待机60秒 | 信息块获得等待/观察其他块的发生 | ||
| rdbms ipc reply | 这个项目是为了使得从前台进程之一的信息待机而被使用。 | 参数timeout | 后台进程开始的信息等待/参数(from_process的进程是否还存活 确认其进程中是否发生了其他的EVENT |
select event,p1,p2,p3,second_in_wait from v$session_wait where sid = “SID(p1)”; | |
| redo wait | 虽然被定义了，但是无法通过代码来使用。 | 没有 | |||
| row cache lock | 会话试着获得数据字典锁定。 | 最多待机60秒 | 数据字典锁定获得等待/确认参数(cacheid,mode) | select cache#,parameter from v$rowcache where cache# = “CacheID(P1)”; select decode(p2, 0,’–‘,1,’NONE’,2,’RS’,3,’RX’,4,’S’,5,’RSX’,6,’X’) from v$session_wait where event = “row cache lock”; |
|
| scginq AST call | 为了搜索出资源上被保持的最高级锁定模式，会话就会被call。 | 最多0.2秒 | 找出最高级锁定模式 | select * from v$lock_activity; select * from v$resource_limit; |
|
| single-task message | 这个项目是表示单独任务执行中，会话会使得可以执行的程序客户端的工作待机。 | 处理所花费总计时间 | 基本没有 | ||
| smon timer | 这里是SMON主要的理想项目。SMON如果超时的话，直到转记到其他进程中为止，大部分时间都会待机。 | 5 分（300 秒） | 基本没有 | ||
| SQL*Net break/reset to client | 服务器会向客户端发送break或者reset信息。服务器上正在执行的会话会等待客户端的应答。 | break或者reset信息从客户端返回所需要的实际时间。 | 确认客户端程序 | ||
| SQL*Net break/reset to dblink | 虽然与SQL*Net break/reset to client 相同，但这时的break/reset信息是经过数据库链接向其他的服务器进程发送信息的。 | break或者reset信息从其他服务器进程返回所需要的时间。 | 确认DB链接地址 | ||
| SQL*Net message from client | 服务器进程（前台进程）直到接收到来自客户端进程的信息为止都会待机。 | 向客户端发送最新的信息后，直到接收到信息所需要的时间 | 确认客户端程序 | ||
| SQL*Net message from dblink | 会话直到服务器进程（前台进程）接收到经过数据库链接的来自其他服务器进程的信息为止，都会待机。 | 从其他前台进程发送信息开始，直到接收到信息为止所需要的时间。 | 确认DB链接地址 | ||
| SQL*Net message to client | 服务器（前台进程）向客户端发送信息。 | 发送所需要的实际时间 | 确认客户端程序 | ||
| SQL*Net message to dblink | 服务器进程（前台进程），经过数据库链接，会向其他的服务器进程发送信息。 | 发送所需要的实际时间 | 确认DB链接地址 | ||
| SQL*Net more data from client | 服务器从客户端执行接收其他信息，上次的动作也是从客户端接受的信息。 | 与接收信息所需要的时间不同。 | 确认网络流量/增加SDU | ||
| SQL*Net more data from dblink | 前台进程等待来自数据库链接的前台数据。 | 读取来自数据库链接所需要的合计时间 | 确认DB链接地址 | ||
| SQL*Net more data to client | 服务器进程会向客户端追加数据或者发送信息。 | 发送所需要的实际时间 | 确认网络流量/增加SDU | ||
| SQL*Net more data to dblink | 这个项目表示服务器经过数据库链接再次发送数据。经过这个数据库链接，也会发送上次的操作。 | 时间发送到其他服务器中所需要的时间 | 确认DB链接地址 | ||
| switch logfile command | 会话直到用户命令SWITCH LOGFILE完结为止都会待机。 | 5 秒 | switch logfile命令终结等待/确认Alert.log | ||
| timer in sksawat | 会话直到归档（ARCH ）非同期I/O 完结为止都会待机。 | 0.01 秒 | 归档的非同期I/O终结等待/非同期I/O・ARCH确认 | ||
| transaction | 块事务会使得回滚待机。 | 1 秒 | 事务回滚待机/(确认TX等待有没有发送其他会话） | Oracle8i中利用 Fast_Start_Parallel_Rollback试着缩短Rollback时间 | |
| unbound tx | 为了确认是否没有已经开始的带有对策的。回滚段而待机。 | 1 秒 | 事务以及回滚段对应确认等待 | ||
| undo segment extension | 回滚段被扩大或者索性了。会话需要直到回滚段操作完成而待机。 | 0.01 秒 | 回滚段扩张/缩小等待 | 频繁发生时， ROLLBACK SEGMENT的Extent小还是Optimal的范围小 select SEGMENT_ID “ID”,SEGMENT_NAME “NAME”,INITIAL_EXTENT “EXT_SIZE”,optsize,extents,shrinks,extends from v$rollstat,dba_rollback_segs where usn=segment_id; |
|
| undo segment recovery | PMON 会回滚变得无效的事务。 直到回滚完成位置都会继续待机。 |
3 秒 | PMON的回滚等待 | 与TRANSACTION Wait相同，OPS环境中，确认 是否变成了TA Lock等待 | |
| undo segment tx slot | 选择的回滚段中，直到可以使用事务slot为止都会待机。 Slot直到可以使用为止都会继续待机。 |
1 秒 | 获得事务slot等待 | ||
| virtual circuit status | 会话直到status中所展示的信息类型从假设circuit返回为止都会待机。 | 30 秒 | 信息类型的假设circuit等待 | prompt dispatcher status(number) select name “NAME”, network “PROTOCOL”,status “STATUS”, (busy/(busy + idle)) * 100 “%TIME BUSY”,OWNED from v$dispatcher; select paddr,type,queued,wait,totalq,decode(totalq,0,0,wait/totalq) “AVG WAIT” from v$queue; prompt shared_server status (number) select name “NAME”, paddr,requests,(busy/(busy + idle)) * 100 “%TIME BUSY”,status from v$shared_server; select maximum_connections “MAX CONN”,servers_started “STARTED”, servers_terminated “TERMINATED”,servers_highwater “HIGHWATER” from v$mts; |
增加共享服务器进程从$shared_server,v$dispatcher,v$circuit,v$queue等开始确认dispatcher共享服务器中是否发生了等待 |
| WMON goes to sleep | 使用UNIX自带的待机监视器的话oracle中的转记或者用于待机的计时器设定相关的系统call数量就可以减少了。要使得WMON进程可用需要重新设定初始化参数。 | 基本没有（Wakeup Monitor的休眠，Wakeup timeout在测试之外都不能使用。） | |||
| write complete waits | 会话直到写入缓冲区为止都会待机。这个写入是由于标准引擎或者实例之间的call而发生的。 | 1 秒 | 缓冲区写入等待/抑制检查点的发生 | 确认统计信息AVERAGE_WRITE_QUEUE_LENGTHを確認。(8i开始终止) 确认OS中是否发生了多余的I/O |
|
| writes stopped by instance recovery or database suspension |
会话直到启动实例恢复的实例完结为止，都会被禁止。 | 5 秒 | 实例恢复等待 |
Leave a Reply