Re: How to make sure I don't write a corrupt page to db when I checkpoint?

On Jul 1, 6:54 pm, Sune <sune_ahlg..._at_hotmail.com> wrote:
> Ok, I'm not mad (yet).
>
> Is there a scheme that has proven itself through research and
> practice, that makes this process lightweight or at least reasonably
> efficient?

If you want to use the same address space to hold both the database data, and the application code, then no, there is no process that fulfills your criteria. Which is precisely why commercial DBMS engines separate the application logic from the data management logic and employ some flavor of inter-process communication.

Even within commercial DBMSs we use checksums, because we're paranoid about our own code. The standard mechanism is to use two: one at the head, and one at the foot of the page. Any code that modifies a page initially sets the header (say) checksum to a known impossible value (say, 0). Then it modifies the page. Then it resets the header to the new checksum. Then it sets the tail checksum to be the same as the header. We even do something similar during disk write operations to ensure that we don't have 'torn' pages (don't rely on your operating system's I/O).

And you have no choice but to 'latch' (not lock) the page during any modification process. Received on Tue Jul 10 2007 - 20:28:09 CEST