首页 > 代码库 > Oracle Study之--Oracle等待事件（9）
Oracle Study之--Oracle等待事件（9）
Oracle Study之--Oracle等待事件（9）
Log buffer space
当log buffer 中没有可用空间来存放新产生的redo log数据时，就会发生log buffer space等待事件。如果数据库中新产生的redo log的数量大于LGWR 写入到磁盘中的redo log 数量，必须等待LGWR 完成写入磁盘的操作，LGWR必须确保redo log写到磁盘成功之后，才能在redo buffer当中重用这部分信息。
如果数据库中出现大量的log buffer space等待事件，可以考虑如下方法：
（1）增加redo buffer的大小。
（2）提升磁盘的I/O性能
Log file sequential read
这个等待事件通常发生在对redo log信息进行读取时，比如在线redo 的归档操作，ARCH进程需要读取redo log的信息，由于redo log的信息是顺序写入的，所以在读取时也是按照顺序的方式来读取的。
这个等待事件包含三个参数：
Log#： 发生等待时读取的redo log的sequence号。
Block#： 读取的数据块号。
Blocks： 读取的数据块个数。
Log file single write
这个等待事件发生在更新redo log文件的文件头时，当为日志组增加新的日志成员时或者redo log的sequence号改变时，LGWR 都会更新redo log文件头信息。
这个等待事件包含三个参数：
Log#： 写入的redo log组的编号。
Block#：写入的数据块号。
Blocks：写入的数据块个数。
Log file parallel write
后台进程LGWR 负责将log buffer当中的数据写到REDO 文件中，以重用log buffer的数据。如果每个REDO LOG组里面有2个以上的成员，那么LGWR进程会并行地将REDO 信息写入这些文件中。
如果数据库中出现这个等待事件的瓶颈，主要的原因可能是磁盘I/O性能不够或者REDO 文件的分布导致了I/O争用，比如同一个组的REDO 成员文件放在相同的磁盘上。
这个等待事件有三个参数：
Files： 操作需要写入的文件个数。
Blocks： 操作需要写入的数据块个数。
Requests：操作需要执行的I/O次数。
Log file switch(archiving needed)
在归档模式下，这个等待事件发生在在线日志切换（log file switch）时，需要切换的在线日志还没有被归档进程（ARCH）归档完毕的时候。 当在线日志文件切换到下一个日志时，需要确保下一个日志文件已经被归档进程归档完毕，否则不允许覆盖那个在线日志信息（否则会导致归档日志信息不完整）。
出现这样的等待事件通常是由于某种原因导致ARCH 进程死掉，比如ARCH进程尝试向目的地写入一个归档文件，但是没有成功（介质失效或者其他原因），这时ARCH进程就会死掉。 如果发生这种情况，在数据库的alert log文件中可以找到相关的错误信息。
这个等待事件没有参数。
Log file switch(checkpoint incomplete)
当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的记录的信息（比如一些脏数据块产生的redo log）被写到磁盘上（checkpoint），这样做的原因是，如果一个在线日志文件的信息被覆盖，而依赖这些redo 信息做恢复的数据块尚未被写到磁盘上（checkpoint），此时系统down掉的话，Oracle将没有办法进行实例恢复。
在v$log 视图里记录了在线日志的状态。通常来说，在线日志有三种状态。
Active: 这个日志上面保护的信息还没有完成checkpoint。
Inactive： 这个日志上面保护的信息已完成checkpoint。
Current： 当前的日志。
Oracle 在做实例恢复时，会使用状态为current和Active的日志进行实例恢复。
如果系统中出现大量的log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志组太少，所以解决的方法是，增加日志文件的大小或者增加日志组的数量。
这个等待事件没有参数。
Log file sync
这是一个用户会话行为导致的等待事件，当一个会话发出一个commit命令时，LGWR进程会将这个事务产生的redo log从log buffer里面写到磁盘上，以确保用户提交的信息被安全地记录到数据库中。
会话发出的commit指令后，需要等待LGWR将这个事务产生的redo 成功写入到磁盘之后，才可以继续进行后续的操作，这个等待事件就叫作log file sync。
当系统中出现大量的log file sync等待事件时，应该检查数据库中是否有用户在做频繁的提交操作。
这种等待事件通常发生在OLTP系统上。OLTP 系统中存在很多小的事务，如果这些事务频繁被提交，可能引起大量的log file sync的等待事件。
这个等待事件包含一个参数：
Buffer#: redo buffer 中需要被写入到磁盘中的buffer。
案例分析：
16:01:25 SYS@ prod>select event,TOTAL_WAITS,AVERAGE_WAIT,EVENT_ID from v$system_event 2* where event like ‘%log%‘ EVENT TOTAL_WAITS AVERAGE_WAIT EVENT_ID ---------------------------------------------------------------- ----------- ------------ ---------- log file sequential read 184 .8 549236675 log file single write 51 .45 215477332 log file parallel write 5318 1.39 3999721902 log buffer space 17 21.07 3357856061 log file switch (private strand flush incomplete) 4 7.92 114164561 switch logfile command 3 9.06 3845123846 log file switch completion 9 13.97 3834950329 log file sync 336 3.41 1328744198 ARCH wait for archivelog lock 18 .01 2370101988 9 rows selected. 16:03:06 SYS@ prod>show parameter log_buffer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_buffer integer 2236416 16:01:10 SYS@ prod>select group#,sequence#,status,bytes/1024/1024 from v$log; GROUP# SEQUENCE# STATUS BYTES/1024/1024 ---------- ---------- ---------------- --------------- 4 31 INACTIVE 4 5 32 CURRENT 4 Elapsed: 00:00:00.02 事务操作； 16:01:53 SCOTT@ prod>select count(*) from t1; COUNT(*) ---------- 700000 Elapsed: 00:00:00.06 16:02:02 SCOTT@ prod>insert into t1 select * from t1; 700000 rows created. 16:09:20 SYS@ prod>select event,TOTAL_WAITS,AVERAGE_WAIT,EVENT_ID from v$system_event 2 where event like ‘%log%‘ 3* EVENT TOTAL_WAITS AVERAGE_WAIT EVENT_ID ---------------------------------------------------------------- ----------- ------------ ---------- log file sequential read 506 .41 549236675 log file single write 143 .42 215477332 log file parallel write 6606 1.36 3999721902 log buffer space 18 20.05 3357856061 log file switch (checkpoint incomplete) 78 58.69 2867289651 log file switch (private strand flush incomplete) 4 7.92 114164561 switch logfile command 3 9.06 3845123846 log file switch completion 51 8.32 3834950329 log file sync 344 3.36 1328744198 ARCH wait for archivelog lock 64 .01 2370101988 告警日志： Fri Aug 08 16:07:38 2014 Thread 1 advanced to log sequence 77 (LGWR switch) Current log# 4 seq# 77 mem# 0: /dsk1/oradata/prod/redo04a.log Fri Aug 08 16:07:38 2014 Archived Log entry 133 added for thread 1 sequence 76 ID 0xfc8aa16 dest 2: Thread 1 cannot allocate new log, sequence 78 Checkpoint not complete Current log# 4 seq# 77 mem# 0: /dsk1/oradata/prod/redo04a.log Thread 1 advanced to log sequence 78 (LGWR switch) Current log# 5 seq# 78 mem# 0: /dsk1/oradata/prod/redo05a.log Fri Aug 08 16:07:46 2014 Archived Log entry 134 added for thread 1 sequence 77 ID 0xfc8aa16 dest 2: Fri Aug 08 16:07:46 2014 ORA-1653: unable to extend table SCOTT.T1 by 128 in tablespace USERS Fri Aug 08 16:08:11 2014 Thread 1 advanced to log sequence 79 (LGWR switch) Current log# 4 seq# 79 mem# 0: /dsk1/oradata/prod/redo04a.log Fri Aug 08 16:08:11 2014 Archived Log entry 135 added for thread 1 sequence 78 ID 0xfc8aa16 dest 2: Fri Aug 08 16:08:56 2014 Thread 1 advanced to log sequence 80 (LGWR switch) Current log# 5 seq# 80 mem# 0: /dsk1/oradata/prod/redo05a.log Fri Aug 08 16:08:56 2014 Archived Log entry 136 added for thread 1 sequence 79 ID 0xfc8aa16 dest 2: Fri Aug 08 16:09:37 2014 Thread 1 advanced to log sequence 81 (LGWR switch) Current log# 4 seq# 81 mem# 0: /dsk1/oradata/prod/redo04a.log Fri Aug 08 16:09:37 2014 Archived Log entry 137 added for thread 1 sequence 80 ID 0xfc8aa16 dest 2: @由于日志组size较小，日志组数量少，在做事务处理时，日志切换频繁，发生大量关于redo log的等待事件 解决方法： 1、调整日志组的个数 2、增加日志组size 3、将redo log存储到I/O较快的磁盘上（RAID 10) 4、增大log buffer的size
本文出自 “天涯客的blog” 博客，请务必保留此出处http://tiany.blog.51cto.com/513694/1537512