Re: Limitation of TSM DB Volumes
2003-04-15 08:47:08
TSM DB pages are 4k.size can't be changed.
Volumes: Raw Logical Volumes for everything, please. DB, logs, storage
pool. no need for filesystem overhead.on all platforms.
in general: use multiple db volumes; use separate physical disks/arrays for
each volume (log, db,stgpool), size correctly the db bufferpool(it is
directly linked to the amount of physical memory in your system).use
external tracks on HDs.configure your disk subsystem to spread the volumes
across the arrays.make the ESS (or HDS or EMC or whatever) cache work.
Cordiali saluti
Gianluca Mariani
Tivoli TSM Global Response Team, Roma
Via Sciangai 53, Roma
phones : +39(0)659664598
+393351270554 (mobile)
gianluca_mariani AT it.ibm DOT com
----------------------------------------------------------------------------------------------------
The Hitch Hiker's Guide to the Galaxy says of the Sirius Cybernetics
Corporation product that "it is very easy to be blinded to the essential
uselessness of them by the sense of achievement you get from getting them
to work at all. In other words ? and this is the rock solid principle on
which the whole of the Corporation's Galaxy-wide success is founded
-their fundamental design flaws are completely hidden by their
superficial design flaws"...
"Richard L.
Rhodes"
<rhodesr@firste To
nergycorp.com> ADSM-L AT VM.MARIST DOT EDU
Sent by: "ADSM: cc
Dist Stor
Manager" bcc
<ADSM-L AT VM DOT MARI
ST.EDU> Subject
Re: Limitation of TSM DB Volumes
15/04/2003
09.44
Please respond
to rhodesr
On 14 Apr 2003 at 10:00, Matt Simpson wrote:
> At 8:16 AM -0005 4/14/03, Richard L. Rhodes wrote:
> >Our current TSM server uses Shark storage. We run a 80gb TSM db on 2
> >shark raidsets (8 packs) of 18gb drives. All 20 db volumes are in
> >this same filesystem along with the log(5gb), spread across all 18
> >spindles.
>
> A lot of this stuff is still pretty hazy to me, but does that mean
> you're not using raw volumes for the DB? IBM recommended that we use
> raw volumes for performance reasons. We're also running on a Shark.
> We have a 60gb database spread across 9 dbvolumes, all raw.
> Considering how much Shark I/O is virtual, would we be better off
> defining file systems on those partitions and defining multiple DB
> vols per partition? --
Boy, I wish I had an answer for you. I'm not sure what is best. All
I can really say is that ours has worked very well. Our staging
pools are all raw volumes - but our db and log afe filesystems. This
was what the IBM help setup when the helped with our initial
installation. To say that we spent many, many hours discussing
pro/con of shark configuration is an understatement.
The rest of our config has 2 staging pool volumes of 50gb each per
shark raidset. Each raidset is a shark 8 pack of 18gb drives. In
all, we have 12 raidsets for staging pools - that's 24 raw volumes
total.
-----------------------------------------
The information contained in this message is intended only for the personal
and confidential use of the recipient(s) named above. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified that you
have received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you
have received this communication in error, please notify us immediately,
and delete the original message.
|
|
|