Forum Discussion

mhdganji's avatar
mhdganji
Level 3
4 years ago

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 origi...
8.1.2
Linux
Oracle
RMAN
  • jnardello's avatar
    jnardello
    4 years ago

    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. 

  • Marianne's avatar
    Marianne
    4 years ago

    mhdganji 

    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.100006225

    As jnardello explained - running another backup is NOT a copy.
    It's a new backup in the RMAN catalog.

    Rather use SLP to automate duplication,

     

mhdganji's avatar
mhdganji
Level 3

First of all thanks for your prompt answer and then:

I know that the second copy may be the answer but I think it is safer and more reliable to make another independent job. I will work on it but as for now, I'd like to know the problem solution.

I again searched the RMAN script and these are all ORA's there:

 

SEND 'NB_ORA_CLIENT=oracle_server.domain.com,NB_ORA_SID=oracle_server,NB_ORA_SERV=netbackupserver.domain.com';

 

No policy name in it. Although even if there was a policy name (such as Policy1) in the script why it should start the second (Policy2). As I said I'll start the Policy1 job but Policy2 is also automatically started

jnardello's avatar
jnardello
Moderator
4 years ago

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. 

  • Marianne's avatar
    Marianne
    Level 6
    4 years ago

    mhdganji 

    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.100006225

    As jnardello explained - running another backup is NOT a copy.
    It's a new backup in the RMAN catalog.

    Rather use SLP to automate duplication,