We are trying to implement the ADSM Connect Agent for Microsoft SQL Server
in our environment, but we have one SQL Server administrator who stongly
objects to using ADSM .  I am not an SQL Server expert, and I don't  fully
understand his issues.

I am attaching his list of issues.   Can someone familiar with SQL Server
and ADSM please review his comments and provide some objective feedback ?
Thanks.


His issues are:

This is a list of the issues with the "global backup strategy" when
> applied to SQL Server.
>
> 1. The ADSM client starts independently from the SQL Server Executive
> and thus can start up "inopportune" times with respect to processes
> already running.  This has already occurred on the SRC server, resulting
> in a complete shutdown at the NT level.  The SRC problem was caused due
to
> the ADSM client grabbing system memory which an SRC procedure required to
> execute.  Both attempted to grab the memory simultaneously resulting in a
> complete system shutdown.

> 2. Numerous maintenance routines are required on any relational DBMS,
> including index re-builds (both to de-fragment table pages and to flatten
> index structures), statistical re-compilations on those tables not
> re-indexed, etc. to maintain performance.

> 3. After the index re-builds and statistic runs, all stored procedures,
> views and triggers must be recompiled to allow the optimizer to
> incorporate the new statistics into the navigation path selections.

> 4. All the above maintenance procedures must be coordinated with the
> backup process which is easily accomplished with the SQL Server internal
> scheduler, but is not possible if ADSM is the backup environment.

> 5. Database activity itself my require the ability to trigger an
> on-demand backup.  This usually occurs when the database's log table is
> full (or nearly full) and must be done immediately or all insert or
update
> activity will cease on the database.  Since ADSM cannot be triggered by
an
> internal database action, it cannot support this requirement.
>