Onbar and LTAPEDEV

All, 10.00.UC6 Solaris 2.8 What are the ramifications of setting the config parameter LTAPEDEV to /dev/null as it relates to onbar level 0 backups? For example with our current configuration LTAPEDEV points to a valid file. When we run onbar -b -L 0 the archive process backs up all dbspaces in addition to the logical log that was current when the archive began, or the log that is current when each dbspace is backed up. We do not restore logs, ever, with the exception of those that are part of the archive. If we set LTAPEDEV to /dev/null would we be forced to use the -w flag when we archived or would the parallel backup option we use now still backup the same logs as it does now? Somewhere in the back of my mind I seem to recall reading something that said LTAPEDEV needs to be set to something other than /dev/null in order to take parallel backups... Thanks, Mike

If you set LTAPEDEV to /dev/null in UNIX or nul on Windows you will not been able tot take dbspace backups. You will need to use only instance backups (whole system backups using -w option). This in version 10 means you will have only serial backups. When LTAPEDEV is set to /dev/null the logical logs cannot be backedup. gustavo MIKE MAGIE wrote: > All, > > 10.00.UC6 > Solaris 2.8 > > What are the ramifications of setting the config parameter LTAPEDEV to > /dev/null as it relates to onbar level 0 backups? For example with our current > configuration LTAPEDEV points to a valid file. When we run onbar -b -L 0 the > archive process backs up all dbspaces in addition to the logical log that was > current when the archive began, or the log that is current when each dbspace > is backed up. We do not restore logs, ever, with the exception of those that > are part of the archive. > > If we set LTAPEDEV to /dev/null would we be forced to use the -w flag when we > archived or would the parallel backup option we use now still backup the same > logs as it does now? > > Somewhere in the back of my mind I seem to recall reading something that said > LTAPEDEV needs to be set to something other than /dev/null in order to take > parallel backups... > > Thanks, > > Mike > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! > > >

So with LTAPEDEV set to /dev/null the archive process, (i.e not a logical log backup process) will not back up the current logical log to the archive device - but with LTAPEDEV set to something other than /dev/null the archive process (as I have seen) will write to the archive device the current logical log (among other logs used during the backup)? I just want to make sure it is clear that I am not talking about logical log backups as a separate activity from the archive. I am fully aware that with LTAPEDEV set to /dev/null the logs cannot be "backed up" but only freed immediatly upon filling or being rolled with onmode. It kind of stinks if this is true - I mean we want to have the backup performance available from a parallel backup but don't care about our logs, other than those needed to restore the archive. Here is our current backup process: 1. Backup logs to a file that is constantly overwritten. 2. Check for open transactions in logs older than the current log - if one is found wait for it to complete. 3. Start our onbar -b command. I want to eliminate step 1. MM

MIKE MAGIE wrote: > So with LTAPEDEV set to /dev/null the archive process, (i.e not a logical log > backup process) will not back up the current logical log to the archive device > - but with LTAPEDEV set to something other than /dev/null the archive process > (as I have seen) will write to the archive device the current logical log > (among other logs used during the backup)? > > I just want to make sure it is clear that I am not talking about logical log > backups as a separate activity from the archive. I am fully aware that with > LTAPEDEV set to /dev/null the logs cannot be "backed up" but only freed > immediatly upon filling or being rolled with onmode. > > It kind of stinks if this is true - I mean we want to have the backup > performance available from a parallel backup but don't care about our logs, > other than those needed to restore the archive. Here is our current backup > process: > > 1. Backup logs to a file that is constantly overwritten. > > 2. Check for open transactions in logs older than the current log - if one is > found wait for it to complete. > > 3. Start our onbar -b command. > > I want to eliminate step 1. > > MM The only thing that the copies of the existing logical logs on disk that are part of the level 0 archive will do for you is to let the server properly roll back transactions that were not completed before the archive began. If you are not backing up your logical logs created since the previous level 0 archive (or level 1 or level 2 if you take incremental archives) then you CANNOT recover to any point later than the moment that last archive was begun if there is a server crash that destroys your data on disk. Period. Your logical logs should be backed up - not to a file that's continously overwritten, but - to a file that is renamed immediately afterwards and preserved at least until the next full level 0 archive is completed. Being a basically paranoid individual who has seen archive tapes that could not be restored I want those logical log backup files archived until the second following level 0 archive is completed and stored safely offsite. That way when the worst happens and the server crashes I can call for the latest two level zero archive tapes and all of the intervening and following logical log file tapes from offsite storage and have two chances to restore my system to the last possible point close to the crash. Not needed? Never going to happen? Phe! I've had to restore from an older archive and roll forward logical logs twice while at BB and once had to walk a client through it since leaving BB in November! To directly answer your question, if you are constantly backing up your logical logs to INDEPENDENT files or to a streaming tape drive then there is no reason for step one in your nightly (or whenever) archive procedure. If you are NOT doing so then there is no purpose to step one. If you set LTAPEDEV to /dev/null then there is nothing there to back up in step one. In any case, it's an unneeded step. Art S. Kagel Oninit ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Art - Thanks for the response and the suggestions. I have a good understanding of the role that logical logs play in archive/restore scenarios, as well as the importance of backing up logs in most cases. In our case we do not need to backup logs. Based on this... If LTAPEDEV is set to /dev/null will onbar -b -L 0 write the log(s) that are current during the archive process to the archive media? Thanks! Mike Magie

If the engine is started with LTAPEDEV set to /dev/null the engine will automagically do continously logging for you Cheers Paul > Art - > > Thanks for the response and the suggestions. I have a good understanding > of > the role that logical logs play in archive/restore scenarios, as well as > the > importance of backing up logs in most cases. In our case we do not need to > backup logs. Based on this... > > If LTAPEDEV is set to /dev/null will onbar -b -L 0 write the log(s) that > are > current during the archive process to the archive media? > > Thanks! > > Mike Magie > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! > > ================================================================================ =========== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > ================================================================================ =========== > -- Paul Watson Tel: +1 913-400-2620 Mob: +1 913-387-7529 Web: www.oninit.com Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Paul - As it relates to logical log backups, setting LTAPEDEV to /dev/null will cause a used log to be immediatly freed for reuse, if the log does not contain information regarding an open transaction - the log is not backed up at all. My question pertains only to archives and the behavior of onbar when LTAPEDEV is set to /dev/null. Thanks, Mike

ids-bounces@iiug.org wrote on 03/19/2008 07:08:51 AM: > Art - > > Thanks for the response and the suggestions. I have a good understanding of > the role that logical logs play in archive/restore scenarios, as well as the > importance of backing up logs in most cases. In our case we do not need to > backup logs. Based on this... > > If LTAPEDEV is set to /dev/null will onbar -b -L 0 write the log(s) that are > current during the archive process to the archive media? Absolutely NOT. onbar has no way of determining which logs are current. You are allowed to backup dbspace1 a week ago and dbspace2 today. The restore will require all logical logs between these to dbspaces. The new feature in version 11 for onbar is whole system parallel backup and restore. This will backup the logical logs on to the level 0 backup media (like ontape). This is probably what you are looking for. John > > Thanks! > > Mike Magie > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!!

AFAIK the engine doesn't care whether it is onbar or ontape, /dev/null automagically gives you 'continous' logging, ie the logs are marked for reuse on filling Maybe I misunderstood the question Cheers Paul > Paul - > > As it relates to logical log backups, setting LTAPEDEV to /dev/null will > cause > a used log to be immediatly freed for reuse, if the log does not contain > information regarding an open transaction - the log is not backed up at > all. > > My question pertains only to archives and the behavior of onbar when > LTAPEDEV > is set to /dev/null.> > Thanks, > > Mike > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!! > > ================================================================================ =========== > Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.oninit.com/home/disclaimer.php > > ================================================================================ =========== > -- Paul Watson Tel: +1 913-400-2620 Mob: +1 913-387-7529 Web: www.oninit.com Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Hi, no! "onbar -b -L 0" is doing a parallel backup of dbspaces. Parallel here means (among other things) that each dbspace is backed up with its own consistency reference point (aka archive checkpoint). And because of that restore of such a backup will need logical logs to "compensate" all those dspaces's consistency points to reach overall consistency for all dbspaces together. Without logical logs backed up you will not be able to successfully restore such backups. And this is why (in newer versions at least) onbar will not let you do such a backup when LTAPEDEV is set to /dev/null. If you want to do a useful (i.e. restorable) backup while not backing up logical logs, then you need to do a so called "whole system backup". This is denoted by a "-w" in the onbar command line, like: "onbar -b -w [ -L 0 ]" Such a backup can then be restored without logical logs and still bring the instance to a consistent state. In newer versions (since 11.10, I believe), this whole system backup can also be done in parallel, but still with one (i.e. the same) archive checkpoint for all dbspaces. Therefore no logs are needed for restore of this. In older versions, a whole system backup can be done serially only (onbar syntax is the same). Here it is very much like a normal backup with ontape (which is always serial and by default "whole system"). Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Entwicklung GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Herbert Kircher Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 19.03.2008 15:08:51: > Art - > > Thanks for the response and the suggestions. I have a good understanding of > the role that logical logs play in archive/restore scenarios, as well as the > importance of backing up logs in most cases. In our case we do not need to > backup logs. Based on this... > > If LTAPEDEV is set to /dev/null will onbar -b -L 0 write the log(s) that are > current during the archive process to the archive media? > > Thanks! > > Mike Magie > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!!

MIKE MAGIE wrote: > Art - > > Thanks for the response and the suggestions. I have a good understanding of > the role that logical logs play in archive/restore scenarios, as well as the > importance of backing up logs in most cases. In our case we do not need to > backup logs. Based on this... > You do if you want to be able to restore an onbar parallel archive and end up with a working server. > If LTAPEDEV is set to /dev/null will onbar -b -L 0 write the log(s) that are > current during the archive process to the archive media? > In the sense that the dbspace they reside in will be archived as-of the beginning of the parallel backup of that particular dbspace, yes. If that's the highest numbered dbspace it MAY even contain the log entries needed to synchronize the dbspaces after a restore, but based on Martin's post and John's I wouldn't bet on it. And certainly if, as is much more typical, the logical log dbspace is dbspace #2 or 3 out of several more, there will be missing logs and missing entries from the last log that's there. Art > Thanks! > > Mike Magie > > ================================================================================ =========== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.oninit.com/home/disclaimer.php ================================================================================ ===========

Thanks for all the responses - Whole system parallelism is what we are looking for - maybe this will inspire us to move to v11. In the meantime we'll make sure we have LTAPEDEV set before we kick off our parallel backups so we have a restorable, if not gnat's arse granular, archive. Restorable archives are always the best kind. Mike

Hi, I hope you are aware that just setting the parameter in the onconfig file will NOT do the trick! When LTAPEDEV is set to /dev/null (or nul on Windows), then the IDS server knows that logical log backup is not needed. And with that knowledge the IDS server is simply marking the logs as "backed up" (without doing anything else) so that they can be overwritten in a circular fashion. When you change LTAPEDEV in the onconfig file while the server is running, the server will not notice this change, because it is reading the onconfig file only during startup. Therefore even after changing the onconfig file a running server will still continue to behave as if LTAPEDEV is still set to /dev/null. Thus logical logs will not be backed up, even if you would explicitly attempt to run "onbar -b -l", because all logs are already marked as "backed up" and thus still nothing would be done. For the change in onconfig file to become effective, you have to stop the server (bring it down completely, not just quiescent mode or similar) and start it again. Only then will it read the changed value of LTAPEDEV and act accordingly. (The same applies in case you plan to revert back to /dev/null after a backup is done ...) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Entwicklung GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Herbert Kircher Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 19.03.2008 17:10:37: > Thanks for all the responses - > > Whole system parallelism is what we are looking for - maybe this will inspire > us to move to v11. In the meantime we'll make sure we have LTAPEDEV > set before > we kick off our parallel backups so we have a restorable, if not gnat's arse > granular, archive. Restorable archives are always the best kind. > > Mike > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > See you at the IIUG Informix 2008 Conference > The Power Conference for Informix Professionals > April 27 - 30, 2008 Marriott Overland Park (Kansas City), Kansas > http://www.iiug.org/conf > Registration Now Open!!

I don't know about onbar. But, ontape picks up tape parameter changes made via onmonitor without needing a restart of the instance. However, I'd strongly recommend backing up your onconfig before hand and checking for diffs when your done. In some versions, onmonitor has been found to delete lines (VPCLASS) from your onconfig.