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