I/O, I/O, it's all about I/O..... and IT DEPENDS on your hardware.
The key here is that when you have the DB or a storage pool split into
multiple "volumes", TSM will start multiple I/O operations to the DB or
storage pool. You can use that to your advantage to improve performance, or
carry it to such and extreme that it hurts your performance.
If you are talking physical disk:
>> when you put many DB or storage pool "volumes" on one disk, you can get
multiple I/O's in flight, all trying to access the same physical disk. The
disk heads get yanked back and forth from one volume location to another,
and that slows you down.
If you are talking ESS, that is a whole different animal.
>> The "volumes" you create are really split across many physical disks
inside the ESS and there is a LOT of cache in the box that buffers I/O and
makes it asynchronous, so you don't have to worry much about the performance
hit caused by physical head movement.
If you are talking non-ESS RAID, that is different still, as every vendor's
implementation is a little different.
>> With simple RAID implementations on arrays made up of a few disks you can
get a performance penalty on WRITE; BUT if the vendor has enough RAM in the
box to buffer the I/O, you see less of an impact.
In your case, I expect the objective is to get your DB spread across those
ESS loops, more than specifically getting you out of a single filesystem.
That spreads your I/O out to get the max advantage of the hardware.
SO IT DEPENDS, you will get different answers about performance and disk
configuration, and there are sometimes multiple ways to do it, depending on
your hardware and the problem you are trying to solve.
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
-----Original Message-----
From: Thach, Kevin [mailto:KThach AT COVHLTH DOT COM]
Sent: Friday, November 22, 2002 9:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Relocating TSM DB (storage)
Funny you should mention that. We have been working with IBM ATS support
about poor performance issues with our TSM config, and they say that our
problem is because we have all 37 volumes in one AIX logical
volume/filesystem. They have had us create 32 new AIX logical
volumes/filesystems (don't need 37 because our db is not very full after
running CLEANUP BACKUPGROUPS), each with a 1GB TSM DBvol inside, all of
which are on separate ESS loops. They said the smaller DB volumes are
better! Argghh!!
-----Original Message-----
From: Robert L. Rippy [mailto:robert_rippy AT KINDREDHEALTHCARE DOT COM]
Sent: Friday, November 22, 2002 9:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Relocating TSM DB (storage)
Yes, you are correct. Create the new DB's and extend the DB and then delete
the old DB's. The data will migrate over to the new extended space. Any
reason you had 37 1GB volumes for your DB's. IBM told me not to really go
over 10 volumes on your DB and to be sure they aren't on the same drive if
you can help it.
I would suggest that if you could, create 5 8GB new volumes for a total of
40GB and move the DB over to the new 8GB partitions.
Thanks,
Robert Rippy
From: "Thach, Kevin" <KThach AT COVHLTH DOT COM> on 11/22/2002 09:30 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Relocating TSM DB (storage)
I am wanting to move our TSM DB which is currently on ESS, and has 37 1GB
dbvolumes, to another set of ESS disk. If I define the new dbvolumes on
the
new disks, do I then just extend the db, and then do a del dbvol on the old
ones? Does the delete make the data migrate over?
Do I have to do a reduce db for any reason before I do the delete dbvol?
Can I do the delete with the server up and running?
Thanks
This E-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only
for the use of the Individual(s) named above. If you are not the intended
recipient of this E-mail, or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
dissemination or copying of this E-mail is strictly prohibited. If you
have
received this E-mail in error, please immediately notify us at (865)
374-4900 or notify us by E-mail at hdesk AT covhlth DOT com.
This E-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only
for the use of the Individual(s) named above. If you are not the intended
recipient of this E-mail, or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
dissemination or copying of this E-mail is strictly prohibited. If you have
received this E-mail in error, please immediately notify us at (865)
374-4900 or notify us by E-mail at hdesk AT covhlth DOT com.
|
