The Oracle (tm) Users' Co-Operative FAQ

How have the log_checkpoint_interval and log_checkpoint_timeout changed from version 7 ?


Author's name: Jonathan Lewis

Author's Email: Jonathan@jlcomp.demon.co.uk

Date written: 11th June 2002

Oracle version(s): 8.1

The log_checkpoint_timeout and log_checkpoint_interval have different descriptions in the 8.1 manuals that do not seem to agree with the verions 7 descriptions. How have they changed ?

Back to index of questions


.There was a very important change made to the log_checkpoint_timeout and log_checkpoint_interval parameters in version 8.  (Possibly between 8.0 and 8.1, but I think it was probably between 7.3.4 to 8.0)  

In earlier versions, after log_checkpoint_interval redo blocks had been written by lgwr (or after log_checkpoint_timeout seconds had elapsed) since the last checkpoint), Oracle issued a checkpoint call and dbwr tried to write all currently dirty buffered blocks to disc.  This resulted in an extreme I/O hit from time to time.  

To avoid the extremes, Oracle decided to keep trickling dirty blocks to disc at a higher rate than had been effected by the old 3-second idle write rate (every 3 seconds, dbwr wakes up and writes a few blocks to disc if it has had no other work in the interval).  To achieve this, they changed the meaning of the two log checkpoint parameters. This change was made possible by a change in the architecture of the buffer management, which now allows Oracle to queue dirty buffers in the order that they were first made dirty.

Amongst other things, Oracle already kept a low redo block address (lrba)on each buffer header for each dirty buffer. This identifies the first redo block that started the process of changing that buffered block from the state that is currently on disc to the dirty state that is in the buffer. The function of the log_checkpoint_interval is simply to limit the distance between a buffer's lrba and the addreess of the redo block that lgwr is currently writing. If the lrba is too low, then the block was first dirtied too long ago and it has to be written to disc (and its lrba set to zero). Since Oracle now queues dirty blocks in the order they were first dirtied (i.e. lrba order) it is a quick and cheap process to find such blocks.

For example: if lgwr is currently writing redo block 12,100 and the log_checkpoint_interval is set to 4,000, then dbwr will be cued to write any dirty blocks with an lrba less than 8,100. This check is carried out every 3 seconds, and I believe the control files and possibly any affected data files are updated with the SCN at which this incremental checkpoint took place.

Note, however, that you are no longer supposed to set these parameters. Over the last few versions, Oracle has introduced different ways of controlling the rate at which dirty blocks are written - including fast_start_io_target (8.1 Enterprise Edition), db_block_max_dirty_target, and in Oracle 9 fast_start_mttr_target.


Further reading: Oracle Server Reference


Back to top

Back to index of questions