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 AT VM.MARIST DOT EDU] On Behalf Of 
Sasa Drnjevic
Sent: Friday, January 06, 2017 10:16 AM
To: ADSM-L AT VM.MARIST DOT 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