50 DB2 Nuggets #49: Expert Advice - How does DB2 interact with TSAMP

Body

In a DB2 HA environment using TSAMP,  here is what goes on in the background when certain DB2 commands are run.

db2start/db2stop:
Running db2stop will lock the Instance resource group where the stop is issued against. Consequently the HADR Database will fall out of peer state and the DB2 engine will request that the HADR resource group gets locked, preventing the resources from being restarted automatically by TSA.

Running db2start will unlock the instance resrouce group, once the DB automatically reintegrates, the lock will be removed from the HADR database resource group.

Takeover HADR:
When a takeover command is issued on a database in a HA environment, then a corresponding move request is sent to TSA to make it aware of the database role switch.

Start/Stop HADR:
The monitor script for the HADR resource will detect the HADR state change which may lead to some automation action, but it is not recommended to run this command against the HADR database while it is highly available. If the database needs to be taken offline for some maintenance task, then I would suggest to remove it from the HA resource model via the db2haicu command and add it back to the HA resource model after the maintenance operation is completed. (db2haicu -disable on both nodes)

In a DB2 TSA -HA Shared Disk Environment, the following commands:

result in the similar behavior:

In a HA Shared Disk configuration, DB2 internally keeps track of storage paths that are being used. If a storage path is in use and it is on a mount path that is eligible to be made Highly Available then a DB2 mount resource will be created for it. Once a storage path is no longer in use (e.g. dropping the only database that makes use of the storage path) then the associated mount resource will also be deleted. We keep track of these storage paths using 'useCounts' in the HA registry file and its contents can be displayed via the "db2hareg -dump" command.

Bada Bing Bada Boom!