Re: Magic? Or good design?

On Tue, 18 Aug 1998, Neil Truby wrote: > Let's assume I'm backing up a large database server with a level 0 > archive, which will take 2 hours. I kick off the archive at 0400. The > pages that make up the instance are therefore being copied to the > archive tape at anything from 0 to 120 minutes after the start of the > archive. My users continue to update the server while the archive > progresses. The last pages are therefore copied some two hours after the > start of the archive, and may have undergone many updates in that time. > > If I then perform a restore, all pages in the database server will on > completion be in the state they were at 0400, even though they may not > actually have been copied to the tape for two hours after that. > > Briefly, how does the engine achieve this? It does it by design, not magic. And it's hard work, too. Briefly, at each checkpoint that occurs while the system is being archived, the archive process prevents the engine from completing the checkpoint until it is ready. The archive process ensures that it has a back up copy on tape of the original version of every modified page (as it was at the checkpoint prior to the start of the archive) before it allows the engine to complete the checkpoint. IIRC, it uses the physical log to collect the before images of any changed pages. That means that the archive process slows down checkpoint completion while it is running because it has supervise the cleaning of the physical log -- it has to check the pages in the physical log and may have to write some of them to tape before the checkpoint can complete. Note that even if a page is modified several times during the archive, it is only backed up once. The page timestamps are critical in determining which pages need backing up. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn