-
Hi All,
1. I have seen that checkpoints occur when the redo log file is 90% full.
2. Also seen that a checkpoint occurs when there is a log switch.
Am I write if I say that :
- A check point will occur when the log file is 90 % full and AGAIN when it is 100 % full ?
- A check point will happen when manually forcing a log switch ?
Thanks in advance.
If there is no solution, it is because there is no problem - Shadok -
-
90% of smallest redo log file size checkpoints is expected, it's incremental
log switch also cause checkpoints but since incremental checkpoints are occurring very often this "interval" checkpoints are not as heavy as oracle 8
-
From MetaLink:
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, there are a couple of things that cause checkpointing to occur.
They are:
o FAST_START_IO_TARGET init.ora parameter.
o LOG_CHECKPOINT_TIMEOUT init.ora parameter.
o LOG_CHECKPOINT_INTERVAL init.ora parameter.
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.
-
If there is no solution, it is because there is no problem - Shadok -
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|