重做日誌（redo log）相關總結

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE檢查點（checkpoint）

檢查點是一個資料庫事件，它存在的意義在於減少崩潰恢復時間（crash recovery time）。檢查點事件由後臺程式CKPT觸發，當檢查點發生時，CKPT程式會負責通知 DBWR程式將髒資料（dirty buffer）寫出到資料檔案上。CKPT程式的另一個職責是負責更新資料檔案頭部及控制檔案上的檢查點資訊。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

Crash and instance recovery involve two distinct operations: rolling forward the current, online datafiles by applying both committed and uncommitted transactions contained in online redo records, and then rolling back changes made in uncommitted transactions to their original state.

Undo blocks (whether in rollback segments or automatic undo tablespaces) record database actions that should be undone during certain database operations. In database recovery, the undo blocks roll back the effects of uncommitted transactions previously applied by the rolling forward phase..

這句話意思是 ：在之前的前滾階段，產生了未提交的事務，在資料庫恢復過程（回滾階段）中，undo塊回滾了這種效果 Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

 After the roll forward, any changes that were not committed must be undone. Oracle applies undo blocks to roll back uncommitted changes in data blocks that were either written before the failure or introduced by redo application during cache recovery. This process is called rolling back or transaction recovery.

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

 最常見的情況，資料庫可能因為斷電而crash，那麼記憶體中修改過的、尚未寫入資料檔案的資料將會丟失。在下一次啟動資料庫，oracle可以通過重做（redo）日誌進行事務前滾（roll forward），將資料庫恢復到崩潰之前的狀態，然後資料庫可以開啟提供使用，之後oracle可以將未提交的事務進行回滾（roll back）。

  而檢查點（checkpoint）的存在就是為了縮短前滾（roll forawrd）的時間。當檢查點發生時（此時的scn被稱為checkpoint scn），oracle會通知dbwr程式把修改過的資料，也就是此checkpoint scn之前的髒資料（dirty data） 從buffer cache寫入磁碟，當寫入完成之後，ckpt程式則會相應更資料檔案頭部和控制檔案，記錄檢查點資訊，標識更改。

而tom大師在他的大作中這樣描述

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

Many things can cause a checkpoint to occur, the most common event being a redo log switch. As we filled up log file 1 and switched to log file 2, Oracle initiated a checkpoint. At this point in time, DBWn started flushing to disk all of the dirty blocks that are protected by log file 1. Until DBWn flushes all of these blocks protected by that log file, Oracle cannot reuse it.So, at this point in time, processing was suspended in the database while DBWn hurriedly finished its checkpoint. Oracle gave all the processing power it could, to DBWn at that point in the hope it would finish faster.

redo 介紹

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

1：redo的功能主要通過3個元件來實現：redo log buffer、lgwr程式、redo log  file。同redo log buffer類似，redo log file也是迴圈使用的，oracle允許使用最少兩個日誌組。當一個日誌檔案寫滿以後，會切換到另外一個日誌檔案，這個過程稱為 log switch 。 log switch會觸發一個檢查點（checkpoint），促使dbwr程式將buffer cache中的髒資料寫出到資料檔案中。在檢查點完成之前，日誌檔案是不能夠被重用的。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

3：系統產生了多少redo日誌

有兩種方法

a：通過 v$mystat 和 v$statname 檢視

 

SQL> create table t2 as select * from dba_tables;

Table created.

SQL> select a.value ,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name='redo size';

     VALUE NAME

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

    940832 redo size

SQL> insert into t2 select * from t2;

2781 rows created.

SQL>  select a.value ,b.name from v$mystat a , v$statname b where a.statistic#=b.statistic# and b.name='redo size';

     VALUE NAME

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

   1717252 redo size

SQL> select 1717252-940832 from dual;

1717252-940832

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

        776420

 

b：通過autotrace 功能

SQL> rollback;

 Rollback complete.

 SQL> set autotrace exp;

Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]

SQL> set autotrace exp stat;

Usage: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]

SQL> set autotrace trace stat;

SQL> insert into t2 select * from t2;

2781 rows created.

 

Statistics

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

          1  recursive calls

        723  db block gets

        714  consistent gets

          0  physical reads

     759652  redo size

        680  bytes sent via SQL*Net to client

        603  bytes received via SQL*Net from client

          3  SQL*Net roundtrips to/from client

          1  sorts (memory)

          0  sorts (disk)

       2781  rows processed

 

如果資料庫執行在歸檔模式下，歸檔日誌的生成量從檢視 v$archived_log 可以得到

以下是每天產生的日誌量

 select trunc(completion_time),sum(M) from

 (select name,COMPLETION_TIME,blocks*block_size/1024/1024 M from  v$archived_log ) group by trunc(completion_time)   order by trunc(completion_time)

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

4：redo寫的觸發條件

a：每3秒超時（timeout）

b：閥值達到：redo log buffer 1/3滿 、redo log buffer 具有1MB髒資料 

              換句話說，也就是lgwr將在 min(1M,1/3 log buffer size) 時觸發

 

c：使用者提交(commit)   ---使用者提交過於頻繁，會出現等待事件 log file sync

++++++++++++++++++++++++++++++++++++++++++++++++

log file sync 描述如下

When a user session commits, the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session.

++++++++++++++++++++++++++++++++++++

 

d：在dbwr寫程式之前

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

5：redo log buffer大小的設定

 因為redo log buffer的寫出操作非常頻繁，所以過大的log buffer 設定通常沒有必要，一般 3M 較為合理。當等待事件 log buffer space 比較明顯時，可以增大 log buffer

當使用者執行commit的時候，這個意味著oracle已經將此時間點之前的redo寫入了重做日誌檔案中，這個日誌寫完之後，oracle可以釋放使用者去執行其他任務。comit的原則是，確保提交成功的資料不丟失。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

6：日誌的狀態

 

可以從v$log中檢視log的狀態

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

     GROUP# STATUS           FIRST_CHANGE#

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

         1 INACTIVE               2283561

         2 INACTIVE               2310032

         3 CURRENT                2329537

 

最常見的四種狀態

 

a) current：指當前的日誌檔案，它是活動的，正在被使用，在進行實crash恢復時current的日誌檔案是必須的。

b）active： 是活動的非當前日誌，該日誌可能已經完成歸檔也有可能沒有歸檔，活動的日誌檔案檔案在crash恢復時會被用到。active狀態意味著檢查點尚未完成，如果日誌檔案迴圈使用再次到達該檔案，資料庫將處於等待的停頓狀態，此時在alert檔案中，可以看到 checkpoint not complete的記錄 。 該記錄在 v$session_wait 中表現出等待事件為 log file switch (checkpoint incomplete)

checkpoint incomplete有多種可能原因

1) 日誌檔案過小，切換頻繁

2) 日誌組太少， 不能滿足正常事務量的需要

3) 日誌檔案所在的磁碟I/O存在瓶頸，導致寫出緩慢，阻塞資料庫正常執行

4) 由於資料檔案磁碟I/O瓶頸，DBWR寫出過於緩慢

5) 由於事務量巨大，DBWR負荷過高

 

針對不同的原因，又可以從以下角度著手分析

 

1) 適當增加日誌檔案大小

2) 適當增加日誌組

3) 使用更快速磁碟儲存日誌檔案（如採用更高速磁碟；使用raid10而不是raid5等方式）

4) 改善磁碟I/O效能

5) 使用多個DBWR程式或使用非同步I/O等

 

需要強調的是，這是一類嚴重的等待，它意味著資料庫不能再產生日誌，所有資料庫修改操作將全部掛起。

 

c) inactive 是非活動日誌組，該日誌在例項恢復時候不再需要，但是在介質恢復時可能會用到。inactive狀態的日誌也可能沒有被歸檔。如果資料庫啟動在歸檔模式，在未完成歸檔之前，日誌檔案也不允許被覆蓋，這時活動程式會處於 log file switch (archiving needed)等待之中。

 

 

SQL> select GROUP#, SEQUENCE#,BYTES,ARCHIVED,STATUS,FIRST_CHANGE#  from v$log;

 GROUP#     SEQUENCE#   BYTES    MEMBERS ARCHIVED  STATUS      FIRST_CHANGE#

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

         1       127       52428800     1       NO     INACTIVE      2283561

         2       128       52428800     1       NO      INACTIVE      2310032

         3      129       52428800     1       NO       CURRENT       2329537

 

注意到此時所有日誌組都沒有完成歸檔（ARCHIVED欄位為NO），所有的 DML事務都將掛起，使用者處於log file switch (archiving needed)等待

出現這種情況一般是由於資料庫異常造成的，可能是因為I/O緩慢，也可能是因為事務量過大，在特殊情況下，有可能是因為日誌損壞。

 

d) unused 表示日誌從未被寫入，這類日誌可能是剛被新增到資料庫或者在resetlogs之後被重置。被使用後，狀態會被改變。

=============================================================

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

有關checkpoint not complete的問題，在如下文件中有解釋

NOTE:147468.1 Title: Checkpoint Tuning and Troubleshooting Guide

Sometimes, you can see in your alert.log file, the following corresponding

messages:

 

Thread 1 advanced to log sequence 248

Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log

Thread 1 cannot allocate new log, sequence 249

Checkpoint not complete

 

 

This message indicates that Oracle wants to reuse a redo log file, but the current checkpoint position is still in that log. In this case, Oracle must wait until the checkpoint position passes that log. Because the incremental checkpoint target never lags the current log tail by more than 90%

of the smallest log file size, this situation may be encountered if DBWR writes too slowly, or if a log switch happens before the log is completely full, or if log file sizes are too small.

When the database waits on checkpoints,redo generation is stopped until thelog switch is done.

 

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24862808/viewspace-735406/，如需轉載，請註明出處，否則將追究法律責任。