BRARCHIVE tool call conflicts

[Former Member]

We have multiple sources that trigger our brarchive tool use for an Oracle database. We use crontab entries to check the saparch space avaiable and triggers a brarchive call to archive the logs and then we also have a Maestro schedule that kicks off one during the backup schedule for example. These occasionally will run into each other a conflict, so i was wondering how we could have these wait for the other one (or run in parrellel) so they do NOT abend with a .lockbra exists error. BR021I Please delete file /oracle/<SID>/saparch/.lock.bra if BRARCHIVE was killed . Isn't there a retry_num parameter or something in Tivoli setting/file (init<SID>.sap or sonwhere that will let that retry a couple of times to eliminate when these conflicts occur actually failing the script ? There is very little direct info on how exactly brtools works for the lock files, so any addtional information on paralell runs etc would be most appreciated.

Thanks.........Bran

[Former Member]

I understand and we do some of that to an extent, but I was hoping the brarchive would read TMs parameter files and allow for conflicts easier (like backup to tape etc.) rather than having scripts work around solutions etc. - guess it is just a limitation of it.

[former_member188883]

Hi Bran,

Just modify all the sources to check whether .lockbra file exists. If yes, do not start respective processes.

Hope this helps.

Regards,

Deepak Kori

[Former Member]

While I agree that would be an easy fix to check for it first, it isn't truly optimum. In the rare case it is an actual TRUE orphaned .lockbra file then none of the brarchives would ever do anything until the database grinds to a halt and stops working. While it it had a retry or something within the brarchive / TSM settings (using utl file etc. settings similar to the way brbackup retries files offloads) then it would eventually fail with an error to have support called and hopefully before the DB system reaches capacity. YET it would allow it to wait and retry if it was momentarily a conflict in brarchive calls overlapping. That was my hope anyway.  Looks like it isn't yet possible.

[Former Member]

Hi,

What you said is true but to avoid issues for system coming to hold.You can try these steps.

Raise an alerting on the /oracle/SID/oraarch file system if the size id greater than 80%. So have monitoring for these file system using Solman.

Increase the size of /oracle/SID/oraarch so that you get more time to fix the issues .

Thanks

Rishi abrol

[Former Member]

Hi,

as an easier fix

the script that is called in crontab to check the archive directory why don't you add another step to check that if any brarchive process is running do nothing.

Thanks

Rishi abrol