We have our database on RAID-5 :  we started off on 7137 SCSI but have
recently moved to SSA, with the enhanced adapter, fast write cache and
9GB drives.  In the early days I did a lot of performance analysis work
:  mirroring, striping etc and I have to say that on balance the RAID-5
performed the best.  Some operations were better on non-RAID and others
better with RAID.

When we moved from 7137 to SSA the time for DB FULL backup decreased
from 3.5 hours to 2.5 hours.  I haven't done any contention measurements
as indicated in recent messages on this topic.  DB is almost 50GB and
the volumes are 2GB each.  Platform is RS6000/R40 and AIX 4.2.1, ADSM
server 3.1.0.2.

STG POOLS don't seem to be behaving quite as well on RAID as on mirrored
volumes - but that's another story ;)

Regards, Sheelagh
------------------------------------------------------------------------------
-----
Sheelagh Treweek                         Email: Sheelagh Treweek                
         Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Oxford University Computing Services     Tel:   +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK     Fax:   +44 (0)1865 273275
------------------------------------------------------------------------------
-----


> From owner-adsm-l AT VM.MARIST DOT EDU  Fri Jun  5 16:52:37 1998
> Date: Fri, 5 Jun 1998 11:51:09 -0400
> From: Richard Sims <rbs AT BU DOT EDU>
> Subject: Re: Anyone else having server database contention problems?
> To: ADSM-L AT VM.MARIST DOT EDU
> 
> >The single biggest caveat to this notion is that ADSM apparently doesn't
> >"spread" the database evenly over the multiple disks as it grows.  Is
> >there a way that this can be forced?
> 
> It really doesn't much matter, because having it optimized for one type of
> operation would render it degraded for another.  What would probably help
> most would be RAID data striping, as in RAID-5, to try to return data
> faster by parallelizing access.  In general, this whole topic gets into
> database architecture study, and given that the ADSM database is of
> proprietary nature, it is incumbent upon IBM to publish information for
> optimizing performance...and we are hearing an abundance of customer need
> in this area, as ADSM is being employed for larger systems, as it is
> being marketed for.  Larger shops may want to consider a hierarchy of
> servers, which is the gist of ADSM v.3, and thus distribute the load over
> multiple servers but with the facilities of v.3 have common terminal and
> report views.  There are possibilities available.  We as customers have to
> grow out of the "single ADSM server" thinking of the past, particularly as
> client volumes grow unweildy for a single server.
>     Richard Sims, Boston University OIT