Our stakeholders don't care about which component of a backup failed - 
they (at least around here) care about failures and resolving any issues 
around failures. It would be nice if libobk would have hooks into RMAN 
which would perform exception handling.

The problem that I have with your analogy, is that NBU accurately 
reports and records job status for everyone, but "BillyBob Oracle". 
Therefore, it would be reasonable to expect that job status would be 
returned correctly for "BillyBob".

The way that it is now, an Oracle backup kicked off via the NBU 
scheduler, can fail, while returning a status 0. It's bad enough that 
NBU doesn't have an alerting mechanism, but furthermore, NBU would never 
report the job as having failed, nor could an operator watching the job 
summary window in the GUI.

As an end user, I expect a backup product to accurately return the exit 
status of a backup job. I don't think that's too much to ask for. So, it 
requires a bit more coding to interface with RMAN. Easily accomplished - 
we wrote one.

Just my $.02



Jeff Lightner wrote:
> NBU isn't terrible at determining RMAN success/failure - it simply
> doesn't do it.  RMAN by its nature is client initiated.  NBU cares about
> the actual transfer to storage unit.  RMAN cares about the end to end
> process so of course should be the tool that determines the
> success/failure.   More than once I've seen RMAN fail before it ever got
> to NetBackup.
>
> It would be much like telling me I have to deposit all the money I
> receive form cashiers then asking me where the $10,000 that BillyBob
> absconded with instead of turning it into me went.  I'd have no clue
> because BillyBob didn't do his part.  The best I could do is say "I
> never got anything from BillyBob."  At that point you would want to see
> me arrested rather than tracking down BillyBob simply because I'm in
> easy reach.  You'd still be out the money but would feel happy because
> you'd found a scapegoat  :p 
>
>
>
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Martin,
> Jonathan
> Sent: Thursday, June 14, 2007 1:34 PM
> To: Hudson, Steve; Wilkinson, Alex; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] [ORACLE] Policy Naming ... Best Practices ?
>
>
> I guess you can do it anyway that floats your boat.  I personally try to
> limit the number of policies.
>
> We have policies grouping application and server.
>
> We use the following parameters.
>
> 1 - script passes the schedule name  (Weekly-Full) to .cmd or .sh
> 2 - RMAN script calls the $schedule variable with an underscore
> (Weekly_Full_) which is the application backup schedule.
> 3 - We have one script per database in the policy under the selection
> list.  If a database doesn't exist on a server that server still has the
> script, its just empty (Echo 123 etc..)
>
> With regards to monitoring for success, Netbackup is TERRIBLE at
> handling RMAN successes and failures.  We have scripts monitor the RMAN
> output logs.
>
> -Jonathan
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Hudson,
> Steve
> Sent: Thursday, June 14, 2007 12:54 PM
> To: Wilkinson, Alex; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] [ORACLE] Policy Naming ... Best Practices ?
>
> We create a separate policy for each Rman Database.....
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
> Wilkinson, Alex
> Sent: Thursday, June 14, 2007 2:56 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] [ORACLE] Policy Naming ... Best Practices ?
>
> Hi all,
>
> Is it best to create a separate policy for each oracle instance ?
>
> Currently I have 4 instances being backed up in a single policy and it
> is impossible to distinguish which instance succeeded and which failed.
>
> What do other people do ?
>
>  -aW
>
> IMPORTANT: This email remains the property of the Australian Defence
> Organisation and is subject to the jurisdiction of section 70 of the
> CRIMES ACT 1914.  If you have received this email in error, you are
> requested to contact the sender and delete the email.
>
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> -----------------------------------------
> The information contained in this email message and its attachments is
> intended only for the private and confidential use of the
> recipient(s) named above, unless the sender expressly agrees otherwise.
> Transmission of email over the Internet is not a secure communications
> medium. If you are requesting or have requested the transmittal of
> personal data, as defined in applicable privacy laws by means of email
> or in an attachment to email, you must select a more secure alternate
> means of transmittal that supports your obligations to protect such
> personal data.
> If the reader of this message is not the intended recipient and/or you
> have received this email in error, you must take no action based on the
> information in this email and you are hereby notified that any
> dissemination, misuse or copying or disclosure of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately by email and delete the original message.
>
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>   


-- 
===================================

   Steven L. Sesar
   Lead Operating Systems Programmer/Analyst
   UNIX Application Services R101
   The MITRE Corporation
   202 Burlington Road - MS K101
   Bedford, MA 01730
   tel: (781) 271-7702
   fax: (781) 271-2600
   mobile: (617) 519-8933
   email: ssesar AT mitre DOT org

=================================== 

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu