Considerations to use DB2 HADR with TSM

Starting with version 6.1 TSM now uses DB2 as its backend database engine. It is a normal DB2 instance, but very tightly controlled by IBM support. After installation one cannot change any parameter in the TSM DB2 instance without permission from IBM support.

As part of normal DB2 engine TSM can use the inbuilt HADR feature of DB2. For example, the TSM electronic vaulting solution (where de-duplicated data in TSM storage pools is replicated to a remote site) can use HADR to replicate the TSM DB2 database to a standby server in that remote site to enhance availability in a disaster recovery scenario. HADR setup procedure, configurations and commands in TSM are same as those in a non-TSM environment. HADR Sync-mode parameter can affect the TSM performance and this parameter value can be set based on the distance between the primary and standby servers. Failover and takeover operations work smoothly.  So, this is all good news for TSM users to take advantage of the HADR feature.

However, I have an interesting catch in using HADR with TSM while working with one customer recently.

Database growth over time may cause TSM performance issues. Version 6.2 onwards TSM uses DB2 9.7 storage including reclaimable storage feature. Also, you have to use online table and index reorganization (housekeeping) process regularly to organize database data and free up storage to operating system so that the database performance improves.  In order to reduce the log space usage during index building such as with online index reorg, the TSM database is configured by default with the DB2 database parameter LOGINDEXBUILD set to OFF.

However, in an HADR environment it is recommended to set LOGINDEXBUILD to ON so that the index rebuild is logged and as such replayed on the standby server. If it remains OFF, then the index will not be logged and hence not be built on the standby server. This means that in the event of a failover, some large indexes will not be available on the new primary server causing severe performance delays during start-up whilst the indexes are rebuilt.

So herein lies the catch. If this parameter is set to ON to accommodate HADR recommendations, then there may be problem of transaction log space being full while reorging large indexes. In a non-TSM environment we could mitigate this by increasing the log file size and /or increasing the number of primary and secondary log files. However, the TSM environment is tightly restricted in that we were not allowed to change any transaction log configuration settings. .

So, my recommendation is to test in a non-production environment first  whether your current log space parameter values are sufficient or not with LOGINDEXBUILD enabled. If not sufficient, then you will have to raise a PMR with IBM support to discuss changing the log space related parameters so that HADR can be used with TSM.