I think I can confirm this. I took my database volumes, and split them
up into individual volumes. What I saw, was TSM hitting one volume, and
it's mirror. It was much slower than the striped volumes. I now have
it striped across 6 volumes, instead of only 4. I am also experimenting
with making the storage pool volumes individual JFS files, instead of
raw striped volumes. I have only converted one at this time, but it
seems like read performance has gone way up. I did this also because
the loss of one disk killed the whole storage pool, and while it is
rare, it happened to us about 3 weeks ago, and I lost abou 120GB of
data.
Andy Carlson |\ _,,,---,,_
andyc AT andyc.carenet DOT org ZZZzz /,`.-'`' -. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html
On Mon, 12 Nov 2001, Joshua S. Bassi wrote:
> I do not believe that TSM starts a separate thread for each DB volume
> created. That is how disk stg pool volumes work, but not the DB. The
> DB is read sequentially from what I understand.
>
>
> --
> Joshua S. Bassi
> Independent IT Consultant
> IBM Certified - AIX/HACMP, SAN, Shark
> Tivoli Certified Consultant- ADSM/TSM
> Cell (408)&(831) 332-4006
> jbassi AT ihwy DOT com
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Salak Juraj
> Sent: Monday, November 12, 2001 2:06 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Best Database Performance
>
> Hi,
>
> this has been discussed very often, you may ant to have a look into
> forums history on http://msgs.adsm.org.
>
> Database performace is all about random access times, not about speed of
> streaming.
>
> Basically, TSM will start one I/O in each database volume,
> so having 4 database volumes spread over 4 physical disk may be a good
> solutions.
>
> If your disk controller has sigificant amount of cache and good
> optimising alghoritm,
> enabling much more I/O on one disk could be helpfull. If you have almost
> no cache on controller and on your disks,
> this may slow down your DB significantly.
>
> There are few parameters in OPT file which affect the performance
> (parallel write, read with verify),
> there you can gain some speed at the costs of security.
>
> Do allow as much software disk cache as possible, it usually helps a
> lot.
>
> Berst Regards
>
> Juraj �alak
> Asamer Familienholding G M B H
> EDV
> Unterthalhamstra�e 2
> A-4694 Ohlsdorf
> �sterreich
> www.asamer.at
>
> B�ro: +43 7612 799 529
> Mobil: +43 664 528 6474
> e-mail: j.salak AT asamer DOT at
>
>
>
>
>
>
>
> -----Original Message-----
> From: Andy Carlson [mailto:andyc AT ANDYC.CARENET DOT ORG]
> Sent: Friday, November 09, 2001 4:16 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Best Database Performance
>
>
> Does anyone have a feeling about what is best for database
> performance? I have, since we moved to AIX, taken the 4 physical drives
> (actually 8 with ADSM mirroring), and striped it into one large
> volume. I saw a post the other day that suggested that maybe splitting
> it to 4 individual volumes might be better, as ADSM can schedule across
> these volumes. What I am seeing leads me to believe that ADSM is
> hitting one volume, and it's mirror predominately. Was I better off
> striped? Any suggestions? Thanks for any info.
>
> Andy Carlson |\ _,,,---,,_
> andyc AT andyc.carenet DOT org ZZZzz /,`.-'`' -. ;-;;,_
> BJC Health System |,4- ) )-,_. ,\ ( `'-'
> St. Louis, Missouri '---''(_/--' `-'\_)
> Cat Pics: http://andyc.dyndns.org/animal.html
>
|
