Oracle Study之--Oracle等待事件(9)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

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。

案例分析:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
  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








本文转自 客居天涯 51CTO博客,原文链接:http://blog.51cto.com/tiany/1537512,如需转载请自行联系原作者
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
SQL 监控 Oracle
Oracle 数据库发生等待事件:enq: TX - row lock contention ,排查思路
Oracle 数据库发生等待事件:enq: TX - row lock contention ,排查思路
Oracle 数据库发生等待事件:enq: TX - row lock contention ,排查思路
|
Oracle 关系型数据库 数据库
Oracle-等待事件解读
Oracle-等待事件解读
90 0
|
SQL Oracle 关系型数据库
Oracle 等待事件研究:SQL*Net break/reset to client
SQL*Net break/reset to client事件是一个容易被误解的事件,这个事件看起来和网络有关,但实际上大多数情况下这个事件与网络无关。
550 0
Oracle 等待事件研究:SQL*Net break/reset to client
|
关系型数据库 数据库 Oracle

推荐镜像

更多