Farren
I echo everything that Troy said in his posting. You appear to be a Sun
shop, so I'll give you an idea of what I have done in the past. I have
found that it has been beneficial.
I have taken a pair of SCSI attached D1000's and populated them with 12
x 9GB ultra2 disks. The D1000's have been EOL for a long time but you
can pick them up cheaply from 2nd user brokers. If you're concerned
about maintenance, sometimes their so cheap you can buy an additional
chassis with 12 disks as a spare. I believe the D2's were the
replacement model for the D1000's, but it appears they have gone EOL
also.
For a ~30GB db area, I would format a 3GB raw partition on 11 of the
disks on the outer cyclinders and then define a TSM dbvol for each of
the 3GB partitions.
I have done the same with the second D1000 and define TSM dbcopy volumes
I would then use the 12th disk in each chassis as the log volume (TSM
mirrored). OK, you could be restricted to a 9GB log, but if that is a
problem then buy an 18GB for the 12th disk.
I would try to ensure that they are attached to SCSI controller cards
that are on different busses. This whole approach has worked well in the
past with E450's & V480's and DB sizes ranging from 30GB-50GB.
Like Troy says, I'm sure that there are plenty of organisations out
there who have just one SAN attached disk system where they have their
TSM DB on a RAID5 or RAID0 array and also have their storage pools on
another array on the same SAN disk system. The big disk vendors will
probably tell you that the latest and greatest SAN controllers with
umpteen GB of cache will outperform something as basic as 12 x Ultra
SCSI 9GB 10Krpm disks, but I am yet to be convinced (in a TSM DB
environment), or maybe I'm just plain cynical.
The other benefit to this approach is that if you encounter performance
issues, it is easier to pin things down. You're DB is on a separate
controller with separate H/W and disk dedicated to it alone.
The only downside (IMO) to this approach is that you have to ensure you
have an automated alert (SNMP) for disk failures in the cheap disk
chassis. You wouldn't want to loose a disk in one of the chassis's
without knowing and loose another in the copy in quick succession.
Leigh
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Farren Minns
Sent: 17 November 2005 11:29
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Version of 5.2 server and DB question
Hi all
I'm about to be getting a new server and can at last install TSM 5.2 on
Solaris. Is it best to go right up to the latest version of that release
(5.2.6.4 I believe)?
Also, as I can plan things a bit better on this new server I want to
size
my DB a bit more efficiently. Now, I know this is an old question with
many
posts but I couldn't seem to get a concrete answer. My DB is only 14GB
and
80% used, so I think I'll allocate 30GB to give me loads of space for
growth. So, is it best to have 3*10GB volumes, or 30*1GB etc. Basically
should I have more smaller ones, and if so how small is too small?
Thanks
Farren Minns
John Wiley & Sons Ltd
######################################################################
The information contained in this e-mail and any subsequent
correspondence is private and confidential and intended solely
for the named recipient(s). If you are not a named recipient,
you must not copy, distribute, or disseminate the information,
open any attachment, or take any action in reliance on it. If you
have received the e-mail in error, please notify the sender and delete
the e-mail.
Any views or opinions expressed in this e-mail are those of the
individual sender, unless otherwise stated. Although this e-mail has
been scanned for viruses you should rely on your own virus check, as
the sender accepts no liability for any damage arising out of any bug
or virus infection.
######################################################################
|
