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@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Sunday, March 08, 2015 5:19 PM To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of Rick Adamson Sent: Friday, March 06, 2015 12:12 PM To: ADSM-L@VM.MARIST.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
