OEM / GRID Basics

Concepts
OEM Grid Components
Hardware Requirements
Installing Oracle Enterprise Grid Manager
Extending OEM

Concepts
Enterprise Manager uses a web-based architecture which is robust, reliable, globally scalable, and easy to deploy and operate within today’s internet-enabled environments. Oracle Enterprise Manager Grid Control provides the administrator with complete access to management information. Its HTML-based console interface allows an administrator to manage from anywhere – all that is needed is a Web browser.
The console interacts with the Oracle Management Service, which is a J2EE Web Application. The Oracle Management Service works with an Oracle database repository (called Management Repository) for its persistent data store. The Management Repository contains centralized management information about all administrators, targets, and applications that are managed within Enterprise Manager.
Oracle Management Agents compose the last component of the framework. An Oracle Management Agent is a lightweight process that is deployed on each monitored host. Oracle Management Agents are responsible for monitoring all services on the host, for communicating monitoring information to the Oracle Management Service(s) and for execution of remote operations on the managed services.


Internet-enabled Management
Communication between each tier is via HTTP, which seamlessly allows any part of the framework to work with and through firewalls that allow HTTP communications to pass through them.

Self-monitoring Architecture
Enterprise Manager contains self-monitoring capabilities that ensure its own critical components are available and functional. Each Management Service and Agent has its own watchdog that monitors the corresponding process. Should the Management Service or Agent be abnormally terminated, the appropriate watchdog would restart the process automatically without user intervention. In addition, key performance and availability metrics are automatically monitored for each critical component of the Enterprise Manager framework. System administrators would receive notifications should any of these components experience availability and/or performance degradation. Using Enterprise Manager’s Application Service Level Management (ASLM) features, Grid Control itself can be monitored like any web-based application to ensure administrators receive optimum performance as they use it to manage their enterprise.

Consolidated Management with Target Home pages
Each managed target has a ‘home page’ that provides a consolidated, at-a-glance view of its health and performance status. Only the most important metrics being measured for the target are displayed on this home page – while further details are available via drilldowns.

Applications Modeling
Because today’s administrators must maintain an ever-growing number of systems and services, they need an efficient and effective way to logically organize their managed systems. By using Groups within Enterprise Manager, administrators are able to consolidate and easily monitor their distributed targets. From a Group’s Home page – whether the Group is based on a homogenous set of targets or modeled after a business’s application – administrators are able to monitor their services easily and reliably; seeing at a glance the Group’s availability and outstanding alerts. Additionally, administrators can define a summary metric for a Group in order to obtain overall performance information for the Group. Hence, when problems occur, administrators can quickly isolate the problems’ root cause with minimal time and effort through intuitive drilldowns.
Managing

Task Automation using the Job System
The ability to automate maintenance tasks is a critical aspect of efficiently managing sets of systems. The Enterprise Manager job system allows administrators to automate the running of ad hoc or periodic tasks against individual systems or groups of systems. Administrators can use any of the predefined database job tasks (e.g. backup, export, import) or define their own logic using custom OS or SQL scripts. Jobs can be submitted to individual targets or groups of targets. Jobs submitted to a group automatically adapt to any changes in group membership. For example, if a weekly backup job is defined against the group MAIL-DATABASES, then if a new database is added to this group, it will automatically be part of the weekly backup job.
When a job is submitted to set of targets, the status of all job executions across all targets is automatically rolled up. From these rollups, administrators can easily determine the job executions that have failed and the job executions that have succeeded. Quick links are provided to allow drilldown into details of the failed (or successful) executions. Similarly, job information for individual targets is automatically rolled up in each target home page (including the Group home page) so administrators can easily determine all job activity that is occurring on targets they are managing.
Jobs that are used frequently can be stored in the Job Library for later re-use. Similar to active jobs, jobs in the library can be selectively shared with other administrators by granting the appropriate privilege to them.

Application Service Level Management
Today’s e-businesses depend heavily upon their Web applications to allow critical business processes to be performed online. As more emphasis is placed on accessing information quickly, remotely, and accurately, how can you ensure your online customers can successfully complete a transaction? Are you certain that your sales force is able to access the information they need to be effective in the field?
Enterprise Manager Application Service Level Management (ASLM) tools present a major shift in system diagnostics and monitoring. Armed with knowledge of end-user response time, administrators are able to proactively monitor and manage their e-business systems from a holistic perspective, anticipating and avoiding performance problems before they occur.
ASLM can be configured out of the box to gather and report status and response times for all servers in the enterprise environment, including non-Oracle servers. Complete integration with the underlying framework of Enterprise Manager provides a consistent and integrated view of the entire enterprise system.

Monitor and Trace Business Transactions
Enterprise Manager proactively monitors critical business transactions to ensure Web applications are performing at all times. Administrators can quickly and intuitively record transactions by launching the transaction recorder and walking through the transaction in a Web browser. Data-driven clicks such as logons and online purchases can be played back and monitored without any additional coding. The recorded transaction is stored in the Enterprise Manager repository and can be deployed from any monitored host, anywhere in your system. Deploying and playing these recorded transactions from different locations enables administrators to measure transaction performance from various user communities in your network. Administrators can proactively detect performance problems in the transaction and immediately know whether it is internal or external to their data center. A monitored transaction is further broken out by the time spent in each phase of its navigation path.
Response thresholds can be defined and assigned to trigger an alert if they are exceeded. Proactively monitoring transactions enables administrators to tune their application by pre-empting problems and making corrections before performance degradation adversely affects users.
When performance problems are identified, Enterprise Manager’s transaction tracing functionality provides a hop-by-hop blueprint of the traversal path and responsiveness of online transactions. The tracing functionality provides an on-demand tool that lets administrators examine in detail all invocation paths of a transaction, and isolate the exact tier and location of a problem. All invocation paths of a transaction are traced and hierarchically broken down by servlet/JSP,EJB, JDBC/SQL times. Further drill-downs into each component identify response time breakouts by invocation path. Click-to-SQL drill-downs allow administrators to navigate down from a transaction view and examine the underlying SQL statements. If for example, performance degradation is identified at the SQL statement level, administrators can easily navigate to Enterprise Manager’s comprehensive database management tools to quickly resolve the problem all within a single management solution. In addition, administrators can run the trace facility following the resolution of a problem to reassure them that the situation has been satisfactorily remedied.

Systems Monitoring
The Agent on each monitored host monitors the status, health and performance of all targets on that host. If the target goes down, or if a performance metric crosses a warning or critical threshold, an alert is generated and sent to the Enterprise Manager console and to administrators who have registered interest in receiving such notifications.

Out-of-the-box Monitoring
Out-of-the-box monitoring simplifies a critical but potentially time-consuming administrator task of setting up monitoring for managed targets. As targets are added to Enterprise Manager, the target is automatically monitored at Oracle recommended settings. This means the target will be monitored using an Oracle recommended set of metrics and thresholds. Novice administrators can simply rely on these Oracle-recommendations, and more experienced administrators continue to have the flexibility of later fine-tuning these thresholds to suit their particular environments. All monitored metrics are also stored and aggregated in the repository to allow administrators to perform trend analysis later on.

System Availability Monitoring
Maximizing availability is one of the most important goals in managing any target. Enterprise Manager proactively monitors the availability of every target it manages, and allows administrators to be notified if the target goes down, if the target is ‘blacked out’ for scheduled maintenance, or even if its current status cannot be determined due to network outages.

Intelligent Thresholding through Metric Baselines
Administrators often want thresholds for performance metrics to be based on deviations from real target performance instead of absolute numbers. For example, if for a given day, performance for a database was acceptable, and that database was running under normal workload, then administrators might want to define thresholds such that they are notified only when database performance becomes 10% worse than that given day. Such thresholds can be defined using Metric Baselines.
A Metric Baseline is a snapshot of a target’s performance at a given point in time. When used for thresholds, administrators should define a metric baseline that will be used as the performance norm – preferably a day in the past when performance was ‘good’ for the target and it was running under normal to high workload. A metric baseline thus consists of a target’s performance metrics for a ‘good’ day.
In the Enterprise Manager console, an administrator defines a metric baseline by first specifying a date in the past that will be used as the performance ‘norm’. Next he specifies percentage values from the metric baseline that represent the points at which performance becomes a problem at a warning, then more critical level. These percentages are then calculated into specific warning and critical threshold values for the performance metrics.
As an example, if the database supporting the financial system had good performance on July 1, 2002, an administrator could use July 1, 2002 to set up the metric baseline for the financial database. Next he specifies 10% and 20% as warning and critical percentages respectively. Enterprise Manager then calculates values that are 10% and 20% ‘worse’ than the baseline data, and provides these calculated values as the warning and critical thresholds for the databases’ performance metrics. The administrator can review or edit the calculated values, then apply them as thresholds for the target. When any performance metric crosses its threshold, an alert is generated.
Metric Baselines thus provides a two-fold benefit – administrators can now simply define thresholds based on high level performance goals and thresholds can be more fine-tuned to reflect actual performance numbers.


Notifications
When a target becomes unavailable or if thresholds for performance are crossed, alerts are generated in the console and notifications are sent to the appropriate administrators. Enterprise Manager supports notifications via email (including email-to-page systems), SNMP traps, and/or by running custom scripts.
Enterprise Manager supports these various notification mechanisms via Notification Methods. A Notification Method is used to specify the particulars associated with a particular notification mechanism, e.g. which SMTP gateway(s) to use for email, which OS script to run to log trouble-tickets, etc. Super available for use. Once defined, other administrators can create Notification Rules that specify ‘when’ and ‘how’ notifications should be sent. The ‘when’ involves specifying the targets, its metrics and severities for which notifications should be sent. The ‘how’ involves specifying which Notification Method(s) to use. For example, you can set up a rule that sends email when CPU Utilization is at a critical 90%, or another rule that creates a trouble-ticket when a database is unavailable.
Notifications are not limited to alerting administrators. Notification Methods can be defined to run any custom OS script or PLSQL procedure, and thus can be used to automate any type of response to an alert. For example, administrators can define methods that call into a trouble ticketing system, invoke third party API’s to share alert information with other monitoring systems, or even log a bug against a product.

Customizing Notifications
Notifications that are sent to Administrators can be customized based on message type and work schedule.
Message customization is useful for administrators who rely on both email and page systems as a means for receiving notifications. The message formats for these systems typically vary – messages sent to email can be lengthy and can contain URLs and messages sent to a pager are brief and limited to a finite number of characters. To support these types of mechanisms, Enterprise Manager allows administrators to associate a long or short message format with each email address. Email addresses that are used to send ‘regular’ emails can be associated with the ‘long’ format; email addresses that are used to send pages can be associated with the ‘short’ format. The ‘long’ format contains full details about the alert; the ‘short’ format contains the most critical pieces of information.
Notifications can also be customized based on an Administrator’s work schedule. As a simple example, an administrator can have a 2-week rotation schedule where he is accessible via his work email address from 9-6 during the week, and accessible via his email-to-page address on the weekends. In reality, administrators’ schedules can be more complicated and can vary from one week to the next. To support various types of schedules, Enterprise Manager allows administrators to define a repeating schedule whose definition can span from 1 to 8 weeks. A notification schedule is essentially a template for specifying conditions like “for my 3 week rotation, contact me via my work address during the first two weeks, contact me via my pager on the third week”. For each hour of the day in the schedule, administrators specify whether or not they should be notified and if so, how they should be notified (i.e. which email address to use for notifications). All alerts that are sent to an administrator automatically adhere to his specified schedule.

Real time Monitoring and Historical Data Analysis
Each target home page in Enterprise Manager provides access to both real-time as well as historical status and performance data for that target. Real time data displays current values of key performance metrics and shows how they compare against acceptable thresholds. Administrators who prefer to keep a constant eye on performance can choose to enable auto-refreshing of performance data at user-specified intervals.

Advice-driven responses to alerts
When an alert is generated to notify administrators of availability or performance problems, administrators can check the Enterprise Manager console for more information about the metric that triggered the alert. This includes information on the metric’s historical values that might show trends over the past week or month, and online help that provides advice on what the administrator can do to fix or further diagnose the problem. For example, if an alert is sent reporting ‘3 segments in the USERS tablespace are unable to extend’, then an administrator can consult the online help which would suggest that he look into increasing the value of the segment’s MAXEXTENTS storage parameter, or rebuild the segment with a larger extent size.

Automated responses to alerts
If a response to an alert can be automated, Enterprise Manager allows administrators to set this up by specifying Response Actions for the appropriate metric. Automated responses come in the form of scripts that are automatically run by the Agent when a monitored metric crosses its threshold. For example, if a disk becomes 80% full, an automated response might be to run a script that clears out space in the temp directory. Each monitored (performance and availability) metric can be assigned its own automated response action. Administrators need only specify the script once, and let Enterprise Manager respond to it automatically at the appropriate time.

User-Defined Metrics
User-Defined Metrics allow administrators to extend the reach of Enterprise Manager’s monitoring to conditions specific to their particular environments. Specifically, if an administrator wants to monitor a particular condition (e.g. check successful completion of monthly system maintenance routines), he can write a custom script that will monitor that condition, then create a user-defined metric that will use his custom script. Each time the metric is evaluated by Enterprise Manager, it will use the script specified by the administrator, relying on that script to return the value of the condition. Once a user-defined metric is defined, all other monitoring features – threshold-based alerting, proactive notifications, historical collections, seamless integration with the console, etc – are automatically available to it. Administrators that already have their own library of custom monitoring scripts can leverage these monitoring features by integrating their scripts as user-defined metrics in Enterprise Manager. Thus, monitoring can be consolidated and simplified by relying on Enterprise Manager as the single monitoring solution for their enterprise.



Blackouts
Blackouts allow the suspension of target monitoring to allow administrators to schedule in maintenance periods for these targets. Blacking out a target prevents unnecessary alerts from being sent when the target is purposely brought down for maintenance. Administrators who strive to meet SLA goals can use blackouts to ensure that scheduled down periods are not calculated as true down time when computing overall target availability.
A blackout can be defined for individual target(s), a group of multiple targets that reside on different hosts, or for all targets on a host. The blackout can be scheduled to run immediately or in the future, and to run indefinitely or stop after a specific duration. Blackouts can be created on an as-needed basis, or scheduled to run at regular intervals. If, during the maintenance period, the administrator discovers that he needs more (or less) time to complete his maintenance tasks, he can easily extend (or stop) the blackout that is currently in effect.
Blackout functionality is available from both the console UI as well as via the Agent’s command-line interface (CLI). The CLI is often useful for administrators who would like to incorporate the blacking out of a target within their maintenance scripts.


Comprehensive Database Management
Enterprise Manager is the premier database management tool for Oracle databases. Database management with Enterprise Manager offers

• The most integrated and complete feature set for managing Oracle databases
• Unparalleled scalability for managing 1,000s of instances
• Industry-leading ease of deployment and use

Database Homepage as the Management Hub
Enterprise Manager’s new Database home page gives the user a comprehensive summary of all relevant instance information on a single screen:

• Current instance availability
• Outstanding alerts
• Session and SQL-related performance information
• Key space usage metrics
• Instance name, database version, Oracle Home location and other pertinent instance data

Additional details are intuitively accessible via drill-downs from the Database home page.




Integrated Performance Management
Database performance management in real-time assumes a central role in Enterprise Manager. The Database Performance page is only a mouse-click away from the home page. Here, the user can quickly see real-time and historical performance graphs for both the database and the underlying host.
The Performance page has three main areas:
Host – Displays the run queue length and paging rate of the host system that the database is running on.
Active Sessions: Waiting and Working – Shows the sessions that are waiting, e.g. for I/O, or for the network, or due to concurrency issues, and the sessions that are using the CPU.
Instance Throughput – Shows transactions and logons per second, and redo size and physical reads per second.

Complete Database Management Solution
Due to space constraints, the wide-ranging database management capabilities of Enterprise Manager cannot be exhaustively discussed in this document. Enterprise Manager offers powerful features for managing

• Init.ora parameters
• Schema objects such as tables, indexes and views;
• Storage entities such as tablespaces, datafiles, control files, rollback segments, redo log groups and archive logs;
• Users, roles and profiles;
• Resource consumer groups and resource plans;
• Source types such as packages, procedures, functions and Java classes.

Saved Host Configurations
Administrators often need to build new systems that are similarly configured to an existing system. One way to do this is to take a "snapshot" of an existing system, which can then be used as a blueprint for creation of new systems. Enterprise Manager fully supports this process of capturing, storing and analyzing system configuration information.

Patching
Enterprise Manager provides administrators with tools to quickly query for patches available for Oracle products installed across their enterprise. Patches can be found either in the context of a specific target or, if desired, the administrator can query for a specific patch. Once the necessary patch is located, Enterprise Manager can download it from Oracle MetaLink and stage it to the appropriate target hosts. Optionally, Enterprise Manager can execute an end-user provided script to install the patch. Each of these steps allows for easier and more timely application of patches across the customer's enterprise.

Cloning an Oracle Home
Duplicating software installations for development or QA purposes is a routine task in many data centers. For Oracle software, such installation cloning has become a lot easier with Enterprise Manager. Enterprise Manager's cloning wizard automates the duplication of database and application server installations (specifically, the directories where the corresponding Oracle homes reside). Thanks to its "multicasting" capability even multiple clones on multiple target hosts can easily be created in a single operation. Enterprise Manager home cloning is intelligent: host names, IP addresses and other environment dependent settings are automatically adjusted for the newly cloned homes. With Enterprise Manager, cumbersome cloning via homegrown scripts may well be a thing of the past.



OEM Grid Components
Oracle Enterprise Manager (OEM) Grid Control is monitoring software for Oracle Database, Fusion MiddleWare (FMW including OAS & SOA Suite), Oracle E-Business Suite, Siebel, SAP …






Oracle Enterprise Manager (OEM) / Grid Control Component
1. Oracle Management Agent: This software is installed on all the nodes(machines) which you would like to monitor.
The Configuration file for Management Agent is $OH/ <hostname>_<sid>/ sysman/ config/ emd.properties. The Agent uploads managed data (from server its monitoring) to Management Service via HTTP Server (URL of management Service HTTP Server is defined by REPOSITORY_URL parameter in emd.properties file)
The Management Agent software also includes in built HTTP Listener (different from standalone HTTP Server) to accept messages(data) from Management Service and this URL is defined by parameter EMD_URL located in the file emd.properties.
The Management Agent Log & Trace files are located under $AGENT_HOME (or $OH/ <hostname>_<sid>)/sysman/emagent.log, emagent.trc, emagentfetchlet.log, emagentfetchlet.trc , emagent.nohup

2. Oracle Management Service : The Management Service upload data (from Management Agent via HTTP Server) to Management Repository (sysman schema in oracle database) using JDBC. The configuration file for Management Service is $OH/<hostname>_<sid>/sysman/config/emoms.properties.
The Repository connection details are defined by the parameter emdRepSID, emdRepServer, emdRepConnectDescriptor and emdRepUser in the emoms.properties file.
The Management Service also monitors Management Agent (to check its up and running), submit enterprise manager jobs and other functions using EMD_URL (Management Agent runs inbuilt HTTP listener) defined in emoms.properties.
The Management Service Log & Tracefiles are located in $AS_HOME (or $OH/ <hostname>_<sid>)  / sysman/ emoms.log, emoms.trc

3. Oracle Management Repository : The Database Schema (sysman) is used to store Enterprise Manager Data. Management Service connects to the Management Repository using JDBC

4. Oracle Enterprise Manager (OEM) Grid Control Console: is a browser based tool to monitor and manage targets.  The Administrator uses the console (URL on browser using webcache post of Grid Control Server) which connects to Webcache Port of OEM Grid Console.
The Webcache in turn forward request to HTTP server of OEM Grid Middle Tier. The HTTP Server retrieves data from Management Repository via Management Service.

5. HTTP Server: Recieves the requests from webcache, pulls data from Repository via Management Service and return response back to Webcache. The HTTP Server also receives data from Management Agents, forward it to Management Service to store them in Management Repository.

6. Webcache : It acts as web accelerator; forward request from Users (console) to HTTP Server and response back from HTTP server to Users (Console)

Communication between Management Agent & Service
The Management Agent connect to Management Service via HTTP Server of Grid Control Middleware where as Management Service connect directly (using HTTP protocol) to Management Agent (Agent software include inbuilt http server).




Hardware Requirements
The system or systems must meet the minimum hardware requirements for hard disk space, available memory, processor speed, and operating memory.

Hard Disk Space Requirements
The hard disk requirements are:
■ 4.5 GB for the "Enterprise Manager Grid Control Using a New Database" installation type
■ 2.5 GB for the "Enterprise Manager Grid Control Using an Existing Database" installation type

Available Memory Requirements
The available operating memory requirements for installation are 1GB (2GB recommended).

Operating Requirements
The hardware requirements to run Enterprise Manager are:
■ Minimum processor speed of 1 GHz (3 GHz recommended) for the host running the Management Service
■ Minimum of 2 GB of free physical memory for the host running the Management Service
■ Minimum of 2 GB (4 to 6 GB recommended for medium and large deployments which typically have 1000 to 10,000 targets) of free physical memory for the Management Repository node


Installing Oracle Enterprise Manager Grid Control
Once you have configured your system to meet hardware and software requirements, start Oracle Universal Installer (OUI) and install Grid Control as follows:
1. Start OUI by specifying the full path to the setup.exe script.

Installation Screen	Recommended Action
Specify Installation Type	Select one of the installation types provided. The complete installation type is chosen by default.
Specify Installation Location	Specify the "parent" directory location for the installation. All Oracle homes created during installation will be placed as subdirectories under the parent directory.
Language Selection	Select the languages to run Grid Control in. The language you specify here is not the language of the installation session
Product-Specific Prerequisite Checks	Product-Specific Prerequisite Checks
Specify Configuration	Appears only for the "Enterprise Manager Grid Control Using a New Database" installation type. Specify the name of the database you want to create, as well as the location to store the   Management Repository files. Choose a file location outside of the Oracle home.
Specify Repository Database Configuration	Appears only for the "Enterprise Manager Grid Control Using an Existing Database" installation type. Specify the database connection details for your existing, qualified database, as well as the locations for the new Management Repository tablespaces.
Specify Optional Configuration	All parameters can be configured through Grid Control after installation. If you want, set the parameters for email notification, OracleMetaLink credentials, and proxy configuration settings.
Specify Security Options	Appears only for the "Enterprise Manager Grid Control Using a New Database" installation type. Specify password used to secure the Management Service, as well as passwords to secure the Management Repository Database.
Specify Passwords	Appears only for the "Enterprise Manager Grid Control Using an Existing Database" installation type. Specify the password used to secure the Management Service, as well as the SYSMAN password.
Summary	Review the information displayed here, then click Install
Configuration Assistants	Displays status information for configuration assistants
End of Installation	Contains important information about your installation, including the URLs configured for your applications. Make a note of these URLs. The port numbers used in these URLs are recorded in the following file: <AGENTHOME>/install/portlist.ini

 
Other Installation or Upgrade Options
In addition to performing a complete Grid Control installation, either using the embedded database or an existing, qualified one, you can perform the following other installation or upgrade operations:
■ Install an additional Management Service.
■ Install the Management Agents using:
    – Using the Agent Deployment Application
    – Using the agentDownload.vbs Script
■ Upgrade a previous, qualified version of Enterprise Manager Grid Control. Existing versions of Enterprise Manager will be automatically detected.
Refer to Oracle Enterprise Manager Grid Control Installation and Basic Configuration for detailed information and instructions on all of the above operations.

■ Deploy a Grid Control Agent to another server via the Grid Control frontend
 

Extending OEM
Only Oracle Database and Host targets can be extended through the UDM(User Defined Metrics) mechanism. Metrics based on SQL queries are used for database targets and those based on OS scripts are for host targets.
UDMs are accessible from the bottom of the target’s home page in the Related Links section. From this list you can manage existing and create new metrics. Figure 1 shows a sample UDM screen.

OEM provides basically the same functionality for UDM as for standard metrics. You can set warning and critical thresholds, receive notifications, and view metric history. UDMs are fully integrated into 10g Grid Control framework.

Example of UDM Creation
As an example, let's say you want to be notified whenever a certain schema has any invalid objects in it. This is how to setup such an alert:
1- Navigate to the database instance "Home" page and Click the "User Defined Metrics" link at the bottom of the page
2- Click the "Create" button (on the right side) to create a new UDM
3- Complete all of the form fields:

• SQL query you would like to run (don't use a semi-colon at the end!)
• Credentials
• Thresholds
• Schedule
• Note that you can customize the subject line of the notification emails
• Click the "Test" button to make sure the results are what you want
• Click "Ok" to save this UDM

4- Now we need to create the Notification Rule, so Click "Preferences" in the top right corner of any Grid Control page
5- Click "Rules" in the left nav bar
6- Create a new Notification Rule





SQL-based User Defined Metrics
OEM 10g Release 1 supports only metrics returning a single value so SQL queries should return a single row with one column.
Let’s create a sample metric that will show actual number of open cursors per session as a percent of the max open cursors (defined by open_cursors init.ora parameter). We only need to consider the session with top number of  opened cursors. This metric will show how close we are to the open_cursors limit. Note that this is sampling data and reflects the state at the moment of metric collection so it might be possible that in between collections the value is higher or lower.

Enter “Max Open Cursors %” as metric name. In the SQL Query field enter the following statement.
SELECT ROUND (c.open_cursors / p.value * 100) open_cursors
  FROM (SELECT sid, COUNT (*) open_cursors
                  FROM v$open_cursor
                  GROUP BY sid
                 ORDER BY 2 DESC) c,
                  v$parameter p
  WHERE p.name = 'open_cursors' AND ROWNUM = 1;

Select metric type NUMBER and, if you use OEM 10gR2, chose a Single Value option for SQL Query Output (OEM 10gR1 has no such option). In the credentials section, enter the Oracle username and password – these can be the same as your target configuration, for example, DBSNMP user. Now chose the greater than sign (>) as a comparison operator and define warning and critical thresholds. I took values 70 and 90 for warning and critical thresholds respectively, with the number of consecutive occurrences preceding notification set to 1. We define that collection should start immediately and repeat every five minutes. That’s it – our first user-defined metric is ready. In 10gR2 we can test metric collection using the “Test” button before actually creating it. In the second release it’s also possible to define a custom alert message but we will cover it in the next example.
OEM will collect this new UDM as if it’s a normal metric and store the results in the repository. You can view metrics history by clicking on its name in the User-Defined Metrics screen.

Note that you can have metrics that return string values and notification conditions can be set using either CONTAINS or MATCH operators. One example of such metric is the standard metric database state (Mounted, Open, etc). 

OS command-based Metrics
UDM based on an OS script/command can be used for a target of type Host. This can be either a script or a binary program returning collected data to its standard output.
The screen to create a new OS-based UDM is similar to the one for a SQL-based metric.
Instead of a SQL query we should enter an OS command to run the required program. There is an optional field for a space-separated list of environment variables that should be set before calling the specified script. Note on the right  side, the area with the list of predefined OEM variables which can be used by the command line in the format of %variable%. These will be substituted by OEM with corresponding values. For example, %perlbin% is the path to the  Perl binary directory. Perl is the Oracle standard scripting language, and one of its definite advantages is portability between different platforms.

UDMs Pros and Cons
The main advantage of UDM is that it is a straightforward method which does not require any additional knowledge of the framework and complex manipulations. However, there are number of disadvantages:

• No direct support for user-defined monitoring targets
• Very limited number of collection types (SQL-based and OS script-based)
• No support for collection based on cumulative counters (like V$SYSSTAT) when the metric’s value is calculated based on the difference between previous and current measurements.
• UDM should be defined for each instance of target type, i.e. having 100 database instances will require user to add 100 UDM metrics.
• Credentials are defined separately and different from those provided in target setup. If they are changed for one target than every UDM of that target has to be updated manually.
• Thresholds are defined in a separate screen from other metrics and have no real time status.

All of the above are addressed with user-defined target types