One last post...

Rocket Servergraph has been expanded to report of lots of stuff other
than TSM including Oracle and Protectier. I'm replacing a poorly
configured Bocada system (ie its not Bocada's fault) with it on one of
my customers, at least I've recommended it but someone has to provide
the dollars.

It may be worth a look.

Regards

Steve

Steven Harris
TSM Admin
Canberra Australia

On 10/03/2015 1:08 AM, Rick Adamson wrote:
> Thanks everyone for the feedback/ideas! They reaffirm my initial
> thoughts that there was no single solution, but collectively it
> appears that I can marginalize the risk. Ultimately as many have
> stated the DBA team will need to be held accountable, and they do
> insist they own their backups........ until there is a problem :) I
> will make a mental note to update the thread once a direction has
> been determined in hopes others find it helpful.
>
> ~Rick
>
>
> -----Original Message----- From: ADSM: Dist Stor Manager
> [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Prather, Wanda Sent:
> Sunday, March 08, 2015 5:19 PM To: ADSM-L AT VM.MARIST DOT EDU Subject:
> Re: [ADSM-L] DB2/Oracle backup reporting and scheduling
>
> Rick, It's a problem, everywhere, no matter how you do it.
>
> *       The simplistic answer to your question is yes; the external
> scheduler is running a list of tasks; after the last task it could
> call a perl/ksh/python/yourfavorite script that invokes dsmadmc and
> does a delete/define schedule with a start time of "now".  One
> drawback, the client has to be running in "prompted" mode, and
> another drawback is that from your end, since the schedule gets
> deleted and redefined, you would have to be able to notice the
> *absence* of that schedule.  But see gotcha in bullet 3 below.
>
> *       What might work better is to have the external scheduler's
> last task be to fire a script that writes a checkpoint/log file.
> Have your TDP client schedule kick off the same time each night,
> add a preschedule cmd script that opens the checkpoint file and
> reads the timestamp, if it doesn't have todays' expected timestamp,
> close the file, sleep 10 minutes, rinse and repeat.
>
> *       However, even if you get one of those methods to work, it
> won't solve the problem.  I don't know about DB2, but unless
> something has changed recently the only result you will get back
> from firing off the Oracle TDP with the TSM scheduler is whether
> RMAN started or not, it won't tell you whether the backup was
> successful or failed.  The DBA's actually have to check the results
> of the backup from RMAN, AFAIK.  (Once years ago I got a Unix
> wizard to poke around and write a script that parsed the actual
> RMAN output and sent email back to me, but it's not something
> that's commonly done and would probably require specific knowledge
> of that particular backup.)
>
> *       If your manager trusts your DBA's, there's nothing wrong
> with distributed authority and making them responsible for their
> backup results, most of my large customers do that.  (Most good
> DBA's want that, anyway.)
>
> *       I have had customers where the DBA's were proved
> untrustworthy, and I also resorted to perl/ksh/whatever scripts
> that did selects on the BACKUPS table and started firing off emails
> to managers if backups were missing.  (You can usually get info
> from the backups table without too much pain if you specify both
> the client node name and filespace name/id so the result table is
> fairly small and TSM can use indexing to find the stuff.)  I've
> even resorted to perl scripts that query the activity log for
> messages from those clients, and report those out via email.
>
> *       FWIW, in the new Operations Center, Tivoli development has
> approached this by introducing the concept of "at risk".  You
> specify in the TOC how often the clients should back up (daily,
> weekly, etc.) and if even the TDP clients go beyond that without a
> backup, they show up as "at risk".  The 7.1.1 TOC has a minimal
> email report that does show the at-risk TDP's.  I haven't played
> with it yet for TDP's to know whether it can distinguish between
> "time since last contact" and "time since a successful RMAN
> backup".  But you could look at it.
>
>
> Wanda Prather TSM Consultant ICF International Enterprise and
> Cybersecurity Systems Division
>
>
>
>
>
> -----Original Message----- From: ADSM: Dist Stor Manager
> [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of Rick Adamson Sent:
> Friday, March 06, 2015 12:12 PM To: ADSM-L AT VM.MARIST DOT EDU Subject:
> [ADSM-L] DB2/Oracle backup reporting and scheduling
>
> I assume someone has dealt with this I would like to hear how they
> handled it.
>
> The issue: DB2 and/or Oracle database backups that are dependent on
> completion of external processes.
>
> Currently our DBA's utilize a variety of methods to initiate DB2
> and Oracle database backups (CRON, external schedulers, etc) which
> presents challenges to confirm that they are being completed as
> expected. As a start, I proposed creating a client schedule and
> using the TSM scheduler to trigger these events, which would
> minimally provide a completed/missed/failed status. Complemented by
> routine reporting of stored objects it would give me some assurance
> that TSM had what it needed to assure their recovery.
>
> The DBA's are pushing back (surprise!) claiming that "some" backups
> have special requirements, such as not running during other tasks
> like payroll processing, runstats, etc. so they use the external
> scheduler to set "conditions" that are met before the backup is
> initiated.
>
> The question proposed to me is can a TSM schedule be triggered by
> the external scheduler once the conditions have been met?
>
> I would be grateful to hear how others handle this, or if they use
> a different approach altogether to assure all DP database backups
> are completing on a timely basis. TIA
>
> ~Rick
>