I believe that IBM recommends 8 or 16 database filesystems, depending on your expected sizing.
We've experimented with 1,4 and 8 containers/filesystems and I can't say that it's made much, if any difference. Much like Sasa points out, the factor that makes the most impact is the IOPS of the backing device. Your XIV system should provide more than adequate IOPS, particularly since the new CONTAINER class pools are much less IO intensive on the database and storage pool filesystems than the old FILE class devices. __________________________ Matthew McGeary Senior Technical Specialist - Infrastructure Management Services PotashCorp T: (306) 933-8921 www.potashcorp.com -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Sasa Drnjevic Sent: Friday, January 06, 2017 10:16 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM DB spaces On 2017-01-06 16:54, David Ehresman wrote: > I am running TSM 7.1.5 on AIX 7.1. My TSM DB is currently made up of > five 120GB filespaces. I need to dramatically increase the size of > the DB as we prepare for dedup. I know I can have 128 DB filespaces. > What, if any, are the performance implications of just adding more > filespaces vs staying with a smaller number of much larger filespaces? > The filespaces are SAN attached XIV with the data spread over 180 > drives. > > David Ehresman > >From experience, I believe it all comes down to IOPS. So, it all depends on how are your TSM DBspaces distributed over as many as possible drives, SAS or SATA HDDs, or SDDs, RAID type and of course the type and throughput of (Fibre Channel?) SAN. Your case with 180 drives sounds very good to me... I've never had more than four TSM DB spaces, but I always distributed them well over FC SAN, some on HDDs, and some on pure SSDs (Storwize V7000), some only on RAID6, some only on RAID10. The sizes at the moment are 400 GB, 200 GB and 800 GB TSM DBs. Hope it helps... -- Sasa Drnjevic
