TSM database across multiple volumes with very small free space on some of them

[rdemaat]

Apologies right up front for this long explanation / question. We have had to extend our database over the years to where it is spread over 5 volumes / drive letters. Way back (a few years) before DB2 and dedupe the database was around 50 GB's. Its now 621 GB's. The G drive, the orginal drive, is 204 GB's with 70 MB free. Yes meg. Drive T is 204 GB with 99 GB. Drive V is 93 GB with 5 GB free. Drive W is 255 GB with 150 GB free. Drive Y is 502 GB with 396 GB free. Last month some type of logging used what little free space the G drive had, crashed TSM and required a database restore. After the restore a coworker dropped a table space in the database that apparently was related to space usage on the G drive so I think/hope the 70 MB free space on G is safe. We watch it daily and its seems pretty stable. But now we just noticed the 5 GB on the V drive dropping to 20 MB. And of course we immediately become concerned about a crash / restore again. Same coworker did something DB2 related to get it back up to 5 GB. But why all of a sudden after a couple years are these low free space volumes becoming an issue. We are not doing an extend db. And if we did we would pick probably the Y drive where there is 396 GB free. Or a new drive letter. But the DB isnt full. It has over 600 GB free to grow in to. Yes the total db size is 1.2 TB's.

Sooooo, is there a best practice that we have not followed at least on the G and V drives where you should leave X amount of free space for who knows what?

Thanks for any advice you can give. We are going to TSM 7 soon and getting a new windows server for it. Not sure if a fresh database will be in order but if it is how should the database volumes be laid out for existing needs and future extends.

q db f=d

Database Name : TSMDB1
Total Size of File System (MB) : 1,289,663
Space Used by Database(MB) : 622,724
Free Space Available (MB) : 666,518
Total Pages : 58,808,940
Usable Pages : 58,807,644
Used Pages : 58,661,640
Free Pages : 146,004
Buffer Pool Hit Ratio : 99.3
Total Buffer Requests : 84,626,857,984
Sort Overflows : 0
Package Cache Hit Ratio : 99.9
Last Database Reorganization : 1/13/14 11:03:54 AM GMT-05:00
Full Device Class Name : LTO4
Incrementals Since Last Full : 0
Last Complete Backup Date/Time : 1/16/14 7:56:20 AM GMT-05:00

q dbspace f=d
Location : G:\tsm\db001
Total Space(MB) : 209,135.203
Used Space(MB) : 209,065.797
Free Space(MB) : 5.42

Location : G:\tsm\db002
Total Space(MB) : 209,135.203
Used Space(MB) : 209,065.797
Free Space(MB) : 5.42

Location : G:\tsm\db003
Total Space(MB) : 209,135.203
Used Space(MB) : 209,065.797
Free Space(MB) : 5.42

Location : G:\tsm\db004
Total Space(MB) : 209,135.203
Used Space(MB) : 209,065.797
Free Space(MB) : 5.42

Location : t:\tsm
Total Space(MB) : 209,135.203
Used Space(MB) : 107,496.656
Free Space(MB) : 101,638.539

Location : v:\tsm
Total Space(MB) : 95,848.711
Used Space(MB) : 91,527.008
Free Space(MB) : 4,321.7

Location : w:\tsm
Total Space(MB) : 261,417.047
Used Space(MB) : 107,498.133
Free Space(MB) : 153,918.922

Location : y:\tsm
Total Space(MB) : 514,127.031
Used Space(MB) : 107,509.758
Free Space(MB) : 406,617.281

 

[SniperKing]

Hi,

This is normal especially when you have added the db space over time and with different size of dbspace volumes. If you want those free space to be spread across evenly, you may need to realign the disks to the same size and backup then restore the db across the realigned disks.

 

[marclant]

At 7.1, the database will rebalance itself automatically. More info here:
http://pic.dhe.ibm.com/infocenter/tsminfo/v7r1/topic/com.ibm.itsm.perf.doc/c_srv_optimdb_dirs.html

It also talks about the importance to size all the volumes the same size, as SniperKing also mentioned.

In the meantime, at 6.3, you can rebalance it this way:
http://pic.dhe.ibm.com/infocenter/tsminfo/v6r4/topic/com.ibm.itsm.perf.doc/t_srv_rebal.html

But the same caveat as other versions, the volume size should be the same.

 

[rdemaat]

Ok. Thanks to both for your input. Working with TSM level 2 now. They are having us do traces, rebalance, and reduce commands. Not sure this will fix the problem though. Whats disconcerting is the fact that we seem to be in danger of crashing TSM because of the small amount of free space on the G and V drives. If DB2 is doing this balancing act behind the scenes why would it use all available space on one of those drives and then crash because it wants more on that drive? At least thats what seems to have happened on the G drive last month. Leave G and V alone!!! Pick a different volume!!!