深入浅出等待事件和性能诊断04

下面再摘要几个关于log的等待事件

Log file switch日志文件切换，数据库进行日志切换时，LGWR需要关闭当前日志组，切换至下一日志组，切换中数据库的所有dml操作都会停止直至切换完成。

Log file switch又包含两个子事件：

1） log file switch（archiving needed）即是日志切换时，需要覆盖先前日志时，发现日志归档尚未完成，出现log file switch（archiving needed），该等待可能表示I/O问题，归档进程写出缓慢，也有可能是日志组设置不合理

可以考虑增大日志组文件和增加日志组；增加归档进程log_archive_max_processes，移动归档文件到快速磁盘

2） log file switch（checkpoint incomplete）检查点尚未完成，如果此时数据库没有完成

写出这个redo log所记录的所有dirty block，该等待事件出现。

Dbwr写出速度太慢或I /O存在问题，可以考虑增加db_writer_processes参数，不过该参数一般不需要增加，db_writer_process一般设置和cpu数量相等，也可以增加日志组或日志大小。

Log file sync日志文件同步：

当一个事物提交或回滚时，lgwr需要将session的该redo log buffer写入重做日志中，lgwr完成任务以后会通知用户进程，Log file sync必须等待这一过程完成。

如果该等待过多，有可能是lgwr写出效率低，或者系统提交过于频繁。针对该问题，可以通过log file parallel write等待事件或user commit user rollback等统计信息观察。

而避免redo log sync等待可以通过提高LGWR性能，尽量使用快速磁盘；使用批量提交；适当使用nologging/unrecoverable等选项。如果系统产生redo过多，每次写得较少，lgwr被过度频繁激活，可能导致redo相关的latch竞争。

Log file single write

该事件仅与日志文件头块相关，通常发生新增日志组成员和log switch增进序列号。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头在后台完成，很少出现等待。

SQL> select event,total_waits,time_waited from v$system_event where event='log file single write';

EVENT TOTAL_WAITS TIME_WAITED

---------------------------------------------------------------- ----------- -----------

log file single write 21 12

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> select event,total_waits,time_waited from v$system_event where event='log file single write';

EVENT TOTAL_WAITS TIME_WAITED

---------------------------------------------------------------- ----------- -----------

log file single write 27 14

在进行switch logfile时需要增进序列号，需要进行日志文件块头写log file single write，可能会出现此等待事件。

Log file parallel write

从log buffer写redo记录到日志文件，主要是常规写操作log file sync，如果log group存在多个组成员，当flush log buffer时，写操作并行的，很可能会出现log file parallel write等待。Log file parallel和log file sync可以用来衡量log file的写入成本，也称为同步成本率。

Log buffer space日志缓冲空间

当数据库产生日志速度比LGWR的写出速度快，或者log switch太慢，就会发生log buffer space等待。等待出现时，通常表明redo log buffer过小，为解决这个问题考虑增大日志文件大小或者增加日志缓冲区大小。Log buffer space等待事件出现时，数据库将处于停顿，由于日志缓存无法分配也无法记录数据库的变更。

Log buffer space也有可能是磁盘I/O问题，LGWR写出太慢，导致redo log buffer中空间不足，可以考虑使用快速磁盘，因为日志文件通常只写，分离存放可以获得性能提升，尽量使用raid 10而不是raid 5磁盘存储日志文件。

Enqueue（队列等待）

Enqueue是一种共享资源的锁定机制，该锁定机制保护共享资源，以避免因并发操作顺坏数据，enqueue采用排队机制，即fifo先进先出控制资源使用。

Enqueue是一组锁定事件集合，如果数据库中等待事件显著还需要进一步追踪哪一类别的锁定引发数据库等待。例如常见的有ST，HW，TX，YM等，在oracle 8I前字典管理表空间典型的是对于uet$和fet$数据字典表争用。

Latch free 闩锁释放

Latch free通常被称为闩锁释放，说明有进程正等待某个latch释放，也就是waiting latch free。

Latch低级串行机制，保护sga中共享内存结构，可以想象成内存锁，保护防止共享内存结构被多个用户同时访问。Latch通常是操作系统利用内存中某个位置，通过设置变量为0或非0来表示latch是否已经被取得，大多数操作系统是利用test and set方式完成latch持有和检查的。在oracle10g后，latch free被具体划分为多个latch竞争，cache buffer chain、cache buffer lru chain、shared pool等latch（关于cache buffer的latch多是由热点块引起，shared pool更多是硬解析造成。）

1 latch分类

Willing-to-wait:指如果请求latch不能立即得到，请求进程将等待一段时间后再次发出请求，进程一直重复此过程直到得到latch

Immediate：如果请求不能立即得到，请求进程不再等待，而是继续执行下去

Oracle的latch机制是竞争

对于willing-to-wait的latch，如果一个进程第一次尝试没有获得latch，那么该latch会等待并且再次尝试，如果系统存在多个cpu，那么此进程将围绕该latch开始spin，经过隐含参数_spin_count此争夺不能获得latch，然后该进程转入睡眠，持续一段指定长度时间再次醒来重复先前过程直到获得该latch。

对于immediate类型的latch通常是因为存在多个可用latch，例如常见的redo copy latch，当process想获取redo copy latch时，首先要求其中一个latch，如果可以命中则持有该latch，不能获取则会转向另一个redo copy latch，只有所有的redo copy latch都无法获取时，才会sleep与wait。

然后immediate另外一种原因是每个latch都有level概念，当一个process需要取得一组latches时，为避免死锁，取得latch有一定顺序，即process新请求latch的level，应该大于process目前所握有的latch的level。如果process要求的新latch的level小于目前所持有的latch的level，oracle要求process释放目前所持有的latch，再依序取得这些latch。为了节省时间，oracle允许以no_wait方式要求较低的latch，如果成功取得，即可以避免deadlock又可以节省时间。

Redo copy latch

进程修改数据产生redo，redo首先存储在pga中，然后redo从pga写入sga的redo log buffer中，不过由于涉及到内存访问需要获取该内存的redo copy latch，获得该latch以后才能把redo写到log buffer中，隐含参数_log_simultaneous_copies为2倍cpu数量定位redo copy latch数量。

Redo allocation latch

Redo copy latch获取后，需要把pga中的redo写入redo log buffer中去，此时又需要获取redo allocation latch分配redo空间，获取到空间时redo allocation latch释放，然后把pga中的redo写入redo log buffer中，写入完成后释放redo copy latch。

如果系统是高端服务器，超过16cpu，而根据v$latch视图发现redo allocation latch竞争激烈

在oracle 9IR2可以通过设置调整参数_log_parallelism来减少latch竞争，log_parallelism默认为1 ，在oracle10g后_log_parallelism为隐含参数，另外又加入隐含参数_log_parallelism_dynamic默认为true，_log_parallelism_max为redo的最大并行度，如果_log_parallelism_max设置为不同于_log_parallelism参数，oracle会动态选择并行度，从这点也可以看出oracle的变化

SQL> select ksppinm, ksppdesc, ksppstvl

2 from x$ksppi a, x$ksppcv b

3 where a.indx = b.indx

4 and a.ksppinm = '_log_parallelism'

5 ;

KSPPINM KSPPDESC KSPPSTVL

------------------------------ ------------------------------ ------------------------------

_log_parallelism Number of log buffer strands 1

完成redo copy以后，如果是commit引发的把redo从pga写入redo log buffer进而还会引发lgwr将redo log buffer写入联机日志组。（而eygle接下来又提到了一段话：为了避免LGWR被不必要post，进程需要先获取redo writing latch检查lgwr是否被激活或者已经被post，如果是，redo writing latch将被释放。对于redo writing latch是如何检查lgwr是否被激活或post）

其实关于oracle的等待事件还有很多，如果纯粹记忆肯定很吃力，如果从oracle原理和体系上逐步分析我们倒是可以从原理出发清晰的认识oracle。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25362835/viewspace-1057093/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25362835/viewspace-1057093/