Oracle RMAN job starts another job (copied)
Hi,
We have an Oracle job (Archive log, Full) set with an RMAN script which works fine and now we'd like to have another copy of this job in another storage. So I simply created a job from the original one and changed the storage destination to the new place.
So, the Original job is : policy name: job1, RMAN script : mysc.sh, storage: site1_stg
I create a copy :
Second job : policy name : job2, RMAN script : mysc.sh, storage: site2_stg
What happens is strange! When I run Job1, Job1 is also automatically launched and run. I looked into the script and there is nothing related to the job policy name which may cause this. I also used a different script (with the same content of course) but the result was the same.
As this is not the case in other jobs I doubt the script or Oracle Linux OS or Netbackup settings on the OS should be the cause. Any help would be appreciated.
Thanks
It occurred to me that if you have two different policies doing archive log backups what you're going to end up with is not two identical copies of those archive logs - RMAN is only going to mark them as needing backing up once; instead it'll result in a semi-random destination for where those single copies of the logs go.
If you want two copies of the logs you need to have it happen in the single original policy, either via SLP or inline tape copy (technically you could dup it manually after-the-fact too but nobody wants to do that multiple times a day).
Side note - Apparently I misunderstood originally and thought triggering policy #2 was calling policy #1 which would point towards a script variable. Since it's the opposite that makes it more likely to be one of NBU's lesser-known foibles where it tries to be "helpful" - frankly I'd rather it just kick out an error code instead. When a client-side job (such as a database agent backup) triggers it calls the Master to determine which policy to use to back up based up on the client name, schedule with an open window, etc. When there are two policies that meet all the criteria though the Master takes its best guess - which may not be the policy you actually want it to use. In this kind of case you're better off with two client-side scripts and have each policy call a different one, each script having their own specific NB_ORA variables pointing to the right policy.
This has been a known issue for as long as I have worked with NetBackup.
The process works like this:
Master server kicks off the backup and the script name is sent to the client.
Client starts the script, connects to bprd on the master server.
bprd sends the backup instruction to nbpem that looks for suitable policy with client name and open window.
The 1st policy that is found is then executed.The ONLY way to prevent this, is by putting the policy name in the script.
This issue and solution is explained in NBU for Oracle manual and various TNs.Extract from the manual:
To avoid unexpected results, it is recommended to configure RMAN to always use
the send command to pass the desired variables and values to NetBackup explicitly.
Alternatively the RMAN ENV parameter can be used to make the variables and
values available to NetBackup.TNs:
https://www.veritas.com/support/en_US/article.100017654
https://www.veritas.com/support/en_US/article.100006225As jnardello explained - running another backup is NOT a copy.
It's a new backup in the RMAN catalog.Rather use SLP to automate duplication,