Oracle Enterprise Manager, aka OEM, aka Grid Control, has lots of parts and lots of screens and lots of log files and lots of features and lots of components and lots of meta-link entries and documentation. Planning, deployment and use of OEM made my head spin for months. I’ve only just now got an almost firm grip on how to organize our OEM deployment to meet the monitoring needs for our DBA team. I’m using OEM 10.2.0.4.0, and have some plans to upgrade to 10.2.0.5.0 over the next few months.

Requirements in my shop were:
1. Allow all DBAs to administer all databases, but be able in the future to limit specific DBAs to specific systems.
2. Allow for two separate on call rotations, and set things up so that On-Call Team A does not get pages at night for databases looked after by On-Call Team B.
3. Distinguish between production and non-production databases so that we can report on them separately and so that an individual DBA can get paged and emailed for a production database at 1AM, but will not get any pages at 1AM for a non-production database.
4. Be able to customize the monitoring threshold settings for individual databases.

I worked with OEM rules, administrators, roles, groups, schedules and metrics and policy settings to meet these requirements.

I created groups classified by business unit, environment and target type. For example: SALES_PROD_LISTENERS, SALES_NONPROD_LISTENERS, HR_PROD_DB, HR_NONPROD_DB, etc. Do this in the targets section.

I created rules also classified by business unit, environment and target type. SALES_PROD_LISTENER_AVAILABILITY, for example. I associated this rule with the matching group. This means that this rule will fire only against specific databases belonging to that group. Go to Preferences – Rules for this.

I created Roles for each target type and assigned all targets of that type to that role. ALL_LISTENERS, for example. If needed in the future I can change this to SALES_LISTENERS and MARKETING_LISTENERS if I need to. Go to Setup – Roles for this.

Each real life person has two accounts, one for production systems and one for non-production systems. These administrator accounts subscribe to the appropriate rules for the systems that belong to their on-call rotation. For example, the production account subscribes to the production rules, e.g. SALES_PROD_LISTENER_AVAILABILITY, but not SALES_NONPROD_LISTENER_AVAILABILITY. They need two accounts because schedules are linked to accounts. In that way, the production account gets pages and emails 24/7 for production systems, and the non-production account only gets notifications during the day for non-production systems, provided the schedules for each account are set up correctly and the accounts are subscribed to the correct rules. Manage Administrators on the Setup page. Each administrator must log in as themselves and then manage Schedules and Rule subscriptions using the links on the Preferences page. Lastly, individual DBAs can customize metric and policy settings for individual systems so that threshold settings are in line for that system. Change metric and policy settings on the target home page for the specific database. Link is at the bottom of the page.

Advertisements