To: ADSM-L @ VM.MARIST.EDU (Multiple recipients of list ADSM-L) @ Internet
cc:  (bcc: John Howard/RICHMOND/PMU/PHILIP MORRIS/US)
From: smcclure @ IS.RICE.EDU (Susan McClure) @ Internet @ WORLDCOM
Date: 05/09/96 02:21:14 PM CDT
Subject: Re: ADSM and SAP

On May 9,  2:49pm, John Howard wrote:
> Subject: ADSM and SAP
> Queries to the crowd:
> 1. ADSM doesn't appear to be good at central logging of events, etc., nor at
> centralized management of servers.  We are building an environment of  3 SP2
> towers, 4 or 5 eight-way R30 systems, and various Sun and HP systems to
support
> SAP and related products.  To minimize our backup time, we have to run
multiple
 > servers and 3494 robotic systems.  A BIG issue is the management of the
backups
> for this environment as a whole, and not as many separate ADSM server
> environments.  IBM folks tell me that this will be addressed in 1997, but
we're
> going "live" in July 1996.   We have been looking closely at products from
> Software Clearing House (affiliated with Storage Technology) that fulfills
this
> need, but has serious problems with SAP's approved backup plan.  Does any one
> of you have any suggestions or know of any helpful documention that may help
us
> make ADMS "be all that it can be" in this environment?
>
> 2. ADSM seems to be constrained in it's ability to keep up with the input
> capacity of 3590 tape systems.  For example, IBM reps have mentioned a rule of
> thumb to expect (even with SSA disk drives) about a 3 to 1 throughput
> capability of the 3590 over the disk drive during the backup.  Other backup
> products claim to overcome this by multiplexing multiple, parallel I/O streams
> from multiple disk drives (or tablespaces) to a single tape drive.  Has any of
> you any experience with this or comments you'd like to share?
>
> Thanks,
>      John Howard
>-- End of excerpt from John Howard

>On May 9, Susan McClure responded:
>John
>HAve you talked to the SAP folks about the BACKINT interface to ADSM for
>backups?  Basically, SAP does the online or offline DB backup to a file, then
>BACKINT invokes ADSM to archive that file (that is the db and logs).  Within
>BACKINT, there is the ability to specify multiple processes.... so ADSM will
>write data to 2,3,4 etc tape drives at once for one database.  We use this on a
>single SP2 with 4 different databases.  Each database kicks off at a different
>time, and the BACKINT is setup to use two tape drives at once.  So each db
>backup ends up on 2 or 4 tapes, depending on size.  They all finish relatively
>quickly.  Our tape robotics are not as robust or fast as yours, but it works.
>(7331, 8 mm tapes library,with 2 drives)
>-- End of excerpt from Susan McClure

Response from John Howard:
Thanks for quick response, Susan!
We are using BACKINT just in the the way you describe in our development
effort.  However, this is the "reverse" of what I attempted to describe in my
original item two.  The method you mention speeds up the backups of a single
database by pointing it to multiple tape drives.  Using this method, we could
continue to expand our 3494 tape robotic system to speed up database backups
(doesn't apply to other files), but we would not be improving use of the
throughput  capacity of the individual drives.  They would still, individually,
run under utilized.  According to IBM's rule of thumb (3MB/sec for disks, 11
MB/sec for 3590 tape), our tapes "rest" about two-thirds of the time, which
indeed seems to be true.
On the other hand, the multiplexing method described by Legato and SCH points
backups of multiple disks (or tablespaces) at a single drive, more fully
utilizing it.  Again, using IBM's rule of thumb as a rough estimate, we could
backup 3 drives (or tablespaces) to one 3590 type drive, in parallel streams,
using this technique.
This issue of performance is particularly critical to us because our primary
SAP database is expected to grow to over a terrabyte in size over the next year
or so, with a goal of 24 by 7 uptime. Improving utilization of tape drives is
far more attractive to us than acquiring more tape drives to shorten backup
windows.

       John Howard