Re: RE: Fuzzy checkpoints.

If you're really paranoid, there's an onconfig parameter (maybe env?) called something like NOFUZZYCQPT (I forget, sorry). Set it to 1 to switch the fuzzy checkpoints off. Also, you can do a "onmode -c fuzzy"" to force a fuzzy checkpoint, so I guess "onmode -c" would still force a _proper_ checkpoint. >>> William Rice <ricew@operamail.com> 05/03/00 03:38am >>> Comments further in >===== Original Message From kagel@bloomberg.net ===== >Remember that the Physical Log records are not STRICTLY needed for recovery. >They are mostly a paranoid holdover. The physical log slapdown that starts >Fast Recovery makes certain that as much as possible the engine has a clean >slate to reapply the logical log records to. Remember that any delete or >update logical log record set contains a before image of the row and any >INSERT or UPDATE logical log record set contains an after image of the row. >Using ONLY this information the engine can successfully and fully recover >completed transactions and rollback incomplete ones. The only difference >after Fast Recovery with PL slapdown and without PL slapdown should be the >garbage in the unused slots from which inserted rows were rolled back due >to incomplete transactions since the rollback does not know what garbage to >put back while the PL slapdown would have previously cleaned the page (and >if I'm willing to risk a headache I might think hard enough to say that >even that will not be different. > >Most important keep in mind that in Fuzzy Checkpoints ONLY the data page >flushing, and only for built in data types, is skipped. Logical and >physical log records are written BEFORE ANY DATA PAGES ARE MODIFIED and 1. I thought that physical log records were not even written for built in data types. 2. Even were this not the case, after 1 fuzzy checkpoint there is no longer a phyiscal log anyway. So are you essentially saying that a partial write to disk is to negligible to worry about? Or am I missing something which allows the database to recover in the case of a partial write to disk. >only log buffering delays those records getting out to disk between >checkpoints. Because of this the engine will absolutely recover to a >consistent and known state after a crash, indeed to the same state that a >restore would place it, it MAY just take longer and often it will not. > Thank you for any help in understanding this, Will ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------