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. <rrhodes AT firstenergycorp DOT com>
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 AT VM.MARIST DOT EDU] On Behalf 
> Of
> Rick Adamson
> Sent: Friday, March 06, 2015 1:38 PM
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
> Of
> Rhodes, Richard L.
> Sent: Friday, March 06, 2015 12:37 PM
> To: ADSM-L AT VM.MARIST DOT 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 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: 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.
>