Roy Hann  writes
>[snip]
>>The starting point on your target database is to drop any secondaries on
>>the target table, look up the filename(s) for the target table in iitables
>>and flush the DMF cache (using trace point DM421 on all DBMS servers, or
>>perform a dummy checkpoint if your CV is not up to date).
>
>Trace point DM1305 on the donor system is what I use for this step (force a
>consistency point).  It doesn't invalidate the cache like DM421, so the
>other users don't get a "blip", and it doesn't mess with the journaling
>system or stall new transactions like a checkpoint.
>
>Roy Hann
>BKB Client/Server (UK) Ltd.
>

From: Ken Richards 

Interesting... Well, DM421 does actually force an immediate flush of
dirty pages to disk. (you can verify this with DM420, by checking the
FORCE counter before and after). It may also invalidate the cache,
however I'm not sure why this would be neccessary. There could be a
blip, however you have to ask yourself what happens during a CP? The
Fast Commit thread is probably going to do exactly the same thing and
more and in fact is a legendary "blipper". 

DM1305 will trigger a CP, however it can mess with the journalling
system (unlike DM421). It notifies the logging system that a CP is
needed, and typically you might expect the Archiver to cut in (using
default of archive on every CP). In fact what happens is that the
Archiver can actually miss his window. (cos he really operates on %log
file filled by journalled records rather than counting CP's). This is
unlikely to be a problem even with a 25% interval, it just means that
when the Archiver is invoked, he might have to do more work. 

Ken Richards

Ingres Q & A

Back to William's Home Page

© William Yuan 2000

Email William