Harvesting Tags for Temporary Tablespace (TEMP16K) in IBM PureData Operational Analytics v1.0 (PDOA) and IBM Smart Analytics (ISAS) 7700/5600

Answer

Note: The objective of this document is to clarify any confusion around the the issue of "SSD, TEMP16K temporary tablespace and Tag Harvesting"

Let us start by saying "Any time the temporary tablespace TEMP16 is re-created, YOU SHOULD RE-HARVEST".

Explanation:

- What the process described as "re-harvesting" does is, copy the first 512 blocks of the SSD containers file of each database partition into tag directory
- the information copied, correspond to what we could call "the container metadata or key information".

What this data is used for?

- When a node fails, the HA process (failover/failback), copy the tags (the files), of the corresponding partitions (the ones which failed over/back) to the first 512 blocks of the SSD container's files on the standby/primary,
- this makes the containers files on the standby/primary be consistent with the temporary tablespace and the same as the ones on the node that failed or moving from.

When you re-create the TEMP16K tablespace:

- The tags files under tag directory becomes obsolete, as the header of all the containers were overwritten with the CREATE TEMP TABLESPACE

SSD Failures:

- An SSD failure and replacement is NOT a TEMP16K failure or re-creation, it should NOT be
- the drive failed and very likely the file system for that SSD was re-created
- after replacing the bad SSD and re-creating the file system, all you need to do is to copy the container directory and file structures from a good SSD file system,
- the tags in the tag's directory are all (still) valid, the temp tablespace have not changed in anyway,
- if you followed the document http://www-01.ibm.com/support/docview.wss?uid=swg21506935 to replace the SSD, you should be ready to "failback" the failed node (ISAS). For PDOA v1.0 the node that had failed is now the new standby of his HA group.

Observations Regarding "Re-Harvesting the Tags".

- You need to guarantee that no user is connected to the database
- is possible that a client application that constantly pings the database for connection, get connected to the database in the midst of the "re-harvest", this
- will cause a partially "harvesting", it would fail for one or more database partitions,
- if this get overlook, the system goes into production assuming all tags were generated, and
- eventually a node that host one of the partition for which the harvesting failed to create a tag for, then the failover of this node overall will fails, meaning
- the failover, seems to work but once you attempt to activate or connect to the database, DB2 fails with container's error in db2diag.log,
- that is due to bad tag

Note: Before initiating the "harvesting", you should do your best to guarantee that there are no connections to the database during this processes. See http://www-01.ibm.com/support/docview.wss?uid=swg21685347

Tags files:

- One file per database partition
- located/copied under directory <INSTANCE_HOME>/ha_setup/tags
- for example, if you have an ISAS 7700 cluster with one Admin (one partition) and two data nodes. That is a total of 16 files (8 per data node) plus 1 file of the Admin/Catalog partition





- at the beginning of the "harvesting", all the current tag files will be deleted and new ones are generated
- at the end you can go to this directory and verify that all files were generated (ie. the image above, see the files dates)


Note: The image above correspond to an ISAS 7700, with one Admin and 2 data nodes. For a PDOA v1.0 with similar configuration would a 2.5 data nodes. That would be a total of 21 tag files. ( T = 8x + 1 ).