aid repeat 但我 方案 activit follow ade complete 條件

報錯信息：

Thread 1 cannot allocate new log, sequence 187398
Checkpoint not complete

處理方法：

查看REDO日誌組

select group#,member from v$logfile;

select group#,sequence#,bytes,members,status from v$log; 查看每組日誌的狀態

alter database add logfile group 4 (‘/opt/oradata/orclbj/redo04.log‘) size 200M; 增加1組日誌組 視情況而定增加日誌組的大小。

alter database add logfile group 5 (‘/opt/oradata/orclbj/redo05.log‘) size 200M;
alter database add logfile group 6 (‘/opt/oradata/orclbj/redo06.log‘) size 200M;
3、alter system switch logfile; 切換日誌組

4、alter database drop logfile group 1; 刪除日誌組1 在線增加日誌組的時候，刪除日誌組的時候只能刪除 日誌組狀態為 INACTIVE 的日誌組。

5、alter database add logfile group 1 (‘/opt/oradata/orclbj/redo1.log‘) size 200M;--新創建的為redo1,上一步drop掉的為redo01

拓展內容：

Thread 1 cannot allocate new log, sequence 2594
Checkpoint not complete
這個實際上是個比較常見的錯誤。通常來說是因為在日誌被寫滿時會切換 日誌組，這個時候會觸發一次checkpoint，DBWR會把內存中的臟塊往數據文件中寫，只要沒寫結束就不會釋放這個日誌組。如果歸檔模式被開啟的 話，還會伴隨著ARCH寫歸檔的過程。如果redo log產生的過快，當CPK或歸檔還沒完成，LGWR已經把其余的日誌組寫滿，又要往當前的日誌組裏面寫redo log的時候，這個時候就會發生沖突，數據庫就會被掛起。並且一直會往alert.log中寫類似上面的錯誤信息。

警告消息中也可能指出Archival required而不是Checkpoint not complete，但是效果幾乎都一樣。必須當心這種情況。如果數據庫試圖重用一個在線重做日誌文件，但是發現做不到，就會把這樣一條消息寫到服務器上的alert.log中。如果DBWR還沒有完成重做日誌所保護數據的檢查點(checkpointing)，或者ARCH還沒有把重做日誌文件復制到歸檔目標，就會發生這種情況。對最終用戶來說，這個時間點上數據庫實際上停止了。它會原地不動。DBWR或ARCH將得到最大的優先級以將redo塊刷新輸出到磁盤。完成了檢查點或歸檔之後，一切又回歸正常。數據庫之所以暫停用戶的活動，這是因為此時已經沒地方記錄用戶所做的修改了。Oracle試圖重用一個在線重做日誌文件，但是由於萬一出現失敗而要恢復數據庫時可能還需要這個文件(Checkpoint not complete)，或者由於歸檔進程尚未完成這個文件的復制(Archival required)，所以Oracle必須等待(相應地，最終用戶也必須等待)，直到能安全地重用這個重做日誌文件為止。
　　如果你看到會話因為一個“日誌文件切換”、“日誌緩沖區空間”或“日誌文件切換檢查點或歸檔未完成”等待了很長時間，就很可能遇到了這個問題。如果日誌文件大小不合適，或者DBWR和ARCH太慢，在漫長的數據庫修改期間，你就會註意到這個問題。
　　要解決這個問題，有下面幾種做法
　　.讓DBWR更快一些。讓DBA對DBWR調優，為此可以啟用ASYNC I/O、使用DBWR I/O從屬進程，或者使用多個DBWR進程。看看系統產生的I/O，查看是否有一個磁盤(或一組磁盤)“太熱”，相應地需要將數據散布開。這個建議對ARCH也適用。這種做法的好處是，不用付出什麽代價就能有所收獲，性能會提高，而且不必修改任何邏輯/結構/代碼。這種方法確實沒有缺點。
　　.增加更多重做日誌文件。在某些情況下，這會延遲Checkpoint not complete的出現，而且過一段時間後，可以把Checkpoing not complete延遲得足夠長，使得這個錯誤可能根本不會出現。這個方法也同樣適用於Archival required消息。這種方法的好處是可以消除系統中的“暫停”。其缺點是會消耗更多的磁盤空間，但是在此利遠遠大於弊。
　　.重新創建更大的日誌文件。這會擴大填寫在線重做日誌與重用這個在線重做日誌文件之間的時間間隙。如果重做日誌文件的使用呈“噴射狀”，這種方法同樣適用於Archival required消息。倘若一段時間內會大量生成日誌(如每晚加載、批處理等)，其後一段時間卻相當平靜，如果有更大的在線重做日誌，就能讓ARCH在平靜的期間有足夠的時間“趕上來”。這種方法的優缺點與前面增加更多文件的方法是一樣的。另外，它可能會延遲檢查點的發生，由於每個日誌切換都會發生檢查點，而現在日誌切換間隔會更大。
　　.讓檢查點發生得更頻繁、更連續。可以使用一個更小的塊緩沖區緩存，或者使用諸如FAST_START_MTTR_TARGET、LOG_CHECKPOINT_INTERVALT和LOG_CHECKPOINT_TIMEOUT之類的參數設置。這會強制DBWR更頻繁地刷新輸出臟塊。這種方法的好處是，失敗恢復的時間會減少。在線重做日誌中應用的工作肯定更少。其缺點是，如果經常修改塊，可能會更頻繁地寫至磁盤。緩沖區緩存本該更有效的，但由於頻繁地寫磁盤，會導致緩沖區緩存不能充分發揮作用。
　　究竟選擇哪一種方法，這取決於你的實際環境。應該在數據庫級確定它，要把整個實例都考慮在內。

產生此問題的原因分析：

CKPT這個後臺進程的就是做checkpoint這件事，checkpoint被觸發的條件之一是就發生redo log switch，Checkpoint的具體工作包括：
• 觸發DBWn向磁盤寫入Dirty data。
• 把checkpoint信息更新到datafile header上。
• 把checkpoint信息更新到control file裏。

Checkpoint做的事情之一是觸發DBWn把buffer cache中的Dirty cache磁盤。另外就是把最近的系統的SCN更新到datafile header和control file（每一個事務都有一個SCN），做第一件事的目的是為了減少由於系統突然宕機而需要的恢復時間，做第二件事實為了保證數據庫的一致性。 　　而redo log switch就是觸發checkpoint的主要的事件(event) ，當第一組redo log被用完之後，Oracle就要停止使用當前的redo log，轉而使用另一組redo log，這就叫做log switch。而log switch觸發checkpoint。 　　Oracle要求的最少的redo group 的是2個，但我們一般都建議配置3個或3個以上redo log group。假設我們只有兩個redo log group：group 1和group 2，並且系統中總是有大量的dirty block需要寫入datafile，當我們從group 1 switch to group 2的時候，會觸發checkpoint, checkpoint要求DBWn把buffer cache中的dirty block寫入datafile，然而，當我們再次用完group 2裏面的空間，需要再次switch to group 1並重用group 1的時候，如果我們發現redo log group 1所保護的那些dirty block還沒有完全寫入到datafile，整個數據庫必須等待DBWn把所有的dirty block寫入到datafile之後才能做其他的事情，這就是我們遇到的“checkpoint not complete”問題。這個問題往往暗示了redo log的配置有問題，就本例而言，要麽是redo log太小，要麽是像我們這裏的redo log group太少，只有2個。而這個問題的解決方案就是加大redo log或添加更多redo log group，不管哪一種解決方案，我們的目的都是給DBWn爭取更多的時間。

（

參考其它解釋如下：
當系統要重新利用某個日誌文件的時候，系統需要將該日誌文件所 包括的buffer cache 中的dirty block 寫到相應的數據文件。由於對於一個數據庫操作而言，它可能產生的redo 量僅僅是幾十字節，但是對於buffer cache中確是一個block （一般為8k）。所以，對於一個僅僅是幾百M的日誌文件，它所保護的buffer cache 可能是幾個G
一旦發生"Thread 1 cannot allocate new log"，表明系統的checkpoint 沒有來得及完成，也就是說 buffer cache 中的dirty data還沒有完全寫到數據文件，就已經有大量的日誌需要寫入到系統。而系統只能通知應用：checkpoint 還沒有完成，你只能等待。這個時候，系統就基本處於hang 狀態了 When the database waits on checkpoints,redo generation is stopped until the
log switch is done
如果，我們在這個時候查看系統信息，就會發現：v$log中的日誌狀態大多處於active 狀態； v$session_wait 中會有很多log file switch 事件的發生

）

解決辦法：

a. 添加更多的日誌文件

b. 加大checkpoint 觸發的頻度

c. 減小redo log 的size

d. 提高DBWR的效率

e. 為了更好的了解系統的運行，可以設置

log_checkpoint_interval = 0 log_checkpoint_timeout = 0 log_checkpoints_to_alert=True

參考資料：

這個主題使DBA能對checkpoint和checkpoint優化的參數有一個較好的理解:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

它也解釋了怎樣解釋和處理出現在ALERT.LOG file中的
checkpoint的錯誤"‘Checkpoint not Complete‘ and ‘Cannot Allocate New Log"

什麽是checkpoint?

checkpoint是為了內存中已經被修改的數據塊與磁盤數據文件同步的一種數據庫事件。它提供了一種
保持事務提交以後數據一致的手段。往Oracle磁盤寫臟數據的機制與事務提交不是同步的。

checkpoint有兩個目地：1.確保數據一致性。2.使數據庫能快速地恢復。怎樣快速恢復呢?
因為數據庫會把所有的改變都在數據文件上設置checkpoint,並一直增加，它不需要請求checkpoint
之前的重做日誌.Checkpoint能保證所有在緩存區的數據寫到相應的數據文件，防止因為意外的實例
失敗導致的數據丟失。

Oracle寫這個臟數據只在一定的條件下：
後面的進程需要1/4個db_block_buffer參數的大小
每三秒
當一個checkpoint產生

一個checkpoint有5中事件類型：
每次重做日誌的切換
LOG_CHECKPOINT_TIMEOUT 這個延遲參數的到達。
相應字節(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被寫到當前的重做日誌

IO OS blocks: 在UNIX下可以 # fstyp -v /dev/vg00/lvol1
vxfs
version: 5
f_bsize: 8192

ALTER SYSTEM SWITCH LOGFILE 這個命令會直接導致checkpoint發生
ALTER SYSTEM CHECKPOINT

Checkpoint期間會有下面進程發生:
DBWR寫所有臟數據到數據文件
LGWR更新控制文件和數據文件的SCN

Checkpoints和優化
Checkpoints是一個數據庫優化的難點。頻繁的Checkpoints可以實現快速的恢復，但也會使性能
下降。DBA怎樣處理這個問題呢？

依賴於數據庫數據文件的數量，一個Checkpoint可能是高速的運行。因為所有的數據文件在Checkpoint
期間都會被凍結。更頻繁的Checkpoints可以快速恢復數據庫。這也客戶對不按規定系統宕機的容忍的原因。
然而，在一些特殊情況下，頻繁的Checkpoints也不能保證可以快速恢復。我們假設數據庫在95%的時間
內是正常運行，5%由於實例失敗導致不可用，要求恢復。對大多數客戶而言，他們更希望調整95%
的性能而不是5%的宕機時間。

這個假設表明，性能是擺在第一位的，所以我門的目標就是在優化期間減少Checkpoints的頻繁度。

優化Checkpoints包括4個關鍵的初始化參數：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

詳細介紹每個參數:
FAST_START_MTTR_TARGET

Oracle9i以來FAST_START_MTTR_TARGET 參數是調整checkpoint的首選的方法。
FAST_START_MTTR_TARGET 可以指定單實例恢復需要的秒數。基於內部的統計，增長的
checkpoint會自動調整的checkpint的目標以滿足FAST_START_MTTR_TARGET 的需求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 顯示當前估計需要恢復的秒數。這個值會被顯示
即使FAST_START_MTTR_TARGET 沒有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR 表明在短時間內MTTR的目標。
V$MTTR_TARGET_ADVICE 顯示這個當前MTTR設置的工作量產生的I/O數量和其他I/O。
這個視圖幫助用戶評定這個在優化和恢復之前的平衡。

LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 參數指定這個最大的重做塊的間隔數目。
如果FAST_START_MTTR_TARGET被指定，LOG_CHECKPOINT_INTERVAL不能被設置為0.

在大多數Unix系統的OS塊大小是512字節。設置LOG_CHECKPOINT_INTERVAL=10000意味著
這個增長的checkpoint不能追加到當前日誌因為多於5M。如果你的重做日誌是20M，你將
發出4個checkpoint對每個重做日誌。

LOG_CHECKPOINT_INTERVAL 會發生影響當一個checkpoint發生時，小心設置這個參數，
保持它隨著重做日誌文件大小變化而變化。checkpoint頻繁是這個影響數據庫恢復的原因之一。
短的checkpoint間隔意味數據庫將快速恢復，也增加了資源的利用。

這個參數也影響數據庫向前回滾的時間。實際的恢復時間是基於這個時間，當然還有失敗的類型和
需要歸檔日誌的數量。

LOG_CHECKPOINT_TIMEOUT
這個參數指定checkpoint發出的時間間隔。換句話說，它指定一次臟數據多少時間寫出一次。

checkpoint頻率會影響這個數據庫恢復的時間。長時間的間隔會要求數據庫恢復要求更久。
Oracle建議用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT
,LOG_CHECKPOINT_TIMEOUT每n秒發一次checkpoint,不顧事務提交的頻率。這可能會導致一些
沒有必要的checkpoint在事務已經變化的情況下。不必要的checkpoint必須被避免。

還有一個容易誤解的地方：LOG_CHECKPOINT_TIMEOUT 會間隔性地發出log switch。
而Log switch會觸發一個checkpoint,但checkpoint不會導致一個log switch.唯一手工方式
alter system switch logfile或者重新設置redo logs大小 可以導致頻繁switch.

在線重做日誌的大小是關鍵的對於優化和恢復。

解決方法:

If redo logs switch every 3 minutes, you will see performance degradation.
This indicates the redo logs are not sized large enough to efficiently handle
the transaction load.

size of the redolog files.
Using Statspack to determine Checkpointing problems

Statspack snapshots can be taken every 15 minutes or so, these reports gather useful
information about number of checkpoints started and checkpoints completed and number
of database buffers written during checkpointing for that window of time . It also contains
statistics about redo activity. Gathering and comparing these snapshot reports gives you
a complete idea about checkpointing performance at different periods of time.

Another important thing to watch in statspack report is the following wait events,
they could be a good indication about problems with the redo log throughput and checkpointing:

log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync

In the case when one or more of the above wait events is repeated frequently
with considerable values then you need to take an action like adding More
online redo log files or increasing their sizes and/or modifying checkpointing parameters

Thread 1 cannot allocate new log, sequence 187398