![](https://csdnimg.cn/release/download_crawler_static/88221912/bga.jpg)
v Automatically detects how DB2 is configured. At startup, HACMP verifies that the home directory for
DB2 resides on shared physical volumes, that is, that DB2 uses shared non-concurrent volume groups.
HACMP Smart Assist for DB2 issues an error if DB2 is using non-shared volume groups.
v Makes highly available the resources specific to a particular DB2 instance, such as a shared volume
group, file systems, and the aliased service IP label associated with the DB2 instance.
v Lets you easily add more DB2 instances to the HACMP configuration. This lets you create a mutual
takeover cluster configuration, or a cluster configuration with multiple nodes and resource groups with
DB2 instances where these instances are recovered on other nodes by the means of fallover.
v Automatically starts and stops the DB2 instances on the nodes by the means of an application server (a
collection of start and stop scripts in HACMP) that is created for each DB2 instance in the HACMP
cluster.
v Automatically monitors DB2 instances running on the nodes. If an application instance becomes
unavailable, HACMP tries to restart the application three times on the node. If the application does not
start after three attempts, HACMP starts the application on another HACMP cluster node. (This is the
default behavior which you can change).
v Verifies the existing configuration of the DB2 components to ensure that the DB2 and HACMP
configuration is valid.
Keeping DB2 instances highly available
HACMP increases the availability of DB2 components by eliminating single points of failure for DB2. A
single point of failure exists when a critical function relies on a single component in a configuration. If
that component fails, the application dependent on that component becomes unavailable.
To protect DB2 instances and eliminate single points of failure, HACMP Smart Assist for DB2 requires
that each database instance that you want to make highly available runs on at least two nodes.
In this guide and the HACMP Smart Assist SMIT user interface, the following terminology is used, to
define the node on which the DB2 instance may run in the cluster:
v A primary node for the DB2 instance. The primary cluster node is the node where the application runs
unless a condition forces a fallover to another cluster node. It is also a home node for the resource
group hosting the DB2 instance.
v A standby node for the DB2 instance. The standby cluster node is the node where the application runs
after a fallover from the primary node.
One of the typical configurations created by HACMP Smart Assist for DB2 - a two-node hot standby
configuration - consists of one primary node and one standby cluster node. The standby node acts as a
standby for only one DB2 instance.
You can specify location dependencies between resource groups in which your applications are
included as resources. This allows you to keep the applications together on the same node, or to keep
them always on separate nodes.
Related reference:
“Sample configurations” on page 3
There are several different cluster configurations that you can have with DB2.
Related information:
Administration guide
Increasing availability for a DB2 server
A DB2 server manages stored, related data. A DB2 server can provide back end storage for application
data.
HACMP Smart Assist for DB2 provides the following availability features for the DB2 server:
v Monitors the DB2 server
2 High Availability Cluster Multi-Processing for AIX: Smart Assist for DB2 user's guide