InfoScale™ 9.0 Cluster Server Agent for DB2 Installation and Configuration Guide - Linux
- Introducing the Cluster Server Agent for DB2
- About the Cluster Server Agent for DB2
- How Cluster Server Agent for DB2 makes DB2 highly available
- How the DB2 agent supports intelligent resource monitoring
- Supported software for VCS agent for DB2
- About agent functions for VCS Agent for DB2
- About the online agent function for VCS agent for DB2
- About the offline agent function for VCS agent for DB2
- About the monitor agent function for VCS agent for DB2
- About the clean agent function for VCS agent for DB2
- About the info agent function for VCS agent for DB2
- About the action agent function for VCS agent for DB2
- About IMF Integration functions for VCS Agent for DB2
- About running the info agent function to get database information for VCS agent for DB2
- Typical DB2 configuration in a Cluster Server
- Road map for setting up DB2 UDB in a VCS environment
- Installing and configuring DB2
- VCS requirements for installing DB2
- Installing DB2 in a VCS environment
- Setting up the DB2 configuration
- Installing and removing the Cluster Server Agent for DB2
- Configuring VCS service groups for DB2
- About configuring service groups for DB2
- About DB2 configurations in VCS
- Before configuring the service group for DB2
- Configuring the VCS Agent for DB2 from Cluster Manager (Java Console)
- Configuring the VCS Agent for DB2 by editing the main.cf file
- Setting up in-depth monitoring of a DB2 instance
- Administering VCS service groups for DB2
- Appendix A. Troubleshooting Cluster Server Agent for DB2
- Appendix B. Resource type information for Cluster Server Agent for DB2
- Appendix C. Resource type attributes for DB2
- Appendix D. Sample configurations
About the monitor agent function for VCS agent for DB2
The agent executes the su $DB2InstOwner -c "$InstHome/sqllib/bin/db2gcf -s -i $DB2InstOwner -p $nodenum" command to check the status of the database partition or node number. If the exit status of the db2gcf command is 0, the monitor returns the exit code 110. Otherwise, the monitor returns an exit code of 100 and the resource is taken offline. The agent then restarts or fails over the resource. This action depends on other type-independent attributes, such as RestartLimit or ToleranceLimit.
Note:
In case of single partition, the monitor checks the process of the respective partition using ps -p command. And in case of multiple partions, db2gcf -s command is used
Set the IndepthMonitor attribute to 1 for in-depth monitoring. The agent looks for the monitor_custom_$db2instance_$nodenum file in the /opt/VRTSagents/ha/bin/Db2udb directory. It executes this customized in-depth monitor file, if the file exists and is executable. You can find samples of custom monitor scripts in the /etc/VRTSagents/ha/conf/Db2udb/sample_db2udb directory.
If the custom monitor has any errors or problems, it checks the value of the WarnOnlyIfDBQueryFailed attribute of the Db2udb agent. If you have a db2error.dat file in the /opt/VRTSagents/ha/bin/Db2udb directory, the agent checks this file, and handles the error according to the error configuration.
If you set the WarnOnlyIfDBQueryFailed attribute to 1 (its default), and you have configured the Notifier resource, the agent performs the following actions:
Sends a notification
Returns the exit code 110
If you set the WarnOnlyIfDBQueryFailed attribute to 0, it performs error handling in the db2error.dat file. Note that the file needs to exist to perform error handling. If it does not exist, it returns the exit code 100, which is the default.
More Information