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