RE: Back to Fuzzy Checkpoints

Just as a note, I am just trying to make sure I understand the situation I am getting into when I upgrade. I actually was looking at this as a trade off between robustness and speed. Even if the robustness was not intended it was still there.(or maybe the robustness was all in my head) Comments embedded. >===== Original Message From dwood@informix.com ===== <SNIP> > 2. We do not physically log all pages and this is the way it has > been for at least 10 years. This has nothing to do with fuzzy > checkpoints. You may have just heard about the reduced physical > logging that occurs with it. But that doesn't mean that prior to > fuzzy checkpoints we logged every page. It was my impression that all dbspace pages which were part of a logged database would be flushed to the physical log before the logical log. If my understanding of this is incorrect please tell me. (I guess blobspaces would be an exception) > 3. Physical logging is not designed to correct hardware problems. It is >designed > to make logical recovery possible. If it occasionally does correct a >partial > page write then; > > a. it is a secondary effect A likeable secondary effect :) > b. it was only because we write some pages twice, to the physical > log and chunk. This is similar to what mirroring does but with > mirroring it was intended and designed that way. With the physical log you are guaranteed to complete the write to the physical log and then do the write to the chunk. Does mirroring provide the same guarantee? > c. it never has been guaranteed and functionally has been that way > for a long time. I agree it has never been guaranteed. I am not claiming Informix has no right to change this. I was just asking peoples opinions on whether or not they thought that the likelihood of a restore in the event of hardware failure was greater. The benefits which a piece of software brings to a company are relevant regardless of whether or not they are intended by the software company. I feel how a piece of software behaves under extreme conditions is good to know. > 4. Fuzzy checkpoints do not change the integrity of logical recovery. I agree completely. >SUMMARY: > Partial page writes rarely occured in the past and fuzzy checkpoints will > not make the effect of this any worse and it does not introduce a new > problem. I am not the most knowledgeable on hardware, so I am not sure about the statement that partial writes rarely occur. I know we have few occasions where off-site machines have lost power 3 or 4 times in a day. I can not see how a power outage on a system with a busy database partial writes would not occur. I agree the situation is horrible, and not one I hold Informix responsible for handling, but the fact that Informix came up was a great credit to the robustness of the database.(And allowed me to continue on my oblivious way) I figure the only way I will find out the effect this will have is to rollout 9.2 to our systems. I am just trying to set my expectation levels of what the differences will be. What I am getting from all of this is, partial writes are considered a rare occurrence and not a situation Informix feels is necessary to handle. Thank you very much for the information, it is quite helpful, Will P.S. Is there a way to cause fuzzy operations to be physically logged? ------------------------------------------------------------ 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: > ... > >===== Original Message From dwood@informix.com ===== > <SNIP> > > 2. We do not physically log all pages and this is the way it has > > been for at least 10 years. This has nothing to do with fuzzy > > checkpoints. You may have just heard about the reduced physical > > logging that occurs with it. But that doesn't mean that prior to > > fuzzy checkpoints we logged every page. > > It was my impression that all dbspace pages which were part of a > logged database would be flushed to the physical log before the logical > log. If my understanding of this is incorrect please tell me. > (I guess blobspaces would be an exception) The v7.3 manual clearly says that all dbspace pages are candidates for physical logging (with some minor exceptions). Database logging status does NOT affect physical logging of its pages (as it does logical logging). > > > 3. Physical logging is not designed to correct hardware problems. It is > >designed > > to make logical recovery possible. I can not see how logical recovery needs the physical log. The manual does say that Fast recovery uses the physical log to "return(ing) all disk pages to their condition at the time of the most recent checkpoint". But, the logical log does have the before and after image of all changes made since the last checkpoint. It also has information of when the last checkpoint was done. That should be enough to achieve logical consistency. About the only purpose that can be served by the Physical log in the context of Fast recovery is that of catering to page corruption. BTW, Oracle (no flames for this, please!), which conceptually has far more similarities than differences to Informix, does not have a physical log or any structure resembling it. It has Redo logs where it stores "after-images" and Rollback segments where it stores "before" images of transactions (not pages). (That is, our logical log, split into two components). During Oracle's fast recovery, it uses the Redo log to roll forward from the last checkpoint and the Rollback segments to roll back un-committed transactions - identical to our Fast recovery except for the Physical log's role. Reference : http://technet.oracle.com/docs/products/oracle8/doc_index.htm > .... > > >SUMMARY: > > Partial page writes rarely occured in the past and fuzzy checkpoints will > > not make the effect of this any worse and it does not introduce a new > > problem. Which still leaves unexplained the question, why were all pages being physically logged in earlier versions? Why are some pages being physically logged now? > What I am getting from all of this is, partial writes are considered a rare > occurrence and not a situation Informix feels is necessary to handle. Does look like it. > P.S. Is there a way to cause fuzzy operations to be physically logged? Make sure that all rows in your database have a non-fuzzy column (user-defined data, blob). :-) Meanwhile, I have independently started a case with Informix on the issue. If anything interesting comes up, I will pass it on. Cheers Rudy