cancel
Showing results for 
Search instead for 
Did you mean: 

Tapes were autometically changing the Volume Pool.

mrinal_sarkar62
Level 6

Hi,

We were handiling a customer having Netbackup 6.5 on HP Unix 11.5. with a Tangberg Robotic Tape Librery(HP Ultrium drive).

We have configured policy for backing up the Oracle database, using script.

We have seperate policy for seperate days(Monday, Tuesday..etc), using the same script file, with seperate volume pool, with single tape each.

The NBU master /Media server is in the same Oracle databse server(HP Unix server).

Now, what happinig is that the while starting a backup of that Oracle policy the tape were used as per the tape volume asigned, but after completing one file it say that successful complete writing the file , then it mount another tape from another volume pool (which is not asigned to that policy) and continued the backup.

When I check the volume pool after wards, it was observed that the assigned volume pool(whose backup policy were exuceted) have two tape and other tape was fetched from another volume pool.

e.g. :-

Policy Name - Rman1_Policy_Monday

Volume Pool - Rman_Vol_Pool_Monday (With one tape); Rman_Vol_Pool_Tuesday...etc.

Now, excuting the Policy -"Rman1_Policy_Monday"

The the policy executed with the default volume pool -  "Rman_Vol_Pool_Monday", but after some time(compeleting one database backup) it went to fetch tape from the 'Rman_Vol_pool_Tuesday".

Now the volume pool named - "Rman1_Policy_Monday" have two tape, rather having one tape and the volume pool named "Rman_Vol_Pool_Tuesday" have now tape.

I have no idea whay it is happaning.

Please, help.

Thanks.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi,

 

Thanks for the file. You need to edit your script and add any one of the following options. The sections you have to add are highlighted in BOLD.

 

Option 1:

Setting the proper policy parameter in the RMAN command with the PARMS keyword.
$RMAN target $TARGET_CONNECT_STR rcvcat RMAN_prod/rman@eman msglog $RMAN_LOG_FILE append << EOF
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=$NB_ORA_POLICY)';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=$NB_ORA_POLICY)';
 
Option 2:
Setting the proper policy parameter in the RMAN command with the SEND keyword.
$RMAN target $TARGET_CONNECT_STR rcvcat RMAN_prod/rman@eman msglog $RMAN_LOG_FILE append << EOF
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' ;
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' ;
send 'NB_ORA_POLICY=$NB_ORA_POLICY' ;
 
Option 3:
The policy name can also be hard coded into the scripts with the NB_ORA_POLICY variable.
 
For example:
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<correct_policy_name>)';

ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<correct_policy_name>)';

View solution in original post

13 REPLIES 13

Amit_Karia
Level 6

Pls ,provide output of bppllist <policyname> -U ,vmpool -listall -b and vmpool -listscratch

Andy_Welburn
Level 6

is that if the all data on your tape in the "Tuesday" pool expired & the tape subsequently re-assigned to your "scratch" pool from where your "Monday" schedule picked it up - it should NOT pull from any other volume pool as that is totally contrary to the reasoning for having separate volume pools.

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Can you post your scripts please. I've got a theory.....

 

The application backup schedule you're using probably has the same name in each policy?? But each respective policy has a specific volume pool. Because you're using the same script, i think when it RMAN send the request to NetBackup it is allowed (or maybe not allowed but indeed doing) to use any schedule that it can find.

 

Or something to that effect, lol.

Will_Restore
Level 6

NetBackup picks the first Policy based on alphabetical sort of all available policies for the client unless specified in the script:

send 'NB_ORA_POLICY=policy_name, NB_ORA_SCHED=schedule_name';

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

So can we assume what I meant to say is correct. Should the user create separate scripts and add those parameters?

mrinal_sarkar62
Level 6

Hi,

As requested the script file, here is the file attached.

 

Thanks.

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Hi,

 

Thanks for the file. You need to edit your script and add any one of the following options. The sections you have to add are highlighted in BOLD.

 

Option 1:

Setting the proper policy parameter in the RMAN command with the PARMS keyword.
$RMAN target $TARGET_CONNECT_STR rcvcat RMAN_prod/rman@eman msglog $RMAN_LOG_FILE append << EOF
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=$NB_ORA_POLICY)';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=$NB_ORA_POLICY)';
 
Option 2:
Setting the proper policy parameter in the RMAN command with the SEND keyword.
$RMAN target $TARGET_CONNECT_STR rcvcat RMAN_prod/rman@eman msglog $RMAN_LOG_FILE append << EOF
RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' ;
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' ;
send 'NB_ORA_POLICY=$NB_ORA_POLICY' ;
 
Option 3:
The policy name can also be hard coded into the scripts with the NB_ORA_POLICY variable.
 
For example:
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<correct_policy_name>)';

ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<correct_policy_name>)';

RiaanBadenhorst
Moderator
Moderator
Partner    VIP    Accredited Certified

Did this work?????

mrinal_sarkar62
Level 6

Hi,

We haven'nt changed the script.

As I am not an expert in script.

 

I was thinking about templet to take backup.

Today, we have started the backup but it fail after completeing one backup.

Is this a script issue.

Thanks.

Marianne
Level 6
Partner    VIP    Accredited Certified

The script should the dba's responsibility. Most dba's are familiar with rman scripts.
 

"Today, we have started the backup but it fail after completeing one backup.

Is this a script issue."

We won't be able to tell you if you don't give us any information.

Please consider carefully when creating lots of Volume Pools - if you are trying to micro-manage to the extent where you want to force Monday's backups into a Monday-pool containing one single tape - you WILL sooner or later run into status 96 (as you have experienced in your other post).

mrinal_sarkar62
Level 6

Hi,

We have changed the script by hard coding the policy name in the script (Last options, posted previously).

We were using the seven different script for seven policy.

This was under observation and let's  hope for better.

I gues , there willl be no change in the tape volume(i.e. autometically taking other volumes's tape).

 

Thanks.

mrinal_sarkar62
Level 6

Hi,

I have changed the script file with the hard coring the policy name and server name .

Adding the parameter with "ENV" and providing the policy name and Master server name resolved my problem of tape changing automatically from other tape volume.

**************************************

CMD_STR="

ORACLE_HOME=$ORACLE_HOME

export ORACLE_HOME

ORACLE_SID=$ORACLE_SID

export ORACLE_SID

$RMAN target $TARGET_CONNECT_STR nocatalog msglog $RMAN_LOG_FILE append << EOF

RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' parms 'ENV=(NB_ORA_CLIENT=mll***db,NB_ORA_POLICY=***Policy_tuesday**,NB_ORA_SERV=***Master Server**)';

BACKUP

$BACKUP_TYPE

SKIP INACCESSIBLE

****

********

**************************************************************************

The characters in bold were added.

The backup is now happening smoothly...but why does the Netbackup behaved in this way.

Thanks.

Marianne
Level 6
Partner    VIP    Accredited Certified

"why does the Netbackup behaved in this way"

NBU policy kicks off a script on the client. The client starts RMAN backup, which sends the backup request to the Master server. If there is no policy name in the job generated by the client, the master server will find the first policy for the client name that is the correct type (Oracle) and run all backups against that policy.

There is a TN explaining this behaviour : http://www.symantec.com/docs/TECH31742

 

Riaan and Bill both suggested that you hard-code the policy name in the script - please mark one of their posts as solution.