Ontape/logical logs

Hi all, I'm reasonably new when it comes to Informix, so I hope this isn't an often- asked question. I've set up a disaster recovery server for our main Informix server, to which I automatically send my level 0/level 1 backups and logical logs, as they're written to disk. I've performed a restore with 'ontape -r' successfully, but have a question. Once I finish performing the ontape command, am I able to apply each logical log in turn, as it's sent to the backup server, to bring it up to date ? I thought 'ontape -l' might be what I needed, but it doesn't seem to work... I realise 'ontape -r' is able to apply logical logs, but I'd obviously prefer not to have to restore the entire database if we ever have a severe crash. Any help appreciated, Cheers, Peter

What about HDR? Or ER? (those would be akin to oracle's standby database in concept... If you know about that oracle feature) We had a fancy home grown combination of expect scripts and rcp scripts on our old hotsite setup (this was with onarchive also). In short the expect scripts would be running the DB restore in constant restore mode and slowly fed the log files to restore as they came off from the PRD system and were copied to the hotsite.... Kinda complex, but cool when understood.... That was the old days... Now I am spoiled with onbar and EMC's BCV & SRDF technology... Good luck, Norma Jean -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of Peter Skipworth Sent: Wednesday, September 29, 2004 7:21 PM To: ids@iiug.org Subject: Ontape/logical logs [3501] Hi all, I'm reasonably new when it comes to Informix, so I hope this isn't an often- asked question. I've set up a disaster recovery server for our main Informix server, to which I automatically send my level 0/level 1 backups and logical logs, as they're written to disk. I've performed a restore with 'ontape -r' successfully, but have a question. Once I finish performing the ontape command, am I able to apply each logical log in turn, as it's sent to the backup server, to bring it up to date ? I thought 'ontape -l' might be what I needed, but it doesn't seem to work... I realise 'ontape -r' is able to apply logical logs, but I'd obviously prefer not to have to restore the entire database if we ever have a severe crash. Any help appreciated, Cheers, Peter ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Hi, no, you are not. You can let the running "ontape -r" command apply as many logs as you want (or have), but once it has finished there is no way to start applying logs again. The reason for this is, at the point where you tell the "ontape -r" command that you have no more logical logs, the database is (at least generally) in an inconsistent state. That means there will be some open transactions. With no more logs available (as you told the "ontape -r" that there are no more logs), there is "no hope" that these transactions will ever be committed. To avoid that these transactions stay open for the remaining eternety, they are rolled back. This is the so-called "transaction clean-up phase" of the restore. Now the database is logically consistent. Applying new log files would mean that you would want to continue where you were before the "transaction clean-up", i.e. you would want to continue those open transactions. But as they have already been rolled back, there's no way to continue them. Therefore it's not possible to apply more logical logs after a restore has finished. You can split the restore into the physical restore ("ontape -p") followed by the logical restore ("ontape -l") but the same applies, as soon as you have finished that "ontape -l" command there was a "transaction clean-up" and no return to log applying is possible. Having said all this, it becomes clear that Norma Jean Sebastian is absolutely correct (as always :) , because HDR (High-availability Data Replication) is doing exactly what you are trying to achieve manually. It keeps the secondary server (the slave) in this "log recovery phase", i.e. after a physical restore (and possibly restoring some logical logs from tape) it will not do the "transaction clean-up". Instead it will always wait for new logical log records to arrive so that they can be applied. This is done automatically, i.e. the primary (master) and secondary server "talk to each other" to figure out, when log records are to be transfered from primary to secondary and applied there. This is ongoing at the discretion of transactions, rather than a whole log file at the time it becomes full. So it gives you a hot standby that is much more up-to-date. It also gives you the added benefit that you can still use this secondary server for querying data (obviously you can't modify data on the slave). There's more benefit to gain, so I recommend reading the manual "Administrator's Guide", especially the chapter about "High-Availability Data Replication". Regards, Martin -- Martin Fuerderer IBM Informix Development Munich Data Management Solutions forum.subscriber@iiug.org wrote on 30.09.2004 02:21:09: > Hi all, > > I'm reasonably new when it comes to Informix, so I hope this isn't an often- > asked question. I've set up a disaster recovery server for our main Informix > server, to which I automatically send my level 0/level 1 backups and logical > logs, as they're written to disk. I've performed a restore with 'ontape -r' > successfully, but have a question. Once I finish performing the ontape > command, am I able to apply each logical log in turn, as it's sent to the > backup server, to bring it up to date ? I thought 'ontape -l' might be what > I > needed, but it doesn't seem to work... > > I realise 'ontape -r' is able to apply logical logs, but I'd obviously > prefer > not to have to restore the entire database if we ever have a severe crash. > > Any help appreciated, > > Cheers, > > Peter

Thanks Martin :) At my current place of employment, the DBAs before me couldn't get HDR or ER working so they made a homegrown solution with the expect scripts. I don't know why they couldn't get HDR or ER working, they left no notes. Perhaps it was because there is a big distance between the production database and the hotsite database (like several U.S. states) with not a big enough/fast enough data pipe between the 2 at the time. Maybe they found that the distance and speed of pipe was such that the HDR or ER solution actually impacted the production database negatively by having the extra overhead of trying to communicate to the hotsite. In any case, they created quite a cool solution that didn't impact the production database at all, the production database didn't know/care that there was a hotsite. I gained a lot of respect for the people before me when I started maintaining those scripts (I can't take credit for the creation.... Only wish I could). Have a good one! Norma Jean -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of Martin Fuer.... Sent: Thursday, September 30, 2004 4:55 AM To: ids@iiug.org Subject: Re: Ontape/logical logs [3504] Hi, no, you are not. You can let the running "ontape -r" command apply as many logs as you want (or have), but once it has finished there is no way to start applying logs again. The reason for this is, at the point where you tell the "ontape -r" command that you have no more logical logs, the database is (at least generally) in an inconsistent state. That means there will be some open transactions. With no more logs available (as you told the "ontape -r" that there are no more logs), there is "no hope" that these transactions will ever be committed. To avoid that these transactions stay open for the remaining eternety, they are rolled back. This is the so-called "transaction clean-up phase" of the restore. Now the database is logically consistent. Applying new log files would mean that you would want to continue where you were before the "transaction clean-up", i.e. you would want to continue those open transactions. But as they have already been rolled back, there's no way to continue them. Therefore it's not possible to apply more logical logs after a restore has finished. You can split the restore into the physical restore ("ontape -p") followed by the logical restore ("ontape -l") but the same applies, as soon as you have finished that "ontape -l" command there was a "transaction clean-up" and no return to log applying is possible. Having said all this, it becomes clear that Norma Jean Sebastian is absolutely correct (as always :) , because HDR (High-availability Data Replication) is doing exactly what you are trying to achieve manually. It keeps the secondary server (the slave) in this "log recovery phase", i.e. after a physical restore (and possibly restoring some logical logs from tape) it will not do the "transaction clean-up". Instead it will always wait for new logical log records to arrive so that they can be applied. This is done automatically, i.e. the primary (master) and secondary server "talk to each other" to figure out, when log records are to be transfered from primary to secondary and applied there. This is ongoing at the discretion of transactions, rather than a whole log file at the time it becomes full. So it gives you a hot standby that is much more up-to-date. It also gives you the added benefit that you can still use this secondary server for querying data (obviously you can't modify data on the slave). There's more benefit to gain, so I recommend reading the manual "Administrator's Guide", especially the chapter about "High-Availability Data Replication". Regards, Martin -- Martin Fuerderer IBM Informix Development Munich Data Management Solutions forum.subscriber@iiug.org wrote on 30.09.2004 02:21:09: > Hi all, > > I'm reasonably new when it comes to Informix, so I hope this isn't an often- > asked question. I've set up a disaster recovery server for our main Informix > server, to which I automatically send my level 0/level 1 backups and logical > logs, as they're written to disk. I've performed a restore with > 'ontape -r' > successfully, but have a question. Once I finish performing the ontape > command, am I able to apply each logical log in turn, as it's sent to the > backup server, to bring it up to date ? I thought 'ontape -l' might be what > I > needed, but it doesn't seem to work... > > I realise 'ontape -r' is able to apply logical logs, but I'd obviously > prefer not to have to restore the entire database if we ever have a > severe crash. > > Any help appreciated, > > Cheers, > > Peter ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================