首页 > 数据库 > 8i Parameters that Influence Checkpoints

8i Parameters that Influence Checkpoints

2006年2月24日 1,991 views 发表评论 阅读评论
Subject: 8i Parameters that Influence Checkpoints
Doc ID: Note:76713.1 Type: TROUBLESHOOTING
Last Revision Date: 20-OCT-2005 Status: PUBLISHED

SCOPE & APPLICATION

  This article can be used by DBAs on Oracle8.1.X.

Purpose:
========

The purpose of this article is to explain what 8i parameters effect
checkpoints in Oracle 8i.

Scope & Application:
====================

This article is meant as an Oracle 8i tuning aid.

8i Parameters that Influence Checkpoints:
=========================================

In Oracle8i, checkpoints occurr at every log switch but there are a few INIT.ORA
parameters that may affect the functionality/frequency of checkpointing.
  They are:

  o FAST_START_IO_TARGET 
  o LOG_CHECKPOINT_TIMEOUT 
  o 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 is in terms of OS blocks.
  o Size of the smallest log.

Oracle continually calculates where the checkpoint position must be in
order to satisfy these things, and writes dirty buffers in order of age
to advance the checkpoint position such that all of these targets are
met.  When it advances the checkpoint, it does not advance it to the end
of the log.  Rather, it advances it far enough to satisfy all of the
targets corresponding to the items above.

FAST_START_IO_TARGET:  

  Oracle continually calculates the number of IO operations that would be 
  required to perform roll-forward should the database fail.  If this number 
  is greater than FAST_START_IO_TARGET, Oracle writes dirty buffers and 
  advances the checkpoint to satisfy this target.  FAST_START_IO_TARGET is 
  only useable on 8i Entreprise Edition.

LOG_CHECKPOINT_TIMEOUT:  

  Assume this is set to 60.  Oracle continually calculates the address of the 
  redo record that was written 60 seconds ago.  In order to satisfy this 
  parameter, the checkpoint position must advance at least as far as this redo 
  record.  Should the checkpoint position point to a redo record older than 
  this target position (written over 60 seconds ago), Oracle writes dirty 
  buffers and advances the checkpoint until it points at a redo record written 
  less than 60 seconds ago.  Should the checkpoint position point to a redo 
  record newer than this target position (written less than 60 seconds ago), 
  Oracle does nothing to satisfy this target for it is already satisfied.

LOG_CHECKPOINT_INTERVAL:  

  Assume this is set to 1000.  Oracle continually calculates the address of 
  the redo record that was written 1000 records (OS blocks) ago.  In order to 
  satisfy this parameter, the checkpoint position must advance at least as far 
  as this redo record.  Should the checkpoint position point to a redo record 
  written earlier than this target position (written over 1000 records before 
  the record at the end of the log), Oracle writes dirty buffers and advances 
  the checkpoint until it points at a redo record written less than 1000
  records ago.  Should the checkpoint position point to a redo record newer
  than this target position (written less than 1000 records ago), Oracle does 
  nothing to satisfy this target for it is already satisfied.

SIZE OF THE SMALLEST REDO LOG:  

  Oracle forces LOG_CHECKPOINT_INTERVAL to be no greater than 90% of the size 
  of the smallest log file.  This guarantees that when Oracle tries to do a log
  switch because it has filled a redo log file, the checkpoint position will 
  have advanced into this current log.  Should you only have two logs (the 
  worst case), Oracle does not have to stall while the checkpoint advances out 
  of the soon to be reused log.

So, when Oracle does a checkpoint due to a log switch, it does not really
have to do anything.  The checkpoint position is already advanced out of the 
soon to be reused log.  The log switch checkpoint does not actually do 
anything right away.  It is a "zero priority" checkpoint: it does not cause 
any writes to happen on its own, but is marked as complete only when 
checkpointing for other reasons causes the checkpoint position to advance 
beyond the rba that marked the end of the log when the checkpoint was initiated. 

Example:
--------

Assume you have two logs, A and B.  When B fills, Oracle initiates a zero
priority checkpoint to advance the checkpoint position to the end of log B. 
However, because the checkpoint position is no more than 90% of the size of 
the smallest log behind the end of the log, the checkpoint position is roughly 
10% of the way into log B when this checkpoint is initiated.  There is no 
reason to do any writes, as log A can be reused immediately.  So Oracle does 
nothing and lets the checkpoint position continue to advance based upon other 
factors.  When the other factors cause the checkpoint position to advance 
beyond the end of log B, the zero priority checkpoint previously initiated is
declared complete and you see the checkpoint complete message.

Note:  If you manually switch log files, the checkpoint position may not 
       have advanced out of the log to be reused.  In this case, Oracle
       initiates a real checkpoint and advances the checkpoint position
       up to the rba that marked the end of the log when the checkpoint 
       was initiated.

References:
===========

Note 147468.1 : CHECKPOINT TUNING AND TROUBLESHOOTING GUIDE
 » 如果喜欢可以: 点此订阅本站
分类: 数据库 标签: ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.