Database Reference
In-Depth Information
Figure 7-9.
Administration group hierarchy with three levels based on Lifecycle, Location, and Line of Business
properties
There can be only one administration group hierarchy. This limit of one prevents conflicts that would arise from
multiple hierarchies. Furthermore, a target can belong to only a single group in the hierarchy.
A target cannot be added directly to a group. Instead, group membership is determined by the target's properties
(for example, LifeCycle Status). These properties can be set at target discovery and promotion time, or at a later time
if the targets have already been discovered. Target properties can be set by using the Enterprise Manager console or
the
emcli
command-line interface with the
set_target_property_value
verb. For more information about the
emcli
commands, see Chapter 2 of the
Oracle Enterprise Manager Command Line Interface
documentation.
■
think of planning your hierarchy in terms of two steps: 1) define your hierarchy. 2) assign properties to your
targets. the “magic” happens then, as your targets are automatically slotted into your hierarchy at the appropriate levels.
Tip
After targets join the administration groups, you can associate template collections so that each group's members
have similar metrics, policies, and standards. Template collections are a set of template metrics composed of several
target types. They are discussed later in the chapter.
Separate template collections should be created for each administration group. Before creating administration
groups, you should first create monitoring templates. Each monitoring template is specific to a single target type.
Therefore, you will need to create a template collection consisting of several monitoring templates: one for each
target type. For example, a Production Targets administration group consisting of hosts, listeners, database, and ASM
instances will require a template collection consisting of four distinct monitoring templates.
If the administration group hierarchy consists of more than two levels, the order in which template collections
are applied is important. Template collections at the leaf levels override metrics from the parent levels. Each group
will have its own template collection, and those from the parent levels are propagated to their respective subgroups.
After template collections have been applied, you should associate the collections with the groups. This
ensures that each group contains a standard set of metrics, standards, and policies. Once that is done, the targets are
synchronized so that any future changes to monitoring templates are automatically applied to the associated targets.
