重做日誌(redo log)相關總結
檢查點是一個資料庫事件,它存在的意義在於減少崩潰恢復時間(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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL重做日誌(redo log)MySql
- redo重做日誌管理
- Oracle11g redo log 建立、新增、刪除(重做日誌組,重做日誌檔案)Oracle
- 【REDO】重做日誌檔案(redo log files)管理(增,刪,改,查,切)
- 【REDO】刪除REDO LOG重做日誌組後需要手工刪除對應的日誌檔案
- 重做日誌檔案的相關操作
- 12C關於CDB、PDB 日誌檔案redo log的總結
- Archived Redo Logs歸檔重做日誌介紹及其優點Hive
- MySQL中Redo Log相關的重要引數總結MySql
- logmnr分析線上重做日誌
- redo log日誌挖掘(二)
- redo log日誌挖掘(一)
- rsyslog日誌總結
- Oracle Redo(重做日誌) 模擬故障和恢復Oracle Redo
- logmnr分析歸檔重做日誌
- 線上重建redo log日誌組
- MySQL 日誌系統 redo log、binlogMySql
- 重做日誌
- 聯機重做日誌、歸檔日誌、備用重做日誌
- 【Mysql】三大日誌 redo log、bin log、undo logMySql
- Oracle調整redo log日誌大小Oracle
- Oracle歸檔日誌比聯機重做日誌小很多的情況總結Oracle
- sqlserver關於日誌傳輸log shipping的總結SQLServer
- 重做日誌管理
- 【聽海日誌】之DATAGUARD新增redo log
- mysql關於redo事務日誌ib_logfile的理解MySql
- mysql日誌:redo log、binlog、undo log 區別與作用MySql
- [Logmnr]對重做日誌進行資料探勘
- 為oracle新增重做日誌組及重做日誌成員Oracle
- 【REDO】刪除聯機重做日誌檔案組的注意事項
- DB2 的事務日誌(redo log)DB2
- Oracle的重做日誌Oracle
- 恢復重做日誌
- mysql關於二進位制日誌binary log的總結MySql
- REDO日誌管理
- 檢查REDO日誌相關資訊並生成HTML檔案的指令碼HTML指令碼
- logstash的安裝使用、收集json日誌、csv日誌總結JSON
- 分散式系統原理--日誌技術Redo Log分散式