OnBar error.

Good morning all, thank you for your responses on my last posting, I am currently trying all the suggestions out and will get feedback for you shortly. Related to the unexpected No Response error from OnBar that stops the Continuous logging( I have a suspicion that this has to do with the continuous logging reaching the last check point in the logs and stopping, but cannot prove this yet), when I try and restart the continuous logging as I have done before successfully, it seems that the Netbackup storgae manager already seems to have a record of the next log to be backed up, even though it does not register as backed up on the onstat -l. onstat -l: 8dea39f0 42 U-B---- 742 2:311349 8192 8192 100.00 8dea3a30 43 U------ 743 2:319541 8192 8192 100.00 8dea3a70 44 U------ 744 2:327733 8192 8192 100.00 8dea3ab0 45 U------ 745 2:335925 8192 8192 100.00 OnBar Erorr: 2006-04-21 11:54:50 29445 29439 Successfully connected to Storage Manager. 2006-04-21 11:54:50 29445 29439 XBSA Error: (BSABeginTxn) That object already exists. 2006-04-21 11:55:04 29445 29439 /home/informix/bin/onbar_d complete, returning 13 (0x0d) This error occurs whether I try and run logical logging, a complete system backup or indeed a verification of an older backup. On trying to instigate the backup of the logical logs it trys to back up log 743 specifically before issuing the error relating to the object existing already. I agree that this is probably a problem with the Veritas Netbackup side of things, but has anyone seen anything similar, and is there any way round it rather than the sledge hammer approach of pointing LTAPEDEV to /dev/null and running an ontape -c to allow the logs to get past this? More importatntly will onbar and Veritas spit the dummy when I try to run it following this action due to the logs being out of sync etc? Kind regards John

Hi, you can try to get rid of the object in the SM with some SM (native) commands. I'm no expert on Veritas Backup, so I can't tell you what such a command would be, but probably there is one. Or it is necessary to "repair" Veritas' internal "database", i.e. where Veritas keeps information on objects ... (whatever such a repair-command would be I also don't know, but there might be something like it). If you would set LTAPEDEV to /dev/null "for a while", then the logs will not be backed up at all. This is not really a problem to onbar or the SM. It will only be a problem for your restore (in case you'd have to do one). But by doing a new level-0 backup of everything (all dbspaces) after setting LTAPEDEV back to something other than /dev/null, you can avoid this problem as you then have a new base from which you can restore. Probably it is also necessary to make sure that you have no open transactions before you start the new level-0 backup. [ Open transactions at backup time might cause a rollback at restore time - which then could mean that you need to restore logs from before the actual dbspace backup. Doing a whole system backup will avoid this possible need, as it will contain all the necessary log records within the whole system backup itself, i.e. no extra log backup and restore is necessary. ] Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management ids-bounces@iiug.org wrote on 21.04.2006 12:05:32: > > Good morning all, > > thank you for your responses on my last posting, I am currently trying all the > suggestions out and will get feedback for you shortly. > > Related to the unexpected No Response error from OnBar that stops the > Continuous logging( I have a suspicion that this has to do with the continuous > logging reaching the last check point in the logs and stopping, but cannot > prove this yet), when I try and restart the continuous logging as I have done > before successfully, it seems that the Netbackup storgae manager already seems > to have a record of the next log to be backed up, even though it does not > register as backed up on the onstat -l. > > onstat -l: > 8dea39f0 42 U-B---- 742 2:311349 8192 8192 100.00 > 8dea3a30 43 U------ 743 2:319541 8192 8192 100.00 > 8dea3a70 44 U------ 744 2:327733 8192 8192 100.00 > 8dea3ab0 45 U------ 745 2:335925 8192 8192 100.00> > OnBar Erorr: > 2006-04-21 11:54:50 29445 29439 Successfully connected to Storage Manager. > 2006-04-21 11:54:50 29445 29439 XBSA Error: (BSABeginTxn) That object already > exists. > 2006-04-21 11:55:04 29445 29439 /home/informix/bin/onbar_d complete, returning > 13 (0x0d) > > This error occurs whether I try and run logical logging, a complete system > backup or indeed a verification of an older backup. On trying to instigate the > backup of the logical logs it trys to back up log 743 specifically before > issuing the error relating to the object existing already. > > I agree that this is probably a problem with the Veritas Netbackup side of > things, but has anyone seen anything similar, and is there any way round it > rather than the sledge hammer approach of pointing LTAPEDEV to /dev/null and > running an ontape -c to allow the logs to get past this? More importatntly > will onbar and Veritas spit the dummy when I try to run it following this > action due to the logs being out of sync etc? > > Kind regards > > John > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum.

John, I too am not familiar with Veritas' product, but we use BMC's SQL-BackTrack with onbar. Instead of using continuous log backup, we are trapping for logical log completions in the script we specify in the ALARMPROGRAM onconfig parameter. The backup command issued when the trap is sprung tells the storage manager to backup any logical logs that need backing up. This way, the engine is issuing separate backup commands as needed rather than having a continuously running process, like a daemon. Just a thought. Rob Schmitz NLC Data Management rob.b.schmitz@sprint.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Martin Fuer.... Sent: Friday, April 21, 2006 5:57 AM To: ids@iiug.org Subject: Re: OnBar error. [6579] Hi, you can try to get rid of the object in the SM with some SM (native) commands. I'm no expert on Veritas Backup, so I can't tell you what such a command would be, but probably there is one. Or it is necessary to "repair" Veritas' internal "database", i.e. where Veritas keeps information on objects ... (whatever such a repair-command would be I also don't know, but there might be something like it). If you would set LTAPEDEV to /dev/null "for a while", then the logs will not be backed up at all. This is not really a problem to onbar or the SM. It will only be a problem for your restore (in case you'd have to do one). But by doing a new level-0 backup of everything (all dbspaces) after setting LTAPEDEV back to something other than /dev/null, you can avoid this problem as you then have a new base from which you can restore. Probably it is also necessary to make sure that you have no open transactions before you start the new level-0 backup. [ Open transactions at backup time might cause a rollback at restore time - which then could mean that you need to restore logs from before the actual dbspace backup. Doing a whole system backup will avoid this possible need, as it will contain all the necessary log records within the whole system backup itself, i.e. no extra log backup and restore is necessary. ] Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management ids-bounces@iiug.org wrote on 21.04.2006 12:05:32: > > Good morning all, > > thank you for your responses on my last posting, I am currently trying all the > suggestions out and will get feedback for you shortly. > > Related to the unexpected No Response error from OnBar that stops the > Continuous logging( I have a suspicion that this has to do with the continuous > logging reaching the last check point in the logs and stopping, but cannot > prove this yet), when I try and restart the continuous logging as I have done > before successfully, it seems that the Netbackup storgae manager already seems > to have a record of the next log to be backed up, even though it does not > register as backed up on the onstat -l. > > onstat -l: > 8dea39f0 42 U-B---- 742 2:311349 8192 8192 100.00 > 8dea3a30 43 U------ 743 2:319541 8192 8192 100.00 > 8dea3a70 44 U------ 744 2:327733 8192 8192 100.00 > 8dea3ab0 45 U------ 745 2:335925 8192 8192 100.00> > OnBar Erorr: > 2006-04-21 11:54:50 29445 29439 Successfully connected to Storage Manager. > 2006-04-21 11:54:50 29445 29439 XBSA Error: (BSABeginTxn) That object already > exists. > 2006-04-21 11:55:04 29445 29439 /home/informix/bin/onbar_d complete, returning > 13 (0x0d) > > This error occurs whether I try and run logical logging, a complete system > backup or indeed a verification of an older backup. On trying to instigate the > backup of the logical logs it trys to back up log 743 specifically before > issuing the error relating to the object existing already. > > I agree that this is probably a problem with the Veritas Netbackup side of > things, but has anyone seen anything similar, and is there any way round it > rather than the sledge hammer approach of pointing LTAPEDEV to /dev/null and > running an ontape -c to allow the logs to get past this? More importatntly > will onbar and Veritas spit the dummy when I try to run it following this > action due to the logs being out of sync etc? > > Kind regards > > John > > ************************************************************************ ******* > Forum Note: Use "Reply" to post a response in the discussion forum. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

We are using ontape with ALARMPROGRAM setup to backup logs and it works quite well. Whenever a log is full, the ALARMPROGRAM is started to backup all the full logs ( including newly generated ones during its running!). The backup file is renamed to a different name to let next backup keep using the name configured by LTAPEDEV. So , only regular OS file system is involved. Thanks, Frank Qu Schmitz, Ro.... wrote: >John, > >I too am not familiar with Veritas' product, but we use BMC's >SQL-BackTrack with onbar. Instead of using continuous log backup, we >are trapping for logical log completions in the script we specify in the >ALARMPROGRAM onconfig parameter. The backup command issued when the >trap is sprung tells the storage manager to backup any logical logs that >need backing up. This way, the engine is issuing separate backup >commands as needed rather than having a continuously running process, >like a daemon. Just a thought. > >Rob Schmitz >NLC Data Management >rob.b.schmitz@sprint.com > >-----Original Message----- >From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >Martin Fuer.... >Sent: Friday, April 21, 2006 5:57 AM >To: ids@iiug.org >Subject: Re: OnBar error. [6579] > >Hi, > >you can try to get rid of the object in the SM with some SM (native) >commands. I'm no expert on Veritas Backup, so I can't tell you >what such a command would be, but probably there is one. >Or it is necessary to "repair" Veritas' internal "database", i.e. >where Veritas keeps information on objects ... (whatever such a >repair-command would be I also don't know, but there might be >something like it). > >If you would set LTAPEDEV to /dev/null "for a while", then the >logs will not be backed up at all. This is not really a problem to >onbar or the SM. It will only be a problem for your restore (in case >you'd have to do one). But by doing a new level-0 backup of >everything (all dbspaces) after setting LTAPEDEV back to something >other than /dev/null, you can avoid this problem as you then have >a new base from which you can restore. >Probably it is also necessary to make sure that you have no open >transactions before you start the new level-0 backup. >[ Open transactions at backup time might cause a rollback at > >restore time - which then could mean that you need to restore logs > >from before the actual dbspace backup. > >Doing a whole system backup will avoid this possible need, as > >it will contain all the necessary log records within the whole > >system backup itself, i.e. no extra log backup and restore is > >necessary. ] > >Regards, >Martin > > -- Yunyao "Frank" Qu Computer Sciences Corporation(CSC) NOAA/CLASS, (301)817-4696