ontape backup and restore

Hi, I'm running online ontape level 0 backup on my dataserver. The ontape begin at 7 PM and lasts 2 hours While this ontape is running, there are transactions running that modify datas in my instance at the same time. At 8 PM one transaction truncated data in a table called my_table My question is : if at 10 PM, I restore using the previous level 0 backup (without restoring log), in which state will be my_table after restore : -1)always at the state it was at the beginning (i.e. 7 PM) of the backup process (ie unchanged) -2)or this state depends of the time my_table backup's took place (ie, before or after truncate) : ie unchanged if the backup took place before truncate, or empty if the backup occured after truncate Thanks for u're answer Regards

Informix archives are always as of the beginning of the archive process. If you run onstat -g arc the reported date/time is the state that the server will be returned to when you restore that latest archive unless you also roll forward logical logs in which case the server state will be as of the last committed transaction in the logs that were restored. The archive process starts with a checkpoint which empties the physical log and forces all storage changes to disk. After that the process captures the physical log records for any pages modified from that checkpoint until the end of the archive in temp tables. As each dbspace's archive copy is completed the engine writes out the physical log pages captured from that dbspace to the archive file/tape. At restore time that insures that the state of the disk/server after the restore is what it was at the time the archive started. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Aug 12, 2014 at 12:26 PM, GILLES TCHAPPI <giltfr@yahoo.fr> wrote: > Hi, > I'm running online ontape level 0 backup on my dataserver. The ontape begin > at 7 PM and lasts 2 hours > While this ontape is running, there are transactions running that > modify datas in my instance at the same time. > At 8 PM one transaction truncated data in a table called my_table > > My question is : if at 10 PM, I restore using the previous level 0 backup > (without restoring log), in which state will be my_table after restore : > > -1)always at the state it was at the beginning (i.e. 7 PM) of the backup > process (ie unchanged) > > -2)or this state depends of the time my_table backup's took place (ie, > before > or after truncate) : ie unchanged if the backup took place before > truncate, or > empty if the backup occured after truncate > > Thanks for u're answer > Regards > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0158c200cecfd1050071883b

Hi Art, And thanks a lot for your answer. I undestand what u said till 'After that the process captures the physical log records for any pages modified from that checkpoint until the end of the archive in temp tables'; But Im' not sure if I understood what follows : 'As each dbspace's archive copy is completed the engine writes out the physical log pages captured from that dbspace to the archive file/tape..... ' Does this means that the the physical log pages captured during ontape are written in ontape backup file ? If so, why ? Furthermore, I red in 'IBM Informix backup and restore guide' about quiescent backup : 'You create a quiescent backup while the database server is quiescent. Use quiescent backups when you want to eliminate partial transactions in a backup'. Can u please, explain what do these 'partial transactions' mean ? Regards

Gilles: Yes, physical log pages created during the archives are written to the archive file. Why? Because you are modifying your data on disk during the archive and the physical log contains an image of the state of each modified page as of the last checkpoint. As I said, the archive begins with a checkpoint. This all means that Informix doesn't have to block any transactions during the archive. Quiescent backups. That's an odd one. After a restore, any transactions that had not been committed when the archive started are incomplete and so "partial". They have to be rolled back. In order to drop the engine down to quiescent mode all open transactions have to have been completed already or the onmode command hangs until the have. Also no new transactions can start. So, once quiescent mode is established an archive taken at that point will not have any rollbacks to perform and the engine will come online faster. The downside is that users will be kicked off the server when you bring the engine down to quiescent mode. Having active transactions during an archive was the innovation Informix brought to the industry in 1992 and the reason why Informix v4.00 through 5.xx are known as Informix Online! Art On Aug 12, 2014 2:33 PM, "GILLES TCHAPPI" <giltfr@yahoo.fr> wrote: > Hi Art, > > And thanks a lot for your answer. I undestand what u said till 'After that > the > process captures the physical log records for any pages modified from that > checkpoint until the end of the archive in temp tables'; > > But Im' not sure if I understood what follows : 'As each dbspace's archive > copy is completed the engine writes out the physical log pages captured > from > that dbspace to the archive file/tape..... ' > > Does this means that the the physical log pages captured during ontape are > written in ontape backup file ? If so, why ? > > Furthermore, I red in 'IBM Informix backup and restore guide' about > quiescent > backup : 'You create a quiescent backup while the database server is > quiescent. Use quiescent backups when you want to eliminate partial > transactions in a backup'. > > Can u please, explain what do these 'partial transactions' mean ? > > Regards > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c221aea6eb8f0500733250

Hi Art, Thanks once again. I'm much more confused about how ontape backup works as I was before I posted my first question. So, I'll forget my question regarding quiescent backup and to avoid confusion, I'll solely focus on my fisrt question and your previous answer which states, among other things, that : "The archive process starts with a checkpoint which empties the physical log and forces all storage changes to disk. After that the process captures the physical log records for any pages modified from that checkpoint until the end of the archive in temp tables. As each dbspace's archive copy is completed the engine writes out the physical log pages captured from that dbspace to the archive file/tape. At restore time that insures that the state of the disk/server after the restore is what it was at the time the archive started." What I undestand with this is that during the ontape backup, all datas that are in disks (just after the checkpoint) are copied in archive file. Meanwhile all modifications are writing in temp tables and at the end of each dbspace copy, these modifications are written to the archive file. So the questions here are : - why are these post checkpoint modifications written to archive file ? should'nt they been directly written to dbspace when dbspace backup is completed ? - if these modifications are written to archive file, how restoration from this archive file can put the datas in the state they were at the begining of the backup, as the archive files also include data modifications made when the backup was running ?

The post checkpoint changes ARE written to disk. The BEFORE images of changed pages always written to the physical log however during a backup these BEFORE images are also written to temp space and then to the backup. The restore first restores all used pages including those written to during the backup, then restores the extra BEFORE images to undo any changes done during the backup and get to a consistent state i.e. undo changes going back to the archive checkpoint. David. > On 12 August 2014 at 21:26 GILLES TCHAPPI <giltfr@yahoo.fr> wrote: > > > Hi Art, > > Thanks once again. I'm much more confused about how ontape backup works as I > was before I posted my first question. > > So, I'll forget my question regarding quiescent backup and to avoid confusion, > I'll solely focus on my fisrt question and your previous answer which states, > among other things, that : > > "The archive process starts with a checkpoint which empties the physical log > and forces all storage changes to disk. After that the process captures > the physical log records for any pages modified from that checkpoint until > the end of the archive in temp tables. As each dbspace's archive copy is > completed the engine writes out the physical log pages captured from that > dbspace to the archive file/tape. At restore time that insures that the > state of the disk/server after the restore is what it was at the time the > archive started." > > What I undestand with this is that during the ontape backup, all datas that > are in disks (just after the checkpoint) are copied in archive file. Meanwhile > all modifications are writing in temp tables and at the end of each dbspace > copy, these modifications are written to the archive file. So the questions > here are : > > - why are these post checkpoint modifications written to archive file ? > should'nt they been directly written to dbspace when dbspace backup is > completed ? > > - if these modifications are written to archive file, how restoration from > this archive file can put the datas in the state they were at the begining of > the backup, as the archive files also include data modifications made when the > backup was running ? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Art, David I now, better understand the ontape machanism Thanks to both of u Best regards