How to customise TSAMP start and stop scripts to make monitoring agents cluster aware

I’ve integrated Tivoli Storage Automation (TSA) and DB2 . The solution is based around a two node TSAMP solution which is “automation software”, running as part of a clustered Reliable Scalable Cluster Technology (RSCT) environment. (RSCT is the “cluster software”) Read More on Tivoli Storage Automation for Multiplatforms(SA MP) and the shared disk approach TSAMP uses a set of automation scripts to manage DB2 that is, start, stop and monitor them. TSAMP responds to an unexpected change in state for individual resources (eg DB2 instance failure), a server failure/crash, a network/NIC related outage To confirm the TSA integration with DB2... Read more →

TSAMP maintenance and diagnostics

You’ve set your TSAMP environment on Linux and DB2. Tested a few failover scenarios and everything is looking positive. One of the key things about TSAMP and DB2 is maintaining the environment. Finding any small problems before they become big problems. For example, monitoring message logs and backing up copies of configuration and state files can save you lots of work when troubleshooting. These are some guidelines to follow, which will give you a firm basis. There are different ways of using the information, but I like to create reports , which are reviewed and apply any fixes 1. Before... Read more →

How to backup the TSA SAMP policy details

Question : I have a TSAMP installation and require to make a SAMP change. Prior to making the change I’d like to backup the existing SAMP policy and have the file available in case of a mistake or a High Availability Incident . How can I backup the SAMP policy ? Answer: It is good practise to save the SAMP policy document. Place it in a location different from the active server. I’ve followed this practise and it’s useful in an HA outage. I use it to doublecheck the live version with the backup version and see if there are... Read more →

DB2 fix : ADM4500W A package cache overflow condition has occurred.

Question: During some troubleshooting , I noticed these messages in the db2diag.log file and instance.nfy files. “There is no error but this indicates that the package cache has exceeded the configured maximum size. If this condition persists, you should perform additional monitoring to determine if you need to change the PCKCACHESZ DB configuration parameter. You could also set it to AUTOMATIC.” I checked the database configurations via : db2 get db cfg | grep ‘PCKCACHESZ’ Package cache size (4KB) (PCKCACHESZ) = (MAXAPPLS*8) How can I get rid of these messages? Do they point to deeper problem? Answer: First thing to... Read more →