Re: Discussion of incremental checkpointing----Added some new content

[Øystein Grøvlen]

Suresh Thalamati wrote:
I agree, it will be nice to have checkpoints(light checkpoint) that does 
not need to flush whole cache to the disk, especially when the cache is 
configured to be very large. I also remember reading about it long time 
ago some where. I think the basic idea is to keep track of the highest 
LSN of the pages that got flushed to the disk and at checkpoint flush 
any pages with LSN lesser than are still in the cache, this might be 
achieved by keeping first LSN that updated the page , in addition to the 
last LSN that currently used to flush the log when page is written to 
the disk. Main difference between the current check point and this one 
will be REDO Low Water Mark can be long before the checkpoint log 
record. In the worst case scenario it will be same as the current 
checkpoint.

Correct, and that is why I think the checkpoint should make sure to 
write the oldest pages.  That way, you will advance the REDO Low Water Mark.


Changing the page writes to synhcronous using "rwd" is good idea when 
cache is large. In small cache sizes like the default of 1000 pages ,
it might be problem  because user request for a empty page is likely to 
trigger foreground sync writes.


The right way to avoid this is to make sure that the background writer 
is so efficient that this is a rare scenario.  In order to achieve this, 
one may need several threads to do background writing.  If one is still 
worried about the effects on user transactions, one could make the disk 
write asynchronous to the user threads by doing the writing in another 
thread, and allowing the cache to temporarily grow so that the user 
thread can immediately read in the requested page.  (This is basically 
what is done today except that one use memory in the file system buffer 
for the page to be written instead of on the Java heap.)

--
Øystein