Re: Can Disk mirroring/db snapshots replace the usage of taking database backups?

Neil Truby wrote: > "Superboer" <superboer7@t-online.de> wrote in message > news:fffc5c22-82a8-4f19-ab32-f090f4c66179@u36g2000prf.googlegroups.com... > >>> Rightm, but all these snapshot-based technologies use "consistency group" >>> functionality so what you describe above doesn't apply. >>> I still don't understand - referring to the implication in Art's original >>> reply - why a database block/unblock is necessary for an external backup. >>> >> well i still would not trust "consistency group". i rather go for an >> onbar/ontape then trust another party >> tool. >> >> when this has a bug or goes wrong who are you gonna talk to/ who is >> gonna fix it.??!! >> if you have massive corruption, then this is absolutely no fun to >> repair it. >> > > That's fine and dandy, but be clear that what you are saying is functionally > identical to saying that IDS Fast recovery cannot be relied upon either. > Neil, Fast recovery can be relied upon, 99% of the time. But there is that one percent. We've all seen the posts, and many of us have been there - I have. The machine crashes or the disk array crashes or there was a maintenance shutdown and the hardware vendor's engineer cleared the disk array cache before startup (I REALLY hated that one) so for one reason or another there was not a complete set of data written to the disk that IDS believed was secure and complete. On restart fast recovery hits the last page at the end of the last logical log and instead of finding a complete commit record, a shutdown record, a checkpoint record or a complete update record of some sort the engine finds half a commit or an update prerecord but no post record. Fast recovery needs a known state at the end of the logical log forward pass so that it can decide whether to commit the last transaction(s) it's been tracking or roll it (them) back. So fast recovery aborts because it doesn't know what to do. Remember that all IDS records are comprised of multiple physical disk pages! This is inconsistent data and it's not due to any bug in the engine. Should the engine just decide that there was an IO problem and continue by ignoring the partial record and roll everything back that was not properly completed? I think so, but obviously, the Informix engineers disagree and require a tech support down system call so one of the down system engineers can determine that there is not a more pervasive problem and then truncate the last logical log at a consistent place and restart fast recovery from the beginning. Is that a bug or a design decision? Add to all of that, and to my 'irrational' fears, Martin's admonition that an external restore will not work without the data that onmode -c block places in the dbspaces, and all of my advice to the original post is valid and correct. Art S. Kagel Oninit