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: domain of raymond_derby@hotmail.com
 designates 64.4.43.71 as permitted sender)
Message-ID: <BAY17-F218527600161688A347F279AB20@phx.gbl>
In-Reply-To: <x1of1x4r30hx.fsf@atum11.norway.sun.com>
From: "Raymond Raymond" <raymond_derby@hotmail.com>
To: derby-dev@db.apache.org
Subject: Re: Re: Can anyone give me some suggestions?
Date: Thu, 18 Aug 2005 16:48:04 -0300
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Oystein.Grovlen,Thanks your for your suggestions. It is exactly what I am 
thinking
about.I am considering two aspects of the checkpointing issue.
1. How to make the engine tune the interval of checkpointing by itsself. I 
think
It depends on the database buffer size, log buffer size and how many dirty 
pages in the
database buffer. And you give me a good suggestion about the machine 
performance
factor. I will take that into account.
2. Although the derby implemeted ARIES algorithsm in its recovery function, 
it did not
adopt fuzzy checkpointing. The current checkpointing approach is not very 
efficient, just
as what you said, it will interfere with updates requires from other 
transactions. I am
trying to find a better way to do that.

Anyone else has any good ideas about that?^_^.


Raymond


>From: Oystein.Grovlen@Sun.COM (�ystein Gr�vlen)
>
>Currently, you can configure the checkpoint interval and log file size
>of Derby by setting the properties:
>
>derby.storage.logSwitchInterval  (default 1 MB)
>derby.storage.checkpointInterval (default 10 MB)
>
>(None of these seems to be documented in the manuals, and the JavaDoc
>for LogFactory.recover() gives wrong (out-dated?) defaults).
>
>This means that by default all log files will be 1 MB, and a checkpoint
>is made for every tenth log file.
>
>In order to know when it is useful to change the defaults, one has to
>consider the purpose of a checkpoint:
>
>   1) Reduced recovery times.  Only log create after the penultimate
>      checkpoint needs to be redone at recovery.  This also means that
>      older log files may be garbage-collected (as long as they do not
>      contain log records for transactions that are still not
>      terminated.)
>
>      To get short recovery times, one should keep the checkpoint
>      interval low.  The trade-off is that frequent checkpoints will
>      increase I/O since you will have less updates to the same page
>      between two checkpoints.  Hence, you will get more I/O per
>      database operation.
>
>   2) Flush dirty pages to disk.  A checkpoint is a much more efficient
>      way to clean dirty pages in the db cache than to do it on demand
>      on a single page when one need to replace it with another.
>      Hence, one should make sure to do checkpoints often enough to
>      avoid that the whole cache is dirty.
>
>Based on 2), one could initiate a new checkpoint when many pages in
>the cache are dirty (e.g., 50% of the pages) and postpone a checkpoint
>if few pages are dirty.  The difficult part would be to determine how
>long checkpoint intervals is acceptable with respect to impact on
>recovery times.
>
>I guess one could argue that for recovery times, it is the clock time
>that matters.  Hence, one could automatically increase the value of
>derby.storage.checkpointInterval on more performant computers since it
>will be able to process more log per time unit.
>
>When would want to change the log switch interval?  I think few would
>care, but since the log files per default are preallocated, space will
>be wasted if operations that perform a log switch (e.g., backup) is
>performed when the current log file is nearly empty.  On the other
>hand, a small log file size will result many concurrent log files if
>the checkpoint interval is very large.
>
>Hope this helps a little,
>
>--
>�ystein
>

_________________________________________________________________
Scan and help eliminate destructive viruses from your inbound and outbound 
e-mail and attachments. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN� Premium right now and get the 
first two months FREE*.