Re: [Veritas-bu] [ORACLE] Policy Naming ... Best Practices ?

Jeff Lightner wrote:

You're incorrect.  NBU only reports what it knows.

That's my point - NBU doesn't know about it and I contend that it should. Commvault does.

If you kick off
mssql backup it will tell you what it did when it got that far but not
what happened afterwards.

I haven't noticed that behavior, but then again, I'm a UNIX guy. OK, I stand corrected. But again, Commvault does.

Similarly - NetBackup DOES show you what
happened to the tape jobs it was told to kick off by RMAN - it simply
can't tell you end to end.

Again, exactly my point - I think that a backup product should accurately and completely report every aspect/component of a backup job.

The job started BEFORE it got to NBU and
ended AFTER it left NBU.

Not true. NBU kicks off the script which builds/executes the RMAN code.

There has been more than one occasion where
I've seen RMAN fail with a status 6 even though the NBU portion of the
job ran fine.   It always had to do with configuration errors in RMAN.
My analogy was about this.  

Certainly if BillyBob in fact gives me the $10,000 NOT in a sealed
envelope I can report that as a "fact".  However, I can not prove a
negative (i.e. that he DIDN'T give me the money.  I wouldn't even know
to state that he didn't unless someone asked me (or looked at my
"activity monitor" to see there was no information regarding it at all).
Restated "information" can help "prove" a point but absence of
information can not "prove" the opposite point.  The best one can say is
"I have no information about this."

I just went this same scenario regarding an Oracle stored procedure and
a script that were supposed to be sending email via the system's
sendmail.  I'm responsible for the sendmail piece (and the next server
which is another sendmail relay) but not for the script or the stored
procedure or Oracle.  User's weren't getting emails.   The best I could
do is show that sendmail never got them which to me implied they were
never sent to sendmail.   However, it might have been that sendmail was
rejecting them without logging them for some reason.   I told them that
my strong suspicion owing to the lack of any mention in sendmail log
regarding this was that they were never being sent to sendmail in the
first place.  On pushing back and asking them to show me a log on their
end that indicated it was going to sendmail they couldn't do it.  What
they DID finally find was that there is a known issue with Oracle_SMTP
whereby it will only do 15 connections and then error out.  It had been
doing this but they hadn't noted it until I did the push back.  Once
they found the known issue and the recommended work around the emails
started showing up in sendmail logs because they finally got there.

Not a great analogy. A better analogy would be, "I'll be responsible for everyone's stored procedures and scripts, except for Billy Bob's".

All of this means that it is certain there IS positive information you
can gain from NetBackup when things work the way they should but it will
still only be NBU's portion of the job and not RMAN's.    

So to reiterate - your end to end solution for the Oracle backup is
actually RMAN and NOT NetBackup and that is why you have to rely on RMAN
(an Oracle Product) to tell you what IT did including what status it got
from NetBackup when NBU did its PORTION of the job.

Hell, when one spends the kind of money that they do for a NBU environment, I think that it should be expected that the backups product, which is what the users/admins interface with, provide the type of functionality that I'm referring to. Other do, and then some. Reporting and alerting a just a few of my gripes with NBU.

You however, are entitled to your opinion no matter how wrong it is.  :p

As you are yours. Bottom line: my company procured another backup application, which provides much more functionality than NBU, for the cost of renewing my NBU licenses for one year. Haven't had to write a single line of code to support it. Haven't had to spend $50K and up for a 3rd. party reporting tool. Haven't had to deal with NBCC, because the data and metadata is stored in a relational database. Should I go on?

-----Original Message-----
From: Steven L. Sesar [mailto:ssesar AT mitre DOT org] 
Sent: Thursday, June 14, 2007 3:12 PM
To: Jeff Lightner
Cc: Martin, Jonathan; Hudson, Steve; Wilkinson, Alex;
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] [ORACLE] Policy Naming ... Best Practices ?

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