Data Base Size reduction

[Hiten]

Hi,

I am having TSM database size around 1.2TB with currently registered 12 nodes out of which only 6 active nodes are operational. Now we do not have alternative option to increase the storage space hence want to reduce the database size. We have identified 2 options by which we can reduce database size

1 Delete very old backup medias which are having data.While checking media I observed more that 100 medias are having old backups.

2 Delete File space and nodes from TSM.

Which of these will be the fastest method to reduce TSM database size kindly suggest.

 

[marclant]

1 Delete very old backup medias which are having data.While checking media I observed more that 100 medias are having old backups.

Old backup date doesn't mean the object is old, it could be current still. TSM does incremental forever backups, so if you have a file that was backed up on June 23, 2002 and it still exists on that system and it has not changed since, this version is still good. Having said that, there's no harm in reviewing your retention policies with business users to make sure they meet their requirements for a restore. If you can reduce the retention, that would reduce the number of objects stored and could help reduce the DB (more info below)

2 Delete File space and nodes from TSM.

That's draconian. If they can be deleted without consequences, why were they even backed up in the first place?

Your suggestions to reduce will reduce the number of rows in the database, but it will not immediately translate to DB reduction. Before doing anything, I recommend that you read these 2 technotes very attentively to better understand how to reduce the DB:
http://www-01.ibm.com/support/docview.wss?uid=swg21655828
http://www-01.ibm.com/support/docview.wss?uid=swg21452146

 

[BDMcGrew]

It goes without saying, but I'll say it anyway... whatever you do, rung a full database backup to some form of removable device class before you do anything! The database is the heart of TSM and if it gets broken then it's game over!

 

[Lars-Owe]

Hi,

I am having TSM database size around 1.2TB with currently registered 12 nodes out of which only 6 active nodes are operational. Now we do not have alternative option to increase the storage space hence want to reduce the database size.

Are you already using DB2 9.7 tablespaces for your database? If not, consider upgrading. cf. http://www-01.ibm.com/support/docview.wss?uid=swg21655828

 

[RavindraTumu]

Fine tuning the include/exclude of File level backups /NAS datamovers (If you backup them) , Reduce the huge space. Most of the administrator's ignore this. But it saves DB space and storagepools etc.,

https://www.linkedin.com/pulse/know...ost-saving-techniques-tumu?trk=mp-author-card

Thanks,
Ravindra

 

[Newcomer]

I have some questions regarding the DB size and if our database is around the size one could expect. I have been reading pretty much all tehcnotes related to the database, and any problems that could occur related to table and index reorganization. But i'm still kinda baffled on how it's possible that indexes are allocating more space in the database than some of the tables. For example this is a snip from our database where i've selected the largest tables. This seems somewhat backwards if the index are allocating and using more space than the table?

NAME                         ROWS_IN_TABLE        TABLE_USED_MB        TABLE_ALLOC_MB       INDEX_USED_MB        INDEX_ALLOC_MB     
---------------------------- -------------------- -------------------- -------------------- -------------------- --------------------
BF_AGGREGATED_BITFILES                 4871964640               345927               345932               632390               644553
BF_BITFILE_EXTENTS                     4744165278               311960               311963               659155               663858
BACKUP_OBJECTS                          130018381                47823                48299                41790                42104

We are running two TSM 7.1.6.0 on RHEL 5.8 servers and have one storagepool with 215 TB per TSM server. And running dedup and replication between the servers. The environment is a mix of tsm4ve and regular tsm ba client, tdpsql and a few oracle clients. The dedup savings are currently at 67% (360 TB saved)

The problem i'm facing is that our database is quite huge with 2.2TB and we are running quite low on disk space. And i'm thinking if the best course of action would be to order more disk for the database or consider more physical TSM servers? We do not have any problems with reorg not running, with exception on the 4 largest tables which we are running offline reorg quite frequently lately. I've also read and followed the technote on cleaning up the optfile from old db tuning entries. http://www-01.ibm.com/support/docview.wss?uid=swg21967852

But more to the question: Is the database size we are seeing something that one could expect with that level of dedup and replication?
According to this article one could expect a DB size between 2-10 TB based on the storagepool capacity.

https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.6/srv.install/t_srv_inst_db_space-linux.html

 

[marclant]

The problem i'm facing is that our database is quite huge with 2.2TB

According to this article one could expect a DB size between 2-10 TB based on the storagepool capacity.

So, it sounds like your database is normal for your environment and on the low end of the spectrum.