Dibyendu Majumdar wrote:
I guess the main difference between ARIES and Derby's method is that in
ARIES, checkpoints happen independently of Buffer Writes. However, in
the end the amount of work done is the same, as the data pages must be
written out anyway.
I do not think it is necessarily true that amount of work will be the
same. Different ways of doing checkpointing may cause a page to be
written for every update or for every tenth update.
1. Make checkpoints lightweight like ARIES? If so, this would require
major changes to recovery logic.
I think the main change would be that it need to be possible to start
the redo activity from any position in the log, not only from the
position of a checkpoint log record.
2. Optimize the IO during checkpoints? I guess if this is the goal, then
one should concentrate on improving the current IO logic - potentially
by ensuring that:
a) IO is non-disruptive - ie - pages are not locked out while they are
being written.
b) IO is optimized - batch write consecutive pages, etc.
c) Have multiple concurrent threads handle IO.
However these changes are useful in large scale environments and will
actually have a negative impact on a small scale system. No point in
increasing IO if there is a single disk, for example.
3. Slow down the IO during checkpoints? I think this is what Mike wants
to do. As far as I know, increasing the time taken to perform a
checkpoint should have no adverse effect. For example, you could reduce
the sleep time between checkpoints but slow down the checkpoint itself.
This way you could keep the total number of pages written fairly
constant without causing peeks of IO.
I think the goal should be, as you state in 3, to spread the disk I/O
evenly over time and avoid bursts of IO when checkpointing.
--
Øystein
