Oracle 部分等待事件列表

本文永久地址:http://www.askmaclean.com/archives/oracle-部分等待事件列表.html

 

列表下载地址: http://zcdn.askmaclean.com/%E3%80%90%E8%AF%97%E6%AA%80%E8%BD%AF%E4%BB%B6%E3%80%91Oracle%E7%AD%89%E5%BE%85%E6%97%B6%E9%97%B4%E6%95%B4%E7%90%86.zip

 

名字 待机项目的意思 单位 原因与对策 推荐处理方法
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控制文件时发生。 读取耗费时间 基本没有(仅限控制文件版本变更制6->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搜索。
没有待机时间 确认索引构成信息 检查索引中变深的项目
重新构造level4以上的索引
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 秒 实例恢复等待

 

 

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569