ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle实验记录 (oracle 详细分析redo(3))

oracle实验记录 (oracle 详细分析redo(3))

原创 Linux操作系统 作者:fufuh2o 时间:2009-10-23 14:28:48 0 删除 编辑

与redo 的相关等待事件


SQL> show user
USER 为 "SYS"
SQL> select name from v$event_name where name like 'log%';

NAME
----------------------------------------------------------------
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (private strand flush incomplete)
log file switch (archiving needed)
log file switch completion
log file sync
log switch/archive
log file switch (clearing log file)

NAME
----------------------------------------------------------------
log write(odd)
log write(even)

已选择13行。


具体 说明下 与redo有关常见的 event 产生原因,及其简单处理方法:


log file sequential read:


当进程等待从REDO文件中读入块时会产生该等待事件。
ARCH进程在读取REDO文件时会遭遇此等待事件。
参数说明:
事件号:174

事件名:log file sequential read

参数一:REDO日志组中重做日志文件的相对序列号。

参数二:开始读入的块号

参数三:块数

等待时间:完成请求读取的IO所占用的实际时间。

 

log file single write:

这是日志文件写的 等待 (不是从log buffer 写入log file)代表写log file header时等待,一般是日志文件头 更新member文件或日志sequence#增加时会写日志文件头


*log file parallel write:

这是一个主要事件 lgwr将log buffer写出到logfile而产生的 等待时间
session commit or rollback,LGWR会等待该事件的完成,用户会话则等待log file sync event


SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session where event='log
file parallel write';

未选定行
实验环境 当前没有这个event


查下历史session
V$SESSION_WAIT_HISTORY

The V$SESSION_WAIT_HISTORY view displays the last ten wait events for each active session.

这个视图会记录 最近最后10次发生的 events
SQL> col event format a30
SQL> col p1text format a10
SQL> col p2text format a10
SQL> col p3text format a10
SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session_wait_history wher
e event='log file parallel write';

EVENT                                  P1 P1TEXT             P2 P2TEXT
------------------------------ ---------- ---------- ---------- ----------
        P3 P3TEXT
---------- ----------
log file parallel write                 1 files               3 blocks
         1 requests

log file parallel write                 1 files               2 blocks
         1 requests

log file parallel write                 1 files               2 blocks
         1 requests

 

 

从p1text,p2text,p3text可以看出来
参数一:写入的日志文件号

参数二:写入的块数

参数三:IO请求的号码

9i前 要连接 v$event_name看才可以 ,没有p1text
SQL> select parameter1 from v$event_name where  name='log file parallel write';

PARAMETER1
----------------------------------------------------------------
files

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

EVENT                          TIME_WAITED AVERAGE_WAIT
------------------------------ ----------- ------------
log file parallel write                239          .25

AVERAGE_WAIT NUMBER Average amount of time waited for the event (in hundredths of a second)   单位是100分 之一秒

若AVERAGE_WAIT >10MS (单位毫秒 1000分之一秒 则表示I/o太慢 )

关于调整:
可以减少redo(nologging ,cats ,append操作)
可以加大log buffer,但相对的_log_io_size应该修改 控制1/3写入 应该相对改小点,否则log buffer大了 1/3写一次 写的redo record太多
但如果redo allocation latch,redo writing latch 争用(lgwr写时候要 占用这两个latch)多不要减少_log_io_size这会造成 lgwr更加频繁的写 获取这些latch 造成latch争用
根本解决方法 还是将redo file放到更快的磁盘上


log buffer space
主要原因就是 server process生成redo record快过lgwr写出redo record的 产生的 等待,新的redo record 从pga写到log buffer中没空间了,就是i/o过慢,另外log buffer过小也是
但如果log buffer过大 ,每次LGWR写的 redo record过多,会造成用户等待log file sync 事件,可以通过_log_io_size改进
调整建议方法 与log file parallel write event一样

  1* select name,value,class from v$sysstat s where statistic#=(select statistic
# from v$statname t where name='redo buffer allocation retries')
SQL> /

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
     CLASS
----------
redo buffer allocation retries                                            0
         2


SQL> col name format a40
SQL> /

NAME                                          VALUE      CLASS
---------------------------------------- ---------- ----------
redo buffer allocation retries                    0          2


以上 查询可以看到 session procss或 system级 必须等待 空间次数(等待lgwr flush  log buffer)等待log buffer space次数.

redo buffer allocation retries :表示再次尝试从log buffer中分空间的次数(最好为0),process第一次没请求成功 会触发LGWR 然后等待完成或其它PROCESS 已经触发而 这个进程等待lgwr完成,完成后再次尝试从log buffer中分配空间
用 redo buffer allocation retries和redo entries可以计算出从PGA copy change vector到SGA LOG BUFFER 时必须等待的重做记录的数量所占的比例
最好为0 或<1%如果>1%且不断边大 说明从PGA copy change vector到SGA LOG BUFFER时必须等待log buffer空的日志块,可以考虑加大log buffer or  提高lgwr写效率

 


log file switch (checkpoint incomplete)
如果发生switch log file会产生一个 检查点,将dirty block写入disk ,记录scn等,如果检查点过慢 就会出现这个 等待事件
(手动switch 不会出现这个事件)

SQL> alter system switch logfile;

系统已更改。

SQL> select group#,status from v$log;

    GROUP# STATUS
---------- ----------------
         1 ACTIVE~~~~~~~~~~~检查点 没完成
         2 ACTIVE~~~~~~~~~~~检查点  没完成
         3 CURRENT


SQL> select event,p1,p1text,p2,p2text,p3,p3text from v$session where event='log
file switch (checkpoint incomplete)';

未选定行


log file switch (archiving needed):
如果是archive log mode 如果日志切换过快,或arch进程 归档过慢 都会造成 这个等待事件,表示下一个日志文件还未归档,此时又发生switch


log file switch completion
当一个redo file 满了后 需要切换(switch), 要打开另一个online redo log file ,写完上一个 文件准备好下一个日志文件这之间的等待就是此事件

 

log file sync
用户commit or rollback 提交了事务触发lgwr写入log file, 那么用户会等待这个事件,如果伴随出现 log parallel write(也很高) 就是i/o过慢
如果log file sync很高 log parallel write很低 那么证明i/o没问题 log buffer很快的刷新到log file中,那么log file sync 表示用户太多的commit or rollback

SQL> select name,value from v$sysstat where name in ('user commits','user rollba
cks');

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
user commits                                                            687
user rollbacks                                                            0
看看是否是过多了

 

 

 

 

log file switch (clearing log file):
alter system clear logfile时(clear会重建redo file member) 会出现且 lgwr正需要切换到被clear的redo file,,等待时间为1S

 

 

 

 

 

log switch/archive:手动执行归档时会发生
Used as part of the ALTER SYSTEM ARCHIVE LOG CHANGE scn statement. The session waits for the current log from all open threads to be archived.

Wait Time: Wait for up to 10 seconds

Parameter Description
thread# The thread number of the thread that is currently archiving its current log


 

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

请登录后发表评论 登录
全部评论

注册时间:2009-06-26

  • 博文量
    182
  • 访问量
    426861