Symantec logo

< Previous  | TOC | Index | Next  >  

Monitor operation

The commands used by the agent to monitor the DB2 instances vary depending on the DB2 version and hardware configuration.

Handling DB2 error codes during in-depth monitoring

The agent for DB2 comes with enhanced handling of DB2 errors during in-depth monitoring. The agent classifies DB2 errors according to their severity and associates predefined actions with each error code.

The agent includes a reference file called db2error.dat, which you can customize. The file lists the DB2 errors and the associated actions that you want the agent to take when it encounters an error.

The file stores information in the following format:

SQL_error_string:action_to_be_taken

For example:

SQL1034N: IGNORE

SQL1039N: WARN

SQL1234N: FAILOVER

The agent supports the following actions:

 

Action

Description

IGNORE 

Ignores the error. 

UNKNOWN 

Marks the resource state as unknown and sends a notification if the Notifier resource is configured. See the Veritas Cluster Server User's Guide for more information about VCS notification. 

This action is typically associated with configuration errors. 

WARN 

Marks the resource state as online and sends a notification if the Notifier resource is configured.  

This action is typically associated with low-severity errors.  

FAILOVER 

(Default) 

Marks the resource state as offline. This faults the service group, which fails over to the next available system. 

This is the agent's default behavior. If the DB2 error code encountered does not exist in the db2error.dat file, then the agent assumes this default behavior. 

NOFAILOVER 

Freezes the service group temporarily and marks the resource state as offline. The agent also sends a notification if the Notifier resource is configured.  

This action is typically associated with errors that are not system-specific. For example, if a database was corrupted, failing it over to another node does not help.  

ESE configurations, version 8.0 or later

For all DB2 ESE configurations, version 8.0 or later, for a single or multi-partition instance in SMP or MPP configuration, the agent executes the
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 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, depending on other type-independent attributes, such as RestartLimit or ToleranceLimit. The command db2gcf is only available starting from ESE version 8.

Set the IndepthMonitor attribute to 1 for in-depth monitoring. Before this release, IndepthMonitor performed a default SQL query to the database. In 5.0, this default query no longer exists.

The agent now looks for the custom_monitor_$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 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. For error handling information:

See Handling DB2 error codes during in-depth monitoring.

If you set the WarnOnlyIfDBQueryFailed attribute to 1 (its default), and you have configured the Notifier resource, the agent sends a notification, and returns exit code 110.

If you set the WarnOnlyIfDBQueryFailed attribute to 0, it performs error handling in the db2error.dat file.


 ^ Return to Top

< Previous  | TOC | Index | Next  >