cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle RMAN job starts another job (copied)

mhdganji
Level 3

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

 

 

 

2 ACCEPTED SOLUTIONS

Accepted Solutions

jnardello
Moderator
Moderator
   VIP    Certified

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. 

View solution in original post

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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

 

View solution in original post

12 REPLIES 12

jnardello
Moderator
Moderator
   VIP    Certified

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 . 

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
Moderator
Moderator
   VIP    Certified

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
Moderator
Moderator
Partner    VIP    Accredited Certified

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

 

You both are right. This is an issue/bug in Netbackup. I expected an error code or warning but it simply ignores us :cathappy: and just choose a random one.

And let's add that using NB_ORA_Policy with Send did not work and error 29 and 6 was there. This is because of Oracle's old version. In 12c we should use ENV after channels.

Regards,

M. Ganji

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Yes, you will see that the extract from the manual and both TNs mention ENV parameters.
You need to use what is relevant to your Oracle version.

Please also note that the variables are case sensitive.

I gave NB its last chance but it didn't take it :cathappy:

I renamed the script file so as to make a distinction between the two jobs and expected the client-side script to mark this as a difference and run my desired copied job but again a random job was run every time.

So, let's accept it as it is and use the NB_ORA Policy via SEND or ENV meanwhile working on the second copy option.

Regards,

M. Ganji

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

What do you mean with 'it didn't take'?

Can you show us the script?

I really hope you have NB_ORA_POLICY and not NB_ORA Policy.
This is working for everyone else that experienced the 'wrong policy' issue.

 
No No. Please don't take me wrong here. Everything is working fine. I was just addressing the first and main issue; thinking maybe not pointing to the policy name in the script, but instead, using different script names causes the client to run the desired correct policy (by checking its name in the backup selection section). But that didn't work. Including policy name in the script whether using ENV or SEND does work fine. 
 
Regards,
M. Ganji

 

Hi @mhdganji 

Great to hear you have it working - but to reiterate what @Marianne and @jnardello have already said - your logic of creating two policies to create two copies of the archive logs is WRONG.

What you will end up with is some archive logs in once place, and others the another. 

You really should be using an SLP for this process (and this is how backup admins elsewhere do this). Go talk to your local DBA's about what you are doing and get them to see where their backed up archive logs reside. 

David

Dear David,

Thanks for your note and I'm working on the second copy but just let me say that AFAIK, This is not an issue:

"What you will end up with is some archive logs in one place, and others the another."

Because you can set the backed up files flag for any number greater than one, i.e. you can tell the script, not to backup log files which have been backed up twice (not once), so you can solve the problem you mentioned.

Anyway, the second copy is what we're investigating to find the pros and cons and implement it. My main fear is that if the first backup produces undesired or corrupt files, then the copy will be the same. This is what makes me hesitated about using secondary copy unless there is some continuous check on the files (by the team) or hmmm I donno. some kind of verification automatically by Oracle.

Regards,

M. Ganji

 

Hi @mhdganji 

Okay - do it your way, but consider this. 

  1. If you don't trust one backup copy of you archive logs, why trust the other.
  2. I understand the backup number of times, but what happens if one of the storage units is unavailable for an period of time and all the copies of some archive logs are only backed up to a single storage unit - there goes your duplicate copy strategy. 

Cheers