In reply to Eric van Loons justification requirement for using EBU with
ADSM via the Connect Agent.

Making your job easier is exactly the point - its how that is expressed
that matters. Whereas technically it is possible to recreate the
functionality, to a certain point, using scripting techniques and the
native Oracle facilities there are additional factors.

When performing restores taken from hot backups you have to be very careful
to get the correct set of files restored, especially the archived redo
logs. Its all about confidence in the ability to restore - without making
the problem that you're originally performing the restore for even worse,
i.e. speed of recovery in the middle of the night or at the end of a very
long day.

As you add more Oracle databases in your enterprise you don't want to have
to add more staff to handle backup and recovery situations, the buzz words
required here are cost-effective scaling up.

Similarly you don't want the overhead of firstly developing any scripts
which could replace the functionality of EBU that you require and then the
overhead of maintaining them (O/S upgrades, rare condition handling, loss
of key staff) - unless your core business is in fact development of system
utilities.

The four lines of text required to perform accurate and reliable backups
and restores in an EBU environment mean de-skilling and even automating the
tasks are more achievable goals - i.e. empower your overnight ops with the
task of performing restores for which they currently need to get you out of
bed  in order to have confidence in the restore. Sorry for more buzz words
and management-speak phrases but they really do help present the case.
Stress the reduction in support costs for out of hours working.

Ok enough, its starting to sound like a lecture, for which I apologise. I
don't work for IBM or Oracle, I just have responsibility for a large
support team who runs many UNIX boxes with about 50 Oracle databases in the
machine room and have had to go through similar pain - we just used scripts
for the hot backups until the connect agent was available and it was indeed
painful when the inevitable restore and disaster recovery situations arose.
Incidentally all the same arguments apply to cold backups too.

I do agree that as a glue API type product the ADSM Connect Agent is
initially seen as prohibitively expensive and can understand why it would
prevent adoption of the facility in a cost (only) conscious company. IBM,
from Erics comments and this please heed. The code only exists because
Oracle have a product and define an API, IBM has a product (ADSM) and
defines an API and neither was compatible with the other.

Good luck in your justification Eric, hope some of the 'BS' type content
above helps present your case to those who need this ;-)
Regards
Alan