EM12c Enterprise Monitoring, Part II

This is part II of the series on effective monitoring with EM12c.

You can read Part I of this series to ensure you have the complete setup for your Enterprise Manager 12c for effective monitoring and notifications.

Groups and Administration Groups

There are two different features that can be used to assign targets to groupings to ease management.

Groups were introduced early on and Administration Groups is new to EM12c.  Although Administration Groups is the newer feature, it is limited to one escalation type, as a target can only belong to one administration group and notification type.

Administration Groups predecessor, “Groups” is able to accept a target being allocated to multiple groups, thus supporting a multiple escalation process for notifications and alerting.  Due to this, we will be focusing on Groups and not Administration Groups, but I hope that the Administration Group feature will soon support multiple escalation paths.


To create a Group, click on Targets –> Groups


Click on Create and click on Group, (note for future reference that this is one location that Administration Groups are available for configuration.)

Choose from the list of targets what ones you want in each of your designated groups.  For this client, we’re going to create a production and a non-production group.

Once the group is named, click on “Search” and choose all the targets that fit the criteria for your group.


Previously another production group was created for ASM with all the production ASM targets assigned and so we will also add this to the new production group, designating it as it’s parent.  Keep in mind, once you add the ASM-Production group, there is no reason to also add the targets from that group.  Once added to the “Parent Group” you will see it assigned when accessing the ASM-Production group.


Breaking large environments down into “sub-groups” with parenting groups can ease management but also adds complexity when targets are automatically discovered.  If a sub-group design is chosen, it’s best to break these down by target type and target use, (development, test, staging, production or non-critical/critical, etc.)

Once completed, you can now assign your groups to Incident rule sets as you would individual targets to create more complex notification and alerting scenarios and not have to select individual targets or types.

 Next:  Part III, Monitoring Templates

Author: dbakevlar


Comments Closed

12 thoughts on “EM12c Enterprise Monitoring, Part II

  1. Hi Kevlar,

    Is the EM12c is solely for the 12c or it can be integrated with earlier Oracle DB versions too like 11gr2/1 etc.

    Is the maximum benefits of em12c can be reaped if its been with 12c DB.

    Also kindly do provide me with the links to integrate em12c with, platform WIN_64BIT, if at all is it plausible to do so.


  2. Hi,

    great blog. I hope to get to OpenWorld next year.

    I’m trying to filter out some generic alert log errors – the expression filter string works when using the alerttest.pl script in DOC ID 1567605.1, but when placed in OEM I still get emails.

    The strings I’m trying to filter:

    “RM cpu_count*” and “Detected change in CPU count to*”

    Any help appreciated. I have an SR with Oracle but no solution for a couple of weeks. I’ve also looked at editing the emd.properties file as per 1290548.1, but the emails still come.

  3. With the advancement of dynamic groups, I think it’s a management choice. If it makes sense, then use the admin groups with hierarchy, otherwise, simplify and use dynamic groups.

Comments are closed.