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:[EMAIL PROTECTED] On Behalf Of Farren Minns Sent: 17 November 2005 11:29 To: ADSM-L@VM.MARIST.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. ######################################################################