Sample EM CLI Scripts - Oracle Enterprise Manager 12c Command-Line Interface - page 129

Since EM agents can only monitor targets that run from the same host (or Oracle cluster), we need to carefully
determine which targets are related to the VCS group being failed-over. Those database and listener targets are the
only targets eligible for relocation through EM CLI. We'll use a second set of VCS query results to decide which EM
targets need to be relocated.
For example, let's say you have two Oracle installations, each with their own Oracle base filesystem. Each base, or
home, contains all the files required to support its own targets, of course, and many databases and listeners may use
those homes. They are all members of one fail-over group. Let's say the groups are named QUAL and TEST.

• The QUAL group has one database named alexis_q with a listener named LSNRQ.

• TEST group has three databases, alexis_t1, alexis_t2, and alexis_t3, and a shared listener

named LSNRT.

• Alexis_q database is identified as the critical resource for the QUAL cluster group.

• All three databases in the TEST cluster group are identified as “critical resources” in the TEST

cluster group.

If VCS does not receive a response back from its heartbeat against the alexis_q, all the resources in the QUAL
cluster group will fail-over to the other node.
If any of three databases in the TEST node becomes unresponsive, everything on that node, including the healthy
databases, will be restarted by VCS on the other node.
A VCS relocation often takes only a moment or two while the healthy members of the resource group
(other databases sharing the binaries and any related listeners) are brought down, filesystems are unmounted and
then re-mounted, and finally all the resources are brought up. Manual intervention is not required.

Oracle Enterprise Manager
Databases and listeners on either host may have been ignored, dropped, or simply never discovered in Enterprise
Manager, so there's nothing to change in OEM. We'll check both the EM repository and the local agent to decide
which targets need to be relocated. 3
In this example, only databases alexis_q and alexis_t1 are configured for monitoring in OEM. The EM agent
knows about all of them, of course, but OEM monitoring and metrics collection only apply to the first two and
their respective listeners. As far as OEM is concerned, we can ignore the other two databases completely. After
the relocation is complete, the agent on the new node will discover alexis_t2 and alexis_t3 as part of its own host
discovery. The agent on the other node also performs regular searches for new targets, so it will essentially forget
about the unmonitored databases. The EM CLI command will transfer its knowledge about the history, metric
collections, and preferred credentials for alexis_q and alexis_t1. That knowledge transfer is the purpose of this
exercise, after all.

Implementation
The emcli_relocate_target_vcs.ksh script is executed without command-line input parameters by VCS after all the
other fail-over tasks are complete, including restarting the databases and listeners:

Sample Script: emcli_relocate_target_vcs.ksh

3 In spite of its title, relocate_target verb does not physically relocate any targets. Its sole purpose is to transfer monitoring and
metrics collection from one agent to another.