>>>>> "RR" == Raymond Raymond <[EMAIL PROTECTED]> writes:
RR> Fuzzy checkpointing means checkpoints are asynchronous and occur ant the
RR> same time as new database updates are being made. The general actions
RR> in a fuzzy checkpoint are:
RR> 1. Force log buffer to disk from memory.
RR> 2. To check if there are any buffer still on the checkpoint list form
RR> the previous checkpoint.
RR> If there are any, then write them out to disk.(the list is
RR> supposed to be empty under
RR> some control).
RR> 3. All dirty buffers will be listed in the current checkpoint list.
RR> 4. Gather other useful information.
RR> Once these actions have done, the remainder of the checkpoint can also
RR> proceed in
RR> parallel with future database updates. e.t.: a write process will
RR> examine the checkpoint
RR> list periodically, write some of the buffers on the list to disk and
RR> remove thme from the
RR> list.Under some controls, it is supposed that the list will be empty
RR> just befor the next
RR> checkpoint is taken.
RR> Those are just the general processes of fuzzy checkpointing. I think
RR> we can use some
RR> technic to make it works more efficient. That is what I am trying to
do.^_^.
RR> Anyone has some ideas about that?
Raymond,
What you describe is one implementation of fuzzy checkpointing. The
term fuzzy checkpoint refers to a checkpoint where the checkpointed
pages are not mutually consistent (ref. Gray&Reuter, "Transaction
Processing"). The significant part about fuzzy checkpointing is that
checkpointing occur in parallel with normal activity. Hence, one will
have to apply the log records generated in parallel with the
checkpoint in order to reach a consistent database state. According
to that definition, Derby implements fuzzy checkpointing.
I am not convinced that you will achieve much by your suggested change
to Derby's checkpointing mechanism. If I understand you correctly,
your idea is that by writing out only what was dirty before the
previous checkpoint there will be less work to do. However, this
means that you will have to do recovery from the penultimate
checkpoint. Derby, on the other hand updates the log control file
when the checkpoint has completed. Hence, it will be able to recovery
from the last completed checkpoint. This way, to support a given
recovery time, Derby can have larger checkpoint intervals than your
method. All in all, I am not convinced that the total number of
writes in your case will necessarily be less than for Derby.
--
Øystein
