Checkpoint in RAC 2007-12-02 - By Andrey Kriushin
Back
Hi,
Dan Norris wrote:
> Checkpoints are instance events, not database events
That's a very important point.
By using the thread checkpoints the instance "protects" the changes to
the blocks in its own buffer cache from being lost.
Of course, there are some implications in RAC. Especially with the dirty
blocks, which were sent to the other instances due to the cache fusion.
Those blocks are marked with the PI (past image) status in the sending
instance's buffer header, and their checkpointing presumes some
communication with the other instances's DBWRs. I.e. one should decide
which instance's DBWR will checkpoint those blocks, contained in the PI
buffers of checkpointing instance.
Once this issue is resolved, the recovery of the failed instance is
logically straitforward. Goran had given a good schema for that process.
Fortunately, those "cache fussioned" blocks are correctly accounted when
building the recovery set, as the redo logs + GRD contain enough
information (with the cache fusion the log flush occurs before the
modified block is sent to the other instance).
The performance impact (GRD freeze time) should be measured separately.
Though there is a rule of thumb - if you don't have significant impact
of 'gc ...' waits during the normal operation, you'll probably will not
notice that impact at all :-).
The (probably) bad news are that IMU (In-Memory Undo) and private
strands (both are the 10g features, depending on each other) are
switched off for the RAC (though I'm not sure for private strands, but
very likely - sorry, Alex (BAAG). Promise - I'll check that).
-- Andrey
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=KOI8-R" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Dan Norris wrote:
<blockquote cite="mid696342.45756.qm@(protected)"
type="cite">
<style type="text/css"><!-- DIV {margin:0px;} --></style>
<div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;">
<div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"
>Checkpoints
are instance events, not database events<br>
</div>
</div>
</blockquote>
That's a very important point. <br>
<br>
By using the thread checkpoints the instance "protects" the changes to
the blocks in its own buffer cache from being lost.<br>
<br>
Of course, there are some implications in RAC. Especially with the
dirty blocks, which were sent to the other instances due to the cache
fusion. <br>
<br>
Those blocks are marked with the PI (past image) status in the sending
instance's buffer header, and their checkpointing presumes some
communication with the other instances's DBWRs. I.e. one should decide
which instance's DBWR will checkpoint those blocks, contained in the PI
buffers of checkpointing instance.<br>
<br>
Once this issue is resolved, the recovery of the failed instance is
logically straitforward. Goran had given a good schema for that
process. Fortunately, those "cache fussioned" blocks are correctly
accounted when building the recovery set, as the redo logs + GRD
contain enough information (with the cache fusion the log flush occurs
before the modified block is sent to the other instance).<br>
<br>
The performance impact (GRD freeze time) should be measured separately.
Though there is a rule of thumb - if you don't have significant impact
of? 'gc ...' waits during the normal operation, you'll probably will
not notice that impact at all :-).<br>
<br>
The (probably) bad news are that IMU (In-Memory Undo) and private
strands (both are the 10g features, depending on each other) are
switched off for the RAC (though I'm not sure for private strands, but
very likely - sorry, Alex (BAAG). Promise - I'll check that).<br>
<br>
-- Andrey<br>
</body>
</html>
|
|
