?

?

首先我們來看下?alertSID.log?日志：

?

Mon?Nov?30?17:31:54?2009

Thread?1?advanced?to?log?sequence?14214?(LGWR?switch)

??Current?log#?3?seq#?14214?mem#?0:?/u03/oradata/newccs/redo03.log

Mon?Nov?30?17:34:29?2009

Thread?1?advanced?to?log?sequence?14215?(LGWR?switch)

??Current?log#?1?seq#?14215?mem#?0:?/u03/oradata/newccs/redo01.log

Mon?Nov?30?17:35:54?2009

Thread?1?cannot?allocate?new?log,?sequence?14216

Checkpoint?not?complete

??Current?log#?1?seq#?14215?mem#?0:?/u03/oradata/newccs/redo01.log

Mon?Nov?30?17:35:55?2009

Thread?1?advanced?to?log?sequence?14216?(LGWR?switch)

??Current?log#?2?seq#?14216?mem#?0:?/u03/oradata/newccs/redo02.log

Mon?Nov?30?17:40:25?2009

Thread?1?advanced?to?log?sequence?14217?(LGWR?switch)

??Current?log#?3?seq#?14217?mem#?0:?/u03/oradata/newccs/redo03.log

Mon?Nov?30?17:44:22?2009

Thread?1?advanced?to?log?sequence?14218?(LGWR?switch)

??Current?log#?1?seq#?14218?mem#?0:?/u03/oradata/newccs/redo01.log

?

?

我們先來分析下它的原因和后果：

當(dāng)我們進(jìn)行redo 切換的時(shí)候，會(huì)觸發(fā)checkpoint 事件。 觸發(fā)該事件有5個(gè)條件。 下文有說明。 Checkpoint做的事情之一是觸發(fā)DBWn把buffer cache中的Dirty cache磁盤。另外就是把最近的系統(tǒng)的SCN更新到datafile header和control file（每一個(gè)事務(wù)都有一個(gè)SCN），做第一件事的目的是為了減少由于系統(tǒng)突然宕機(jī)而需要的恢復(fù)時(shí)間，做第二件事實(shí)為了保證數(shù)據(jù)庫的一致性。

??????

?????? Checkpoint will flush dirty block to datafile, 從而觸發(fā)DBWn書寫dirty buffer，等到redo log覆蓋的dirty block全部被寫入datafile后才能使用redo log（循環(huán)使用），如果DBWn寫入過慢，LGWR必須等待DBWn完成，則這時(shí)會(huì)出現(xiàn)“checkpoint not completed！”。 所以當(dāng)出現(xiàn)checkpoint? not competed的時(shí)候，還會(huì)伴隨cannot allocate new log的錯(cuò)誤。

??????

?????? 如果遇到這個(gè)問題，可以增加日志組和增大日志文件，當(dāng)然也可以修改 checkpoint參數(shù)使得檢查點(diǎn)變頻繁一些。

?????? 在出現(xiàn)這個(gè)錯(cuò)誤的時(shí)候，數(shù)據(jù)庫是短暫hang住的，等待checkpoint的完成。 在hang住的時(shí)候，沒有日志產(chǎn)生。

?

?

Tom 同學(xué)對(duì)這個(gè)問題的解釋如下：

?

the infamous "checkpoint not complete, cannot allocate new log" message.

?

this occurrs when Oracle attempts to reuse a log file but the checkpoint that would flush

the blocks that may have redo in this log file has not yet completed -- we must wait

until that checkpoint completes before we can reuse that file -- thats when this message is printed.? during this time (when we cannot allocate a new log) processing is suspended in the database while the checkpoint is made to complete ASAP.

-- 我們必須等待checkpoint 的完成， 在這個(gè)過程中， 數(shù)據(jù)庫是短暫的hang住的。

?

The major way to relieve this is to have sufficient log to carry you through peak times.? that way, we can complete the? checkpoint while you are not busy.? also make sure your checkpoints happen as fast as they can (eg: enable ASYNC IO or configure >1 DBWR if ansyc IO cannot be used, make sure disks are not contending with other apps and so on)

?

Another way is to make the log files smaller, hence increasing the frequency with which we checkpoint (log checkpoint interval and other init.ora parameters achieve the same effect btw).

?

?

?

這個(gè)主題使DBA能對(duì)checkpoint和checkpoint優(yōu)化的參數(shù)有一個(gè)較好的理解：

-?FAST_START_MTTR_TARGET
-?LOG_CHECKPOINT_INTERVAL

-?LOG_CHECKPOINT_TIMEOUT
-?LOG_CHECKPOINTS_TO_ALERT

?

它也解釋了怎樣解釋和處理出現(xiàn)在ALERT<sid>.LOG?file中的checkpoint的錯(cuò)誤"'Checkpoint?not?Complete'?and?'Cannot?Allocate?New?Log"。

?

什么是checkpoint

Checkpoint是為了內(nèi)存中已經(jīng)被修改的數(shù)據(jù)塊與磁盤數(shù)據(jù)文件同步的一種數(shù)據(jù)庫事件。它提供了一種保持事務(wù)提交以后數(shù)據(jù)一致的手段。往Oracle磁盤寫臟數(shù)據(jù)的機(jī)制與事務(wù)提交不是同步的。

?

checkpoint有兩個(gè)目的：

1、確保數(shù)據(jù)一致性。

2、使數(shù)據(jù)庫能快速地恢復(fù)。

?

怎樣快速恢復(fù)

因?yàn)閿?shù)據(jù)庫會(huì)把所有的改變都在數(shù)據(jù)文件上設(shè)置checkpoint并一直增加，它不需要請(qǐng)求checkpoint之前的重做日志，Checkpoint能保證所有在緩存區(qū)的數(shù)據(jù)寫到相應(yīng)的數(shù)據(jù)文件，防止因?yàn)橐馔獾膶?shí)例失敗導(dǎo)致的數(shù)據(jù)丟失。

?

Oracle寫這個(gè)臟數(shù)據(jù)只在一定的條件下：
1、DBWR?超時(shí)，大約3秒時(shí)間
2、系統(tǒng)中沒有多的空緩沖區(qū)來存放數(shù)據(jù)
3、CKPT進(jìn)程(產(chǎn)生新的checkpoint）?觸發(fā)DBWR。

?

一個(gè)checkpoint有5中事件類型：
1、每次重做日志的切換；
2、LOG_CHECKPOINT_TIMEOUT?這個(gè)延遲參數(shù)的到達(dá)；
3、相應(yīng)字節(jié)(LOG_CHECKPOINT_INTERVAL*?size?of?IO?OS?blocks)被寫到當(dāng)前的重做日志；
4、ALTER?SYSTEM?SWITCH?LOGFILE?這個(gè)命令會(huì)直接導(dǎo)致checkpoint發(fā)生
5、ALTER?SYSTEM?CHECKPOINT

?

Checkpoint期間會(huì)有下面進(jìn)程發(fā)生：
1.?DBWR寫所有臟數(shù)據(jù)到數(shù)據(jù)文件；
2.?LGWR更新控制文件和數(shù)據(jù)文件的SCN。

?

Checkpoints和優(yōu)化：
Checkpoints是一個(gè)數(shù)據(jù)庫優(yōu)化的難點(diǎn)。頻繁的Checkpoints可以實(shí)現(xiàn)快速的恢復(fù)，但也會(huì)使性能下降。怎樣處理這個(gè)問題呢？

依賴于數(shù)據(jù)庫數(shù)據(jù)文件的數(shù)量，一個(gè)Checkpoint可能是高速的運(yùn)行。因?yàn)樗械臄?shù)據(jù)文件在Checkpoint期間都會(huì)被凍結(jié)。更頻繁的Checkpoints可以快速恢復(fù)數(shù)據(jù)庫。這也客戶對(duì)不按規(guī)定系統(tǒng)宕機(jī)的容忍的原因。然而，在一些特殊情況下，頻繁的Checkpoints也不能保證可以快速恢復(fù)。我們假設(shè)數(shù)據(jù)庫在95%的時(shí)間內(nèi)是正常運(yùn)行，5%由于實(shí)例失敗導(dǎo)致不可用，要求恢復(fù)。對(duì)大多數(shù)客戶而言，他們更希望調(diào)整95%的性能而不是5%的宕機(jī)時(shí)間。這個(gè)假設(shè)表明，性能是擺在第一位的，所以我門的目標(biāo)就是在優(yōu)化期間減少Checkpoints的頻繁度。

?

優(yōu)化Checkpoints包括4個(gè)關(guān)鍵的初始化參數(shù)：

-?FAST_START_MTTR_TARGET
-?LOG_CHECKPOINT_INTERVAL
-?LOG_CHECKPOINT_TIMEOUT
?-?LOG_CHECKPOINTS_TO_ALERT

?

詳細(xì)介紹每個(gè)參數(shù)：

FAST_START_MTTR_TARGET：

Oracle9i以來FAST_START_MTTR_TARGET?參數(shù)是調(diào)整checkpoint的首選的方法。FAST_START_MTTR_TARGET?可以指定單實(shí)例恢復(fù)需要的秒數(shù)?；趦?nèi)部的統(tǒng)計(jì)，增長的checkpoint會(huì)自動(dòng)調(diào)整的checkpint的目標(biāo)以滿足FAST_START_MTTR_TARGET?的需求。

V$INSTANCE_RECOVERY.ESTIMATED_MTTR?顯示當(dāng)前估計(jì)需要恢復(fù)的秒數(shù)。這個(gè)值會(huì)被顯示即使FAST_START_MTTR_TARGET?沒有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR?表明在短時(shí)間內(nèi)MTTR的目標(biāo)。
V$MTTR_TARGET_ADVICE?顯示這個(gè)當(dāng)前MTTR設(shè)置的工作量產(chǎn)生的I/O數(shù)量和其他I/O。這個(gè)視圖幫助用戶評(píng)定這個(gè)在優(yōu)化和恢復(fù)之前的平衡。

?

LOG_CHECKPOINT_INTERVAL：

LOG_CHECKPOINT_INTERVAL?參數(shù)指定這個(gè)最大的重做塊的間隔數(shù)目。如果FAST_START_MTTR_TARGET被指定，LOG_CHECKPOINT_INTERVAL不能被設(shè)置為0。
在大多數(shù)Unix系統(tǒng)的OS塊大小是512字節(jié)。設(shè)置LOG_CHECKPOINT_INTERVAL=10000意味著這個(gè)增長的checkpoint不能追加到當(dāng)前日志，因?yàn)槎嘤?/span>5M。如果你的重做日志是20M，你將發(fā)出4個(gè)checkpoint對(duì)每個(gè)重做日志。

LOG_CHECKPOINT_INTERVAL?會(huì)發(fā)生影響當(dāng)一個(gè)checkpoint發(fā)生時(shí)，小心設(shè)置這個(gè)參數(shù)，保持它隨著重做日志文件大小變化而變化。checkpoint頻繁是這個(gè)影響數(shù)據(jù)庫恢復(fù)的原因之一。短的checkpoint間隔意味數(shù)據(jù)庫將快速恢復(fù)，也增加了資源的利用。這個(gè)參數(shù)也影響數(shù)據(jù)庫向前回滾的時(shí)間。實(shí)際的恢復(fù)時(shí)間是基于這個(gè)時(shí)間，當(dāng)然還有失敗的類型和需要?dú)w檔日志的數(shù)量。

?

?

LOG_CHECKPOINT_TIMEOUT：
這個(gè)參數(shù)指定checkpoint發(fā)出的時(shí)間間隔。換句話說，它指定一次臟數(shù)據(jù)多少時(shí)間寫出一次。checkpoint頻率會(huì)影響這個(gè)數(shù)據(jù)庫恢復(fù)的時(shí)間。長時(shí)間的間隔會(huì)要求數(shù)據(jù)庫恢復(fù)要求更久。Oracle建議用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_TIMEOUT每n秒發(fā)一次checkpoint，不顧事務(wù)提交的頻率。這可能會(huì)導(dǎo)致一些沒有必要的checkpoint在事務(wù)已經(jīng)變化的情況下。不必要的checkpoint必須被避免。還有一個(gè)容易誤解的地方：LOG_CHECKPOINT_TIMEOUT?會(huì)間隔性地發(fā)出log?switch。而Log?switch會(huì)觸發(fā)一個(gè)checkpoint，但checkpoint不會(huì)導(dǎo)致一個(gè)log?switch。唯一手工方式alter?system?switch?logfile或者重新設(shè)置redo?logs大小可以導(dǎo)致頻繁switch。

SQL>?alter?system?set?log_checkpoint_timeout=300;[單位是秒]?

?

log_checkpoint_to_alert：

設(shè)置為真,可以在告警日志中觀察到增量檢查點(diǎn)的觸發(fā)。

SQL>?alter?system?set?log_checkpoints_to_alert=true;?

?

對(duì)于優(yōu)化和恢復(fù),?在線重做日志的大小是關(guān)鍵的。

?

修改Redo?log?大小的操作方法：

查看當(dāng)前日志組狀態(tài)：

SQL>?select?group#,sequence#,bytes,members,status?from?v$log;

?

????GROUP#??SEQUENCE#??BYTES????MEMBERS?STATUS

????----------?----------????----------????----------?----------------

?????????1??????14230???52428800??????????1????ACTIVE

?????????2??????14231???52428800??????????1????CURRENT

?????????3??????14229???52428800??????????1????INACTIVE

?

CURRENT:?表示是當(dāng)前的日志。

INACTIVE：臟數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)塊。該狀態(tài)可以drop。

ACTIVE：?臟數(shù)據(jù)還沒有寫入數(shù)據(jù)塊。

?

查看當(dāng)前日志組成員：

SQL>?select?member?from?v$logfile;

?

MEMBER

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

/u03/oradata/newccs/redo03.log

/u03/oradata/newccs/redo02.log

/u03/oradata/newccs/redo01.log

?

?

添加online?redo?log組：

SQL>?alter?database?add?logfile?group?4?('/u03/oradata/newccs/redo04.log')?size?100m?reuse;

SQL>?alter?database?add?logfile?group?5?('/u03/oradata/newccs/redo05.log')?size?100m?reuse;

SQL>?alter?database?add?logfile?group?6?('/u03/oradata/newccs/redo06.log')?size?100m?reuse;

?

?

切換歸檔日志：

SQL>?alter?system?switch?logfile;

?

?

查看歸檔文件的狀態(tài)，因?yàn)橹挥?span style="font-family:'Times New Roman';">Inactive的我們才可以drop，它的數(shù)據(jù)塊已經(jīng)寫入了數(shù)據(jù)塊。如果是Active狀態(tài)，表示這里的臟數(shù)據(jù)還沒有寫入寫入數(shù)據(jù)庫，手工加個(gè)全局檢查點(diǎn)，督促CKPT馬上喚醒DBWR寫入臟數(shù)據(jù)

SQL>alter?system?checkpoint;

SQL>?select?group#,sequence#,bytes,members,status?from?v$log;

????GROUP#??SEQUENCE#??BYTES????MEMBERS?STATUS

????----------?----------????----------????----------?----------------

?????????1??????14230???52428800??????????1????ACTIVE

?????????2??????14231???52428800??????????1????ACTIVE

?????????3??????14229???52428800??????????1????INACTIVE

? ?4??????14229???52428800??????????1????CURRENT

?5??????14229???52428800??????????1????UNUSED

? ?6??????14229???52428800??????????1????UNUSED

?

因?yàn)?span style="font-family:'Times New Roman';">5，6?我們還沒有用，所以顯示為UNUSED

?

刪除redo?log組：

SQL>?alter?database?drop?logfile?group?1;

Database?altered.

或者：

SQL>?alter?database?drop?logfile?'/u03/oradata/newccs/redo01.log';

?

在添加redo?log?group?1.?

SQL>?alter?database?add?logfile?group?1?('/u03/oradata/newccs/redo01.log')?size?100m?reuse;

?

通過刪除在添加，達(dá)到對(duì)redo?log?group?的resize.?

?

注意兩點(diǎn)
1.?單純加redo?log?group單個(gè)文件的大小沒有作用，同一個(gè)group里，文件大小都是一致的。

2.?如果是歸檔模式的話，確保已經(jīng)自動(dòng)歸檔，如果手動(dòng)歸檔的話，需要在alter?system?switch?logfile鎖死的時(shí)候，用alter?system?log?current?來手動(dòng)歸檔?；蛘咄ㄟ^alter?system?archive?log?start打開自動(dòng)歸檔。否則的話，當(dāng)redo?log?group切換完整個(gè)groups的時(shí)候，會(huì)一直等待狀態(tài)(******).?

?

3. 《Oracle DBA必備技能詳解》（Robert G.Freeman）,上面建議redo log 最好是15分鐘切換一次

?

轉(zhuǎn)載于:https://www.cnblogs.com/Hiberniane/archive/2009/11/30/2488772.html

總結(jié)

以上是生活随笔為你收集整理的Redo Log 和Checkpoint not complete的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。