We have a host that houses an oracle instance backed up by 2 separate policies.  1 Policy backups up archivelogs.  The second policy backs up the database.  Both of these policies call the same RMAN script.  Both policies point to the same storage unit group which contains 2 storage units.  These storage units are 2 directories on a data domain storage appliance

 

In the activity monitor, both policies show that they run when they are supposed to run and complete without error.  The backups logs for all backups managed for these 2 policies show the backups complete without error.

 

However… When querying the Netbackup catalog, We can see images from the archive log backup policy but cannot see a single image for the database policy.  Also… looking on the datadomain, we can see the images written by the archive policy but cannot see the images written by the database policy.  Both policies are subject to the same RMAN parameters so we are totally baffled as to why one would work successfully and the other would appear to be working fine but never sends any data.

 

The only obvious difference I can see anywhere in this whole setup is in the detailed info for the jobs created by the two policies.

 

In the archive policy (which works) we see the path to the data domain clearly displayed in the job info

 

4/29/2010 2:53:23 PM - requesting resource DataDomain_OraArchTier1

4/29/2010 2:53:23 PM - requesting resource nbumaster01.sun.spartech.com.NBU_CLIENT.MAXJOBS.oraprod.sun.spartech.com

4/29/2010 2:53:23 PM - requesting resource nbumaster01.sun.spartech.com.NBU_POLICY.MAXJOBS.Solaris_OraArchTier1

4/29/2010 2:53:23 PM - granted resource nbumaster01.sun.spartech.com.NBU_CLIENT.MAXJOBS.oraprod.sun.spartech.com

4/29/2010 2:53:23 PM - granted resource nbumaster01.sun.spartech.com.NBU_POLICY.MAXJOBS.Solaris_OraArchTier1

4/29/2010 2:53:23 PM - granted resource MediaID=@aaaah;Path=/dd/ddstldd560/backup/oracle/arch;MediaServer=nbumedia01.sun.spartech.com

4/29/2010 2:53:23 PM - granted resource ddnbumedia01_OraArchTier1_1

4/29/2010 2:53:24 PM - estimated 0 Kbytes needed

4/29/2010 2:53:24 PM - started process bpbrm (5715)

4/29/2010 2:53:24 PM - connecting

4/29/2010 2:53:34 PM - connected; connect time: 00:00:10

4/29/2010 2:53:37 PM - begin writing

4/29/2010 3:06:30 PM - end writing; write time: 00:12:53

the requested operation was successfully completed(0)

 

However, in the db backup job, although it appears to assign the storage unit successfully, it never shows this path to the data domain

 

4/17/2010 12:59:59 AM - requesting resource DataDomain_OraDbTier1

4/17/2010 12:59:59 AM - requesting resource nbumaster01.sun.spartech.com.NBU_CLIENT.MAXJOBS.oraprod.sun.spartech.com

4/17/2010 12:59:59 AM - requesting resource nbumaster01.sun.spartech.com.NBU_POLICY.MAXJOBS.Solaris_OraDbTier1

4/17/2010 12:59:59 AM - granted resource nbumaster01.sun.spartech.com.NBU_CLIENT.MAXJOBS.oraprod.sun.spartech.com

4/17/2010 12:59:59 AM - granted resource nbumaster01.sun.spartech.com.NBU_POLICY.MAXJOBS.Solaris_OraDbTier1

4/17/2010 12:59:59 AM - granted resource ddnbumedia01_OraDbTier1_1

4/17/2010 1:00:00 AM - estimated 0 Kbytes needed

4/17/2010 1:00:00 AM - started process bpbrm (16780)

4/17/2010 1:00:01 AM - connecting

4/17/2010 1:00:01 AM - connected; connect time: 00:00:00

4/17/2010 6:13:01 AM - end writing

the requested operation was successfully completed(0)

 

Has anyone seen anything like this before ?  This is baffling us as the oracle backup script called by Netbackup, the RMAN parameters on the host and the storage units are all the same for both of these policies but we can see data from one and nothing from the other.

 

I should also point out that we have an OS backup that runs on the host which also writes to the data domain without issue.

 

Any help greatly appreciated,

 

Mark Glazerman

Enterprise Storage Administrator

Spartech Corporation

Desk: 314-889-8282

Fax: 314-854-8282

Cell: 618-520-3401

mark.glazerman AT spartech DOT com

http://www.spartech.com

P please don't print this e-mail unless you really need to

This e-mail and any files transmitted with it are confidential, are intended solely for the use of the addressee, and may be legally privileged. If you have received this email in error please notify the sender immediately, and do not copy or forward it.