RE: Fuzzy checkpoints.

<SNIP> >> 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. Admin Guide for IDS 2000 Page 623(21-5) ++++++++++++++++++++++++++++++++++++++++++++++++++++++ Database Server Activity That Is Physically Logged All dbspace page modifications except the following ones are physically logged: --- Pages that do not have a valid database server address This situation usually occurs when the page was used by some other database server or a table that was dropped. --- Pages that the database server has not allocated and that are located in a dbspace where no table has been dropped since the last checkpoint. --- Pages for fuzzy operations such as inserts, deletes, and updates. In case of multiple modifications before the next checkpoint, only one before-image is logged in the physical log (the first before-image). Storing all before-images of page modifications in the physical log might seem excessive. But the database server stores the before-images in the physical log only until the next checkpoint. To control the amount of data that the database server logs, you can tune the checkpoint interval configuration parameter CKPTINTVL. Physical Logging and Simple Large Objects ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 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. After any checkpoint the physical log pointer is moved to the end of the physical log, hence blowing away any pages in it. Admin Guide for IDS 2000 page 649(23-9) +++++++++++++++++++++++++++++++++++++++++++++++++++ Sequence of Events in a Checkpoint The following section outlines the main events that occur during a check-point once a user thread raises the checkpoint-requested flag. This section also notes the differences between full and fuzzy checkpoints: 1. The database server prevents user threads from entering critical sections. 2. The logical-log buffer is flushed to the current logical-log file on disk. 3. The page-cleaner thread flushes the physical-log buffer. 4. In a fuzzy checkpoint, the page-cleaner threads flush modified pages for nonfuzzy operations in the buffer pool to disk. In a full checkpoint, the page-cleaner threads flush all modified pages in the buffer pool to disk. 5. The checkpoint thread writes a checkpoint record to the logical-log buffer. 6. The physical log on disk is logically emptied. (Current entries can be overwritten). ++++++++++++++++++++++++++++++++++++++++++++++++++++ > >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 1. Is fast recovery smart enough to try to repair a page that does not have matching time stamps. 2. In the case of an expanding varchar rows can be rearranged on a data page which means a partial write can occur and blow away relevant data. Which is located nowhere in the logical log. 3. I have not gone through a very thorough thought process of other things that can be messed up by a partial write. That is why I brought this up on the newsgroup, to see who has more information than me on what Informix does to handle this situation. Even if my assumptions are correct, I am not extremely upset with the change. The benefits of fuzzy checkpoints are huge if you talk about performance. I am under the impression I am sacrificing some performance for this benefit though. If it turns out things are less reliable my next question will be can I make all operations physically logged in situations where not having to restore are more important than day to day performance. Will P.S. I know I am learning alot :) ------------------------------------------------------------ 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/ ------------------------------------------------------------