The site believes that RMAN is configured to specify the policy that should be used for the application backup, but when the application job goes active, it is using a different and unexpected policy.
Supposedly, the RMAN statements within the backup script are configured to requesting a specific policy (Policy-1).
$RMAN target ... append << EOF
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=Policy-1)';
But notice that while the RMAN script output only NB_ORA_POLICY is set as an environment variable before RMAN is started, once RMAN starts the channel allocation is followed immediately by the start of the backup. No indication that it is sending NB_ORA_POLICY to the SBT API (i.e. NetBackup).
==== started on Wed Aug 17 21:40:04 PDT 2011 ====
Full backup requested
Recovery Manager: Release 18.104.22.168.0 - Production on Wed Aug 17 21:40:04 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: MySID (DBID=907118944)
connected to recovery catalog database
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16>
allocated channel: ch00
channel ch00: SID=363 device type=SBT_TAPE
channel ch00: Veritas NetBackup for Oracle - Release 7.0 (2010010419)
Starting backup at 17-AUG-11
channel ch00: starting incremental level 0 datafile backup set
channel ch00: starting piece 1 at 17-AUG-11
channel ch00: finished piece 1 at 17-AUG-11
piece handle=bk_27572_1_759447628 tag=HOT_DB_BK_LEVEL0 comment=API Version 2.0,MMS Version 22.214.171.124
The dbclient debug log shows the thread that handled the backupset piece shown in the RMAN output. Notice that Oracle made SBT API calls to initialize the channel (sbtinit and sbtinit2) and then went directly to requesting a backup (sbtbackup) without passing the NB_ORA_POLICY variable (sbtcommand). Consequently, dbclient NONE and NONE are provided to the master server for NB_ORA_POLICY and NB_ORA_SCHED, and the master server then selects Policy-2 as the policy.
21:40:23.400  <2> sbtinit: INF - entering
Veritas NetBackup for Oracle - Release 7.0 (2010010419)
21:40:23.401  <2> sbtinit: INF - leaving
21:40:23.401  <2> sbtinit2: INF - entering
21:40:23.401  <2> sbtinit2: INF - leaving
21:40:29.303  <2> sbtbackup: INF - entering
21:40:29.358  <4> VxBSAGetEnv: INF - entering GetEnv - NBBSA_POLICY
21:40:29.358  <4> VxBSAGetEnv: INF - returning -
21:40:29.360  <4> sendRequest: sending BACKUP request to bprd
21:40:29.360  <4> sendRequest: request = oracle dba myclient myclient myclient /usr/openv/netbackup/logs/user_ops/dbext/logs/9883.0.1313642429 NONE NONE 5 MySID 0 4 0 C C C C C 0 0 0 0 5
21:40:54.410  <4> serverResponse: read comm file:<21:40:45 INF - Policy name = Policy-2>
21:42:34.438  <4> handshake: INF - got filename from server: </bk_27572_1_759447628>
21:42:34.440  <2> sbtbackup: INF - leaving
Because the Oracle server process that loads the libobk.so or orasbt.dll may not be a direct child of the RMAN process, Oracle has provided the RMAN statements to allow third-party variables to be passed from the RMAN script to the third-party backup software.
In this case, the Oracle server process is not calling sbtcommand to provide the variables to NetBackup. If it had, the RMAN output should have shown the call.
allocated channel: ch00
channel ch00: sid=19 devtype=SBT_TAPE
channel ch00: Veritas NetBackup for Oracle - Release 6.5 (2010042405)
sent command to channel: ch00
Starting backup at 25-AUG-11
The dbclient debug log would then have show the call being processed by NetBackup.
16:22:25.170  <2> sbtcommand: INF - entering
16:22:25.170  <2> sbtcommand: INF - command string=<NB_ORA_POLICY=Policy-1>
16:22:25.170  <4> int_ProcessCommandString: INF - cmd_key=<NB_ORA_POLICY> cmd_val=<Policy-1>
16:22:25.171  <2> sbtcommand: INF - leaving
Oracle originally provided the PARMS syntax as a valid way to pass variables to the third-party backup software. E.g.
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<policy_name>)';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE' PARMS 'ENV=(NB_ORA_POLICY=<policy_name>)';
Later versions of Oracle provided a newer syntax. E.g.
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
ALLOCATE CHANNEL ch01 TYPE 'SBT_TAPE';
If neither syntax results in a sbtcommand function call, double check that the expected backup script is really being used and if so, then contact Oracle technical support for assistance in determining why the call is not occurring.
Any supported combination of NetBackup and Oracle versions.
Was this content helpful?
Rating submitted. Please provide additional feedback (optional):