brbackup (util_vol_online) fails with BR0344E No tablespace has been put in backup status by backup utility

[Former Member]

Here are the details of two different brbackup executions:

1. Backup_mode=all; backup_type=online; backup_dev_type=util_vol_online (according to BC-BRI spec this has similar behavior to util_file_online)
2. ‘brbackup’ successfully invoked the ‘backint’ program.
3. ‘backint’ reported set of files to be backed up in .switch.lis file with “#BEGIN”, created .switch.sem file and waited for the semaphore file to be deleted
4. ‘brbackup’ created .switch.log file with “#SUCCESS” and deleted .switch.sem file
5. ‘backint’ then took a backup and reported the end of backup by reporting files in .switch.lis file with #END before file names.
6. ‘brbackup’ again reported “#SUCCESS” in .switch.log file and deleted .switch.sem file
7. ‘backint’ reported the successful backup for all files to output in format: “#SAVED  <BID> <filename>”
8. ‘brbackup’ recognized the “#SAVED” messaged and reported the completion back
9. ‘brbackup’ failed with error: BR0344E No tablespace has been put in backup status by backup utility

Question:

1. According to spec, ‘brbackup’ takes care of putting DB/tablespace in backup status; but we don’t see any ‘Alter database…’ command executed with util_vol_online (or util_file_online) option. And the error at the end indicates that it expected backup utility to move tablespaces into backup status. What is expected from ‘backint’ after it reports back “#SAVED” messages?

1. Backup_mode=all; backup_type=online; backup_dev_type=util_vol (according to BC-BRI spec this has similar behavior to util_file)
2. ‘brbackup’ put the DB in backup mode: ‘Alter database begin backup’
3. ‘brbackup’ successfully invoked the ‘backint’ program.
4. ‘backint’ reported set of files to be backed up in .switch.lis file with “#BEGIN”, created .switch.sem file and waited for the semaphore file to be deleted
5. ‘brbackup’ does not delete the .switch.sem file at all and ‘backint’ keeps on waiting (this continued for almost couple of hours after which I exited the ‘backint’ process)

Question:

1. According to BC-BRI spec, ‘brbackup’ is actually putting tablespaces into backup status and once done with that, it deletes the .switch.sem file. How much time should it take usually? Spec says it’s around 20 mins but here it went on forever.
2. Is there a requirement such that only specific user should execute ‘brbackup’? If yes, which user should that be?

(Above executions are done using BR*TOOLS 7.20 installed on RHEL6.3)

I have attached the log files for both of these operations here; can you please have a look and provide some help/insight into what exactly might be wrong here?

[util_vol]belynowd.anv.txt.zip

[util_vol_online]belyppaz.anv.txt.zip

[former_member188883 · Accepted solution]

Hi Neerav,

In the backup tool please define orasid user and check it.

Hope this helps.

Regards,

Deepak Kori

[Former Member · Accepted solution]

Thanks Deepak; although this didn't solve the problem with util_vol_online option, running brbackup under 'ora<SID>' user was also very much necessary, without which it fails at other places. This was helpful.

[Former Member]

Which external backup program you use for backup?

[Former Member]

Thanks all for their feedback.

One of the problems mentioned in original post is resolved which is 'util_vol_online' option.

The error reported by BRBACKUP (BR0344E) was because .switch.log file created by BRBACKUP towards end (after #END...) was not deleted by backint.

However, the problem of semaphore file not getting deleted by BRBACKUP in 'util_vol' option is still not resolved. While the backint is waiting for .switch.sem file to be deleted, an instance of BRCONNECT operating on the very same BRBACKUP process can be observed. This BRCONNECT process does not close for long time and probably for the very same reason .switch.sem file is not deleted by BRBACKUP. It's not clear though, why BRCONNECT takes long time (over 2-3 hours).

[former_member188883]

Hi Neerav,

Just a thought. Could you have a check with latest version of backint. Also check the owner of this file. It should be root.

Additionall you may revisit the SAP note below to verify the kernel parameters configuration

Note 1496410 - Red Hat Enterprise Linux 6.x: Installation and Upgrade

Hope this helps.

Regards,

Deepak Kori

[Former Member]

Hi ,

Just to ensure that its not a permission problem  ,can you run saproot.sh and oraroot.sh , the suids on the br* files are important .

Also which external backup program is being used here ?

Regards,

Suneeth

[Reagan]

Hello

I would query the v$backup to see the status of the datafiles whether they are in backup mode or not.

http://docs.oracle.com/cd/B28359_01/server.111/b28320/dynviews_1034.htm

select * from v$backup;

Secondly I will check the TSM backup script to see how the backup is triggered.

Regards

RB

[Former Member]

Thanks RB; when I checked the tablespace status after reporting "#BEGIN" in .switch.lis file, it was actually in backup mode and the same was taken out of backup mode on reporting "#END..." in .switch.lis file after backup.

[Reagan]

Hello

The problem I see is with the script used for taking backups (I might be wrong)

User:  uid=504(oracsh) gid=0(root) groups=502(dba),0(root),500(sapinst),507(asmadmin)

Secondly the primary group of the oracsh user should be dba. In your case it is not.

Not sure whether this could help but you can change it and then try.

command_line                   ./brbackup -u system -c

This doesnt look like the correct backup command string.

I suggest you to review the backup script

Regards

RB