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

 

 

 

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,

     

12 Replies

Sort By
  • jnardello's avatar
    jnardello
    Moderator
    4 years ago

    First off, you're looking at this the wrong way. Why would you want to run a second backup, impacting the client/network/storage a second time, rather than just automatically making a copy via your first policy's SLP ? Just add yet another step to that SLP and you'll be done. 

    Second off, I'd be willing to bet money your RMAN script does actually reference the specific NetBackup policy so that the DBAs can trigger the backup if needed. You'd be looking for a variable in the script called NB_ORA_POLICY . 

    • mhdganji's avatar
      mhdganji
      Level 3
      4 years ago

      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.