Message-ID: <475313CA.8020808@rdtex.ru>
Date: Sun, 02 Dec 2007 23:21:30 +0300
From: Andrey Kriushin <Andrey.Kriushin@rdtex.ru>
Organization: RDTEX J.S.C.
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dannorris@dannorris.com
Cc: sulkdnl@yahoo.com, oracle-l@freelists.org
Subject: Re: Checkpoint in RAC
References: <696342.45756.qm@web35413.mail.mud.yahoo.com>
In-Reply-To: <696342.45756.qm@web35413.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------070002020803060708050604"
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: Andrey.Kriushin@rdtex.ru
--------------070002020803060708050604
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------070002020803060708050604
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: 8bit

<!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@web35413.mail.mud.yahoo.com"
 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>

--------------070002020803060708050604--

--
http://www.freelists.org/webpage/oracle-l