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
Re: DB2/Oracle backup reporting and scheduling
Our Oracle backups have three scenarios. 1) Home grown scripts are scheduled via cron on the Oracle server, copy/compress the db to local disk, then pushed the db backup to TSM via a dsmc backup of the backup disk area. 2) RMAN backups are scheduled via cron which push data to TSM via LanFree/SAN or Network. 3) Some RMAN backups run via cron and write direct to DataDomain via NFS. (no TSM involvement) Note - archive logs are pushed to TSM via scripts and run around the clock. Rick -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: 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 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: DB2/Oracle backup reporting and scheduling
Rick, This all began after a recent audit revealed many systems either had missed backup schedules, excessive retention, or no backups at all, which led to the question of how we can better account for them on a day-to-day basis. Of course then the usual finger pointing ensued and management asked what could be done to address it. How do you assure your business, and auditors, that the expected data is available in the event a recovery is needed? ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Friday, March 06, 2015 12:37 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] DB2/Oracle backup reporting and scheduling Our Oracle backups have three scenarios. 1) Home grown scripts are scheduled via cron on the Oracle server, copy/compress the db to local disk, then pushed the db backup to TSM via a dsmc backup of the backup disk area. 2) RMAN backups are scheduled via cron which push data to TSM via LanFree/SAN or Network. 3) Some RMAN backups run via cron and write direct to DataDomain via NFS. (no TSM involvement) Note - archive logs are pushed to TSM via scripts and run around the clock. Rick -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: 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 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: DB2/Oracle backup reporting and scheduling
Yea, that's a major problem we struggle with also. We've had major problem with the dba's making sure that the Oracle backup are completed/good. We've had several instances where major systems have had failing backups that they didn't know about to the point where there was no backups for them. For Oracle/Rman backups I have a report that crawls throught the backups table and reports on old files, but that is mostly to catch RMAN not expiring items. Sorry, but no good solution here. Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick Adamson Sent: Friday, March 06, 2015 1:38 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: DB2/Oracle backup reporting and scheduling Rick, This all began after a recent audit revealed many systems either had missed backup schedules, excessive retention, or no backups at all, which led to the question of how we can better account for them on a day-to-day basis. Of course then the usual finger pointing ensued and management asked what could be done to address it. How do you assure your business, and auditors, that the expected data is available in the event a recovery is needed? ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Friday, March 06, 2015 12:37 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] DB2/Oracle backup reporting and scheduling Our Oracle backups have three scenarios. 1) Home grown scripts are scheduled via cron on the Oracle server, copy/compress the db to local disk, then pushed the db backup to TSM via a dsmc backup of the backup disk area. 2) RMAN backups are scheduled via cron which push data to TSM via LanFree/SAN or Network. 3) Some RMAN backups run via cron and write direct to DataDomain via NFS. (no TSM involvement) Note - archive logs are pushed to TSM via scripts and run around the clock. Rick -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: 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 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: DB2/Oracle backup reporting and scheduling
We have the same scenario. Oracle, db2 and MSSQL clients all prefer to do their own backups. It comes down to accountability. If they want to run their own backups then THEY are responsible for reporting on them. Maybe a harsh stance, but if I can't schedule it I will not report on it or be accountable for its success or fail. As long as they, and their management know that, then that's fine. FYI, oracle grid will report on rman backups. Steven On Sat, 7 Mar 2015 12:15 Rhodes, Richard L. wrote: > Yea, that's a major problem we struggle with also. > > We've had major problem with the dba's making sure that the Oracle backup > are completed/good. We've had several instances where major systems have > had failing backups that they didn't know about to the point where there > was no backups for them. > > For Oracle/Rman backups I have a report that crawls throught the backups > table and reports on old files, but that is mostly to catch RMAN not > expiring items. > > Sorry, but no good solution here. > > Rick > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Rick Adamson > Sent: Friday, March 06, 2015 1:38 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: DB2/Oracle backup reporting and scheduling > > Rick, > This all began after a recent audit revealed many systems either had > missed backup schedules, excessive retention, or no backups at all, which > led to the question of how we can better account for them on a day-to-day > basis. Of course then the usual finger pointing ensued and management > asked what could be done to address it. > > How do you assure your business, and auditors, that the expected data is > available in the event a recovery is needed? > > ~Rick > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Rhodes, Richard L. > Sent: Friday, March 06, 2015 12:37 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] DB2/Oracle backup reporting and scheduling > > Our Oracle backups have three scenarios. > > 1) Home grown scripts are scheduled via cron on the Oracle server, > copy/compress the db to local disk, then pushed the db backup to TSM via a > dsmc backup of the backup disk area. > > 2) RMAN backups are scheduled via cron which push data to TSM via > LanFree/SAN or Network. > > 3) Some RMAN backups run via cron and write direct to DataDomain via NFS. > (no TSM involvement) > > Note - archive logs are pushed to TSM via scripts and run around the clock. > > > Rick > > > -----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: 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 > > > - > > The information contained in this message is intended only for the > personal and confidential use of the recipient(s) named above. If the > reader of this message is not the intended recipient or an agent > responsible for delivering it to the intended recipient, you are hereby > notified that you have received this document in error and that any review, > dissemination, distribution, or copying of this message is s
Re: 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
Re: DB2/Oracle backup reporting and scheduling
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 ha
Re: DB2/Oracle backup reporting and scheduling
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@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 reporti
