John,
I had an LPAR dedicated to TSM - (200Mips) on a z/900.
This LPAR did NOTHING but TSM.
When your database starts going over 40Gig you WILL NOT compete
with even a Win2K server in terms of throughput.
How many concurrent TSM sessions does your TSM server handle currently?
How much data can you pump through to TSM in an evening?
How long does your database backup run to do do 35Gig?
Some performance stats from a P650 - Lpar with 4Gig Ram, 4Cpu's and 2.9 Tb
of
staging area on a FastT900.
On average we backup between 1.5 Tb to 2.5 Tb a night - on the z900 we
battled
to do 500Gig (I've got all the graphs from the mainframe days of TSM to
now).
The TSM server on AIX handles this via two Gig ethernet adapters.
The mainframe had 2 Gig ethernet adapters as well doing into the Enterprise
backbone.
The network on the mainframe was OSA express adapters BTW.....
My database currently on AIX is 85Gig big and 96% utilized.
A full database backup takes 22minutes to LTO-2 drives - my database
backup on z/Os took +- 4hours to do 39Gig - this was to 3590-K model drives.
When I originally installed Tivoli Descision Support and tried to run
reports it took in excess
of 24 Hours to actually run - which made the descision support product
useless because
I was running TSM on OS/390/z/Os - on my AIX TSM server I'm able to use the
product properly.
Don't think I'm negative towards the mainframe, (I ran ADSM v1 on MVS a
decade ago already),
and it runs fine up to a certain point - if your load is not high, then it
will suffice - when you are
running large workloads it becomes impractical - I would have had to run
about 5 LPAR's
to achieve the same I'm achieving with one midrange TSM server.
Hope this puts my perspective on mainframe TSM servers into perspective....
Regards
Christo Heuer
> Well, I have a 35 gbTSM database on Mod 9s, two volumes per physical
device
> and I have not noticed any worse performance since moving from mod 3s.
> I would have preferred to have one logical volume per physical device but
> TSM does not currently support extended vsam (over 4gb)
> If/when TSM does support extended vsam then mod 27s will be quite feasible
> for larger databases,
> I do not agree with Christo's premise that TSM mainframe performance is
> crap.
> You are not comparing like with like.
> What you see are dedicated unix or windows TSM servers, while the TSM
> mainframe server is normally sharing
> resources with many other applications.
> Certainly in my experience poor TSM mainframe performance is down to
> insufficient resources for the overall workload rather than anything
> inherent in TSM.
> thanks,
> John
>
>
>
> Christo Heuer
> <christoh AT absa DOT co
> .za> To
> Sent by: "ADSM: ADSM-L AT vm.marist DOT edu
> Dist Stor cc
> Manager"
> <[email protected] Subject
> .edu> Re: Maximum database volumes?
>
>
> 08/07/2004 07:19
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <[email protected]
> .edu>
>
>
>
>
>
>
> Performance and Tuning documentation states it should not be more than 13
> Volumes - not
> too sure how you achieve that in the mainframe world where you have 2.835
> Gig
> disks - (Mod3's).
> Most shops don't really have access to mod9's, so then from a performance
> guide point of view
> you can not really go over 36.8 Gig database size - but on the mainframe
> TSM
> starts performing
> crap before you even reach that size in anycase.
>
> Anyhow - 13 is the recommended number of DB vols.
>
> Cheers
> Christo
>
> > Before I upgrade our TSM server to v5.2 (seems to be taking forever to
do
> due to small outage windows) I want to reorganise our database volumes so
> they are a little more efficient. Is there any recommended maximum number
> of
> database volumes a TSM database should have? Ours is spread across about
20
> different volumes of varying sizes, not the best makeup I am sure, hence
> why
> I want to re-arrange it before hand.
> >
> > I've looked in the TSM Admin guide and searched IBM support, as well as
> this list, but haven't really found anything of help.
> >
> > Thanks in advance,
> >
> > Gordon
> >
> >
> > --
> >
> > This e-mail may contain confidential and/or privileged information. If
> you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> ______________________________________________
>
> E-mail Disclaimer and Company Information
>
> http://www.absa.co.za/ABSA/EMail_Disclaimer
>
>
>
>
> **********************************************************************
> The information in this E-Mail is confidential and may be legally
> privileged. It may not represent the views of Scottish and Southern
> Energy Group.
> It is intended solely for the addressees. Access to this E-Mail by
> anyone else is unauthorised. If you are not the intended recipient,
> any disclosure, copying, distribution or any action taken or omitted
> to be taken in reliance on it, is prohibited and may be unlawful.
> Any unauthorised recipient should advise the sender immediately of
> the error in transmission.
>
> Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
> are trading names of the Scottish and Southern Energy Group.
> **********************************************************************
______________________________________________
E-mail Disclaimer and Company Information
http://www.absa.co.za/ABSA/EMail_Disclaimer
|
