db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Raymond" <raymond_de...@hotmail.com>
Subject Some idea about automatic checkpointing issue
Date Thu, 27 Oct 2005 01:41:28 GMT
Oystein wrote:
>
>I would like to suggest the following:
>         - 1. The user may be able to configure a certain recovery time
>           that Derby should try to satisfy.  (An appropriate default
>           must be determined).
>         - 2. During initilization of Derby, we run some measurement that
>           determines the performance of the system and maps the
>           recovery time into some X megabytes of log.)
>         - 3. A checkpoint is made by default every X megabytes of log.
>         - 4. One tries to dynamically adjust the write rate of the
>           checkpoint so that the writing takes an entire checkpoint
>           interval.  (E.g., write Y pages, then pause for some time).
>         - 5. If data reads or a log writes (if log in default location)
>           start to have long response times, one can increase the
>           checkpoint interval.  The user should be able to turn this
>           feature off in case longer recovery times are no acceptable.
>
>Hope this rambling has some value,
>
>--
>Řystein
>
Thanks for Oystein's comment. I agree with your comment
and I have any other thought about it. In order to be easier
to explain,I added the sequence number to your comment.

In step 3 and 4 I have another idea. Generally, we do checkpointing
from the earliest useful log record which is determined by the
repPoint and the undoLWM, whichever is earlier, to the current
log instant (redoLWM) and then update the derby control file(ref. 
http://db.apache.org/derby/papers/recovery.html). I agree with
you to spread the writes out over the checkpoint interval, but the
trade-off is that we have to do recovery from the penultimate
checkpoint(Am I right here?^_^). If the log is long, it will take us
a long time in recovery. How about we update the derby control
file periodically instead updating the control file when the whole
checkpoint is done? (E.g. write several pages, if we detect that the
system is busy, then we update the derby control file and pause for
some time or we update the control file once every several minutes)
That seems we do a part of checkpoint at a time if the system
become busy. In this way, if the system crushes, the last checkpoint
mark (the log address up to where the last checkpoint did)will be
closer to the tail of the log than if we update the control file when
the whole checkpoint is done. Maybe we can call it Incremental
Checkpointing.

I will keep thinking of this issue to find a good way to do it. Welcome
everyone gives your comment.

Thanks.


Raymond

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


Mime
View raw message