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: [EMAIL PROTECTED] (Ø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*.
