Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 23 Aug 2005 16:26:21 +0200
From: Oystein.Grovlen@Sun.COM (=?iso-8859-1?q?=D8ystein_Gr=F8vlen?=)
Subject: Re: Can anyone give me some suggestions?
In-reply-to: <BAY17-F357239C6BBFE8A3719ABCB9AB60@phx.gbl>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <x1ofll2sybjm.fsf@atum11.norway.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
Lines: 60
References: <BAY17-F357239C6BBFE8A3719ABCB9AB60@phx.gbl>

>>>>> "RR" == Raymond Raymond <raymond_derby@hotmail.com> 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