cancel
Showing results for 
Search instead for 
Did you mean: 

Yet another Oracle thread - this time an interesting error

rjrumfelt
Level 6
Ok, I've been on a roll with Oracle lately.  Its like every time we start up a new set of hot Oracle backups, something different goes wrong.

The setup:

I have 2 calendar based schedules, one to run every day of the month except for one, and another to run that one day of the month.  The end goal is to send that one tape offsite (I dont know why, since the data will be nearly worthless to restore but anyway), so I need a separate policy to make sure it is duplicated appropriately.

Lets say the policy names are:

Oracle_hot_backup_daily
Oracle_hot_backup_monthly

I noticed that the images from the monthly backup were not getting duplicated.  When I further investigated the issue, I found that the reason the images were not getting duplicated via the correct profile - when the Oracle_hot_backup_monthly ran, it kicked off child streams (the default-application backup streams) through the Oracle_hot_backup_daily policy.  When a different profile ran, it picked up all of the default application backup streams for Oracle_hot_backup_daily, sending them to a completely different pool then where they need to be.

I consulted with a colleague who stated we would probably need to have separate rman scripts for the two policies, but I'm not sure how to hard-code the policies in.  Also, if anyone might know of a reason as to why the daily policy is being initiated through the monthly policy, please let me know - I'm not really sure how Oracle passes this information back to NBU.

We are using the same backup script right now for both policies.

Master is at 6.5.4 running solaris 10, clients are solaris 10, running at 6.5.2
1 ACCEPTED SOLUTION

Accepted Solutions

Will_Restore
Level 6
Details:
In NetBackup 6.0 and previous versions:
During a scheduled Oracle backup, bphdb creates the file /tmp/obackup_class on UNIX and BP\temp\obackup_class on Windows.  The presence of this file may lead to unexpected behavior in an environment with virtual instances of Oracle on the client. Very few current installations depend on this variable.

In NetBackup 6.5 and beyond:
The variable "obackup_class" is removed. The NB_ORA_POLICY environmental variable must be defined by the RMAN PARMS or send statement in the backup request. This is usually done in the script. For Example:

ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' ;
send 'NB_ORA_POLICY=Oracle_Backup' ;
BACKUP

***In this example, Oracle_Backup is the name of the desired NetBackup Policy.

As long as the policy is defined once in the script, it should be retained for the logs and control file too.

If NB_ORA_POLICY is not set, NetBackup will search the policy list until an appropriate policy is found and use it for the backup job.

http://support.veritas.com/docs/293049

View solution in original post

8 REPLIES 8

David_McMullin
Level 6
Your policy calla a script, script.sh which calls a data file script.rcv
In the rcv file is a value of send 'NB_ORA_POLICY=YOUR.POLICY, NB_ORA_CLIENT=YOUR.CLIENT';

You can use one script if you have two policies, and use scripting logic to set the value to the correct policy.

The policy will set the storage unit.

Each time the parent kicks off a child job, it gets its information from the policy it calls - you can change the storage in the middle of a backup and the next child will use the updated storage.

rjrumfelt
Level 6
so I cant execute "find'

Would you happen to know where this *.rcv file would be located?  And does it need to be modified?  Sorry for sounding dense, but I've never had to modify the rman script before.

David_McMullin
Level 6
Check your policy, the location is in the Backup Selections.
My example is from unix - if you are running windows there may be differences.

rjrumfelt
Level 6
I was curious about the .rcv file.  I do not see it listed in the same directory as the actual rman script.  I'm sure most environments are different, but is there a typical place this .rcv file is located?

When I look through the rman log file, I see where the correct policy name is set as the "NB_ORA_POLICY" variable.  But when I go to the activity monitor, I see all of the default-application streams running under a different policy.


*******EDIT********

Something else to note, I disabled the daily policy and ran the monthly policy, and it ran as it should, with the default-application streams running under the monthly policy - weird

rjrumfelt
Level 6
as to why my monthly policy as the parent stream is kicking off default-application backup streams under a different policy?

rjrumfelt
Level 6
although I did check the rman output, and it appears it is being passed the correct policy variable, as I can see NB_ORA_POLICY being set to the monthly policy.

I am seeing if the DB can set the policy variable manually by using SEND.  Lets hope this works.

Will_Restore
Level 6
Details:
In NetBackup 6.0 and previous versions:
During a scheduled Oracle backup, bphdb creates the file /tmp/obackup_class on UNIX and BP\temp\obackup_class on Windows.  The presence of this file may lead to unexpected behavior in an environment with virtual instances of Oracle on the client. Very few current installations depend on this variable.

In NetBackup 6.5 and beyond:
The variable "obackup_class" is removed. The NB_ORA_POLICY environmental variable must be defined by the RMAN PARMS or send statement in the backup request. This is usually done in the script. For Example:

ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' ;
send 'NB_ORA_POLICY=Oracle_Backup' ;
BACKUP

***In this example, Oracle_Backup is the name of the desired NetBackup Policy.

As long as the policy is defined once in the script, it should be retained for the logs and control file too.

If NB_ORA_POLICY is not set, NetBackup will search the policy list until an appropriate policy is found and use it for the backup job.

http://support.veritas.com/docs/293049

rjrumfelt
Level 6
and added a "SEND 'NB_ORA_POLICY=Policyname';

and now I am seeing the behavior that I expected to see the first time around.

And thanks Bill for fixing your link.