Remco,

I couldn't agree with you more... I was just giving an example... Although I
would say in our case I run all my TSM volumes against an ESS array so I
don't have the flexibility of putting volumes on different spindles...
Although when I upgrade from 4.2.2.3 to 5.1.6.2 it took about 5 mins to do a
30GB DB, so its not doing too badly.

Cheers

Andy Wilcox
Midrange Services
Aquila Networks Services Ltd




> -----Original Message-----
> From: Remco Post [SMTP:r.post AT SARA DOT NL]
> Sent: 15 May 2003 20:03
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: dsmserv.dsk
>
> On Thu, 15 May 2003 16:13:14 +0100
> "Wilcox, Andy" <andy.wilcox AT AQUILA-NETWORKS.CO DOT UK> wrote:
>
> > Use dsmfmt to create your log and DB volumes and then use dsmserv
> > format to format the recovery log space and create the dsmserv.dsk.
> > Please note that dsmserv.dsk will be created in the current directory.
> >
> > eg
> >
> > cd /tsm/server0 #where this $DSMSERV_CONFIG directory
> > dsmfmt -m -db /tsm/server0/db/dbvol1 1000 #where the last number is
> > size of volume in MB
> > dsmfmt -m -db /tsm/server0/db/dbvol2 1000
>
> Which works, but when tweeking for performance on our TSM server, I got
> the very strong impression that TSM tries to do smart things with
> volumes.
>
> It assumes that if you have multiple db volumes, it gives better
> performance to 'stripe' across those than first filling one and than the
> other. Which means that in your example you have a slightly decreased
> performance that just defining one 2000 MB large DBvol, and a sligtly
> bigger change of trashing effects on the disk. I've stuck to
> one dbvol per phisical volume, and it has served me well (remember me
> bragging about a 5.1 upgrade with just 15 minutes of upgradedb on our
> 100 GB db just yesterday?)
>
> > dsmfmt -m -db /tsm/server0/db/logvol1 500
> >
> > dsmserv format 1 /tsm/server0/db/logvol1 2 /tsm/server0/db/dbvol1
> > /tsm/server0/db/dbvol2 #where 1 is the number of following log file
> > specifications and 2 is the number of following db file specs.
> >
> > hope this helps a bit more...
> >
> > Cheers
> >
> > Andy Wilcox
> > Midrange Services
> > Aquila Networks Services Ltd
> >
>
> --
>
> Remco
>
>
> **************************************************************************
> **************************
> Confidentiality: This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity
> to whom they are addressed.  If you have received this e-mail in error,
> use of this information (including disclosure, copying or distribution)
> may be unlawful.  Please notify postmaster AT aquila-networks.co DOT uk. and
> delete the message immediately.
>
> Security: Internet e-mail is not a 100% secure communications medium.
>
> Viruses: This e-mail (and any attachments) has been checked (using Sophos
> Sweep 3.68 + patches) and found to be clean from any virus infection
> before leaving.
> Therefore neither Aquila Networks Services Ltd nor Midlands Electricity
> plc  or any of their group undertakings  (as defined by the Companies Act
> 1989) (together referred to as the "Companies") accept legal
> responsibility for this message or liability for the consequences of any
> computer viruses which may have been transmitted by this e-mail.
>
> Monitoring: All electronic communications with the Companies may be
> monitored in accordance with the UK Regulation of Investigatory Powers
> Act, Lawful Business Practice Regulations, 2000.  If you do not consent to
> such monitoring, you should contact the sender of this e-mail.
>
> Aquila Networks Services Limited,
> Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB
> Registered in England and Wales number 3600545
> This e-mail may be sent on behalf of any of the Companies.
> **************************************************************************
> **************************