Netbackup for Oracle - Redirected Restore by Different User

From: Allen, Brandon <>
Date: Tue, 7 Oct 2008 10:57:01 -0700
Message-ID: <04DDF147ED3A0D42B48A48A18D574C450DA068D4@NT15.oneneck.corp>

Hi List,  

I just wanted to share something very helpful I just found out about that might save you a lot of time if you need to perform redirected restores (aka alternate host restores, cross-host restores, alternate node duplicate database, etc.). In the past, you had to run the restore on your target host as the same username that originally ran the backup on your source host. In the past, this hasn't been a problem for me since I always installed as the "oracle" user so my source and target hosts always matched. Recently however, I've started working with some Oracle Apps (EBS) environments, and it seems to be standard procedure in these environments to install under different usernames such as oraprod, oradev, oratest, etc. so I just encountered this problem for the first time. Veritas* and Metalink** both mention cumbersome workarounds for the problem that involve removing the setuid bit from the oracle binary, but I just found out that in Netbackup for Oracle 6.0 MP4*** they have fixed this problem by changing the ownership and permissions of the backup images so that they can be restored by other users as long as they are members of the same group. Here is an example of the difference as seen in the output of the bplist command:  

NB for Oracle 6.0 before MP4:

[oraprod_at_prodhost ~]$ bplist -t 4 -k Oracle-rman-PROD-arc -l -R -s 10/06/08 /

-rw------- oraprod oraprod 38273024 Oct 06 08:27

After applying MP4:

[oradevl_at_devhost ~]$ bplist -C prodhost -t 4 -k Oracle-rman-PROD-arc -l
-R -s 10/06/08 /

-rw-rw---- oraprod dba 40108032 Oct 07 08:37

You can see above that we were able to list the backups taken by the oraprod user on the production server with the bplist command being executed by the oradevl user on the development server (prior to MP4, this bplist command would just return "EXIT STATUS 227: no entity was found"), and you can see that the backups are now owned by oraprod:dba instead of oraprod:oraprod. Once we were able to see the production backups from the development server, we were then able to run the redirected restore (or duplicate database in our case) successfully.  

Hopefully this will help someone else that runs into the same problem because it took us a few days to figure out we needed to upgrade to MP4 to get this functionality - unfortunately it is not well documented by either Symantec or Oracle.  




**ML note 212117.1

***Search for "ET643841" here:  

-- Received on Tue Oct 07 2008 - 12:57:01 CDT

Original text of this message