Making backup during perpetual roll forward

Hello everyone, I'm preparing new database server to take over our current production one. The servers are not at the same location and copying level 0 backup takes more than twenty hours. I'm using few days old backup for perpetual roll forward to get to current database status. The problem is that I have to commit logical restore to make database server available for testing at new location. That enforces me to start restore process over every time I need the most recent data on new server because testing with yesterday's data is not very useful. I was wondering if I could make a level 0 backup on new server I could use later for physical restore phase. The point is to make logical restore phase shorter by using more "fresh" level 0 backup made locally. I have already tried to suspend logical restore and make full level 0 backup while IDS in fast recovery state. I can use that backup for physical restore phase but it fails to restore first next logical log I supposed to continue with when I suspended it. Am I missing something or it is crazy idea that would never work? Cheers

On Aug 2, 12:45 pm, askel <dummy...@mail.ru> wrote: > Hello everyone, > > I'm preparing new database server to take over our current production > one. The servers are not at the same location and copying level 0 > backup takes more than twenty hours. I'm using few days old backup for > perpetual roll forward to get to current database status. The problem > is that I have to commit logical restore to make database server > available for testing at new location. That enforces me to start > restore process over every time I need the most recent data on new > server because testing with yesterday's data is not very useful. > > I was wondering if I could make a level 0 backup on new server I could > use later for physical restore phase. The point is to make logical > restore phase shorter by using more "fresh" level 0 backup made > locally. > > I have already tried to suspend logical restore and make full level 0 > backup while IDS in fast recovery state. I can use that backup for > physical restore phase but it fails to restore first next logical log > I supposed to continue with when I suspended it. > > Am I missing something or it is crazy idea that would never work? > > Cheers I forgot to tell that we are using IDS 9.40.FC6 on Solaris 9 on both servers.

Hi, uhm. This is not an intended usage/combination of suspended log restore and backup. To be honest I never even tried to do a dbspace backup while the server is in recovery mode. The crux why this will not work is this (I think): The fact that you do a dbspace backup/archive on the recovery/test instance will write archive info. And this will make it different (out of sync) from the production system. And after that it is not possible to bring the two instances back in sync again. Dbspace backup (or archive) requires a checkpoint to be done. This is the archive checkpoint. For a restore this is the reference where any logical rollforward (and or rollback) will refer to. Of course an archive checkpoint is also written into the logical log (and at this point I'm not even sure if/how that works when the instance is in recovery mode with log restore suspended). Anyway, assuming that the above somehow works, the archive checkpoint has happened, but is "local" to the instance that is being recovered. But the logical logs that you want to restore are from the production instance - which did not do the backup/archive of dbspaces and hence does not know of this archive checkpoint. And of course the production instance does not write the log record for this archive checkpoint into its log. Now, after you restored the dbspace backup/archive (i.e. the physical restore part), a following logical restore will look for the log record (in logical logs) of the archive checkpoint. But since the logs you (want to) restore are from the production machine, they do not contain this archive checkpoint. Hence logical restore will not be possible. I (currently) do not see a way to achieve what you would like to do. In order to bring the two instances in sync again (after some actions on the test instance), you have to start with a level-0 archive that was done on the production system. And that will even be the case if you would use HDR. (And if you would use HDR, you would not be able to do a dbspace backup/archive on the secondary instance.) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 informix-list-bounces@iiug.org wrote on 02.08.2007 18:53:30: > On Aug 2, 12:45 pm, askel <dummy...@mail.ru> wrote: > > Hello everyone, > > > > I'm preparing new database server to take over our current production > > one. The servers are not at the same location and copying level 0 > > backup takes more than twenty hours. I'm using few days old backup for > > perpetual roll forward to get to current database status. The problem > > is that I have to commit logical restore to make database server > > available for testing at new location. That enforces me to start > > restore process over every time I need the most recent data on new > > server because testing with yesterday's data is not very useful. > > > > I was wondering if I could make a level 0 backup on new server I could > > use later for physical restore phase. The point is to make logical > > restore phase shorter by using more "fresh" level 0 backup made > > locally. > > > > I have already tried to suspend logical restore and make full level 0 > > backup while IDS in fast recovery state. I can use that backup for > > physical restore phase but it fails to restore first next logical log > > I supposed to continue with when I suspended it. > > > > Am I missing something or it is crazy idea that would never work? > > > > Cheers > > I forgot to tell that we are using IDS 9.40.FC6 on Solaris 9 on both > servers. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

On Aug 3, 5:27 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote: > Hi, > > uhm. This is not an intended usage/combination of suspended > log restore and backup. To be honest I never even tried to > do a dbspace backup while the server is in recovery mode. > > The crux why this will not work is this (I think): > > The fact that you do a dbspace backup/archive on the > recovery/test instance will write archive info. And this will > make it different (out of sync) from the production system. > And after that it is not possible to bring the two instances > back in sync again. > > Dbspace backup (or archive) requires a checkpoint to be done. > This is the archive checkpoint. For a restore this is the > reference where any logical rollforward (and or rollback) will > refer to. Of course an archive checkpoint is also written into > the logical log (and at this point I'm not even sure if/how that > works when the instance is in recovery mode with log restore > suspended). > > Anyway, assuming that the above somehow works, the > archive checkpoint has happened, but is "local" to the instance > that is being recovered. But the logical logs that you want to > restore are from the production instance - which did not do > the backup/archive of dbspaces and hence does not know > of this archive checkpoint. And of course the production > instance does not write the log record for this archive > checkpoint into its log. > > Now, after you restored the dbspace backup/archive (i.e. the > physical restore part), a following logical restore will look for > the log record (in logical logs) of the archive checkpoint. But > since the logs you (want to) restore are from the production > machine, they do not contain this archive checkpoint. Hence > logical restore will not be possible. > > I (currently) do not see a way to achieve what you would like > to do. In order to bring the two instances in sync again (after > some actions on the test instance), you have to start with a > level-0 archive that was done on the production system. > And that will even be the case if you would use HDR. > (And if you would use HDR, you would not be able to do > a dbspace backup/archive on the secondary instance.) > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > IBM Deutschland GmbH > Chairman of the Supervisory Board: Hans Ulrich M'rki > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian > Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael > Diemer > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 > > informix-list-boun...@iiug.org wrote on 02.08.2007 18:53:30: > > > On Aug 2, 12:45 pm, askel <dummy...@mail.ru> wrote: > > > Hello everyone, > > > > I'm preparing new database server to take over our current production > > > one. The servers are not at the same location and copying level 0 > > > backup takes more than twenty hours. I'm using few days old backup for > > > perpetual roll forward to get to current database status. The problem > > > is that I have to commit logical restore to make database server > > > available for testing at new location. That enforces me to start > > > restore process over every time I need the most recent data on new > > > server because testing with yesterday's data is not very useful. > > > > I was wondering if I could make a level 0 backup on new server I could > > > use later for physical restore phase. The point is to make logical > > > restore phase shorter by using more "fresh" level 0 backup made > > > locally. > > > > I have already tried to suspend logical restore and make full level 0 > > > backup while IDS in fast recovery state. I can use that backup for > > > physical restore phase but it fails to restore first next logical log > > > I supposed to continue with when I suspended it. > > > > Am I missing something or it is crazy idea that would never work? > > > > Cheers > > > I forgot to tell that we are using IDS 9.40.FC6 on Solaris 9 on both > > servers. > > > _______________________________________________ > > Informix-list mailing list > > Informix-l...@iiug.org > >http://www.iiug.org/mailman/listinfo/informix-list Martin, Thank you for the explanation. The only reason I was trying to achieve that was the fact that effective testing could not be done without current data and keeping databases in sync takes way to long for that. Cheers

On Aug 3, 10:58 am, askel <dummy...@mail.ru> wrote: > On Aug 3, 5:27 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote: > > > > > Hi, > > > uhm. This is not an intended usage/combination of suspended > > log restore and backup. To be honest I never even tried to > > do a dbspace backup while the server is in recovery mode. > > > The crux why this will not work is this (I think): > > > The fact that you do a dbspace backup/archive on the > > recovery/test instance will write archive info. And this will > > make it different (out of sync) from the production system. > > And after that it is not possible to bring the two instances > > back in sync again. > > > Dbspace backup (or archive) requires a checkpoint to be done. > > This is the archive checkpoint. For a restore this is the > > reference where any logical rollforward (and or rollback) will > > refer to. Of course an archive checkpoint is also written into > > the logical log (and at this point I'm not even sure if/how that > > works when the instance is in recovery mode with log restore > > suspended). > > > Anyway, assuming that the above somehow works, the > > archive checkpoint has happened, but is "local" to the instance > > that is being recovered. But the logical logs that you want to > > restore are from the production instance - which did not do > > the backup/archive of dbspaces and hence does not know > > of this archive checkpoint. And of course the production > > instance does not write the log record for this archive > > checkpoint into its log. > > > Now, after you restored the dbspace backup/archive (i.e. the > > physical restore part), a following logical restore will look for > > the log record (in logical logs) of the archive checkpoint. But > > since the logs you (want to) restore are from the production > > machine, they do not contain this archive checkpoint. Hence > > logical restore will not be possible. > > > I (currently) do not see a way to achieve what you would like > > to do. In order to bring the two instances in sync again (after > > some actions on the test instance), you have to start with a > > level-0 archive that was done on the production system. > > And that will even be the case if you would use HDR. > > (And if you would use HDR, you would not be able to do > > a dbspace backup/archive on the secondary instance.) > > > Regards, > > Martin > > -- > > Martin Fuerderer > > IBM Informix Development Munich, Germany > > Information Management > > > IBM Deutschland GmbH > > Chairman of the Supervisory Board: Hans Ulrich M'rki > > Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian > > Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael > > Diemer > > Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, > > HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 > > > informix-list-boun...@iiug.org wrote on 02.08.2007 18:53:30: > > > > On Aug 2, 12:45 pm, askel <dummy...@mail.ru> wrote: > > > > Hello everyone, > > > > > I'm preparing new database server to take over our current production > > > > one. The servers are not at the same location and copying level 0 > > > > backup takes more than twenty hours. I'm using few days old backup for > > > > perpetual roll forward to get to current database status. The problem > > > > is that I have to commit logical restore to make database server > > > > available for testing at new location. That enforces me to start > > > > restore process over every time I need the most recent data on new > > > > server because testing with yesterday's data is not very useful. > > > > > I was wondering if I could make a level 0 backup on new server I could > > > > use later for physical restore phase. The point is to make logical > > > > restore phase shorter by using more "fresh" level 0 backup made > > > > locally. > > > > > I have already tried to suspend logical restore and make full level 0 > > > > backup while IDS in fast recovery state. I can use that backup for > > > > physical restore phase but it fails to restore first next logical log > > > > I supposed to continue with when I suspended it. > > > > > Am I missing something or it is crazy idea that would never work? > > > > > Cheers > > > > I forgot to tell that we are using IDS 9.40.FC6 on Solaris 9 on both > > > servers. > > > > _______________________________________________ > > > Informix-list mailing list > > > Informix-l...@iiug.org > > >http://www.iiug.org/mailman/listinfo/informix-list > > Martin, > > Thank you for the explanation. The only reason I was trying to achieve > that was the fact that effective testing could not be done without > current data and keeping databases in sync takes way to long for that. > > Cheers You can use ER to keep the development server in close sync with production. If you don't need real-time syncronicity, you can do that. Just set up all of the ER for all tables you are interested in replicating. Then you can periodically add the DEV server as a replicant, sync it with the primary, then disconnect it and work on the DEV server offline for a while. Art S. Kagel