今天發現alter.log有以下信息:
Thread 1 cannot allocate new log, sequence 6166
Private strand flush not complete
對于這個錯誤信息得解釋如下:
當系統要重新利用某個日志文件的時候,系統需要將該日志文件所包括的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
9i以后可能大家都喜歡通過設置fast_start_mttr_target來控制instance
recovery的粒度。但是仍然有兩個參數一直影響著我們的checkpoint,就是他們:
log_checkpoint_interval
Oracle8.1版本后log_checkpoint_interval指的是兩次checkpoint之間操作系統數據塊的個數。checkpoint時Oracle把內存里修改過的數據塊用DBWR寫到物理文件,用LGWR寫到日志和控制文件(在8i的時候lgwr進程在兼有ckpt進程的作用,呵呵。為了減輕我們本來就可能在高壓情況下疲于奔命的LGWR兄弟的負擔,Oracle引入了ckpt來更新我們的控制文件和數據文件頭的SCN信息)。
一般UNIX操作系統的數據塊為512bytes。
從性能優化的角度來說,建議log_checkpoint_interval=redologfilesizebytes
/ 512bytes,根據我們的online redo?file的大小來指定我們數據塊的個數.
from
concept:
LOG_CHECKPOINT_INTERVAL specifies the frequency of
checkpoints(用來指定檢查點發生的頻率) in terms of the number of redo log file blocks that
can exist between an incremental checkpoint and the last block written to the
redo log. This number refers to physical operating system blocks, not database
blocks.
Regardless of this value, a checkpoint always occurs when switching
from one online redo log file to another. Therefore, if the value exceeds the
actual redo log file size, checkpoints occur only when switching logs.
Checkpoint frequency is one of the factors that influence the time
required for the database to recover from an unexpected
failure.
log_checkpoint_timeout
Oracle8.1版本后log_checkpoint_timeout指的是兩次checkpoint之間時間秒數(單位是秒)。
Oracle建議不用這個參數來控制,因為事務(transaction)大小不是按時間等量分布的(事務的長短并不是最重要的,重要的是我們的業務邏輯和數據的完整性)。那么我們用log_checkpoint_interval參數控制會更好一些。
我們可以通過log_checkpoint_timeout=0來禁用此參數或者按默認的900。
LOG_CHECKPOINT_TIMEOUT
specifies (in seconds) the amount of time that has passed since the incremental
checkpoint at the position where the last write to the redo log (sometimes
called the tail of the log) occurred. This parameter also signifies that no
buffer will remain dirty (in the cache) for more than integer
seconds.
Specifying a value of 0 for the timeout disables time-based
checkpoints. Hence, setting the value to 0 is not recommended unless
FAST_START_MTTR_TARGET is set.