RE: Fuzzy checkpoints.

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/ ------------------------------------------------------------

William Rice wrote: > > 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. ALL modified pages have their pre-image written to the physical log the first time they are touched after a checkpoint. > 2. Even were this not the case, after 1 fuzzy checkpoint there is no longer > a phyiscal log anyway. HUH? There is still a Physical Log for non-fuzzy operations. For Fuzzy Operations Informix has modified the Fast Recovery operation to make physical log pages unneccessary (even in the presence of partial writes!). Now Fast Recovery begins NOT with the last checkpoint, as it did before Fuzzy Checkpointing, but with the OLDEST operation in the logical logs. This assures that the fast recovery is operating on a consistent page on disk as the page MUST have been completely written before that oldest operation was written to the logical log. This is guaranteed because if the logical log file containing the last sync (full) checkpoint is about to be reused a sync checkpoint is forced which forces all datapages to disk. Even if a page were subsequently partially written all parts of that page are either on disk as they finally appeared because they have not been modified since the page was last written or because that part will be corrected by reapplying some logical log record. So by making this one change in the fast recovery operation my original claim that physical logging is not needed is now true. Damn, I finally understand where I went wrong and they make me right again. Art S. Kagel > 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/ > ------------------------------------------------------------