Hello, I just want to thank you all for the input. It has been really valuable in my discussion with the money people at my work place. Right now we're running TSM on a Bull Esala PL220(power3, 2CPU 2GB memory) and use some left-over Sun jbods disk rack for the database. Expiration takes about 8-12 hours. We will probably buy a new Power5-server and move the database to a proper disk array(HDS9570 maybe) and spread it over as many RAID-1 volumes as possible. And using the disk arrays striping together with Physical Partition Striping in AIX. We will then follow the expiration time closely and make a server split in good time before we get into real trouble. Bet regards Hans Chr. Riksheim
________________________________ Fra: ADSM: Dist Stor Manager på vegne av Richard Rhodes Sendt: ti 06.09.2005 15:45 Til: ADSM-L@VM.MARIST.EDU Emne: Re: Trouble when TSM-database reaches 100Gb? > I would be interested in hearing what others have to say >on this matter. When we moved from 10k rpm SSA drives (non-RAID, >with cache on the SSA adapter) to 15k rpm FAStT RAID5 arrays, we saw >a world of improvement on our server. It made a huge improvement. I >attribute this to a combination of faster drives (15k rpm) and >spreading the I/O across spindles using RAID5. We firmly believe in stripping the TSM database (and any other mostly random access database) across as many spindles as possible. Like any database, you have to tune the disk layout. A spindle is capable of a limited number of iops. To get more random throughput you need more spindles, and, you need to make sure that all the spindles are working for you all the time. If you have a spindles that is not constantly being used it is a wasted resource. I'll describe one of our TSM databases (~140gb). It is on a Clariion array. I created 6 luns - one each on the 6 raid5 raidsets defined in the Clariion. At the AIX level I pull these 6 luns into a volume group and create stripped logical volumes across the luns using a 32k strip size. The database and log volumes setup the exact say way. The database uses 13 raw stripped logical volumes and the log uses 3 stripped raw logical volumes. Yes . . . .It's a PLAID!!!! When I changed the TSM database from what amounted to a very minimally stripped setup to the plaid our backup times fell from 4-5hr to 1hr. Expiration dropped form several days to 12hr. We use this same setup for almost all our Oracle databases - we create plaids. When we setup our big sap databases (8tb, 8tb, 4tb, 2tb), we told EMC that we were going to create plaids. They told us quite firmly that this was a mistake and not to do it. We did it anyway. We use Veritas Volume Manager (hpux systems) to be able to maintain the plaid across newly added storage space by re-stripping existing filesystems on the fly across the new storage. It's been 3 years now, and EMC seems amazed that the bottleneck on our symms are the busses, not the drives. We seldom have performance issues related to not enough iops. They now not only support what we've done, they recommend it to others. At a recent EMC conference they made a big point in one sessions that the number one reason for performance problems in any disk subsystem is hot drives. You have to tune your disk subsystem to prevent this, whether the disk system is a symm, dmx, clariion, ess/shark, fastt, ds8k/ds6k, ssa or jbod. A disk that is not pulling it;'s share if the i/o load is being wasted. Rick ----------------------------------------- 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.
