PK ^UIoa,mimetypeapplication/epub+zipPK^UIMETA-INF/container.xml PKYuPK^UIOEBPS/addnl_tasks.htm Additional Configuration Tasks

18 Additional Configuration Tasks

This chapter contains the following sections:

18.1 Understanding Default and Custom Data Collections

When you install the Oracle Management Agent on a host computer, Enterprise Manager automatically begins gathering a default set of metrics that you can use to monitor the performance and availability of each targets on that host. For some of these target metrics, Enterprise Manager provides default threshold settings that determine when you will be notified that there is a problem with the metric.


See Also:

"About Alerts" in the Enterprise Manager online help

For selected metrics, you can customize the default thresholds. When you make these types of customizations, Enterprise Manager saves the new settings in a file on the local disk. The following sections provide more information about how these settings are saved:

18.1.1 How Enterprise Manager Stores Default Collection Information

Enterprise Manager stores the default collection criteria for each target in the following location on each Oracle Management Agent host:

AGENT_HOME/sysman/admin/default_collection/

For some targets, you can use the Oracle Enterprise Manager 10g Grid Control Console to modify the default metric collection settings. For example, you can modify the default thresholds for your host targets. When you make these types of modifications, Enterprise Manager creates a new default collection file in the following directory:

AGENT_HOME/sysman/emd/collection/

This collection file overrides the default collection information stored in the sysman/admin/default_collection directory.

18.1.2 Restoring Default Collection Settings

If you have made modifications to the metric thresholds for a particular target, you can restore the default metric collection settings by deleting the customized collection information in the sysman/emd/collection directory.

For example, if you want to restore the default collections for a particular database target, remove the customized collection file for that target from the sysman/emd/collection directory. Enterprise Manager will begin using the metric collection information stored in the sysman/admin/default_collection directory.

18.2 Enabling Multi-Inventory Support for Configuration Management

Every time you install an Oracle software product on a host computer, Oracle Universal Installer saves information about the software installation on your hard disk. The directories and files that contain this software configuration information are referred to as the Oracle Universal Installer inventory.

When you use Enterprise Manager to monitor your Oracle software installations, Enterprise Manager takes advantage of information saved in the Universal Installer inventory.

As it gathers information about the configuration of your host computer, by default, Enterprise Manager assumes that you have one Oracle Universal Installer inventory on the host. Specifically, Enterprise Manager recognizes the inventory that Oracle Universal Installer uses when you run the Universal Installer on the host.

However, in some cases, you may have more than one inventory. For example, you may have worked with Oracle Support to clone your Oracle software installations. For those cases, you can use the following procedure to be sure that Enterprise Manager can track and manage the software information in multiple inventories on the same host.


Caution:

Enabling support for multiple inventories is optional and available only for advanced users who are familiar with the Oracle Universal Installer inventory architecture and who have previously worked with multiple inventories on a managed host. This procedure is not required for hosts where normal installations have been performed.

To set up Enterprise Manager so it can read multiple inventories on a host:

  1. Locate the OUIinventories.add file in the following directory:

    $ORACLE_HOME/<nodename>_<sid>/sysman/config
    
    

    The Management Agent state listed in this example represents an installation for Database Control. For more information about the Management Agent state to use for other installations, see Section 18.2.1, "AGENT_HOME Versus AGENT_STATE Directories" .

  2. Open OUIinventories.add using a text editor.

    Instructions within the file describe the format to use when identifying multiple inventories, as well other techniques for mapping Oracle Homes.

  3. Carefully review the instructions within the file.

  4. Add entries to the file for each additional inventory on the managed host.

  5. Save your changes and close the file.

During its next collection of host configuration information, Enterprise Manager will start gathering software configuration information from the inventories that you identified in the OUIinventories.add file, in addition to the default inventory that Enterprise Manager normally collects.

Alternatively, to see the data gathered from the additional inventories before the next regularly-scheduled collection, navigate to the Host home page in the Grid Control Console, click the Configuration tab, and click the Refresh Data icon next to the page timestamp.


Note:

If there any irrecoverable problems during the collection of the default inventory (for example, if the inventory file or directory protections prevent Enterprise Manager from reading the inventory), inventories listed in OUIinventories.add file are also not collected.

If the Enterprise Manager is able to read the default inventory, but there is a problem reading an additional inventory listed in the OUIinventories.add file, Enterprise Manager issues a collection warning for those inventories. However, Enterprise Manager does collect the configuration information for the other inventories.


18.2.1 AGENT_HOME Versus AGENT_STATE Directories

The Management Agent recognizes two main directory structures; its installation directory where software binaries and all unchanging metadata are stored, and its configuration/state directory where all customizations and output/log content are stored and/or generated. In a normal Management Agent installation, these two directories are the same. However, they can be different in the following cases:

  • RAC Agent installation ($ORACLE_HOME versus $ORACLE_HOME/<hostname>)

  • Database Control installation ($ORACLE_HOME versus $ORACLE_HOME/<nodename><sid>)

  • State-only Management Agent deployment (using the emctl deploy agent command -- $ORACLE_HOME versus $EMSTATE)

In each of the above cases, there will be multiple instances of the Management Agent running off the same binaries installation. The different instances have different locations to maintain separate configurations but use the same set of binaries. The command emctl agent status provides the values of the Management Agent's binaries and state locations.

18.3 Manually Configuring a Database Target for Complete Monitoring

When you first discover an Oracle Database 10g target, you should check the monitoring credentials to be sure the password for the DBSNMP database user account is set correctly in the database target properties.

Besides setting the monitoring credentials, no other configuration tasks are required to monitor an Oracle Database 10g target.

However, when you monitor an Oracle9i database or an Oracle8i database, there is some additional configuration required if you want to monitor certain types of database performance metrics using the Grid Control Console.

To monitor these additional performance metrics Enterprise Manager requires that Oracle Statspack and some additional Enterprise Manager packages be installed and configured in the database you are monitoring.


See Also:

"Using Statspack" in Oracle Database Performance Tuning Guide and Reference in the Oracle9i Documentation Library

If these additional objects are not available and configured in the database, Enterprise Manager will not be able to gather the data for the complete set of performance metrics. In addition, Enterprise Manager will not be able to gather information that otherwise could be readily available from the Database home page, such as Bad SQL and the Top SQL Report.

You can use the Configure Database wizard in the Grid Control Console to install the required packages into the database, or you can use the following manual procedure.


See Also:

"Modifying Target Properties" in the Enterprise Manager online help for information on configuring managed targets, including database targets

To manually install Statspack and the other required database objects into an Oracle9i database that you are managing with Enterprise Manager, you can use SQL*Plus and the following procedure:

  1. Log in to the database host using an account with privileges that allow you to write to the database home directory and to the Management Agent home directory.

    For each of the commands in this procedure, replace AGENT_HOME with the actual path to the Oracle Management Agent home directory and replace ORACLE_HOME with the path to the database home directory.

  2. Start SQL*Plus and connect to the database using the SYS account with SYSDBA privileges.

    For example:

    $PROMPT> ./sqlplus "connect / as sysdba"
    
    
  3. Enter the following command to run the database dbmon script:

    SQL> @AGENT_HOME/sysman/admin/scripts/db/config/dbmon
    
    

    The script will display the following prompt:

    Enter value for dbm_password:
    
    
  4. When prompted, enter the password for the DBSNMP account.

    The script performs several configuration changes and returns you to the SQL*Plus prompt.

  5. Connect as the DBSNMP user.

    For example:

    SQL> connect DBSNMP
    
    
  6. Enter the following command:

    SQL> @AGENT_HOME/sysman/admin/scripts/db/config/response.plb
    SQL> grant EXECUTE on dbsnmp.mgmt_response to OEM_MONITOR;
    

    Note:

    The above script should not be run on an Oracle database of version 8.1.7 or prior. Oracle does not support SQL Response Time for 8.1.7 databases or prior.

  7. Connect as SYS and enter the following command to create the PERFSTAT user:

    SQL> @ORACLE_HOME/rdbms/admin/spcreate
    

    Note:

    The spcreate script will prompt you for a default tablespace and default temporary tablespace for the PERFSTAT user. Do not specify the SYSTEM tablespace as the default tablespace for the PERFSTAT user. For more information, see "Using Statspack" in the Oracle Database Performance Tuning Guide.

  8. Connect as the PERFSTAT user.

    For example:

    SQL> connect PERFSTAT;
    
    
  9. Enter the following commands from the PERFSTAT user account:

    SQL> define snap_level='6';
    SQL> define cinterval='1';
    SQL> define cjobno='-1';
    SQL> @AGENT_HOME/sysman/admin/scripts/db/config/spset
    
    
  10. Connect as the SYS user and enter the following command:

    SQL> grant OEM_MONITOR to dbsnmp;
    
    
  11. If the database you are modifying is an Oracle8i database, also enter the following commands as the SYS user:

    grant select on sys.ts$ to OEM_MONITOR;grant select on sys.seg$ to OEM_MONITOR;grant select on sys.user$ to OEM_MONITOR;grant select on sys.obj$ to OEM_MONITOR;grant select on sys.sys_objects to OEM_MONITOR;grant select on sys.file$ to OEM_MONITOR;grant select on sys.attrcol$ to OEM_MONITOR;grant select on sys.clu$ to OEM_MONITOR;grant select on sys.col$ to OEM_MONITOR;grant select on sys.ind$ to OEM_MONITOR;grant select on sys.indpart$ to OEM_MONITOR;grant select on sys.indsubpart$ to OEM_MONITOR;grant select on sys.lob$ to OEM_MONITOR;grant select on sys.lobfrag$ to OEM_MONITOR;grant select on sys.partobj$ to OEM_MONITOR;grant select on sys.tab$ to OEM_MONITOR;grant select on sys.tabpart$ to OEM_MONITOR;grant select on sys.tabsubpart$ to OEM_MONITOR;grant select on sys.undo$ to OEM_MONITOR;
    
    
  12. For any supported database version, enter the following command from the SYS account:

    SQL> show parameter job_queue_processes
    
    

    If the output from the show parameter command is zero, then perform the following steps to modify the job_queue_processes initialization parameter:

    If you start the database using an spfile, enter the following command:

    SQL> alter system set job_queue_processes = 2 SCOPE=BOTH;
    
    

    Otherwise, do the following:

    1. Enter the following command:

      SQL> alter system set job_queue_processes = 2;
      
      
    2. Exit SQL*PLUS and update the init.ora database configuration file with the following entry so the parameter will be applied whenever the database is restarted:

      job_queue_processes=2
      
      
  13. Exit SQL*Plus and change directory to the following directory in the home directory of the Management Agent that is monitoring the database:

    AGENT_HOME/bin
    
    
  14. Reload the Management Agent by entering the following command:

    $PROMPT> ./emctl agent reload
    
    
  15. Using the Grid Control Console, return to the Database home page and verify that the Bad SQL and Top SQL Report metrics are now being gathered.

18.4 Modifying the Default Login Timeout Value

To prevent unauthorized access to the Grid Control Console, Enterprise Manager will automatically log you out of the Grid Control Console when there is no activity for a predefined period of time. For example, if you leave your browser open and leave your office, this default behavior prevents unauthorized users from using your Enterprise Manager administrator account.

By default, if the system is inactive for 45 minutes or more, and then you attempt to perform an Enterprise Manager action, you will be asked to log in to the Grid Control Console again.


Caution:

As stated in the previous paragraphs, the timeout value for logging in to the Grid Control Console is defined in order to protect your system from unauthorized logins. If you make changes to the login timeout value, be sure to consider the security implications of leaving your session open for other than the default timeout period.

To increase or decrease the default timeout period:

  1. Change directory to the following location in the Oracle Application Server home directory where the Management Service was deployed:

    IAS_HOME/sysman/config/
    
    
  2. Using your favorite text editor, open the emoms.properties file and add the following entry:

    oracle.sysman.eml.maxInactiveTime=time_in_minutes
    
    
  3. For example, if you want to change the default timeout period to one hour, add the following entry:

    oracle.sysman.eml.maxInactiveTime=60
    
    
  4. Save and close the emoms.properties file.

  5. Restart the Management Service.


    Note:

    The default timeout value does not apply when you restart the Web server or the Oracle Management Service. In both of those cases, you will be asked to log in to the Grid Control Console, regardless of the default timeout value.

18.5 Configuring Clusters and Cluster Databases in Grid Control

This section describes how to configure clusters, cluster databases, and discovering instances.

18.5.1 Configuring Clusters

To add a cluster target that was installed but not discovered as a target automatically during installation, perform the following steps:

  1. Click All Targets from the Targets page.

  2. Select Cluster from the Add menu and click Go. The Add Target: Cluster page appears.

  3. Optional: Specify the cluster name and provide the Clusterware home path if it is installed on the cluster.

  4. To add hosts to the cluster, use the arrow buttons to move items from Available Hosts to Selected Hosts. The hosts you select must not already belong to a cluster.

  5. Click Add to save the cluster target to the targets.xml file on every selected host.


See Also:

The Enterprise Manager online help for more information about configuring clusters

18.5.2 Configuring Cluster Databases

After you have added the cluster target, you can add a cluster database target either from the Databases page or from the All Targets page.

To add a cluster database target, perform the following steps:

  1. In the Enterprise Manager Grid Control Console, select one of the following entry locations:

    • From the Databases page, click Add. The Add Database Instance Target: Specify Host page appears.

    • From the All Targets page, select Database Instance from the Add drop-down menu, then click Go. The Add Database Instance Target: Specify Host page appears.

  2. Specify any host member of the cluster target where the cluster databases reside, then click Continue. The Add Database: Specify Source page appears.

  3. Keep the default option (on all hosts in the cluster) selected and click Continue. This option sends requests to all Management Agents in the cluster to perform discovery.

    After target discovery completes, the newly discovered RAC databases appear in the Targets Discovered on Cluster page. If the databases do not appear, see the Troubleshooting section below.

  4. If the desired targets do not appear in the Cluster Databases table, or if the discovered targets are not configured appropriately, click Manually Add. The Properties page of the Configure Cluster Database wizard appears.

  5. Provide the required values for the Properties table.

  6. You must specify at least one instance in the Instances table. If no instances appear in the table, click Add. The Properties: Add Instance page appears. Provide the required values, then click OK. The Properties page of the Configure Cluster Database wizard reappears.

  7. Click Next. For versions 10.1 and higher, Enterprise Manager bypasses the Install Packages, Credentials, and Parameters steps, and goes directly to the Review page.

  8. Click OK. The Targets Discovered on Cluster page reappears, and displays the newly added cluster database and instances.


See Also:

The Enterprise Manager online help for more information about configuring cluster databases

18.5.3 Discovering Instances Added to the Cluster Database

If you need to configure additional instances, follow these steps:

  1. In Enterprise Manager, click Databases in the Targets page, and navigate to the desired Cluster Database Home page.

  2. Click Monitoring Configuration in the Related Links section. The Properties page of the Configure Cluster Database wizard appears.

  3. Provide the required information in the Properties table at the top of the page.

  4. Examine the Instances table. One or more additional instances may exist, but may not appear in the Instances table. If this is the case, click Add to discover the instance in the cluster database. The Properties: Add Instance page appears.

  5. Provide the required information, then click OK. The wizard Properties page reappears, and displays the added instance view.

  6. Click Check Connection to ensure that the connection is working.


See Also:

The Enterprise Manager online help for more information about discovering instances added to the cluster database

18.5.3.1 Troubleshooting

If you encounter configuration issues, check the following required conditions to ensure that automatic discovery is able to function correctly:

  • The host user running the Management Agent is able to run the SRVCTL utility in the Oracle home and retrieve the database configuration.

  • The host user running the Management Agent is able to connect to the database through SQLPLUS using OS authentication.

  • The Oratab (UNIX) or Registry (Windows) contains information about the database.

  • If automatic discovery still does not resolve your configuration issues after you have ensured the conditions previously listed, you can manually configure cluster databases (see Section 18.5.2, "Configuring Cluster Databases").

    For more information about configurations for Oracle Enterprise Manager Grid Control, see Chapter 3, "Grid Control Common Configurations".

18.6 Collecting Client Configurations

A client is comprised of a host and operating system user. Client configuration data that is collected includes:

18.6.1 Configuring the Client System Analyzer

The Client System Analyzer (CSA) allows Web server administrators to collect and analyze end-user client data. The client data is collected by an applet, diagnosed and sent back to the CSA application. The Oracle Management Agent uploads this data to the Enterprise Manager Management Repository. After the client configuration data has been collected by the client configuration collection applet and written to the Web server directory specified by the CSA applet, the client configuration data is uploaded to the Oracle Management Repository.

You can either use the Client System Analyzer in the Grid Control application pre-installed with Enterprise Manager or you can deploy CSA independently to your Web server.

18.6.1.1 Client System Analyzer in Oracle Grid Control

Client System Analyzer in Grid Control - An instance of CSA is pre-installed with Enterprise Manager. If you use this option, you can collect client data without setting up a separate Web server. To activate the pre-installed CSA application in Enterprise Manager, click Deployments. Then click Client System Analyzer in Grid Control and use the button provided to activate the application. Once CSA is activated, end-users can use the URL provided to run the CSA applet. The CSA applet can collect base client configuration information from client systems and Oracle Collaboration Suite client information from Oracle Collaboration Suite client systems.

  • To download the CSA applet and have it collect base client configuration information, a client should use the Client System Analyzer URL in this format: http[s]://management-service-host:port/em/public/ecm/csa/CSA

  • To download the CSA applet and have it collect Oracle Collaboration Suite client configuration information, a client should use the Client System Analyzer URL in this format: http[s]://management-service-host:port/em/public/ecm/csa/CSA?application=OCS

18.6.1.2 Deploying Client System Analyzer Independently

The Client System Analyzer Application can be deployed independently to any J2EE-capable Web server. Click the Deployments tab. Then click Getting Started with Client System Analyzer and click Deploy Client System Analyzer Application. Follow these steps to deploy the CSA applet and collect the client configuration data.

    1. Download the CSA Application:

      The CSA application includes the CSA directory along with the necessary JSP applet files. The application is packaged as an EAR file. To download this default EAR file, click Download Client System Analyzer Application. You can customize the default CSA EAR file by modifying the following:

      • Rules - This file contains a default set of rules against which the client data is evaluated. You can customize and add rules before deploying CSA.

      • Context parameters - You can customize the context parameters in the web.xml file.

      • Custom classes - You can provide customized applet classes that can be used to perform tasks like collecting additional data, changing the behavior of the applet, and performing certain operations on the client.

    2. Deploy CSA to any J2EE Web server.

      The CSA application is deployed on an Application Server as a regular J2EE application. Once the CSA application is deployed, context parameters can be changed similar to other web applications.

    3. Direct users to the CSA.

      In order for the client data to be collected, the user must access the CSA application. Users can access the CSA JSP page directly or by using a link from another application. Users can be automatically redirected to CSA using the following methods:

      • HTTP Server (Apache's mod_rewrite) - This option does not require changes in the Web application.

      • Servlet Filter - A servlet filter is a program that filters requests to and from the server. The CSA_filter.jar file contains the servlet filter classes. The servlet filter and the filter mapping need to be added to the Web application.

      • CSA Redirection JSP - The CSA Redirection JSP (CSARedirect.jsp) page can be included into the Web application.

    4. Configure Enterprise Manager.

      Collected client data is recorded in the Receive File Directory on the Web server. To upload the collected client data into Enterprise Manager, you need to do the following:

      • Add a CSA Collector Target to the Enterprise Manager Management Agent. To do so, click Add Collector and choose a target from the list.

      • Specify the absolute path to the Receive File Directory. The path specified must be the same as the path specified in the outputDir parameter of the CSA application. By default, the client data is stored in the Receive File Directory "csa_results" under the context root of the Client System Analyzer Web application, but this can be configured by changing the applications's "outputDir" context parameter.

    5. Test the CSA Deployment.

      To verify the CSA deployment, click the URL of the CSA page and check if the client data is collected.

18.6.2 Configuration Parameters

The Client System Analyzer (CSA) can be further configured by modifying the context parameters in the CSA application's WAR file.

Table 18-1 Configuration Parameters

ParameterDescriptionDefault Value

alertWhenDone

If set to true, a message indicating that the applet has been executed is displayed.

false

appletJAR

The name of the JAR file.

CSA.jar

application

The name of the application associated with this CSA instance. If the application parameter value is not specified, then the Collection Tag has a value of Default.

none

autoRedir

If set to "true", this causes the CSA JSP page to automatically use the Sun JVM if JVM was set to JInitiator and the client does not have the appropriate version of JInitiator installed.

false

bwTestFile

The name of the file that is downloaded from the server during the bandwidth test.

CSA.mb (included with CSA)

bwTestMsec

The amount of time the applet should spend on the bandwidth test. The applet computes bandwidth by counting the number of bytes it can download in this interval.

200 ms

classid

The "classid" field for the OBJECT tag. Applicable only if JVM is set to "JInitiator." The classid for Sun is "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"codebase - the "codebase" field for the OBJECT tag. Applicable only if JVM is set to "JInitiator."

None – this field MUST be set if JVM is set to "JInitiator," and is ignored otherwise

codebase

The codebase field for the OBJECT tag. Applicable only if the JVM is set to "JInitator".

The default for Sun is http://java.sun.com/products/plugin/autodl/jinstall-1_4_2-windows-i586.cab#Version=1,4,0,0

collectCookie

The list of the names of cookies to be collected. This parameter is a comma-separated list of cookie names. Only cookies for the current OS user in the current browser will be collected. The Administrator can specify asterisk (*) to collect all of the current user's cookies for the current browser.

If this field is not present, no cookies will be collected.

cookieDomain

The domain of the CSA cookie.

If either the domain or path of the cookie is not set, cookies are disabled

cookieMaxAge

The maximum duration, in seconds, of the cookie on the client machine.

1 year

cookiePath

The path of the CSA cookie

If either the domain or path is not specified, cookies are disabled.

customClass

The name of the class used to collect custom data.

none – the default behavior is for no custom code to be executed

customKey1customKey2customKey3

The values of the three custom keys. All client collections done by a CSA JSP page that uses this deployment descriptor will have these values for the custom keys. These values can be overridden by custom code.

If no custom key values are specified, none will be collected (unless they are collected by custom code)

descriptionFile

The full path of a text file containing the description that will be displayed on the deployment page. The contents of the file should be HTML-formatted text.

None

destURL

Specifies the destination URL. This is the URL to which the "Proceed" button on the CSA JSP page is linked.

If no destURL is specified, the "Proceed" button will take the user to the referring page; if there is no referring page, the "Proceed" button will not be displayed.

destURLResultsParam

Specifies the name of the URL parameter that will be added to the "destination URL" to indicate the client's compliance level. For example, if the value was "compliance", and the client's overall compliance level was critical, then the parameter "compliance=critical" would be added to the destination URL.

Sun

JVM

This determines the type of JVM that is to be used. If the value is ""Sun," the JSP page will direct the browser to use the Sun JVM. If the value is "Oracle," the page will direct the browser to use Oracle Jinitiator. If the value is "any," the JSP will write out the standard "applet" tag, which causes the client to use whichever JVM is plugged into the browser.

Sun

maxExecInterval

Parameter that is added to CSA cookie payload. When the redirection logic reads the cookie, if the timestamp of the cookie differs from the current time by more than this value, the applet is deployed again. This parameter can be overridden by the "csa execInterval" context parameter in the redirection JSP filter.

90 days

maxFileSize

Maximum amount of data, in KB, that can be posted back to the receiver in a single request. If the size of the posted data exceeds this limit, the request is rejected and any data already written to the hard drive is deleted.

100

maxOutputFiles

Maximum number of output files that can be present in XML OutputDir.

100

outputDir

Directory to which CSA configuration xml files will be written. Both the applet page and the receiver page must read this parameter, and this parameter must be identical for both pages.

By default, the output files are written into the "csa_results" subdirectory of the application root directory (if the application root directory exists, and if the subdirectory exists or can be created). Using the default value for this parameter is not recommended.

outputEnabled

Enables or disables creation of output XML files. Applicable to both applet and receiver pages.

By default, the XML files are created and stored in the XMLOutputDir.

pluginspage

Used to direct the user to the JVM installer under Netscape, since Netscape does not support automatic installation. Applicable only if JVM is Jinitiator. Default for Sun is http://java.sun.com/products/plugin/index.html#download

none - This field must be set if JVM is set to "JInitiator" and is ignored otherwise.

receiver

The URL to which the applet should post the collected data.

Note: When setting this parameter, the administrator must ensure that the version of the receiver is the same as the version of the applet.

Default is to look for "CSAr.jsp" in the same path as the CSA JSP page

ruleFile

Specifies the path on the server, relative to the web application root, of the file that contains the rules to be evaluated.

rules.xml

script

Specifies a script, provided by the administrator, which can be run on the CSA XML file before it is marked for upload by the agent.

none - If no script is specified, no script will be run.

type

The type field for the OBJECT tag rendered by the CSA JSP page to deploy the applet. This is only applicable if the JVM is set to JInitiator. If the JVM is set to Sun, the type is application/x-java-applet.

none - this field must be set if JVM is set to "JInitiator," and is ignored otherwise

viewData

If set to true, this parameters allows the end-user to view the collected data after it is posted to the server.

false


In addition to these parameters, the CSA redirection parameters can also be configured. Redirection can be enabled either by using a servlet filter or by including a CSA redirection JSP file in some other page. The following context parameters must be available for the redirection to work.

Table 18-2 Configuration Parameters

Parameter NameDescriptionDefault Value

csaURL

The URL of the CSA JSP page to which the user should be redirected.

No default: This value must be set or redirection cannot work.

execInterval

The interval, in seconds, between executions of CSA. If the difference between the cookie's age and the current server time is greater than execInterval, the user is re-directed.

None. If the execInterval is not set, then the user is only redirected if there is a CSA cookie.

redirectURL

The URL to which the user should be directed after CSA has executed

None.

If this parameter is not set, the user is directed back to the originally requested page

UIMode

0 - synchronous (in the current browser window)

1 - asynchronous visible

2 - asynchronous invisible

synchronous


18.6.2.1 Associating the Parameters with an Application

In certain cases, different sets of parameters may be required for different applications. For example, two different applications may have different rule sets and custom code, and the administrator may want to associate them with different CSA Collector Targets. In this scenario, the administrator can specify the ruleFile, appletJar, script, and outputDir parameters for a particular application by using the context parameters <application name> ruleFile, <application name> appletJar, and so on. If an application is specified, either as a context parameter or through the URL, then CSA is executed using the parameter values specific to the application. If no application is specified, or if one of the parameters for an application is not overridden, the default parameters are used.

18.6.3 Rules

Custom rules can be supplied to the CSA application so that the users receive immediate feedback as to whether their systems satisfy certain constraints. A sample RULES file is shown in Example 18-1 followed by a description of each tag contained in the file.

Example 18-1 Sample RULES

<RULES>
<RULE>
<NAME>Client has sufficient memory</NAME>
<DESCRIPTION>Checks to see if the client has enough memory to run the application</DESCRIPTION>
<VIOLATION> //ROWSET[@TABLE='MGMT_ECM_HW']/ROW/AVAIL_MEMORY_SIZE_IN_MB[number() &lt; $arg=SIZE$] </VIOLATION>
<SEVERITY level="CRITICAL">
<PARAM id='SIZE'>100</PARAM>
<MOREINFO>
<TEXT>Application cannot run with less than 100 MB. </TEXT>
</MOREINFO>
</SEVERITY>
<SEVERITY level="WARNING">
<PARAM id='SIZE'>150</PARAM>
<MOREINFO>
<TEXT>Approaching minimum memory level</TEXT>
</MOREINFO>
</SEVERITY>
</RULE>
</RULES>

Example 18-1 demonstrates a rule that can be used to check whether or not the client has sufficient memory to run the application. The <VIOLATION> is an XPATH expression that the applet will evaluate against an XML file that contains all of the data it has collected. Since the violation is an XPATH expression embedded in an XML file, certain characters in the XPATH, such as '<', '>', and '&', must be replaced with entities. If the XPATH expression returns a non-null node set, the rule has failed. In this case, the rule will fail if the client's available memory is less than a certain amount. The actual amount that triggers a violation can be configured by using different severity levels.

In Table 18-3, the applet will first replace the substring "$arg=SIZE$" in the VIOLATION expression with "100" and then evaluate the expression. If the client's available memory is less than 100 MB, then the rule will fail with critical status. The applet will indicate the status along with the message "Application cannot run with less than 100 MB of memory". If the rule passes through successfully, the applet will then replace "$arg=SIZE$" with 150 and try again; if the rule fails, the applet will display the message "Approaching minimum memory level." If the applet goes through all specified severity levels and does not find a violation, the rule is successful.

Table 18-3 Tags in the RULES File

Tag NameDescription

RULES

This is the top-level tag for the XML file

BUNDLE

This tag specifies the resource bundles used for translation. The value of the tag is either the name of a file or a Java class name. The rule engine reads this string and first attempts to find a file in the applet JAR that has this name. This file is expected to contain a mapping of resource IDs to strings in various languages. If such a file does not exist, then the string is treated as the name of a Java resource bundle class. Strings in a resource bundle are referenced using the syntax <resource id>@<bundle id>.

PRECONDITION

This tag is used to specify an XPATH expression that must return a non-null node set in order for a rule to be evaluated. The "id" attribute specified the ID of the precondition. A rule can specify a list of preconditions that should be evaluated by listing their IDs.

RULE

This tag represents an individual node that is to be evaluated. The rule's severity is specified using a <SEVERITY> tag. At least one severity tag must be specified for a rule. The tag has an optional "precondition" attribute, which is used to specify a list of precondition IDs separated by commas. Before the rule is evaluated, all of the preconditions must be met. If the pre-conditions are not met, the rule has a status of "Not Applicable" and is not displayed in the client UI at all. The children of a RULE tag are NAME, DESCRIPTION, VIOLATION, SEVERITY, and MOREINFO.

NAME

This tag specifies the name of the rule and identifies the tag in the repository.

Note: This tag must contain a value and cannot be blank.

DESCRIPTION

This is the description of the rule.

VIOLATION

This tag lists the violations that are to be checked for a given rule. The violation is specified in the CSA Condition Language.

SEVERITY

A rule can have three severity levels: INFO, WARNING, and CRITICAL. The SEVERITY node must contain a number of ARG children equal to the number of arguments that can be accepted by the expression in the VIOLATION node. When the rule engine evaluates a rule, it evaluates the condition in VIOLATION for each of the sets of arguments specified in the severity levels, starting with CRITICAL and moving down in order of severity. As soon as the engine encounters a condition that fails, the rule is declared a failure, with a severity level equal to the severity level of the argument that caused the failure. If the conditions for all specified levels are met, the rule passes.

PARAM

This tag specifies the value of an argument that should be substituted into an expression. The 'id' attribute of the tag must match the name of one of the arguments in the expression.

MOREINFO

This tag specifies the information that is displayed if the user clicks the "more information" button that is displayed next to a failed rule. The children of MOREINFO are TEXT and ARG.

Note: The MOREINFO node can be a child either of the severity node (in the case where multiple severities are specified) or of the rule itself.

TEXT

This tag specifies the text to be displayed when the "More Info" button is clicked. The "resource" attribute specifies a string in a resource bundle – if this string is not present, the value of the node is displayed instead. The text (either in the resource bundle or in the node itself) can specify a location for arguments to be inserted by using "{0}", "{1}", and so on. In this case, the expressions in the ARG nodes are evaluated and inserted into the text in the order in which they are specified. If there are more ARG nodes specified than there are slots in the string, the extra nodes are ignored.

ARG

This tag specifies an expression in the CSA Condition Language that can be evaluated and inserted into the MOREINFO text.



See Also:

Enterprise Manager online help associated with the Getting Started with CSA page

18.6.4 Customization

In addition to writing custom classes to collect custom properties, the administrator can also specify custom properties in the deployment descriptor. Custom property names are specified by including a context parameter of the form csa value_<name>. The <name> field of the context parameter name is treated by the Client System Analyzer (CSA) as the custom property name, and the value of the parameter is treated as the custom property value. Similarly, administrators can specify the type, type_ui, name_ui, display_ui, and history_tracking fields for a custom property by using csa_type_<name>, csa_type_ui_<name>, csa_name_ui_<name>, csa_display_ui_<name>, and csa_history_tracking_<name> parameters, respectively. Custom properties can also be specified on the CSA Applet URL, using the same naming convention.

18.6.5 CSA Deployment Examples

The following sections outline sample use cases for client configurations.

18.6.5.1 Using Multiple Collection Tags

An administrator can check the compatibility of users with two distinct Web applications. The first is an online teaching website that delivers content using a number of various plug-ins, allowing an administrator to be sure that all users have the required installed plug-ins. The second is a software distribution portal that allows an administrator to ensure that all users downloading software from the portal have the required hardware and operating system. In this case, though both applications require their own set of rules, the administrator can use a single CSA instance for both applications through the use of collection tags displayed in the following list:

  1. Choose a collection tag for each application, such as "teaching" and "distribution".

  2. Create two separate rule files, one for each application.

  3. Use context parameters to map each rule file to the corresponding application, as shown in Example 18-2.

  4. Create the appropriate links from each application to CSA. The links from the teaching and distribution applications should have "application=teaching" and "application=distribution", respectively, in the query string. This ensures that users of each application have the correct collection tags when running CSA.

Example 18-2 Using Collection Tags for Selecting a Rule File

<context-param>
  <param-name>csa teaching ruleFile</param-name>
  <param-value>teaching_rules.xml</param-value>
</context-param>
 
<context-param>
  <param-name>csa distribution ruleFile</param-name>
  <param-value>distribution_rules.xml</param-value>
</context-param>

Example 18-2 shows only the use of collection tags for selecting a rule file. However, collection tags can be used for any of the CSA context parameters.

Collection tags also affect how client configurations are stored in the Enterprise Manager Management Repository. If the user comes to CSA using the link from the teaching application in Example 18-2, then in addition to running the rules for the "teaching" collection tag, CSA also causes this tag to be stored with the client configuration data in the Management Repository. The collection tag forms part of the unique identifier for the client configuration, which makes it possible for a single client to have multiple configurations in the Management Repository, each with its own tag. Collection tags can be associated with Enterprise Manager targets in order to restrict access to client data; an Enterprise Manager user can only view a client configuration if he or she has view privileges on a target that is associated with the collection tag for that client configuration.

In Example 18-2, suppose that host H1, application server A1, and database D1 are used to host the teaching application, while host H2, application server A2, and database D2 are used for the distribution application. All 6 targets are monitored by Enterprise Manager, with user X having access to A1, H1, and D1 and user Y having access to A2, H2, and D2. Since each of the two Enterprise Manager users is monitoring the resources used for one of the applications, it may also make sense to have each user also monitor the application's clients. In that case, an Enterprise Manager super user would associate the "teaching" tag with A1, D1, or H1 and associate the "distribution" tag with A2, D2, or H2. This allows user X to see all client configurations with the "teaching" tag and user Y to see all configurations with the "distribution" tag.

18.6.5.2 Privilege Model for Viewing Client Configurations

Collection Tags are used to restrict access to client data in Enterprise Manager. A client configuration is visible to the user only if the Collection Tag for that configuration is associated with a target on which the user has View privileges. For example, if collection tag C is associated with target T1, then only those users that can view target T1 will be able to see client configurations that have tag X. In Example 18-2, user X will be able to see client configurations with the "teaching" tag because user X has view privileges on targets that are associated with the "teaching" tag. However, user X will not be able to see any client configurations with the "distribution" tag because that tag is not associated with any targets that user X can see. Super users can associate collection tags with targets by using the Collection Tag Associations page, which can be accessed from the Deployments tab or from the Client System Analyzer in Grid Control link on the Setup page. Super users can view all client configurations regardless of any collection tag associations.

18.6.5.3 Using the Customization API Example

If the administrator is interested in the user's settings for an e-mail client in addition to the normal CSA data, the administrator can add this information to the other data collected by CSA through the use of the customization API, as shown in Example 18-3.

  1. Create the Java classes required to gather the information. The administrator can create as many classes as necessary, but there must be at least one class that implements oracle.symsan.eml.ecm.csa.CSAResultInterface and one that implements oracle.sysman.eml.ecm.csa.CSACustomInteface, both of which are shown in Example 18-3. Assume that the former is acme.csa.custom and the latter is acme.csa.result.

  2. Set the value of the "customClass" parameter in CSA to "acme.csa.custom"

    Example 18-3 Customization API

    public interface CSACustomInterface {
     
        /**
         * requires: none
         * effects: returns a CSAResultInterface object that may contain custom
         * properties. Other effects are determined by the customActions method
         * in the implementing class
         * modifies: unknown - dependent on implementing class.
         * @param inputData contains client config data collected by default, plus
         * applet parameters, etc.None of the data in the inputData is guaranteed
         * to be there as there could have been collection errors. 
         * @return a data structure that may contain custom properties
         */
        CSAResultInterface customActions(CSAInputInterface inputData);
    }
     
    public interface CSAResultInterface {
     
        /**
         * requires: none
         * effects: returns an array of custom properties
         * modifies:none
         * @return String[][7] where ...
         *
         * String[i][0] is a name 
         * String[i][1] is a value of the i-th row. (Type and name must be unique.)
         * String[i][2] is a type/category of data (could be null),
         * String[i][3] is the displayed value of the name of the property
         * String[i][4] is the displayed value of the type of the property
         * String[i][5] indicates data item (ie "Y") whose history should be computed
         * String[i][6] indicates data item (ie "Y") should be displayed in default UI
         */
        String[][] getResultsData();
    }
     
    public interface CSAInputInterface {
     
        /**
        * Get data value for given name
        * requires: name is not null
        * effects: returns the data value associated with the name
        * modifies: none
        * @param name the name of the key whose value is to be returned
        * @return the value assocaited with name
        *
        */
        String getDataValue(String name);
     
        /**
        * Get table-formatted data.
        * requires: name is not null
        * effects: returns the table with this name
        * modifies: none
        * @param name the name of the table
        * @return the rows of the child tables
        *
        */
        CSAInputInterface[] getDataTable(String name);
    }
    

    The additional data collected by the custom code will be stored in the table MGMT_ECM_CSA_CUSTOM. To add data to this table, the custom code returns it in an object that implements CSAResultInterface. The custom code can also manipulate the normal data collected by CSA by modifying the CSAInputInterface object passed to the customActions method by the applet.

    Since the custom code is executed before rules are evaluated, the administrator can also write rules based on the custom data. For example, if the administrator wants to write a rule that raises a critical error if the user does not have the correct IMAP server set up his or her e-mail client, the administrator would write custom code that retrieves the IMAP server settings and stores in them in the MGMT_ECM_CSA_CUSTOM table and then writes a rule that checks these values.

18.6.5.4 Using the CSA Servlet Filter Example

Since CSA does not involve the use of a Management Agent on the user's machine, there is no way to keep the data in the Management Repository up to date unless end users run CSA periodically. One way to ensure that they do is to check whether or not users have run CSA recently, and if they have not, to inform them to run CSA again. This check can be accomplished using the CSA servlet filter provided by Oracle.

The CSA servlet filter works by checking the cookie that CSA sets in the user's browser whenever it runs. The payload of this cookie indicates the time at which CSA was last run. To use the filter, the administrator places it in front of some frequently accessed application, such as an employee portal. The administrator then sets the interval at which he or she wants users to run CSA. Whenever a user tries to connect to the portal application, the filter intercepts the request and checks the CSA cookie. If the cookie is not present or if it is older than the execution interval specified by the administrator, the user is directed to the CSA page; if not, the user is allowed to proceed to the application.

Assume that Acme Corporation has a CSA instance deployed at www.acme.com/csa/CSA.jsp. Assume also that the company has a portal at www.acme.com/portal that can be used by employees to check e-mail, access their personal information, or display news about the company. Because the portal is accessed frequently by employees, the administrator at Acme decides that the portal can be used to keep CSA data up to date. The administrator would take the following steps:

  1. Download the CSA servlet filter classes. These classes are contained in a JAR file, CSA_filter.jar, which can be downloaded from the "Deploy Client System Analyzer" page in the Enterprise Manager Grid Control Console.

  2. Place the JAR file in the WEB-INF/lib directory of the application to which the filter will be applied.

  3. Specify context parameters for the filter. In this case, the administrator wants users to run CSA every 30 days and return to the portal homepage after CSA has finished.

    <context-param>
      <param-name>csa csaURL</param-name>
     <param-value>www.acme.com/csa/CSA.jsp</param-value>
    </context-param>
     
    <context-param>
      <param-name>csa execInterval</param-name>
      <param-value>2592000</param-value>
    </context-param>
    
    

An alternative is to have CSA run in a separate browser window in the background. This can be set up by using the csa_uiMode parameter. If the parameter is set to 1, the filter will open a new browser window that is the same size as the original window and go to the CSA page. If the parameter is set to 2, CSA will run in "invisible" mode; in this case, the filter will open a new browser window and immediately minimize it, and it will close the window as soon as CSA has completed.

18.6.5.5 Sample Deployments

In the following sample deployment examples, there are three primary actors. The first is the CSA administrator, who is responsible for setting up CSA. The second is the Enterprise Manager user, who will be viewing the client data in Enterprise Manager. The third is the end user, whose data is being collected by CSA.

18.6.5.5.1 Example 1: Helpdesk

In this example, the CSA administrator is using CSA to support the operations of a helpdesk. End users who have problems running a particular application can call customer support, and the customer support technician can, if necessary, instruct the user to go to a particular URL and run CSA. The Enterprise Manager users are the support personnel who will use the data collected by CSA to assist the end user. To speed up the process of diagnosing the customer's problem, the CSA administrator creates some rules in a file called "rules.xml" so that the helpdesk personnel can quickly identify potential problems. In the simplest case, suppose that the helpdesk is being set up to provide support for a single application. The application is running on an application server on host application.acme.com, which has an Enterprise Manager Management Agent installed on it that sends data back to the Management Service at oms.acme.com/em. The helpdesk personnel who will be looking at client data can log into Enterprise Manager as the user "helpdesk," which does not have super user privileges.

  1. The CSA administrator adds rules.xml to the CSA.war file contained in CSA.ear.

  2. Deploy the EAR file to the application server using the Application Services Control Console.

  3. Use the Application Services Control Console to set the necessary context parameters, such as ruleFile and outputDir.

  4. Optionally, the administrator can choose a collection tag for the CSA data by specifying a value for the "application" context parameter. If no tag is chosen, the tag "Default" will be used.

  5. An Enterprise Manager user with super user privileges adds a CSA Collector Target to the Management Agent on application.acme.com and sets its receive file directory to the directory specified in the "outputDir" parameter of CSA.

  6. An Enterprise Manager superuser creates the collection tag associations needed to allow the helpdesk users to look at the data. For example, the superuser could associate the tag "Default" with host application.acme.com and then give the "helpdesk" Enterprise Manager user view privileges on the host.

With the setup previously described, when a user calls the helpdesk to ask for support with the application, the helpdesk technician can instruct the user to run CSA from the appropriate URL on application.acme.com. The Management Agent collects the data after a certain interval and loads it into the Management Repository. The helpdesk technician can then log into Enterprise Manager as "helpdesk" and find the customer's information by searching for an identifying field such as the customer's operating system user name or host name. By default, the Management Agent will check the output directory for new data every two minutes, but this interval can be shortened by editing the file $ORACLE_HOME/sysman/admin/default_collection/oracle_csa_collector.xml.

18.6.5.5.2 Example 2: Inventory

In Example 18-4, a system administrator is in charge of keeping track of the hardware and software used by employees in two different departments, Human Resources (HR) and Sales. This administrator serves as both the Enterprise Manager user and the CSA administrator. The setup for this case is similar to the one described in the example on using servlet filters, but in this case, each department has its own portal application, at hr.acme.com/portal and sales.acme.com/portal, respectively. The administrator sets up an application server on host server1.acme.com and deploys CSA with the URL http://server1.acme.com/csa/CSA.jsp. A Management Agent on server1.acme.com collects data and sends to a Management Server at oms.acme.com/em. The administrator would like to collect data once every 30 days and to have CSA run in invisible mode. The administrator would also like to distinguish data from the two different departments by using two separate collection tags, "hr" and "sales." The administrator can log into Enterprise Manager as sysman and will thus be able to see clients with both tags.

The administrator arranges to have users directed to CSA by deploying the CSA servlet filter on both applications. Most of the filter context parameters for the two applications will be identical. However, because each application corresponds to a different tag, the values of the "csa csaURL" parameter will be slightly different. For the HR portal, the value would be http://server1.acme.com/csa/CSA.jsp?application=hr, and for the sales portal, the value would be http://server1.acme.com/csa/CSA.jsp?application=sales.

Example 18-4 Inventory Code

<context-param>
  <param-name>csa csaURL</param-name>
 <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value>
</context-param>
 
<context-param>
  <param-name>csa execInterval</param-name>
  <param-value>2592000</param-value>
</context-param>
 
<context-param>
  <param-name>csa uiMode</param-name>
  <param-value>2</param-value>
</context-param>

Under this setup, users in the HR department who are directed to CSA from the HR portal will have the tag "hr," and users from the sales department will have the tag "sales". Thus, if the administrator wants to see information about only hardware on machines in the HR department, he or she can simply use the "Collection Tag" filter on the Client Configurations page in Enterprise Manager and set it to "hr".

18.6.5.5.3 Example 3: Problem Detection

In this example, the goal is to use CSA to inform end users of potential problems they may experience while running an application. The setup is similar to the one used in Example 2. In this example, however, the CSA administrator creates rules for each application. In addition, the administrator wants CSA to run in the original browser window to ensure that end users are aware of any potential problems.

Example 18-5 displays the context parameter values for the CSA servlet filter on the sales portal.

Example 18-5 Context Parameter Values for CSA Servlet Filter

<context-param>
  <param-name>csa csaURL</param-name>
 <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value>
</context-param>
 
<context-param>
  <param-name>csa execInterval</param-name>
  <param-value>2592000</param-value>
</context-param>
 
<context-param>
  <param-name>csa uiMode</param-name>
  <param-value>0</param-value>
</context-param>

Example 18-6 represents the context parameter definitions to map rules to collection tags.

Example 18-6 Context Parameter Definitions Mapping Rules to Collection Tags

<context-param>
  <param-name>csa sales ruleFile</param-name>
  <param-value>sales_rules.xml</param-value>
</context-param>
 
<context-param>
  <param-name>csa distribution ruleFile</param-name>
  <param-value>hr_rules.xml</param-value>
</context-param>

18.7 Setting Up and Configuring a Software Library With Oracle Enterprise Manager

The following sections describe how to set up and configure a software library using Oracle Enterprise Manager.

18.7.1 Setting Up a Software Library

The software library should be located in a directory accessible by all Oracle Management Servers (OMS). If there is only one OMS, the directory can be local. For multiple OMS environments, the directory can ge on a Network File Server accessible from all Oracle Management Servers. You should ensure that there is sufficient space available on the shared storage to store file that hold the binary data for all of the components.

If you create operating system components, TAR files containing all the RPMs for a Linux installation will be stored in the software library. If you create Oracle database components, TAR files containing all the files from a reference Oracle home directory or contents from the installable media will be stored in the software library.

You should ensure that the shared storage is accessible through NFS mount points to all Oracle Management Servers in the environment.

18.7.2 Configuring a Software Library

The graphical user interface of the Provisioning application shows various tabs for Components, Directives, and Images. You can access all of the tabs depending on the privileges assigned to you. For example, if you have superuser privileges, you can access the Administration tab. The Administration tab contains different sections that you can use to configure various elements in the environment.

To configure a software library, follow these steps:

  1. In the Software Library Configuration section of the Administration tab of the Provisioning application, press the Add button.

  2. On the Add Software Library Location page, enter the directory location of the software library you are creating and then click OK.

18.7.3 Deleting or Cleaning Up a Software Library

To delete the software library , select the software library from the Administration tab and click Remove to delete it.

To delete the components of a software library, select the components from the software library and choose Delete. This will remove the components. To clean up the delete components completely from the File System , you must run the following command:

<OMS HOME>/bin/purgeDeploymentLibrary <conn string> <username> <password> [-job <oms_host>

The options for this command are listed below:

<conn string> is of form: "jdbc:oracle:thin:@dbhost:dbport:sid" where dbhost, dbport and sid should be replaced appropriately

<username> is repository username

<password> is repository passwd

[-job <oms_host>] is optional; if provided a job would be submitted (schedule is immediate). The user can view the status of the job by navigating to the Jobs page on the Enterprise Manager console.

<oms_host> is OMS hostname

[
PKؿwo[PK^UIOEBPS/firewalls.htm Configuring Enterprise Manager for Firewalls

6 Configuring Enterprise Manager for Firewalls

Firewalls protect a company's Information Technology (IT) infrastructure by providing the ability to restrict network traffic by examining each network packet and determining the appropriate course of action.

Firewall configuration typically involves restricting the ports that are available to one side of the firewall, for example the Internet. It can also be set up to restrict the type of traffic that can pass through a particular port such as HTTP. If a client attempts to connect to a restricted port (a port not covered by a security "rule") or uses a protocol that is incorrect, then the client will be disconnected immediately by the firewall. Firewalls can also be used within a company Intranet to restrict user access to specific servers.

You can deploy the components of Oracle Enterprise Manager on different hosts throughout your enterprise. These hosts can be separated by firewalls. This chapter describes how firewalls can be configured to allow communication between the Enterprise Manager components.


See Also:

Chapter 3 for more information about some of the ways you can configure the Grid Control components on your network

This chapter contains the following topics:

6.1 Considerations Before Configuring Your Firewall

Firewall configuration should be the last phase of Enterprise Manager deployment. Before you configure your firewalls, make sure you are able to log in to the Grid Control Console and that your Management Agents are up and monitoring targets.

If you are deploying Enterprise Manager in an environment where firewalls are already installed, open the default Enterprise Manager communication ports for all traffic until you have completed the installation and configuration processes and are certain that you are able to log in to the Oracle Enterprise Manager 10g Grid Control Console and that your Oracle Management Agents are up and monitoring targets.

The default communication ports for Enterprise Manager are assigned during the installation. If you modify the default ports, be sure to use the new port assignments when you configure the firewalls.


See Also:

Chapter 12, "Reconfiguring the Management Agent and Management Service" for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent

If you are enabling Enterprise Manager Framework Security for the Management Service, the final step in that configuration process is to restrict uploads from the Management Agents to secure channels only. Before completing that step, configure your firewalls to allow both HTTP and HTTPS traffic between the Management Agent and Management Repository and test to be sure that you can log in to Enterprise Manager and that data is being uploaded to the Management Repository.

After you have confirmed that the Management Service and Management Agents can communicate with both protocols enabled, complete the transition to secure mode and change your firewall configuration as necessary. If you incrementally configure your firewalls, it will be easier to troubleshoot any configuration problems.

6.2 Firewall Configurations for Enterprise Management Components

Your main task in enabling Enterprise Manager to work in a firewall-protected environment is to take advantage of proxy servers whenever possible, to make sure only the necessary ports are open for secure communications, and to make sure that only data necessary for running your business is allowed to pass through the firewall.

The following sections describe the ports and types of data required by Enterprise Manager in a secure, firewall-protected environment:

6.2.1 Firewalls Between Your Browser and the Grid Control Console

Connections from your browser to the Oracle Enterprise Manager 10g Grid Control Console are performed over the default port used for your Oracle HTTP Server.

For example, the default, non-secure port for the Oracle HTTP Server is usually port 7778. If you are accessing the Grid Control Console using the following URL and port, then you must configure the firewall to allow the Grid Control Console to receive HTTP traffic over port 7778:

http://mgmthost.acme.com:7778/em

On the other hand, if you have enabled security for your Oracle HTTP Server, you are likely using the default secure port for the server, which is usually port 4443. If you are accessing the Grid Control Console using the following URL and port, then you must configure the firewall to allow the Grid Control Console to receive HTTP traffic over port 4443:

https://mgmthost.acme.com:4443/em

Figure 6-1 shows the typical configuration of a firewall between your browser and the Grid Control Console Web-based console that is rendered by the Management Service.

Figure 6-1 Firewall Between Your Browser and the Grid Control Console

Description of Figure 6-1 follows

6.2.2 Configuring the Management Agent on a Host Protected by a Firewall

If your Management Agent is installed on a host that is protected by a firewall and the Management Service is on the other side of the firewall, you must perform the following tasks:

  • Configure the Management Agent to use a proxy server for its uploads to the Management Service.

  • Configure the firewall to allow incoming HTTP traffic from the Management Service on the Management Agent port. Regardless of whether or not Enterprise Manager Framework Security has been enabled, the default port is 3872. If this default port is not available, the default port range between 1830 - 1849 is used. Incoming traffic can be received only if the port corresponding to the Management Agent is open in the firewall.

Figure 6-2 illustrates the connections the Management Agent must make when it is protected by a firewall.

Figure 6-2 Configuration Tasks When the Management Agent Is Behind a Firewall

Description of Figure 6-2 follows

6.2.2.1 Configuring the Management Agent to Use a Proxy Server

You can configure the Management Agent to use a proxy server for its communications with a Management Service outside the firewall, or to manage a target outside the firewall.

  1. Use a text editor to open the following Management Agent configuration file:

    AGENT_HOME/sysman/config/emd.properties (UNIX)
    AGENT_HOME\sysman\config\emd.properties (Windows)
    
    
  2. Locate the following entry in the emd.properties file:

    # If it is necessary to go through an http proxy server to get to the
    # repository, uncomment the following lines
    #REPOSITORY_PROXYHOST=
    #REPOSITORY_PROXYPORT=
    
    
  3. To enable support for authenticating the proxy server, the following additional properties need to be specified.

    #REPOSITORY_PROXYREALM=
    #REPOSITORY_PROXYUSER=
    #REPOSITORY_PROXYPWD=
    
    
  4. Edit the following properties by removing the pound sign (#) at the start of each line and entering a value as follows:

    # If it is necessary to go through an http proxy server to get to the
    # repository, uncomment the following lines
    REPOSITORY_PROXYHOST=proxyhostname.domain
    REPOSITORY_PROXYPORT=proxy_port
    REPOSITORY_PROXYREALM=realm
    REPOSITORY_PROXYUSER=proxyuser
    REPOSITORY_PROXYPWD=proxypassword
    
    

    For example:

    REPOSITORY_PROXYHOST=proxy42.acme.com
    REPOSITORY_PROXYPORT=80
    REPOSITORY_PROXYREALM=
    REPOSITORY_PROXYUSER=
    REPOSITORY_PROXYPWD=
    
    
  5. Save your changes and close the emd.properties file.

  6. Stop and start the Management Agent.


Note:

The proxy password will be rewritten when you restart the Management Agent.

6.2.2.2 Configuring the Firewall to Allow Incoming Communication From the Management Service

While the Management Agents in your environment must upload data from your managed hosts to the Management Service, the Management Service must also communicate with the Management Agents. As a result, if the Management Agent is protected by a firewall, the Management Service must be able to contact the Management Agent through the firewall on the Management Agent port.

By default, the Enterprise Manager installation procedure assigns port 1830 to the Management Agent. However, if that port is occupied, the installation may assign an alternate port number.


Note:

The port number for the Management Agent does not change when you enable Enterprise Manager Framework Security. For more information, see "Configuring Security for Grid Control"

In addition, administrators can change the Management Agent port after the installation.


See Also:

"Chapter 12, "Reconfiguring the Management Agent and Management Service" for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent.

After you determine the port number assigned to the Management Agent, you must then configure the firewall to allow incoming HTTP or HTTPS traffic (depending upon whether or not you have enabled Enterprise Manager Framework Security) on that port.


See Also:

Your firewall documentation for more information about opening specific ports for HTTP or HTTPS traffic.

"Configuring Security for Grid Control" for information about Enterprise Manager Framework Security


6.2.3 Configuring the Management Service on a Host Protected by a Firewall

If your Management Service is installed on a host that is protected by a firewall and the Management Agents that provide management data are on the other side of the firewall, you must perform the following tasks:

  • Configure the Management Service to use a proxy server for its communications to the Management Agents.

  • Configure the firewall to allow incoming HTTP traffic from the Management Agents on the Management Repository upload port.

    If you have enabled Enterprise Manager Framework Security, the upload URL uses port 1159 by default. If this port is not available, Enterprise Manager will default to first available port in the range 4898-4989. If you have not enabled Enterprise Manager Framework Security, the upload port is the first available port in the range 4889 - 4897.

Figure 6-3 illustrates the connections the Management Agent must make when it is protected by a firewall.

Figure 6-3 Configuration Tasks When the Management Service Is Behind a Firewall

Description of Figure 6-3 follows

6.2.3.1 Configuring the Management Service to Use a Proxy Server

This section describes how to configure the Management Service to use a proxy server for its communications with Management Agents outside the firewall.


Note:

The proxy configuration properties described in this section are the same Management Service properties you must modify if your network is protected by a firewall and you want Enterprise Manager to search automatically for critical patches and patch sets. For more information, see "Specifying Patching Credentials" in the Enterprise Manager online help.

To configure the Management Service to use a proxy server:

  1. Use a text editor to open the following configuration file in the Management Service home directory:

    ORACLE_HOME/sysman/config/emoms.properties
    
    
  2. Add the following entries to emoms.properties file:

    proxyHost=proxyhost.domain
    proxyPort=proxy_port
    dontProxyFor=.domain1, .domain2, .domain3, ...
    proxyRealm=realm
    proxyUser=proxyuser
    proxyPwd=proxypassword
    

    For example:

    proxyHost=proxy42.acme.com
    proxyHost=80
    dontProxyFor=.acme.com, .acme.us.com
    proxyRealm
    proxyUser
    proxyPwd
    

    The dontProxyFor property identifies specific URL domains for which the proxy will not be used. The proxyRealm property indicates the protected space that requires authentication.


    See Also:

    "About the dontProxyfor Property" for guidelines on when to use the dontProxyFor property

  3. Save your changes and close the emoms.properties file.

  4. Stop and start the Management Service:

    $PROMPT> ORACLE_HOME/bin/emctl stop oms
    $PROMPT> ORACLE_HOME/bin/emctl start oms
    

    Note:

    The proxy password will be rewritten when you restart the Management Service.

6.2.3.2 About the dontProxyfor Property

When you configure the Management Service to use a proxy server, it is important to understand the purpose of the dontProxyFor property, which identifies specific URL domains for which the proxy will not be used.

For example, suppose the following were true:

  • You have installed the Management Service and several Management Agents on hosts that are inside the company firewall. These hosts are in the internal .acme.com and .acme.us.com domains.

  • You have installed several additional Management Agents on hosts that are outside the firewall. These hosts are installed in the .acme.uk domain.

  • You have configured Enterprise Manager to automatically check for critical software patches on the OracleMetaLink Internet site.

In this scenario, you want the Management Service to connect directly to the Management Agents inside the firewall without using the proxy server. On the other hand, you want the Management Service to use the proxy server to contact the Management Agents outside the firewall, as well as the OracleMetaLink Internet site, which resides at the following URL:

http://metalink.oracle.com

The following entry in the emoms.properties file will prevent the Management Service from using the proxy server for connections to the Management Agents inside the firewall. Connections to OracleMetaLink and to Management Agents outside the firewall will be routed through the proxy server:

proxyHost=proxy42.acme.com
proxyHost=80
dontProxyFor=.acme.com, .acme.us.com

6.2.3.3 Configuring the Firewall to Allow Incoming Management Data From the Management Agents

While the Management Agents in your environment must contact the Management Agents on your managed hosts, the Management Service must also be able to receive upload data from the Management Agents. If the Management Service is behind a firewall, you must configure the firewall to allow the Management Agents to upload data on the upload port.

By default, the Enterprise Manager installation procedure assigns port 4889 as the Repository upload port. However, if that port is occupied, the installation will assign an alternate port number.

In addition, when you enable Enterprise Manager Framework Security, the upload port is automatically changed to the secure 1159 HTTPS port.


See Also:

"Configuring Security for Grid Control" for information about Enterprise Manager Framework Security

Administrators can also change the upload port after the installation.


See Also:

Chapter 12, "Reconfiguring the Management Agent and Management Service" for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent.

After you determine the port number assigned to the Management Service upload port, you must then configure the firewall to allow incoming HTTP or HTTPS traffic (depending upon whether or not you have enabled Enterprise Manager Framework Security) on that port.


See Also:

Your firewall documentation for more information about opening specific ports for HTTP or HTTPS traffic

6.2.4 Firewalls Between the Management Service and the Management Repository

Secure connections between the Management Service and the Management Repository are performed using features of Oracle Advanced Security. As a result, if the Management Service and the Management Repository are separated by a firewall, you must configure the firewall to allow Oracle Net firewall proxy access.


See Also:

"Configuring Secure Sockets Layer Authentication" in the Oracle Database Advanced Security Administrator's Guide

Figure 6-4 shows a typical configuration of a firewall between the Management Service and the Management Repository.

Figure 6-4 Firewall Between the Management Service and the Management Repository

Description of Figure 6-4 follows

6.2.5 Firewalls Between the Grid Control and a Managed Database Target

When you are using the Grid Control Console to manage a database, you must log in to the database from the Grid Control Console in order to perform certain monitoring and administration tasks. If you are logging in to a database on the other side of a firewall, you will need to configure the firewall to allow Oracle Net firewall proxy access.

Specifically, to perform any administrative activities on the managed database, you must be sure that the firewall is configured to allow the Oracle Management Service to communicate with the database through the Oracle Listener port.

You can obtain the Listener port by reviewing the Listener home page in the Grid Control Console.

Figure 6-5 shows a typical configuration of a firewall between the Management Service and the Management Repository.

Figure 6-5 Firewall Between the Grid Control and a Managed Database Target

Description of Figure 6-5 follows

6.2.6 Firewalls Used with Multiple Management Services

Enterprise Manager supports the use of multiple Management Services that communicate with a common Management Repository. For example, using more than one Management Service can be helpful for load balancing as you expand your central management capabilities across a growing e-business enterprise.

When you deploy multiple Management Services in an environment protected by firewalls, be sure to consider the following:

  • Each Management Agent is configured to upload data to one Management Service. As a result, if there is a firewall between the Management Agent and its Management Service, you must configure the firewall to allow the Management Agent to upload data to the Management Service using the upload URL.

  • In addition, each Management Service must be able to contact any Management Agent in your enterprise so it can check for the availability of the Management Agent. As a result, you must be sure that your firewall is configured so that each Management Service you deploy can communicate over HTTP or HTTPS with any Management Agent in your enterprise.

    Otherwise, a Management Service without access to a particular Management Agent may report incorrect information about whether or not the Management Agent is up and running.


    See Also:

    "About Availability" in the Enterprise Manager online help for information about how Enterprise Manager determines host and Management Agent availability

6.2.7 Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

Oracle Beacons provide application performance availability and performance monitoring. They are part of the Application Performance Management features of Enterprise Manager.


See Also:

"About Application Performance Management" in the Enterprise Manager Online Help

Enterprise Manager uses the industry-standard Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP) to transfer data between Beacon and the network components you are monitoring. There may be situations where your Web application components and the Beacons you use to monitor those components are separated by a firewall. In those cases, you must configure your firewall to allow ICMP, UDP, and HTTP traffic.

6.2.8 Configuring Firewalls When Managing Oracle Application Server

If you are using Grid Control to manage instances of Oracle Application Server, there may be other ports that you need to access through a firewall, depending upon your configurations.

For example, when you are monitoring the performance of your Oracle Application Server instance from the Grid Control Console, you can click Administer on the Application Server Home page to display the Application Server Control Console. If the Oracle Application Server target you are monitoring is separated from the Grid Control Console by a firewall, you will need to configure the firewall to allow an HTTP or HTTPS connection through Application Server Control Console port (usually, 1810).


See Also:

Oracle Application Server Administrator's Guide for more information about configuring ports for Oracle Application Server

6.3 Viewing a Summary of the Ports Assigned During the Application Server Installation

As described in the previous sections of this chapter, it is important to understand and identify the ports used by each of the Oracle Enterprise Manager 10g components before you configure your firewalls.

When you install the Oracle Application Server 10g or the Oracle Enterprise Manager 10g Grid Control, you can view a list of the ports assigned during the application server installation by viewing the contents of the following file

ORACLE_HOME/install/portlist.ini

Note:

The portlist.ini file lists the port numbers assigned during the installation. This file is not updated if port numbers are changed after the installation.

In addition, you can use the Application Server Control Console to view a list of all the ports in use by the application server:

  1. Navigate to the Application Server home page in the Application Server Control Console.

  2. Click Ports.


See Also:

"Viewing and Modifying Application Server Port Assignments" in the Enterprise Manager online help

6.4 Additional Considerations for Windows XP

For secure agent install, ensure that the firewall settings are disabled for HTTP/HTTPS communication for Windows XP:

  1. Go to Start, and then select Control Panel.

  2. In Control Panel, click Windows Firewall.

  3. In the Exceptions tab in the Windows Firewall dialog box, click Add Port.

  4. In the Add a Port dialog box, specify the name and number of the port.

  5. Click Change scope to specify the computers for which the port is unblocked.

PK/\RPK^UI OEBPS/toc.htm Table of Contents

Contents

Preface

1 Introduction to Enterprise Manager Advanced Configuration

2 Starting and Stopping Enterprise Manager Components

3 Grid Control Common Configurations

4 Configuring Oracle Enterprise Manager for Active and Passive Environments

5 Enterprise Manager Security

6 Configuring Enterprise Manager for Firewalls

7 Configuring Services

8 Locating and Configuring Enterprise Manager Log Files

9 Maintaining and Troubleshooting the Management Repository

10 Using Enterprise Manager For Grid Automation With Deployment Procedures

11 Sizing and Maximizing the Performance of Oracle Enterprise Manager

12 Reconfiguring the Management Agent and Management Service

13 Configuring Notifications

14 User-Defined Metrics

15 Using a Software Library

16 Configuring Remedy Connector

17 Configuring Microsoft Operations Management Connector

18 Additional Configuration Tasks

A Out-Of-Box RuntimeData Templates

B Sample Property Files for the Out-of-Box RuntimeData Templates

Index

PK2FPK^UI OEBPS/mom.htmjl Configuring Microsoft Operations Management Connector

17 Configuring Microsoft Operations Management Connector

Microsoft Operations Management Connector enables Oracle Enterprise Manager to retrieve alerts from Microsoft Operations Manager (MOM). The retrieved alerts are stored in the Enterprise Manager repository and displayed through the Enterprise Manager console.

This chapter provides the following information on setting up and configuring MOM Connector:

17.1 Introduction to MOM Connector

MOM Connector retrieves data through Web Services on HTTP and HTTPS protocols. The retrieval is done through a polling mechanism. The polling interval is user-definable. The polling interval cannot be shorter than 5 minutes. If an interval shorter than 5 minutes is defined, then it defaults to 5 minutes.

The default target_type defined in Enterprise Manager is mom_managed_host. The retrieved alerts are stored in the default target instance generic_mom_managed_host. You can create more target instances based on your requirements. See "Configuring the MOM Connector".

17.2 Installing MOM Connector

MOM Connector is installed as part of the Enterprise Manager base installation. After you install Enterprise Manager, you should see the MOM Connector listed on the Management Connectors page.


See Also:

Enterprise Manager Grid Control Installation and Basic Configuration Guide available at: http://www.oracle.com/technology/documentation/oem.html

17.3 Prerequisites

Before using MOM Connector, ensure that the following pre-requisites are met:

17.4 Configuring the MOM Connector

  1. From the Enterprise Manager console, click Setup.

  2. Click Management Connectors link in the left pane.

    The Management Connector Setup page appears. For the MOM Connector row, the Configured column should be blank (Figure 17-1).


    Note:

    A check mark in the Configured column indicates that the Connector is already configured.

  3. Click the Configure icon for the MOM Connector.

    The General tab of the Configure Management Connector page appears.

  4. Provide the required settings. See "General Settings" for details (Figure 17-2).

  5. Click OK.

  6. (Optional) Go to the Targets tab and specify the details for creating additional target instances. See "Additional Target Instances" for details.

  7. Click OK.

    The Management Connector Setup page reappears.

    The MOM Connector row should have a check mark in the Configured column.

    Figure 17-1 Management Connectors Page

    Surrounding text describes Figure 17-1 .

    Figure 17-2 Configure Management Connector Page

    Surrounding text describes Figure 17-2 .

17.4.1 General Settings

This section provides the communication details required for configuring the connector.

  • MOM Registered Connector Name — Specify the connector name that you want to register with MOM. This is the name that MOM administrator identifies for marking alerts to Enterprise Manager. Ensure that the name you provide is unique in MOM.

  • Resolution State — Specify a value between 1 and 255. Make sure that you do not specify a value already in use including the standard values such as 85 or 255.

    The default value for MOM Connector is 218.

  • Protocol — Select either HTTP or HTTPS based on the protocol MOM Web services are running on.

  • Server — Enter the IP address or the DNS name of the MOM server.

  • Port — Enter the port number used by the MOM Web server. The default is 1271.

    In the case of HTTPS connection, you must change the port to the HTTPS port enabled in MOM.

  • Service Name — Enter the MOM Web service name. The default is ConnectorServiceV2.asmx. In most cases, you need not change this.

  • Polling Interval — Enter the time interval between event collections.

  • Enterprise Manager Username — Enter the username to be used to insert alerts, for example, SYSMAN. The user must have full privilege on the target of type MOM Managed Host.

    Administrator privileges are recommended, for instance you should be a super user such as SYSMAN.

  • Enterprise Manager Password — Enter a password for the username you specified.

17.4.2 Additional Target Instances

When you deploy or install a MOM Connector, a default target instance generic_mom_managed_host is created. In addition, you can create specific target instances.

Alert gets assigned to the respective targets based on the computer name in MOM. If the name specified under Computer column in the MOM Operator console matches the target name you specify in the Target Name column in the section "Targets Managed by External System", then the alert will be assigned to that target.

If the target does not exist, then the alert will be assigned to the default target instance.

In the Configure Management Connector page, click the Targets tab to create specific target instances. Figure 17-3 shows the Configure Management Connector Target page.

Default Connector Target

The default target instance holds external alerts that are not associated with any particular Enterprise Manager target. Oracle recommends that you do not remove this default connector target when you create additional targets.

If the default target is removed accidentally, you can recreate it by clicking the Enable button in the Targets tab of the Configure Management Connector page.

If the default target is removed, for alerts that cannot be mapped to any target, error messages are logged in the file emoms.log.

Targets Managed by External System

(Optional) In this section, you can create target instances and allow external alerts to be associated with those target instances.

To add a new target,

  1. Specify the target name in the Target Name column.

  2. In the MOM HOSTNAME column, specify the fully qualified hostname (hostname along with the domain name, for example smp-mpi2.us.oracle.com) of the target.

  3. Click OK.


Note:

If you want to create more target instances, then click Add Rows to add additional rows and then specify the target information. To remove a target, check the Select check box corresponding to the target, click Remove, then click OK.

Figure 17-3 Configure Management Connector Target Page

Surrounding text describes Figure 17-3 .

17.4.2.1 Response Status of Targets

The response status of generic_mom_managed_host asserts whether the MOM server is running. Immediately after registration, the status shows Pending.

After you configure the MOM Connector and the first event collection job is run (within a polling interval), the status shows either Up or Down. The response status of individual targets represent whether the host (represented by that target) is up or down.When the target is created, Enterprise Manager pings the host. If the server is reachable, the status is marked Up. Subsequently, if Enterprise Manager receives any alerts (indicating that the host is down), then it marks the target as Down.

If the target is down, then alert retrieval is interrupted until the target is up again.


Note:

In Enterprise Manager, the response status of targets managed by MOM might not be definitive and can be used only for reference purposes. For accurate information of its managed entities, use MOM.

17.5 Enabling SSL Connection for HTTPS

Follow the steps provided in this section if you choose HTTPS as the protocol to establish a connection between MOM and Enterprise Manager.

17.5.1 Generating a Certificate Request File

Generate a certificate request file from the MOM server by doing the following:

  1. On the Windows task bar, go to Start, then click Run.

  2. Type inetmgr in the Open field.

    The Internet Information Services (IIS) Manager screen appears.

  3. In the left pane, navigate to Web Sites and select the Microsoft Operations Manager 2005 connector framework.

  4. Right-click and select Properties.

    The Microsoft Operations Manager 2005 Connector Framework Properties dialog box appears.

  5. In the Directory Security tab, go to the Secure Communications section and click Server Certificate.

  6. Using the wizard, create a new certificate.


    Note:

    When you specify details for certificate generation, do not use abbreviated forms for city and state names as the wizard does not recognize abbreviations. For example, CA is not accepted for California.

  7. At the completion of the wizard, a text file, certreq.txt is generated.

  8. Send this request file to the Certificate authority, for example VeriSign.

17.5.2 Using the Certificate from the Certificate Authority

After processing your request, the certificate authority sends you the certificate. After you receive the certificate, do the following:

  1. Paste the content in to a text file.

    The content looks like the following:

    -----BEGIN CERTIFICATE-----
    MIICdzCCAV8CAQAwDQYJKoZIhvcNAQEEBQAwITELMAkGA1UEBhMCVVMxEjAQBgNVBAMMCXJvb3Rf
    dGVzdDAeFw0wNjExMTAxMDI5MzJaFw0xNjExMDcxMDI5MzJaMGYxCzAJBgNVBAYTAlVTMQ4wDAYD
    VQQIEwVUZXhhczEPMA0GA1UEBxMGRGFsbGFzMQ8wDQYDVQQKEwZvcmFjbGUxCzAJBgNVBAsTAkVN
    MRgwFgYDVQQDEw9zbXAtbXBpMi1vcmFwa2kwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOch
    GIHp6MFW78OQw/mSdU0xfVq5u9pgqndnTqoh4aGFg1bTZD6/Azf3Nn8ibtKVJmGp3PLa3xP/gk7S
    tjZ/9sM4bvnw0Y4U9xsj0BiDG4JBo35uXAUxDHLReh8F4x45Wtv/SxvE0tjNnESlBMYynLip7P9l
    fSzcGKjSViyFW9M9AgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAIktFTvDs7ULf0PclYXsJPeK4vFq
    7HZ86omktA9lYS+oA6SaudwDGY5yxcl9O2s78o+EK9e8Wz4wM4dmUg4aSuHVHWs75W86uh7gpEFo
    wssH9mtcxkqIbdPVwQoeAUTVOifNaujfXtgClvlvOjkfzvvD7SieRjD9mP2rJ2pRWUbv7xR7oJmt
    RXp6t22a+MKMQQR8ofAZV/WxFJcgmBR/JxLA28X+jnzmIH/yqHK/b6Agwwy7PgbJrwPI7WQ/busm
    6ASeV8ZgSfAkJ83nWz4NICnH5Y8Dyu8vDtERsOQ8z/WttrBDEmcGikkO9P+o2Y9w1pEJQhh4bKtD
    PyO9YLmlrLM=
    -----END CERTIFICATE-----
    
  2. Save the file as cert.cer.

  3. On the Windows task bar, go to Start, then click Run.

  4. Type inetmgr in the Open field.

    The Internet Information Services (IIS) Manager screen appears.

  5. In the left panel, navigate to Web Sites and select the Microsoft Operations Manager 2005 connector framework.

  6. Right-click and select Properties.

    The Microsoft Operations Manager 2005 Connector Framework Properties dialog box appears.

  7. In the Directory Security tab, go to the Secure Communications section, and click Server Certificate.

    Add the certificate file to the server.

17.5.3 Adding Signed Certificates to Wallet Manager


Note:

Oracle Wallet Manager is available at $ORACLE_HOME/bin on OMS. See Oracle Application Server Administrator's Guide for details.

  1. Create a wallet using orapki utility by using the following command:

    orapki wallet create -wallet client -auto_login


    Note:

    orapki is available at $ORACLE_HOME/bin on OMS.

  2. Add the trusted certificate to the wallet by using the following command:

    orapki wallet add -wallet client -trusted_cert -cert verisignCert.cer

  3. To view the content of the wallet, run the following command:

    orapki wallet display -wallet client

    Ensure that a file named ewallet.p12 is available.

  4. In the Oracle Wallet Manager, open the client certificate ewallet.p12.

  5. Go to Select Trusted Certificates and select Operations on the main menu.

  6. Select Export All Trusted Certificates.

  7. Save the file as certdb.txt.

  8. Place the certdb.txt in the connector home root directory ($OMS_HOME/sysman/connector).

    If the file certdb.txt already exists in the connector home root directory, then open the file and add the contents in your certdb.txt to the existing content.

Now this file can be used by the Java SSL for communication between Enterprise Manager and MOM server in HTTP mode.


See Also:

For information on creating wallet, see "Creating and Viewing Oracle Wallets with orapki" in the Oracle Database Advanced Security Administrator's Guide, 10g Release 2 (10.2).

17.6 MOM Connector Tips

This section provides various tips that might help you in resolving issues you encounter while configuring or using the MOM Connector.

17.6.1 Recommended Protocol

Oracle recommends that you use HTTPS as the protocol for the communication between Enterprise Manager and MOM.

Use HTTP only if a secure connection is not required and the data can be transferred in clear text between the two systems.

In the case of HTTPS connection, you need to change the port to the HTTPS port enabled in MOM. Because Enterprise Manager polls data from MOM to Enterprise Manager, this means configuring MOM in HTTPS mode.

17.6.2 Connector Configuration Fails

If the connector configuration fails, then ensure the following in the MOM Administrator Console:

  • Resolution state is not already in use

  • Connector name is unique

17.6.3 MOM Connector Fails to Retrieve Alerts

Ensure the following if Enterprise Manager fails to retrieve alerts although MOM server is marked for forwarding alerts:

  • Valid resolution state is correctly marked

  • Connector is not accidentally disabled on MOM server

  • Enterprise Manager username and password that you specified in the MOM Configuration page are valid.

17.6.4 Alert Logging to Additional Target Instance Fails

Even if you define additional target instances, alerts are logged to the default target instance if the target name has characters with case mis-match.

The target name is case-sensitive and therefore should match the case of the target name in the Enterprise Manager.

17.6.5 Adding Targets in the Same Transaction

You cannot delete and add the same target in the same transaction.

17.6.6 Polling Interval

The value of polling interval is in minutes. The minimum value is 5 minutes. If you specify a shorter polling interval, then it will default to 5 minutes.

17.6.7 Alerts per Polling

Processing Capability

Connector can process alerts up to twenty times the value of the polling interval at an instance.

For example, if Schedule Interval is 5, then the maximum number of alerts retrieved is 100 (20*5). This is also the default value.This number need not be the same as the maximum number of alerts the connector is capable of requesting from MOM.

Modifying the Processing Capability

The maximum number of alerts the connector is capable of requesting from MOM depends on the number you specify in the files generic_request_newalerts.xml and generic_request_updatedalerts.xml.

For example, if you have specified 100 (<maxCount>100</maxCount>), then the Connector can request up to 100 alerts at an instance.

To optimize the network usage, Oracle recommends that you set the maximum value for both the processing and the requesting capabilities as the same.

17.6.8 Metric/Target Does Not Exist

Target

If target does not exist, then the alert is assigned to generic_mom_managed_host.

Metric

If the metric does not exist, then Enterprise Manager creates one.

Generic MOM Target

If the alert does not match any target and the generic MOM target (generic_mom_managed_host) does not exist, then the alerts are discarded and a message is logged to the log file.

PK:/oljlPK^UI OEBPS/toc.ncx& Oracle® Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0) Cover Title and Copyright Information Contents Preface 1 Introduction to Enterprise Manager Advanced Configuration 2 Starting and Stopping Enterprise Manager Components 3 Grid Control Common Configurations 4 Configuring Oracle Enterprise Manager for Active and Passive Environments 5 Enterprise Manager Security 6 Configuring Enterprise Manager for Firewalls 7 Configuring Services 8 Locating and Configuring Enterprise Manager Log Files 9 Maintaining and Troubleshooting the Management Repository 10 Using Enterprise Manager For Grid Automation With Deployment Procedures 11 Sizing and Maximizing the Performance of Oracle Enterprise Manager 12 Reconfiguring the Management Agent and Management Service 13 Configuring Notifications 14 User-Defined Metrics 15 Using a Software Library 16 Configuring Remedy Connector 17 Configuring Microsoft Operations Management Connector 18 Additional Configuration Tasks A Out-Of-Box RuntimeData Templates B Sample Property Files for the Out-of-Box RuntimeData Templates Index Copyright PKL`+&PK^UI$OEBPS/appndx_b_sample_prop_files.htmA* Sample Property Files for the Out-of-Box RuntimeData Templates

B Sample Property Files for the Out-of-Box RuntimeData Templates

This appendix displays sample property files for out-of-box RuntimeData templates. The following templates are described:

B.1 Sample Properties File with Mandatory Parameters for RAC Provisioning Procedure Using Gold Image

The following section describes in detail the sample properties file with mandatory parameters for RAC provisioning procedure using Gold Image:

# --------------------------------------------------

# Properties file for Rac Provisioning on Linux with # 1. Gold Image as source # 2. ASM # 3. DB Instance # 4. No Mirrors # 5. No Save to Software Library ## Testcase Name: CRSASMRAC_GOLD_PROV ## Variables and values to be replaced in the template RuntimeDataXML file ## Format: # ------- # Variable=Value # --------------------------------------------------

# Mandatory Parameters #-----------------------------

CRS_COMPONENT=<CRS gold image location in the Software Library Eg: Components/CRS GOLD IMAGE>RAC_COMPONENT=<RAC gold image location in the Software Library Eg: Components/CRS GOLD IMAGE>ASM_COMPONENT=<ASM gold image location in the Software Library Eg: Components/CRS GOLD IMAGE>ORACLE_HOME_BASE_LOC=<Base installation directory for installation of the CRS, RAC and ASM>CLUSTER_ORACLE_HOME_NAME=<CRS Oracle Home Name. Eg: OraCrs10g_home>CLUSTER_NAME=<CRS Name. Eg: crs>DB_ORACLE_HOME_NAME=<RAC DB Oracle Home Name. Eg: OraRAC10g_home1>ASM_ORACLE_HOME_NAME=<ASM Oracle Home Name. Eg: OraASM10g_home1>

PUB_NODELIST_VALUE=<Comma separated list of nodes present in the Cluster with fully qualified host names. Eg: node1.example.com, node2.example.com>PRIV_NODELIST_VALUE=<Comma separated list of private fully qualified host names of the nodes present in the Cluster. Eg: node1-i.example.com, node2-i.example.com >VIRTUAL_NODELIST_VALUE=<Comma separated list of fully qualified virtual host names of the nodes present in the Cluster. Eg: node1-vip.example.com, node2-vip.example.com >

OCR_PARTITION_VALUE=<OCR Location. Eg:/store/storage/ocr>VDSK_PARTITION_VALUE=<VDISK Locations. Eg: /store/storage/vdsk>ORADATA_LOC=<Shared OraData Location. Eg:/store/storage/oradata>INSTALL_USER=<Target Credentials. Eg: oracle>USER_PASSWORD=<Target Credentials. Eg: oracle>

DEVICES=<Device List. Eg: ,node1.example.com:/scratch/nfs/src/nfs3%1320%NFS%/scratch/nfs/des/nfs3%NFS,,>

DB_SID=<The Cluster Database Name. Eg: racdb>

ASM_RED=<ASM Redundancy Type. Eg: NORMAL>ASM_DISK_LIST=<Comma separated ASM Disk List. Eg:/store/asmdisks/asm1,/store/asmdisks/asm2,/store/asmdisks/asm3>ASM_DISK_STRING=<ASM Disk Search String. Eg:/store/asmdisks/*>

CENTRAL_INVENTORY_LOCATION=<Oracle Inventory Location. Eg:/scratch/rac/oraInventory>

NICS=<Network Interface List in a specific Format. Eg:eth0:152.68.196.0:PUBLIC,eth1:152.68.80.0:PRIVATE>PRIV_IP_LIST_VALUE=<Comma separated private IPs. Eg:152.68.81.85,152.68.81.86>

B.2 Sample Properties File With Mandatory Parameters for RAC Provisioning Procedure Using a Reference Installation

The following section describes in detail the sample properties file with mandatory parameters for RAC provisioning procedure using a reference installation:

# -------------------------------------------------- # Properties file for Rac Provisioning on Linux with # 1. Installed Home as source # 2. ASM # 3. DB Instance # 4. No Mirrors # 5. No Save to Software Library ## Test case Name: CRSASMRAC_INSHOME_PROV ## Variables and values to be replaced in the template RuntimeDataXML file ## Format: # ------- # Variable=Value # -------------------------------------------------- #Mandatory Parameters #-----------------------------

REF_HOST_NAME=<Fully qualified host name of the reference node Eg:racnode2.example.com>WORK_DIR_LOC=<Working Directory Location. Eg: /tmp>HOST_USER=<Target Credentials for the Reference Host Eg:oracle>HOST_PASSWD=<Target Credentials for the Reference Host Eg:oracle>

SOURCE_CRS_HOME_LOC=<Reference CRS Oracle Home location /scratch/NewHomes/OraCrs10g_home1>SOURCE_RAC_HOME_LOC=<Reference RAC Oracle Home location/scratch/NewHomes/OraDB10g_home1>SOURCE_ASM_HOME_LOC=<Reference ASM Oracle Home location/scratch/NewHomes/OraAsm10g_home1>

ORACLE_HOME_BASE_LOC=<Location for cluster installation /scratch/app/oracle>CLUSTER_ORACLE_HOME_NAME=<New CRS Oracle Home Name Eg:OraCrs10g_home>CLUSTER_NAME=<New CRS Cluster name Eg:mycrs>DB_ORACLE_HOME_NAME=<New RAC Cluster name Eg:OraDB10g_home>ASM_ORACLE_HOME_NAME=<New ASM Cluster name Eg:OraAsm10g_home>

PUB_NODELIST_VALUE=<Comma separated list of nodes present in the Cluster with fully qualified host names. Eg: node1.example.com, node2.example.com>PRIV_NODELIST_VALUE=<Comma separated list of private fully qualified host names of the nodes present in the Cluster. Eg: node1-i.example.com, node2-i.example.com >VIRTUAL_NODELIST_VALUE=<Comma separated list of fully qualified virtual host names of the nodes present in the Cluster. Eg: node1-vip.example.com, node2-vip.example.com >

OCR_PARTITION_VALUE=<OCR Location. Eg:/store/storage/ocr>VDSK_PARTITION_VALUE=<VDISK Locations. Eg: /store/storage/vdsk>ORADATA_LOC=<Shared OraData Location. Eg:/store/storage/oradata>

INSTALL_USER=<Target Credentials. Eg: oracle>USER_PASSWORD=<Target Credentials. Eg: oracle>

DEVICES=<Device List. Eg: ,node1.example.com:/scratch/nfs/src/nfs3%1320%NFS%/scratch/nfs/des/nfs3%NFS,,>

DB_SID=<The Cluster Database Name. Eg: racdb>

ASM_RED=<ASM Redundancy Type. Eg: NORMAL>ASM_DISK_LIST=<Comma separated ASM Disk List. Eg:/store/asmdisks/asm1,/store/asmdisks/asm2,/store/asmdisks/asm3>ASM_DISK_STRING=<ASM Disk Search String. Eg:/store/asmdisks/*>

CENTRAL_INVENTORY_LOCATION=<Oracle Inventory Location. Eg:/scratch/rac/oraInventory>

NICS=<Network Interface List in a specific Format. Eg:eth0:152.68.196.0:PUBLIC,eth1:152.68.80.0:PRIVATE>PRIV_IP_LIST_VALUE=<Comma separated private IPs. Eg:152.68.81.85,152.68.81.86>

B.3 Sample Properties File With Mandatory Parameters For RAC Extend Cluster Procedure

The following section describes in detail the sample properties file with mandatory parameters for RAC extend cluster procedures:

# -------------------------------------------------------------------------- # Properties file for Extending Cluster with CRS/RAC # Please note that # 1. Reference target should have CRS and RAC # 2. CRS/RAC targets and instances should be up. # 3. No Mirrors # 4. RAC and CRS targets should have 10.2.0.3 agents ## Variables and values to be replaced in the Template RuntimeDataXML file # # Format: # ------- # Variable=Value # --------------------------------------------------------------------------

# for extending ASM stack, include properties for # ASM_ORACLE_HOME_LOC and ASM_ORACLE_HOME_NAME # Mandatory Parameters #-----------------------------

CLUSTERWARE_ORACLE_HOME_LOC=<CRS Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/crs>DB_ORACLE_HOME_LOC=<RAC DB Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/mydb_1>DB_ORACLE_HOME_NAME=<RAC DB Oracle Home Name. Eg: OraRAC10g_home1>CLUSTER_ORACLE_HOME_NAME=<CRS Oracle Home Name. Eg: OraCrs10g_home> DB_TARGET=LINORCL DB_SID=<RAC Database SID Eg:LINORCL1>CLUSTER_NAME=<CRS Name. Eg: crs>

NEW_DB_SID_LIST=<List of SID for new nodes of RAC Database Eg:LINORCL2,LINORCL3>PUB_NODELIST_ALL_NODES=<Comma separated list of nodes present in the Cluster. Eg: node1,node2>

WORK_DIR_LOC=<Working Directory Location. Eg: /tmp>REF_NODENAME_username=<Target Credentials for reference cluster installation. Eg: oracle>REF_NODENAME_password=<Target Credentials for reference cluster installation. Eg: oracle>EXT_NODENAME_username=<Target Credentials for the new nodes. Eg: oracle>EXT_NODENAME_password=<Target Credentials for the new nodes. Eg: oracle>

ORADATA_LOC=<Location of shared dbfiles /oradbshare/oradata/linorcl/temp01.dbf>EM_REP_USER_NAME=<Management Repository User Eg:SYSMAN>LISTENER_ORACLE_HOME=<RAC Listener Oracle Home/u01/app/oracle/product/10.2.0/rac>REF_NODENAME=<Fully qualified host name of the reference Eg:node1.example.com>CRS_NEW_NODE_LIST=<List of fully qualified hostname,private host name and virtual ip for each node that would be included in the cluster Eg: node2.example.com:node2-priv:10.35.69.70:node2-vip:136.34.56.176,node3.example.com:node3-priv:10.35.69.71:node3-vip:136.34.56.177>

B.4 Sample Properties File With Mandatory Parameters for RAC Delete Cluster Procedure

The following section describes in detail the sample properties file with mandatory parameters for RAC delete cluster procedures:

# -------------------------------------------------- # Properties file for Rac Delete of entire Cluster ## Variables and values to be replaced in the Template RuntimeDataXML file ## Format: # ------- # Variable=Value # -------------------------------------------------- # Mandatory Parameters #-----------------------------

CLUSTER_NAME=<CRS Name. Eg: crs>DB_TARGET=<The Cluster Database Name. Eg: racdb>DBPASSWORD=<The Cluster Database password for SYS uses. Eg: welcome1>DATABASE_INSTANCE_LIST=<Comma separated list of database instance names. Eg: racdb1,racdb2>

CLUSTER_ORACLE_HOME_NAME=<CRS Oracle Home Name. Eg: OraCrs10g_home>ASM_ORACLE_HOME_NAME=<ASM Oracle Home Name. Eg: OraASM10g_home1>DB_ORACLE_HOME_NAME=<RAC DB Oracle Home Name. Eg: OraRAC10g_home1>CLUSTERWARE_ORACLE_HOME_LOC=<CRS Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/crs>ASM_ORACLE_HOME_LOC=<ASM Oracle Home Location. Eg: /u01/app/oracle /product/10.2.0/myasm_1>DB_ORACLE_HOME_LOC=<RAC DB Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/mydb_1>

PUB_NODELIST_ALL_NODES=<Comma separated list of nodes present in the Cluster. Eg: node1,node2>HOST_LIST_FOR_DELETION=<Comma separated list of node fully qualified host names selected for deletion. Eg: node1.example.com, node2.example.com>

WORK_DIR_LOC=<Working Directory Location. Eg: /tmp>

TARGET_USERNAME=<Target Credentials. Eg: oracle>TARGET_PASSWORD=<Target Credentials. Eg: oracle>

B.5 Sample Properties File With Mandatory Parameters for RAC Descale Cluster Procedure

The following section describes in detail the sample properties file with mandatory parameters for RAC descale cluster procedures:

# ------------------------------------------- # Properties file for partial delete of a Cluster ##Variables and values to be replaced in the # Template RuntimeDataXML file ## Format: # ------- # Variable=Value # ------------------------------------------- ## Mandatory Parameters#-----------------------------

CLUSTER_NAME=<CRS Name. Eg: crs>DB_TARGET=<The Cluster Database Name. Eg: racdb>DBPASSWORD=<The Cluster Database password for SYS uses. Eg: welcome1>DATABASE_INSTANCE_LIST=<Comma separated list of database instance names. Eg: racdb1,racdb2>

CLUSTER_ORACLE_HOME_NAME=<CRS Oracle Home Name. Eg: OraCrs10g_home>ASM_ORACLE_HOME_NAME=<ASM Oracle Home Name. Eg: OraASM10g_home1>DB_ORACLE_HOME_NAME=<RAC DB Oracle Home Name. Eg: OraRAC10g_home1>CLUSTERWARE_ORACLE_HOME_LOC=<CRS Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/crs>ASM_ORACLE_HOME_LOC=<ASM Oracle Home Location. Eg: /u01/app/oracle /product/10.2.0/myasm_1>DB_ORACLE_HOME_LOC=<RAC DB Oracle Home Location. Eg: /u01/app/oracle/product/10.2.0/mydb_1>

PUB_NODELIST_ALL_NODES=<Comma separated list of nodes present in the Cluster. Eg: node1,node2>HOST_LIST_FOR_DELETION=<Comma separated list of node fully qualified host names selected for deletion. Eg: node1.example.com, node2.example.com>

FIRST_TARGET_NAME=<Fully qualified host name of the node to be deleted Eg:node1.example.com>

WORK_DIR_LOC=<Working Directory Location. Eg: /tmp>TARGET_USERNAME=<Target Credentials. Eg: oracle>TARGET_PASSWORD=<Target Credentials. Eg: oracle>

B.6 Sample Properties File With Mandatory Parameters For All Patching Procedures

The following section describes in detail the sample properties file with mandatory parameters for all patching procedures:

# Properties file for Standalone Database patching to be used with the above runtime # Template ## Use case: Patching a single database target ##Variables and values to be replaced in the template RuntimeDataXML file ## Format: # ----------- # Variable=Value # ---------------------------------------------------------------------

# Mandatory ParametersPA_VAR_targetsToPatch=<Target Names to be Patched. Eg:oracle1>

#Optional ParametersPA_VAR_hostCredentialsSet=<HostPrefNormal>PA_VAR_patchID_1=123456 PA_VAR_patchData_1=p1212121_10.2.0.3_46_9840 PA_VAR_patchSrcs_1=METALINK PA_VAR_patchTypes_1=Patch PA_VAR_patchReleases_1=10.2.0.3 PA_VAR_patchPlatforms_1=Linux PA_VAR_stageDir=%oracle_home%/EMStagedPatches PA_VAR_isPatchSet=false PA_VAR_isNotPatchset=true PA_VAR_sqlScript=defaultSqlScript PA_VAR_isUpgradeStepEnabled=true

PKq AAPK^UIOEBPS/dcommon/oracle-logo.jpg yJFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222'7" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE!KEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzE7V%ȣOΏ9??:a"\fSrğjAsKJ:nOzO=}E1-I)3(QEQEQEQEQEQEQE֝Hza<["2"pO#f8M[RL(,?g93QSZ uy"lx4h`O!LŏʨXZvq& c՚]+: ǵ@+J]tQ]~[[eϸ (]6A&>ܫ~+כzmZ^(<57KsHf妬Ϧmnẁ&F!:-`b\/(tF*Bֳ ~V{WxxfCnMvF=;5_,6%S>}cQQjsOO5=)Ot [W9 /{^tyNg#ЄGsֿ1-4ooTZ?K Gc+oyڙoNuh^iSo5{\ܹ3Yos}$.nQ-~n,-zr~-|K4R"8a{]^;I<ȤL5"EԤP7_j>OoK;*U.at*K[fym3ii^#wcC'IIkIp$󿉵|CtĈpW¹l{9>⪦׺*ͯj.LfGߍԁw] |WW18>w.ӯ! VӃ :#1~ +މ=;5c__b@W@ +^]ևՃ7 n&g2I8Lw7uҭ$"&"b eZ":8)D'%{}5{; w]iu;_dLʳ4R-,2H6>½HLKܹR ~foZKZ࿷1[oZ7׫Z7R¢?«'y?A}C_iG5s_~^ J5?œ tp]X/c'r%eܺA|4ծ-Ե+ْe1M38Ǯ `|Kյ OVڅu;"d56, X5kYR<̭CiطXԮ];Oy)OcWj֩}=܅s۸QZ*<~%뺃ȶp f~Bðzb\ݳzW*y{=[ C/Ak oXCkt_s}{'y?AmCjޓ{ WRV7r. g~Q"7&͹+c<=,dJ1V߁=T)TR՜*N4 ^Bڥ%B+=@fE5ka}ędܤFH^i1k\Sgdk> ֤aOM\_\T)8靠㡮3ģR: jj,pk/K!t,=ϯZ6(((((((49 xn_kLk&f9sK`zx{{y8H 8b4>ÇНE|7v(z/]k7IxM}8!ycZRQ pKVr(RPEr?^}'ðh{x+ՀLW154cK@Ng C)rr9+c:׹b Жf*s^ fKS7^} *{zq_@8# pF~ [VPe(nw0MW=3#kȵz晨cy PpG#W:%drMh]3HH<\]ԁ|_W HHҡb}P>k {ZErxMX@8C&qskLۙOnO^sCk7ql2XCw5VG.S~H8=(s1~cV5z %v|U2QF=NoW]ո?<`~׮}=ӬfԵ,=;"~Iy7K#g{ñJ?5$y` zz@-~m7mG宝Gٱ>G&K#]؃y1$$t>wqjstX.b̐{Wej)Dxfc:8)=$y|L`xV8ߙ~E)HkwW$J0uʟk>6Sgp~;4֌W+חc"=|ř9bc5> *rg {~cj1rnI#G|8v4wĿhFb><^ pJLm[Dl1;Vx5IZ:1*p)إ1ZbAK(1ׅ|S&5{^ KG^5r>;X׻K^? s fk^8O/"J)3K]N)iL?5!ƾq:G_=X- i,vi2N3 |03Qas ! 7}kZU781M,->e;@Qz T(GK(ah(((((((Y[×j2F}o־oYYq $+]%$ v^rϭ`nax,ZEuWSܽ,g%~"MrsrY~Ҿ"Fت;8{ѰxYEfP^;WPwqbB:c?zp<7;SBfZ)dϛ; 7s^>}⍱x?Bix^#hf,*P9S{w[]GF?1Z_nG~]kk)9Sc5Ո<<6J-ϛ}xUi>ux#ţc'{ᛲq?Oo?x&mѱ'#^t)ϲbb0 F«kIVmVsv@}kҡ!ˍUTtxO̧]ORb|2yԵk܊{sPIc_?ħ:Ig)=Z~' "\M2VSSMyLsl⺿U~"C7\hz_ Rs$~? TAi<lO*>U}+'f>7_K N s8g1^CeКÿE ;{+Y\ O5|Y{/o+ LVcO;7Zx-Ek&dpzbӱ+TaB0gNy׭ 3^c T\$⫫?F33?t._Q~Nln:U/Ceb1-im WʸQM+VpafR3d׫é|Aү-q*I P7:y&]hX^Fbtpܩ?|Wu󭏤ʫxJ3ߴm"(uqA}j.+?S wV ~ [B&<^U?rϜ_OH\'.;|.%pw/ZZG'1j(#0UT` Wzw}>_*9m>󑓀F?EL3"zpubzΕ$+0܉&3zڶ+jyr1QE ( ( ( ( ( ( ( (UIdC0EZm+]Y6^![ ԯsmܶ捆?+me+ZE29)B[;я*wGxsK7;5w)}gH~.Ɣx?X\ߚ}A@tQ(:ͧ|Iq(CT?v[sKG+*רqҍck <#Ljα5݈`8cXP6T5i.K!xX*p&ќZǓϘ7 *oƽ:wlຈ:Q5yIEA/2*2jAҐe}k%K$N9R2?7ýKMV!{W9\PA+c4w` Wx=Ze\X{}yXI Ү!aOÎ{]Qx)#D@9E:*NJ}b|Z>_k7:d$z >&Vv󃏽WlR:RqJfGإd9Tm(ҝEtO}1O[xxEYt8,3v bFF )ǙrPNE8=O#V*Cc𹾾&l&cmCh<.P{ʦ&ۣY+Gxs~k5$> ӥPquŽўZt~Tl>Q.g> %k#ú:Kn'&{[yWQGqF}AЅ׮/}<;VYZa$wQg!$;_ $NKS}“_{MY|w7G!"\JtRy+贾d|o/;5jz_6fHwk<ѰJ#]kAȎ J =YNu%dxRwwbEQEQEQEQEQEQEQEQEQE'fLQZ(1F)hQ@X1KEQE-Q@ 1KE3h=iPb(((1GjZ(-ʹRPbR@ 1KE7`bڒyS0(-&)P+ ڎԴP11F)h&:LRmQ@Q@Š(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((?l:ϊw "{{-3j3%{Ə77}>ٻګ=Vf&-P7h)Y3>eր.QX>,ާy43/c'Vg%|#Ee$+|NU0>޺F.ݼFm[zWA<7V\[J6 dGhJ+/R.\-3X&+2qF}\㼰L $0? ESմ>P[G4ʍ3d ',r`zZ7tmPiszlZuAhHlm NF9Ƞ J*z66h)[ELrɜ/$wNŞ#wu&vCr;`p آˏĺ \ڤZޚ|/[C73=ǭ\,伿?8ԀvW.o,ާy43/c'VU=KVtku5 K,S,J[ g{tH5_dkt$n8g{ZԢxn⸷9$l]H #=O]O+[U"ߌg2:zТ麶۵ƗZ_@QeP#8 Qjnnic8EeK` c@(KĺpcHH AA5@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@'K|U].VCyCO#GUH~9Й䊏4ıZpq8=} y|Y`ZǿmRGNeY8Kev#FA<|B9X^U2822Vf qՉ'=+*E5s_P|w_x6\ҾuX8FνO?[|5OXe|Ň8'qw|rq,ҵ^3>BIm]YY'䊯K_)^ ͥŭܵvp,YMI{#kKM."o91 8'+،'ihAw{ft@aN wky}YghSˑr0H94? eOU;߽[rpq=5_§FװPΚ& jYٛx%1 $+  - n 'u h?k ydF#37}@󂧔|gcS\i,Ʉ4P6PdpI#Oc~濇W. H9vH?+ſ..̍ydGY$JN2۸+> 6ӼgZim\2!<`FAX+xz@klMJS~GU '9TV#"g'dQP>Ѽ#C6-d <ד.f$QWQh›??'_c6}cInQjxkRFGj #AeCq"bbH hڑ#\H^öXyC99w)#Jf#tkv-oEܮI$?6'a2_u\g d |Ć^\F>#mN"lq#: EƵ?Xm,s^9cܐ IaY?TT3–'k$:uUFsrH!u|?q |7^Aj[<+$Xd%1t'ğӵ%k!\#FG˹89qy<-]nx/uMkRO:ky5Da@2s/ ww^Wcٶ.-$r*r@fB `(vq]x%5ѿ [LU$]o Z@Gq8Q@މxGIխc>2-웶aʐG  X4k 8[XSq;Q@ 2y8uP=DžkZx{=F.<miwUgCC=ad3F=UN`kBo 5Ӵ0QIA F`a [F%gKY%32y&\ ˒z(be4OZlӼ.L Y!Vy}O ࿅ wwzèWե՘@RJZ>kiV7N|ۤ3p8OAFh'Xy>noqg=}MI5n4VX(PN^U4H'fFxd 7g]E{ׄ|+xo4}.IWNY+|և<-xN\]r<׏=uEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEG/N=((Xu K$qz6ĨBmJ %S3N>-+Pɾť JQס(m7O1kS=?xkG ?h7]2xYԢ"g Fh£ ??'og~:@ExޛqxY֤BFR(q> xzܗךǘ\3:,s(W^Kz&H^DLccFw#qeH -3ax\u4SwyyEFKuЀ{P ?C9|A K~N~FAd1, W'g>YU5yvPt21PQ^?T/ kzŢ\iz*ȫ(Wy\wxǖ<;cX\ 0 >PHc(I^?8^Wǩk2ë&eW'+!pNps<'_I>O[Ɖ,֗,XO;]Y(ϊM~ kV|2)Ps3܂"{>h &j_7w}y`7uMk~*}kI|3̰ &s3P{f WWĿivޙNWԚԀUX ᕦʞ(:+/o!o|A[Od.VyT@#vܣ}0}?X[3j QTw#4G,AH{ygYZk,YDU_ :K&./p~ $hZbfU$@@@wA6 jޥ ^T"6Nc]߈|'`? +1xTѴ=;GV]K}>sFѮIy#ds?㾿&T {W?O5 `l߅u|Ko)}IH ?UZn̼ _ - kxZjإtuUWA=:zwW|)w/"O>1'`ہ+&&ެ}F\$c{ne'uJ)"&pp$l6@](ߍu/ ]A^{.)HzWy_>|dV7 4aIz:L*|&|ͪiwznR#(RQNr\Ӽ ?| E/!~t>=x|Y`ZgZZ >e(S9HA=@Ex3k~|uqw?gZԺ\>bX9 q(=@E| 0.Y4SZJ2ݙxShx{|0| J{'ArʤȌ j~5o'uW>V7m3VQEQEQEQEQEQEQEQEQEx_+mKǞ<Ѽ {wvQUSQgOG9ߕz4i_u_5MEn:1"*ae~A'=%|/|:xgVHrZMhP8:|F|)~4ăE[wXg1>%1( IJJEͫdlYHʡH:4mV1R:e 2К\MnĈLnBJ33?Z:ϊ j"{{k 3kRyUs.{0Op J"x#xSZ?ufI3,AX.Bƪj`(a}&FKș /Nm&4D.]<$nV_ `08 {YC/}MW=r 8k? 7\st%FdPI•E A# >)7=oQ.bX@H):YH  > /k_Lh^,Di=,3^<[oqsA*92<G+|wy$˪F\)D^Iq_E foH#Ȓ!s#3WFz_§FQ|'7^`m>'8"ppYؐ: V<YеKEEr6*It#?6⽂ +M𾳮S>qԪ6l&3!OA@g=Z?cxh,֥u#sXȑ94eFIzepZZǍO $< X,^]9lO7` ?$ \=K]V5`B>AEn:GON(?Ѿg^'}">32G)Or6FXs| w9/귶N@;XyYVS3ȯln巸9 I]H#W~> xellb.`tf$ 1?~ [3\lcg%O &@Ld# Ͻ?u}M״iǔH`3N$w sm#]ʛ%}' :pgj$fxzt֭<+qdbB0JT2X?sjU|*/+Ȓ@7jEEZ7?i^JږUh%QWwLakWiz\sA-\3]:*Tc;zI^? io *Azc*9[{ PȡԌA8c_/tcVK9dLNU2 ~'#g4ھSG"l99 #ǟ ޘW,s\0P9PgDϚSp*90ئC &I|~"Va˒OVOx/B񮜶zէn0LRHY VʒA !}ST"F*+-7Skg'dQVZFaZ0 TUl<7z4^=Kp NmU޴ ;£FWaOY>zwKĒAO12A0H=s~ |/뺥rO\}fu*  zWA<[oqsA*92<G} bֺ(߸ƅLvѲ>e6ǚ"X c*6?^?~!ӞWղvLH#r' 0Fx4c?k>W0y~^7on9LW3|aw,٤4B7²G9Z> O>oO/9ٝ㏽zF~ӒHpvB@s,rN94?Nѷ|mCۿG[V}g],}j+3TmL( fCԞxv~.އ$l06 ;P<R֦iͻ\iz KYU pJ3=So[O}췃9*<*@u=;W/guk ^JwM[ $QEQEQEQEQEQEQEQEQEQ\ߍo|WcC/MCP7 EtTE. :[Tz`3PQ@Q@:?xv5jơ⟊ x hhkm,w7*)\,t p_[zueI4/8<:Պ(i<־ żC-|Fկ?{}mvQKvEہx!3+2O㯋|=v$'^qg;FQI쁘p=rSӮl/#-nxfMnF0dҼnZ4ӯfDy6đq Oxžu˥Ed1&@8Fqrx3i{jG#kvsAAxXanH>/\?]_AGe[MyFC yv8ݐ|q>#'Zuq["IUh8'p۹N!iXK0K.z"GSA5[𮙣n弥I88(>7;?Uo'2Ilqִ>#GѼsOV#8!GY2wv Igh??U/v.>qg /Yǥj;1pJ$dxkMF𮑥4m=64d,2=y^x⏈ockO:rLN *~f_vj#9L8t;X09G?mz}ۭΕl\S&RUVFqryOi7`Mv#=!gc%*k5f?5^H%s e[" [{J$DԌA+M |Դ}F=F{׎5 $0rsր$%$B(}G\i~ ֟/ueÌ98*T7:_Ht/x҉+>/XkoxwSntb8™263Ƞ]oVxM޻nI1\ 8#,U^炎Ď{&)Yp;c|6 db>*⦳4I#%eu#gq؝w[KR{;rmocUUc<$|A!e¯j/oY H!\p6x@ IgG?<_}[Vx9ܦ|Sx~!o J+"ȠjB1p#p1X/EGu a)L9&UTp6A9⏊G __i3vW.$۝bjIBJpW,\s*ZTep*2N3n;x^c{t#h=c SINA^_"&k vb,-"s\d‘8VF8{ O ;B xbuO\ 8-!A;xy'?ut΁4,k l1qY5{~?8oVkT e8.WHҾ\=3sgpa9A@<->5=7RΙ 9|pW.Ah85pԡ.k_'Im)2!i X88d?Y|åꖚn ֱ(R̸;NrwP#/ ?;](5@cnbM1cm(JVVv|> =и-! "0{{QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEs~5ޥ-/7zpͨmΡXl;]N `zOZڤ:u'!M]Qy_3ps^Eq~Okx_O?67H{p鏺:~>g62Z#,#'= }CQž3u[|ܘ$#s;.]zCkoQH8Ppb<~}^jl l^GR <d`(WxzFi_]~7`K˷;!*N%#h 7_Z{lݴX 8q3Z)[ƚNS61H[Λwq". 0=I5P_umYﯴ^/.Lm BA~RLrr| ԵWBu]=y`@*^Gx9d3t=/N-l LH"Ԧ(s09ݜ9'9/[񞫠Z`oЕn#Nk(;¥мAuj^ -Ѣ,H~gˑJ( z_iw "{o%$dC^W kĖӾ(k1~Qr&QAҽ |mrk/[)p*lc ="(((((((((((((((((((((/Ě>֥唳yB<1#гaG85-oop8*ƾ,~â[2js[+06~s8̋COoAGv!%L%{HA%wG`'(~?neU(>y\f*>]JmºnVS\FT!`8Ѭvڌ)K$2v;FoZ|Q-<9e]_KZ]+]MՃr,pYA=bލg|3fO6X巐6RH$ dWyJmgºFpPH3bI84^?|Axž K9f\9Vd-u# Ex__mR~"xV; >V3$906@d+د#K[TEb1kl` g6mºFpѴVPђT RF@8^ KJDk1l9 ~T+}oOČ7Sӭ-nI}nFd֫5t;"7>%sї }Ԧd-XX^oPrT-]0 \A#~mm?>`X ;«[u]O4ϴ8zPxׇ"<c.8r]@RwY$أ,Wc#"C']ëpJ9!{Ƿ6!s7`Js;jMb9&%6'iH$.qRI=8o㯂7{h&Fأ(~΀t-#{w7?fk۷~//ŷ񝏎5c W8 0 rI^7|7ƞӢ4۴|6hp:烐 xYg]u_YH 90TfJq+m/֢Tms!ةdkCγBK$hK$.GbrsF9<uQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEyHZ|<&1ŧ Hxg'8\/⯅şEGCyh#Fv2 N{8$ i]W 'Qʯ p3@Ex(*?mt5Ҿ$_k0i~-d0eaG^Ǐ^GkkAuK3Zuේc4]c{'tٵ ]FMoHHP΅A8'Y>iпV,\FH"i N2U+𵾻iH ׆裸Mo:rac8a +>:Ět v[doC܂ABrq _|Oq/~۶oݏ1;^oXQ2I1.f3J@(€'$GOk9m>hAN^E1ՙGyi 4nh`7G}5_׵ƙ&˭fU[!'8l3^acoiqv$0vdp@(((((((((((((((((((((((*WZ}oHaTi$c''((((((((((((zN6hɲ[Dpόr((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((PKey yPK^UIOEBPS/dcommon/oracle.gifJGIF87aiyDT2F'G;Q_oKTC[ 3-Bq{ttsoGc4I)GvmLZ).1)!ꑈ53=Z]'yuLG*)g^!8C?-6(29K"Ĩ0Яl;U+K9^u2,@@ (\Ȱ Ë $P`lj 8x I$4H *(@͉0dа8tA  DсSP v"TUH PhP"Y1bxDǕ̧_=$I /& .)+ 60D)bB~=0#'& *D+l1MG CL1&+D`.1qVG ( "D2QL,p.;u. |r$p+5qBNl<TzB"\9e0u )@D,¹ 2@C~KU 'L6a9 /;<`P!D#Tal6XTYhn[p]݅ 7}B a&AƮe{EɲƮiEp#G}D#xTIzGFǂEc^q}) Y# (tۮNeGL*@/%UB:&k0{ &SdDnBQ^("@q #` @1B4i@ aNȅ@[\B >e007V[N(vpyFe Gb/&|aHZj@""~ӎ)t ? $ EQ.սJ$C,l]A `8A o B C?8cyA @Nz|`:`~7-G|yQ AqA6OzPbZ`>~#8=./edGA2nrBYR@ W h'j4p'!k 00 MT RNF6̙ m` (7%ꑀ;PKl-OJPK^UIOEBPS/dcommon/cpyr.htmd Oracle Legal Notices

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Oracle Logo

PKS\UKPK^UIOEBPS/dcommon/doccd_epub.jsM /* Copyright 2006, 2012, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2012.3.17 */ function addLoadEvent(func) { var oldOnload = window.onload; if (typeof(window.onload) != "function") window.onload = func; else window.onload = function() { oldOnload(); func(); } } function compactLists() { var lists = []; var ul = document.getElementsByTagName("ul"); for (var i = 0; i < ul.length; i++) lists.push(ul[i]); var ol = document.getElementsByTagName("ol"); for (var i = 0; i < ol.length; i++) lists.push(ol[i]); for (var i = 0; i < lists.length; i++) { var collapsible = true, c = []; var li = lists[i].getElementsByTagName("li"); for (var j = 0; j < li.length; j++) { var p = li[j].getElementsByTagName("p"); if (p.length > 1) collapsible = false; for (var k = 0; k < p.length; k++) { if ( getTextContent(p[k]).split(" ").length > 12 ) collapsible = false; c.push(p[k]); } } if (collapsible) { for (var j = 0; j < c.length; j++) { c[j].style.margin = "0"; } } } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(compactLists); function processIndex() { try { if (!/\/index.htm(?:|#.*)$/.test(window.location.href)) return false; } catch(e) {} var shortcut = []; lastPrefix = ""; var dd = document.getElementsByTagName("dd"); for (var i = 0; i < dd.length; i++) { if (dd[i].className != 'l1ix') continue; var prefix = getTextContent(dd[i]).substring(0, 2).toUpperCase(); if (!prefix.match(/^([A-Z0-9]{2})/)) continue; if (prefix == lastPrefix) continue; dd[i].id = prefix; var s = document.createElement("a"); s.href = "#" + prefix; s.appendChild(document.createTextNode(prefix)); shortcut.push(s); lastPrefix = prefix; } var h2 = document.getElementsByTagName("h2"); for (var i = 0; i < h2.length; i++) { var nav = document.createElement("div"); nav.style.position = "relative"; nav.style.top = "-1.5ex"; nav.style.left = "1.5em"; nav.style.width = "90%"; while (shortcut[0] && shortcut[0].toString().charAt(shortcut[0].toString().length - 2) == getTextContent(h2[i])) { nav.appendChild(shortcut.shift()); nav.appendChild(document.createTextNode("\u00A0 ")); } h2[i].parentNode.insertBefore(nav, h2[i].nextSibling); } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(processIndex); PKo"nR M PK^UIOEBPS/dcommon/blafdoc.cssc@charset "utf-8"; /* Copyright 2002, 2011, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2011.8.12 */ body { font-family: Tahoma, sans-serif; /* line-height: 125%; */ color: black; background-color: white; font-size: small; } * html body { /* http://www.info.com.ph/~etan/w3pantheon/style/modifiedsbmh.html */ font-size: x-small; /* for IE5.x/win */ f\ont-size: small; /* for other IE versions */ } h1 { font-size: 165%; font-weight: bold; border-bottom: 1px solid #ddd; width: 100%; text-align: left; } h2 { font-size: 152%; font-weight: bold; text-align: left; } h3 { font-size: 139%; font-weight: bold; text-align: left; } h4 { font-size: 126%; font-weight: bold; text-align: left; } h5 { font-size: 113%; font-weight: bold; display: inline; text-align: left; } h6 { font-size: 100%; font-weight: bold; font-style: italic; display: inline; text-align: left; } a:link { color: #039; background: inherit; } a:visited { color: #72007C; background: inherit; } a:hover { text-decoration: underline; } a img, img[usemap] { border-style: none; } code, pre, samp, tt { font-family: monospace; font-size: 110%; } caption { text-align: center; font-weight: bold; width: auto; } dt { font-weight: bold; } table { font-size: small; /* for ICEBrowser */ } td { vertical-align: top; } th { font-weight: bold; text-align: left; vertical-align: bottom; } li { text-align: left; } dd { text-align: left; } ol ol { list-style-type: lower-alpha; } ol ol ol { list-style-type: lower-roman; } td p:first-child, td pre:first-child { margin-top: 0px; margin-bottom: 0px; } table.table-border { border-collapse: collapse; border-top: 1px solid #ccc; border-left: 1px solid #ccc; } table.table-border th { padding: 0.5ex 0.25em; color: black; background-color: #f7f7ea; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } table.table-border td { padding: 0.5ex 0.25em; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } span.gui-object, span.gui-object-action { font-weight: bold; } span.gui-object-title { } p.horizontal-rule { width: 100%; border: solid #cc9; border-width: 0px 0px 1px 0px; margin-bottom: 4ex; } div.zz-skip-header { display: none; } td.zz-nav-header-cell { text-align: left; font-size: 95%; width: 99%; color: black; background: inherit; font-weight: normal; vertical-align: top; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-header-link { font-size: 95%; } td.zz-nav-button-cell { white-space: nowrap; text-align: center; width: 1%; vertical-align: top; padding-left: 4px; padding-right: 4px; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-button-link { font-size: 90%; } div.zz-nav-footer-menu { width: 100%; text-align: center; margin-top: 2ex; margin-bottom: 4ex; } p.zz-legal-notice, a.zz-legal-notice-link { font-size: 85%; /* display: none; */ /* Uncomment to hide legal notice */ } /*************************************/ /* Begin DARB Formats */ /*************************************/ .bold, .codeinlinebold, .syntaxinlinebold, .term, .glossterm, .seghead, .glossaryterm, .keyword, .msg, .msgexplankw, .msgactionkw, .notep1, .xreftitlebold { font-weight: bold; } .italic, .codeinlineitalic, .syntaxinlineitalic, .variable, .xreftitleitalic { font-style: italic; } .bolditalic, .codeinlineboldital, .syntaxinlineboldital, .titleinfigure, .titleinexample, .titleintable, .titleinequation, .xreftitleboldital { font-weight: bold; font-style: italic; } .itemizedlisttitle, .orderedlisttitle, .segmentedlisttitle, .variablelisttitle { font-weight: bold; } .bridgehead, .titleinrefsubsect3 { font-weight: bold; } .titleinrefsubsect { font-size: 126%; font-weight: bold; } .titleinrefsubsect2 { font-size: 113%; font-weight: bold; } .subhead1 { display: block; font-size: 139%; font-weight: bold; } .subhead2 { display: block; font-weight: bold; } .subhead3 { font-weight: bold; } .underline { text-decoration: underline; } .superscript { vertical-align: super; } .subscript { vertical-align: sub; } .listofeft { border: none; } .betadraft, .alphabetanotice, .revenuerecognitionnotice { color: #f00; background: inherit; } .betadraftsubtitle { text-align: center; font-weight: bold; color: #f00; background: inherit; } .comment { color: #080; background: inherit; font-weight: bold; } .copyrightlogo { text-align: center; font-size: 85%; } .tocsubheader { list-style-type: none; } table.icons td { padding-left: 6px; padding-right: 6px; } .l1ix dd, dd dl.l2ix, dd dl.l3ix { margin-top: 0ex; margin-bottom: 0ex; } div.infoboxnote, div.infoboxnotewarn, div.infoboxnotealso { margin-top: 4ex; margin-right: 10%; margin-left: 10%; margin-bottom: 4ex; padding: 0.25em; border-top: 1pt solid gray; border-bottom: 1pt solid gray; } p.notep1 { margin-top: 0px; margin-bottom: 0px; } .tahiti-highlight-example { background: #ff9; text-decoration: inherit; } .tahiti-highlight-search { background: #9cf; text-decoration: inherit; } .tahiti-sidebar-heading { font-size: 110%; margin-bottom: 0px; padding-bottom: 0px; } /*************************************/ /* End DARB Formats */ /*************************************/ @media all { /* * * { line-height: 120%; } */ dd { margin-bottom: 2ex; } dl:first-child { margin-top: 2ex; } } @media print { body { font-size: 11pt; padding: 0px !important; } a:link, a:visited { color: black; background: inherit; } code, pre, samp, tt { font-size: 10pt; } #nav, #search_this_book, #comment_form, #comment_announcement, #flipNav, .noprint { display: none !important; } body#left-nav-present { overflow: visible !important; } } PKr.hcPK^UIOEBPS/structure.htm Introduction to Enterprise Manager Advanced Configuration

1 Introduction to Enterprise Manager Advanced Configuration

This chapter introduces you to Enterprise Manager advanced configuration and provides basic information about your Enterprise Manager installation. It describes the directory structure and how to make Enterprise Manager accessible to all your users.

After you review this chapter, you can move on to the other advanced configuration tasks described in this manual.

Specifically, this chapter includes the following topics:

1.1 Types of Advanced Configuration Tasks

Enterprise Manager is designed to install easily with a set of standard configuration settings so you can get up and running with the software quickly.

However, Oracle realizes that hardware and software management requirements vary dramatically among business enterprises. As a result, Enterprise Manager can be reconfigured after installation so you can:

  • Implement Enterprise Manager security and firewall features.

  • Enable End-User Performance Monitoring for your Web applications.

  • Reconfigure Enterprise Manager components when you need to modify the topology of your network environment.

  • Maintain and troubleshoot the Enterprise Manager components as your business grows.

1.2 Understanding the Enterprise Manager Directory Structure

Before you perform maintenance and advanced configuration tasks, you must be familiar with the directories and files that are copied to disk when you install Enterprise Manager. Understanding where specific files are located can help you if you need to troubleshoot installation or configuration problems.

The directories and files installed by Enterprise Manager vary, depending upon the installation options you select during the Enterprise Manager installation. The location of Enterprise Manager files and directories also varies slightly when Enterprise Manager is installed as part of an Oracle Application Server or Oracle Database 10g installation.

Use the following sections to become familiar with the directories that are created on your disk when you install Enterprise Manager:

1.2.1 Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager 10g Grid Control

When you install Oracle Enterprise Manager 10g Grid Control, you can select from four installation types. All of these installation types, except the Oracle Management Agent installation type, install the Oracle Management Service.

When you install the Oracle Management Service, you actually install three Oracle home directories:

  • The Management Service home directory

  • The Management Agent home directory

  • The Database home directory


Note:

When you install Oracle Enterprise Manager 10g Grid Control, Oracle Database is also installed, but will not contain Enterprise Manager Configuration Assistant (EMCA) in the Oracle Database Home.

1.2.1.1 About the Oracle Management Service Home Directory

The Oracle Management Service is a J2EE application in the form of an OC4J instance (OC4J_EM) that is installed and deployed using the Oracle Application Server J2EE and Web Cache installation type.

The installation procedure installs the Enterprise Manager components within the Oracle Application Server Home, including the Oracle Management Service.

Information about the directories that are specific to the Oracle Application Server installation can be found in the Oracle Application Server documentation. For example, the location of the most of the Oracle Application Server configuration and log files are described in the Oracle Application Server documentation.


See Also:

"Configuration Files and Log Files" in the Oracle Application Server Administrator's Guide

1.2.1.2 About the Oracle Management Agent Home (AGENT_HOME) Directory

In addition to the Management Service home directory, the installation procedure installs the Oracle Management Agent that is used to gather management data and perform administration tasks for the targets on the Management Service host.

By default, if the Oracle Universal Installer (or the account used to run the Universal Installer) has the proper privileges to write to the install directories, the Management Agent is installed in a separate Oracle home directory at the same level as the Oracle Application Server home directory.

However, if the Oracle Universal Installer does not have the necessary privileges, the Management Agent is installed in a subdirectory of the Oracle Application Server home directory.

1.2.1.3 Summary of the Important Directories in the Management Service Home

Figure 1-1 shows some of the important directories you should be familiar with in a typical Grid Control Console installation. You can use this information as you begin to maintain, troubleshoot, and configure the Oracle Management Service installation.

Figure 1-1 Important Oracle Management Service Installation Directories

Description of Figure 1-1 follows

Table 1-1 describes in more detail the Management Service directories shown in Figure 1-1. In the table, ORACLE_HOME refers to the Management Service home directory in which the Oracle Management Service is installed and deployed.

Table 1-1 Important Directories in the Management Service Oracle Home

DirectoryDescription

ORACLE_HOME/bin

The bin directory in the Oracle Application Server Home contains commands used to control the components of the Oracle Application Server J2EE and Web Cache installation, including the Application Server Control Console, which is used to monitor and configure Oracle Application Server instances.

Use the emctl command in this directory to start and stop the Application Server Control Console. For more information about the Application Server Control Console, see the Oracle Application Server Administrator's Guide.

ORACLE_HOME/sysman

The sysman directory in the Oracle Application Server Home contains the system management files associated with this Oracle Application Server Release 2 (9.0.4) installation.

Note that the ORACLE_HOME/sysman/log directory contains the Oracle Management Service log files (emoms.log) and trace files (emoms.trc).

ORACLE_HOME/opmn

This directory contains files used to control the Oracle Process Manager and Notification Server (OPMN) utility. OPMN can be used to start and stop the instances of Oracle Application Server Containers for J2EE (OC4J) associated with this instance of Oracle Application Server. The Oracle Management Service runs as an application in one of those OC4J instances.

ORACLE_HOME/j2ee

This directory contains the files associated with the OC4J instances running in this instance of Oracle Application Server. For example, you will notice a directory for the OC4J_EM instance, which is the OC4J instance used to deploy the Management Service J2EE Web application.

ORACLE_HOME/hostname

For real application cluster agent install, this directory contains sysman files.


1.2.2 Understanding the Enterprise Manager Directories Installed with the Management Agent

The Management Agent is installed automatically when you install the Grid Control Console. This local instance of the Management Agent gathers management information about the targets on the Management Service host. You can then manage those targets, such as the host itself, from the Grid Control Console.

The Management Agent is also available as its own install type. This enables you to install the Management Agent on the hosts throughout your enterprise. The Management Agent can then gather management data about the targets on each host so those targets can be managed from the Grid Control Console.

When you select the Additional Management Agent installation type, you install only the files required to run the Management Agent.

Specifically, the Management Agent files are installed into the same directory structure shown in the agent directory when you install the Oracle Management Service (Figure 1-1).

The directory that contains the files required to run the Management Agent is referred to as the AGENT_HOME directory. For example, to start or stop an Oracle Management Agent, you use the emctl command located in the bin directory of the AGENT_HOME. Similarly, to configure the log files for the Management Agent, you modify the configuration files in the sysman/config directory of the AGENT_HOME.

1.2.2.1 Summary of the Important Directories in the Management Agent Home

Table 1-2 describes some of the important subdirectories inside the AGENT_HOME directory.

Table 1-2 Important Directories in the AGENT_HOME Directory

DirectoryDescription

AGENT_HOME

The agent directory contains all the files required to configure and run the Oracle Management Agent on this host.

This directory serves as the Oracle Home for the Management Agent. Later in this document, this directory is referred to as the AGENT_HOME.

If you install only the Management Agent on a managed host, only the files in this directory are installed. For more information, see "Understanding the Enterprise Manager Directories Installed with the Management Agent".

AGENT_HOME/bin

The agent/bin directory in the Oracle Application Server Home contains the emctl command that controls the Management Agent for this host.

You use the emctl command in this directory to start and stop the Oracle Management Agent on this host.

AGENT_HOME/sysman/admin

This directory contains the files used by the Management Agent to define target types (such as databases, hosts, and so on), to run configuration scripts, and other administrative tasks.

AGENT_HOME/sysman/config

This directory contains the configuration files for the Management Agent. For example, this is where Enterprise Manager stores the emd.properties file. The emd.properties file defines settings such as the Management Service upload URL for this particular agent.

AGENT_HOME/sysman/log

This directory contains the log files for the Management Agent.

AGENT_HOME/hostname

For real application clusters, this directory contains all configuration, log files, and system files.


1.2.2.2 Understanding the Management Agent Directory Structure on Windows

When you install the Management Agent on a Windows system, the directory structure of the AGENT_HOME directory is the same as the directory structure for installations on a UNIX system.

For example, if you installed the Management Agent in the E:\oracle\em10gAgent directory of your Windows system, you can locate the emctl command for the Management Agent on a Windows system, by navigating to the following directory:

$PROMPT> E:\oracle\em10gAgent\bin

1.2.3 Understanding the Enterprise Manager Directories Installed with Oracle Application Server

When you install Oracle Application Server (Oracle Application Server), you also install the Oracle Enterprise Manager 10g Application Server Control Console. The Application Server Control Console provides you with the Enterprise Manager features required to manage your Oracle Application Server installation. As a result, the Oracle Application Server installation procedure installs a set of Enterprise Manager directories and files into each Oracle Application Server home directory.

In particular, the emctl commands required to control the Application Server Control Console are installed into the ORACLE_HOME/bin directory. The configuration and log files for the Application Server Control Console are installed into the ORACLE_HOME/sysman directory structure.

1.2.4 Understanding the Enterprise Manager Directories Installed with Oracle Database 10g

When you install Oracle Database 10g, you also install Oracle Enterprise Manager 10g Database Control. Database Control provides the tools you need to manage your Oracle Database 10g immediately after you install the database. As a result, the Oracle Database 10g installation procedure installs a set of Enterprise Manager directories and files into each Oracle Database 10g home directory.

In particular, the emctl commands required to control Database Control are installed into the ORACLE_HOME/bin directory.

The Management Agent and Management Service support files are installed in two locations in an Oracle Database 10g installation:

  • Files that are common and shared among all instances of the database are stored in the following directory of the Oracle Database 10g home:

    ORACLE_HOME/sysman
    
    

    For example, the administration files, which define the supported target types and the scripts used to perform Management Agent configuration tasks are stored in the ORACLE_HOME/sysman/admin directory.

  • Files that are unique to each instance of the database are stored in following directory of the Oracle Database 10g home:

    ORACLE_HOME/hostname_sid/ (for a single instance database)
    ORACLE_HOME/nodename_sid/ (for a cluster database)
    
    

    Throughout the rest of this guide, ORACLE_HOME/hostname_sid/ and ORACLE_HOME/nodename_sid/ may be used interchangeably. Both paths refer to the same concept – the Enterprise Manager directory for the specific database instance. The difference is that ORACLE_HOME/hostname_sid/ is used for single instance databases, while ORACLE_HOME/nodename_sid/ is used for cluster (RAC) databases. In cluster databases, nodename refers to the public name of the node, as specified during Cluster Ready Services (CRS) configuration for cluster environments.

    For example, if the database host name is mgmt1.acme.com and the system identifier for the database instance is db42, the log files for the Management Agent and Management Service for that instance are installed in the following directory:

    ORACLE_HOME/mgmt1.acme.com_db42/sysman/log
    

    If a hostname_sid directory does not exist in the Oracle Database 10g home directory, then Oracle Enterprise Manager 10g Database Control was never configured for the database instance.

In addition, the files required to deploy the Database Control as a J2EE application are installed into the ORACLE_HOME/oc4j/j2ee directory structure. Database Control is a J2EE application that is deployed using the standalone version of Oracle Application Server Containers for J2EE (OC4J). The OC4J_DBConsole directory contains the template files that are used to create database-specific deployment directories for each Database Control instance deployed in the Oracle home.

The installation and configuration files are stored in the ORACLE_HOME directory in the following sub-directories:

  • cfgtoollogs/cfgfw

  • cfgtoollogs/dbua

  • cfgtoollogs/netca

  • cfgtoollogs/rconfig

  • cfgtoollogs/dbca

  • cfgtoollogs/emca

  • cfgtoollogs/oui

  • cfgtoollogs/opatch

Figure 1-2 summarizes the location of the important Enterprise Manager directories in a typical Oracle Database 10g home directory. Note that references to hostname_sid are for single instance databases; cluster databases have paths of the form nodename_sid instead.

Figure 1-2 Important Enterprise Manager Directories in an Oracle Database 10g Installation

Description of Figure 1-2 follows

1.2.5 Tip for Identifying the Oracle Home When Using the emctl Command

When you install Grid Control, Oracle Application Server, or Oracle Database 10g, the resulting directory structure can often include multiple subdirectories with the same name. For example, you can have a bin directory within the AGENT_HOME directory. Use the emctl command within the AGENT_HOME/bin directory to control the Management Agent.

In addition, you can have a bin directory within the Management Service Oracle home. Use the emctl command in this directory to control the Management Service.

To quickly identify the Oracle home that is controlled by the files in a particular bin directory, use the following command:

$PROMPT> emctl getemhome

This command displays the path to the current Oracle home that will be affected by commands executed by this instance of the emctl command. For example, the following example shows how the current emctl command can be used to control the Management Service installed in the /dev1/private/em_ms_home1/ Oracle home:

$PROMPT> emctl getemhome
Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.
EMHOME=/dev1/private/em_ms_home1

1.2.6 Configuring Database Control During and After the Oracle Database 10g Installation

The following sections describe how Oracle Enterprise Manager 10g Database Control is configured during the Oracle Database 10g installation. These sections also describe how you can configure Database Control after the installation:

1.2.6.1 Configuring Database Control During Installation

If you create a database while installing Oracle Database 10g, you have the option of configuring your database so it can be managed by Oracle Enterprise Manager 10g Grid Control Console or by Oracle Enterprise Manager 10g Database Control Console.

Figure 1-3 shows the Management Options page, which allows you to select your database management options while installing Oracle Database 10g.

Figure 1-3 Selecting Your Management Options While Installing Oracle Database 10g

Description of Figure 1-3 follows

To select Grid Control Console as your management option, the Oracle Management Service must be installed on a network host. In addition, the Oracle Management Agent must be installed on the host where you are installing the database. Otherwise, the Grid Control Console option is unavailable and you must instead choose to manage your database with Database Control.

For most of the Oracle Database 10g installation types, you must choose either Database Control or Grid Control as your management option when you create a database during the installation.

However, if you create a database using one of the following methods, you can choose not to configure Database Control:

  • Choosing to create a database during a custom installation

  • Choosing the Advanced database configuration option during an Enterprise or Standard Edition installation

  • Running Database Configuration Assistant (DBCA) after the installation

If you do not configure Database Control during the Oracle Database 10g installation, no hostname_sid directory is created in the resulting Oracle home directory (Figure 1-2).

1.2.6.2 Configuring Database Control with DBCA

The primary method for configuring an existing Oracle Database 10g database so it can be managed with Database Control is to use DBCA. You can use DBCA to create a new database or to reconfigure an existing database.


See Also:

"Installing Oracle Software and Building the Database" in Oracle Database 2 Day DBA for more information about using DBCA to create a new database instance

To use DBCA to reconfigure your database so it can be managed with Database Control:

  1. Log into the database host as a member of the administrative group that is authorized to install Oracle software and create and run the database.

  2. Start DBCA, as follows:

    • On Windows, select Start, point to Programs, Oracle - home_name, Configuration and Migration Tools, and then select Database Configuration Assistant.

    • On UNIX, change directory to the ORACLE_HOME/bin directory and enter the following command:

      $PROMPT> ./dbca
      
      

    The DBCA Welcome page appears.

  3. Advance to the Operations page and select Configure Database Options.

  4. Advance to the Database page and select the database you want to configure.

  5. Advance to the Management Options page (Figure 1-4) and select the following options:

    • Configure the Database with Enterprise Manager

    • Use Database Control for Database Management

  6. Optionally, select the options for enabling e-mail notifications and enabling daily backups.

    For more information about Enterprise Manager notifications and daily backups, click Help on the Management Options page.

  7. Advance until the Finish button is available.

  8. Click Finish to reconfigure the database so it uses Database Control.

    After DBCA reconfigures the database, a new subdirectory appears in the Oracle home. This directory is named using the following format and contains Database Control configuration and state files specific to the database you just configured:

    hostname_sid
    
    

    For example:

    mgmthost1.acme.com_myNewDB
    
    

    Note that for cluster databases, the directories are named nodename_sid.

Figure 1-4 Management Options Page in DBCA

Description of Figure 1-4 follows

1.2.6.3 Configuring Database Control with EMCA

When you use DBCA to configure Oracle Database 10g, DBCA provides a graphical user interface to help you select Database Control options and to configure other aspects of your database.

However, if you want to use the operating system command line to configure Database Control, you can use the Enterprise Manager Configuration Assistant (EMCA).

To configure Database Control with EMCA:

  1. Set the following environment variables to identify the Oracle home and the system identifier (SID) for the database you want to manage:

    • ORACLE_HOME

    • ORACLE_SID

  2. Change directory to the ORACLE_HOME/bin directory.

  3. Start EMCA by entering the following command with any of the optional command-line arguments shown in Table 1-3:

    $PROMPT> ./emca 
    
    

    Depending upon the arguments you include on the EMCA command line, EMCA prompts you for the information required to configure Database Control.

    For example, enter the following command to configure Database Control so it will perform automatic daily backups of your database:

    $PROMPT> ./emca -config dbcontrol db -backup
    
    

EMCA commands are of the form:

emca [operation] [mode] [flags] [parameters]

Note:

To configure Database Console for single instance database using ASM, no extra parameters need to be passed along with the EMCA command. Run the following command to configure the Database Console which will automatically detect the ASM instance:
emca -config dbcontrol db -repos create

Table 1-3 describes the valid execution operations and modes, and lists the optional parameters in brackets. Table 1-4 discusses the flags and their behavior, while Table 1-5 defines the optional parameters in detail. EMCA parameters are of the form [ -parameterName parameterValue ]. Multiple parameters can be used in combination at the command line.

Table 1-3 EMCA Command-Line Operations

CommandDescription

emca -h | --h | -help | --help

Use this option to display the Help message for the EMCA utility. The options described in Table 1-3, Table 1-4, andTable 1-5, and the valid parameters you may include are listed.

emca –version

Prints the version information associated with EMCA.

emca -config dbcontrol db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [parameters]

Configures Database Control for a database. Options include creating (or recreating) Database Control repository, configuring automatic backups, and performing these operations on a cluster database.

emca -config centralAgent (db | asm) [-cluster] [-silent] [parameters]

Configures central agent management for a database or an Automatic Storage Management (ASM) instance. Options include performing this operation on a cluster environment.This operation will configure the database so that it can be centrally managed by the Oracle Enterprise Manager 10g Grid Control Console. To use this option, you must have previously installed the Oracle Management Service component of Enterprise Manager on a network host. In addition, the Oracle Management Agent must be installed on the host where you are running the database.

emca -config all db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [parameters]

Configures both Database Control and central agent management for a database. The possible configuration options are similar to those described above.

emca -deconfig dbcontrol db [-repos drop] [-cluster] [-silent] [parameters]

Deconfigures Database Control for a database. Options include dropping the Database Control repository and performing these operations on a cluster database. For example, you might use this command to remove the Database Control configuration from a database you are planning to delete. In such a scenario, remove the Database Control configuration before physically deleting the database. This operation does not remove the actual database or its data files.

emca -deconfig centralAgent (db | asm) [-cluster] [ -silent] [parameters]

Deconfigures central agent management for a database or an ASM instance. Options include performing this operation on a cluster environment. For example, you might use this command to remove the central agent management configuration from a database you are planning to delete. In such a scenario, remove the central agent management configuration before physically deleting the database. This operation does not remove the actual database or its data files.

emca -deconfig all db [-repos drop] [-cluster] [-silent] [parameters]

Deconfigures both Database Control and central agent management for a database. The possible deconfiguration options are similar to those described above.

emca -addInst (db | asm) [-silent] [parameters]

Configures Enterprise Manager for a new cluster instance of a database or ASM storage. For more information, refer to Section 1.2.6.5.

emca -deleteInst (db | asm) [-silent] [parameters]

Deconfigures Enterprise Manager for a specific instance of a cluster database or ASM storage. This is discussed further below, in Section 1.2.6.5.

emca -reconfig ports [-cluster] [parameters]

Explicitly reassigns Database Control ports. Options include performing this operation on a cluster environment. For more information, refer to Section 1.2.6.6.

emca -reconfig dbcontrol -cluster [-silent] [parameters]

Reconfigures Database Control deployment for a cluster database. Note that this command must be used with the "-cluster" option. For more information, refer to Section 1.2.6.5.

emca -displayConfig dbcontrol -cluster [-silent] [parameters]

Displays information about the current deployment configuration of Database Control in a cluster environment. Note that this command must be used with the "-cluster" option. For more information, refer to Section 1.2.6.5.

emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]

Upgrades the configuration of an earlier version of Enterprise Manager to the current version. This operation can be performed for database, ASM, or database and ASM instances together simultaneously. This does not upgrade the actual database or ASM instances, nor does it upgrade the Enterprise Manager software. Instead, it upgrades the configuration files for the specified instance so that they are compatible with the current version of the Enterprise Manager software. EMCA will attempt to upgrade all instances of the specified database and/or ASM target on the host, across all Oracle Homes (since it is likely that certain target properties, such as listener port or Oracle Home, have changed).

emca -restore (db | asm | db_asm) [-cluster] [-silent] [parameters]

Restores the current version of Enterprise Manager configuration to an earlier version. This is the inverse of the "-upgrade" option (and will reverse any changes that result from an "-upgrade" operation), and as such, the options are similar.


Table 1-4 EMCA Command-Line Flags

FlagDescription

db

Performs the operation for a database (including cluster databases). Use this option for databases that use Automatic Storage Management (ASM) to store the data files. If a database is using ASM, all the configuration operations and modes described above (except for "-upgrade" and "-restore") will detect this automatically and apply the changes to both the database and ASM instance(s).

asm

Performs the operation for an ASM-only instance (including cluster ASM instances).

db_asm

This flag can only be used in "-upgrade" and "-restore" mode. Performs the upgrade/restore operation for a database and an ASM instance together. Database and ASM instances may be upgraded or restored separately (that is, upgrading an ASM instance does not require upgrading the database instances it services). Hence, the Enterprise Manager configuration can be upgraded or restored separately for a database and its respective ASM instance.

-repos create

Creates a new Database Control management repository.

-repos drop

Drops the current Database Control management repository.

-repos recreate

Drops the current Database Control management repository and then recreates a new one.

-cluster

Performs the operation for a cluster database or ASM instance.

-silent

Performs the operation without prompting for additional information. If this mode is specified, all the required parameters must be entered at the command line or specified in an input file using the –respFile argument. You can view a list of the available parameters by entering emca -help at the command line.

-backup

Configures automatic backup for a database. EMCA will prompt for daily automatic backup options. The default Enterprise Manager settings will be used to backup the database files.

Note: If you use this option, EMCA will use the value of the db_recovery_file_dest initialization parameter to identify the flashback recovery area for the automated backups. If that parameter is not set, EMCA will generate an error. You can modify these settings later using the Maintenance page in Database Control. For more information, see the Database Control online Help.


Table 1-5 EMCA Command-Line Parameters

ParameterDescription

-respFile

Specifies the path of an input file listing parameters for EMCA to use while performing its configuration operation. For more information, refer to Section 1.2.6.4.

-SID

Database system identifier

-PORT

Port number for the listener servicing the database

-ORACLE_HOME

Database Oracle Home, as an absolute path

-LISTENER_OH

Oracle Home from where the listener is running. If the listener is running from an Oracle Home other than the one on which the database is running, the parameter LISTENER_OH must be specified.

-HOST_USER

Host machine user name (for automatic backup)

-HOST_USER_PWD

Host machine user password (for automatic backup)

-BACKUP_SCHEDULE

Schedule in the form of "HH:MM" (for daily automatic backups)

-EMAIL_ADDRESS

E-mail address for notifications

-MAIL_SERVER_NAME

Outgoing Mail (SMTP) server for notifications

-ASM_OH

Automatic Storage Management Oracle Home

-ASM_SID

System identifier for ASM instance

-ASM_PORT

Port number for the listener servicing the ASM instance

-ASM_USER_ROLE

User role for connecting to the ASM instance

-ASM_USER_NAME

User name for connecting to the ASM instance

-ASM_USER_PWD

Password for connecting to the ASM instance

-DBSNMP_PWD

Password for DBSNMP user

-SYSMAN_PWD

Password for SYSMAN user

-SYS_PWD

Password for SYS user

-SRC_OH

Oracle Home of the database with Enterprise Manager configuration to be upgraded/restored

-DBCONTROL_HTTP_PORT

Use this parameter to specify the port you use to display the Database Control Console in your Web browser. For more information, refer to Section 1.2.6.6.

-AGENT_PORT

Use this parameter to specify the Management Agent port for Database Control. For more information, refer to Section 1.2.6.6.

-RMI_PORT

Use this parameter to specify the RMI port for Database Control. For more information, refer to Section 1.2.6.6.

-JMS_PORT

Use this parameter to specify the JMS port for Database Control. For more information, refer to Section 1.2.6.6.

-CLUSTER_NAME

Cluster name (for cluster databases)

-DB_UNIQUE_NAME

Database unique name (for cluster databases)

-SERVICE_NAME

Database service name (for cluster databases)

-EM_NODE

Node from which Database Control console is to be run (for cluster databases). For more information, refer to Section 1.2.6.5.

-EM_SID_LIST

Comma-separated list of SIDs for agent-only configurations, uploading data to –EM_NODE. For more information, refer to Section 1.2.6.5.


1.2.6.4 Using an Input File for EMCA Parameters

Instead of answering a series of prompts when you run EMCA, you can use the -respFile argument to specify an input file. The input file you create must be in a format similar to the following example:

PORT=1521
SID=DB
DBSNMP_PWD=xpE234D
SYSMAN_PWD=KDOdk432

After you create an EMCA input file, you can use it on the command line as follows:

$PROMPT> ./emca -config dbcontrol db -respFile input_file_path

For example, to configure the Database Control to perform daily backups and create the Database Control Management Repository, create an input file similar to the one shown in and enter the following command at the operating system prompt:

$PROMPT> ./emca -config dbcontrol db -repos create -backup -respFile input_file_path

Example 1-1 EMCA Input File that Configures Database Control for Automatic Backup and Creates the Database Control Management Repository

PORT=1521
SID=DB
DBSNMP_PWD=dow3l224
SYSMAN_PWD=squN3243
HOST_USER=johnson
HOST_USER_PWD=diTf32of
SYS_PWD=qlKj4352
BACKUP_SCHEDULE=06:30

1.2.6.5 Using EMCA with Real Application Clusters

Oracle Real Application Clusters (RAC) provides a high availability database environment spanning multiple hosts. Each cluster may be made up of multiple cluster databases, each of which consists of multiple cluster database instances. A cluster database is available as long as one of its instances is available.

Each EMCA command can be used in Real Application Clusters environments; certain commands are only applicable in cluster setups. To indicate that you have a cluster database, use the –cluster flag which is available in almost every EMCA operational mode.

When you use EMCA to configure Database Control for Real Application Clusters, you configure the Database Control for each instance in the cluster. However, by default, the Database Control Console will only start on the local node. On every other node of the cluster, only the Enterprise Manager agent will start. This is because the Database Control Console opens a number of connections to the database. If an instance of the console is running on every host in the cluster, then you may easily exceed the maximum number of permitted open connections on a 32-node or 64-node environment.

To remedy this, the Database Control Console is only started on the local node. On every other node, the commands emctl start dbconsole and emctl stop dbconsole only start and stop the agent. Each of the remote agents will upload their respective data to the console running on the local node, from where you can monitor and manage all the targets in the cluster. On each instance of the RAC database, the following subdirectories will be created:

L
$ORACLE_HOME/hostname1.domainname_SID1
$ORACLE_HOME/hostname2.domainname_SID2
.
.
$ORACLE_HOME/hostnamen.domainname_SIDn

where <SID1>...<SIDn> are database system identifiers.

However, note that if you upgrade a 10g Release 1 cluster database (configured with Database Control) to 10g Release 2, the 10g Release 1 Database Control configuration will be retained. The 10g Release 1 Database Control has a Database Console running on each node for the real-application cluster. The console will still be started on each individual node. If you wish to modify the configuration, use the following command:

emca -reconfig dbcontrol –cluster –EM_NODE <nodename> -EM_SID_LIST <SID list>

where <nodename> is the public name of the node and <SID list> is a comma-separated list of database system identifiers. This command reconfigures the current Database Control setup and:

  1. Starts a Database Control Console on <nodename>, if one has not been started yet.

  2. Redirects the agents monitoring the database instances in <SID list> so that they upload their data to the console running on <nodename>. Also, agents monitoring database instances on <nodename> will also upload their data to the local console. Note that if you do not pass -EM_NODE or -EM_SID_LIST at the command line, you will be prompted for them.

-EM_NODE defaults to the local node if not specified when prompted. -EM_SID_LIST defaults to all database instances if not specified.

You may use this command to start the console on more than one node. For instance, on an 8-node cluster with <node1, node2, node3, node4, node5, node6, node7, node8> and database instances <oradb1, oradb2, oradb3, oradb4, oradb5, oradb6, oradb7, oradb8>, you can run the following commands in succession:

$PROMPT> emca -reconfig dbcontrol –cluster –EM_NODE node1 -EM_SID_LIST oradb2,oradb3,oradb4
$PROMPT> emca -reconfig dbcontrol –cluster –EM_NODE node5 -EM_SID_LIST oradb6,oradb7,oradb8

In this scenario, there will be two Database Control consoles running, one on node1 and the other on node5. From either of these consoles, you can manage and monitor all targets in the cluster.

For information on the current cluster configuration, you can run:

emca -displayConfig dbcontrol –cluster

The above command prompts for the database unique name for the cluster database. This will print the current configuration onto the screen, indicating the nodes that have consoles running on them and the consoles where each agent is uploading.

For configuring Enterprise Manager for a new cluster instance of a database or ASM storage, use the following command:

emca -addInst db

On cluster databases, another common operation is the creation and deletion of database instances. After you create a new instance, you can run EMCA to configure Database Control or central agent management for that instance using the command emca -addInst db. Running EMCA does not create the actual database instance; it only configures Enterprise Manager so that you can manage the instance in a way consistent with the rest of the cluster database instances. When configuring Enterprise Manager for a new instance, run the EMCA command only after you have created the instance. Also, run the command from a node in the cluster that already has Enterprise Manager configured for its associated database instance, as these configuration settings will be propagated to the new instance. Do not run this command from the node on which the new instance was created. Note that this option can be used only in a Real Application Clusters environment, so you do not need to use the -cluster option on the command line. After running the command emca -addInst db, enter the following information for the node and database:

Node name: node2
Database Unique Name: EM102
Database SID: EM1022

To deconfigure Enterprise Manager for a specific database instance (typically before the database instance is deleted), use the inverse command, emca -deleteInst db. Running EMCA does not delete the database instance; it only removes the Enterprise Manager configuration so that you will no longer be able to manage the instance with Enterprise Manager. Ensure that you run the EMCA command before you delete the actual cluster database instance. Also, ensure that you run the command from a different node and not from the node on which the database instance will be deleted. Note that this option can be used only in a Real Application Clusters environment, so you do not need to use the -cluster option on the command line.

For more information, see Table 1-3 which describes EMCA command-line operations.


Caution:

If you use emca -c to configure the Database Control for Real Application Clusters, check TNS_ADMIN on all cluster nodes. If different TNS_ADMIN are set for each node, the listener for the target acnnot be configured correctly. If so, set the same TNS_ADMIN on all cluster nodes before executing the emca -c command.

1.2.6.6 Specifying the Ports Used By the Database Control

When you initially install Oracle Database 10g or configure the Database Control with EMCA, the Database Control uses a set of default system ports. For example, by default, you access Database Control using port 1158 in 10g Release 2, as in:

http://host.domain:1158/em

This is the default port assigned to Database Control by the Internet Assigned Numbers Authority (IANA). Likewise, the default Database Control Agent port, as assigned by the IANA, is 3938.

To use ports other than the default ports, use the following EMCA command-line arguments when you initially configure the Database Control with EMCA. Alternatively, you can explicitly assign ports after configuring Database Control using the following command:

emca -reconfig ports [-cluster]

Note:

You can also use the following EMCA command-line arguments to configure Database Control after you have installed and configured Oracle Database 10g.

The following list summarizes the EMCA command-line arguments that control the standard Database Control port assignments:

  • -DBCONTROL_HTTP_PORT <port_number>

    This port number is used in the Database Control Console URL. For example, if you set this port to 5570, you can then display the Database Control Console using the following URL:

    http://host.domain:5570/em
    
    
  • -RMI_PORT <port_number>

    This port number is used by the Remote Method Invocation (RMI) system, which is part of the J2EE software required by Database Control. The default port can be changed if the user wants to configure a specific port for Database Console. When a port other than the default port (1521) is used, use the -RMI_PORT or -JMS_PORT options along with the emca reconfig command.

  • -JMS_PORT <port_number>

    This port is used by the OC4J Java Message Service (JMS), which is part of the J2EE software required by Database Control. The default port can be changed if the user wants to configure a specific port for Database Console. When a port other than the default port (1521) is used, use the -RMI_PORT or -JMS_PORT options along with the emca reconfig command.

  • -AGENT_PORT <port_number>

    This port is used by the Database Control Management Agent, which is monitoring and administering the database for the Database Control.

1.2.6.7 EMCA Troubleshooting Tips

The following section describes some troubleshooting tips to consider when using EMCA to configure the Database Control:

1.2.6.7.1 Using EMCA After Changing the Database Listener Port

If you change the listener port of the database after you have configured Database Control, the database status will appear as down. To reconfigure Database Control so it uses the new listener port, run the EMCA command using the -config dbcontrol db [-cluster] command-line arguments.

1.2.6.7.2 Upgrading Database or ASM Instances with 10g Release 2 Grid Control Agents

When upgrading a 10g Release 1 database and/or ASM instance that was configured for Oracle Enterprise Manager (either Database Control or a Grid Control central agent) to 10g Release 2, all Enterprise Manager targets on the relevant host(s) referring to the upgraded instance(s) will be updated automatically. This is because the upgrade involves altering the instance's Oracle Home, port, or other target-associated properties. However, some of these targets on the host(s) will not be updated successfully during the upgrade if they are managed by a 10g Release 2 Grid Control Agent. To update these targets, in the Home page for the upgraded database (or ASM) target, click the "Monitoring Configuration" link. On this page, you can update the required properties such as Oracle Home, listener port and so on to the correct values.

1.2.6.7.3 Using EMCA When Database Host Name or IP Address Changes

When the database host name (including the domain name) or the IP address changes, deconfigure and then reconfigure the Database Console with the repository create command. Run the following command:

emca -deconfig dbcontrol db -repos drop
emca -config dbcontrol db -repos create

or

emca -deconfig dbcontrol db
emca -config dbcontrol db -repos recreate

1.2.6.7.4 Using EMCA When the TNS Configuration Is Changed

When the TNS configuration is changed, set the environment variable and then run the following command:

emca -config dbcontrol db

1.3 Enabling Enterprise Manager Accessibility Features

As part of the effort to make Oracle products, services, and supporting documentation accessible and usable to the disabled community, Enterprise Manager offers several features that make management data available to users of assistive technology.

To enable these features and provide for full accessibility, you must modify two configuration settings, which are described in the following sections:

1.3.1 Enabling Enterprise Manager Accessibility Mode

Enterprise Manager takes advantage of user interface development technologies that improve the responsiveness of some user operations. For example, when you navigate to a new record set in a table, Enterprise Manager does not redisplay the entire HTML page.

However, this performance-improving technology is generally not supported by screen readers. To disable this feature, and as a result, make the Enterprise Manager HTML pages more accessible for disabled users, use the following procedure.


Note:

The following procedure is valid for both Grid Control Console and Database Control installations. Differences in the location of configuration files is noted where applicable.

For information on enabling accessibility for the Application Server Control Console, see "Managing and Configuring the Application Server Control" in the Oracle Application Server Administrator's Guide.


  1. Locate the uix-config.xml configuration file.

    To locate the uix-config.xml file in a Grid Control Console installation, change directory to the following location in the Management Service home:

    ORACLE_HOME/j2ee/OC4J_EM/applications/em/em/WEB-INF (Grid Control)
    
    

    To locate the uix-config.xml file in a Oracle Database 10g installation, change directory to the following location in the database home:

    ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/WEB-INF (Database Control)
    
    
  2. Open the uix-config.xml file using a text editor and locate the following entry:

    <!-- An alternate configuration that disables accessibility features  -->
    <default-configuration>
      <accessibility-mode>inaccessible</accessibility-mode>
    </default-configuration>
    
    
  3. Change the value of the accessibility-mode property from inaccessible to accessible.

  4. Save and close the file.

  5. Restart the Oracle Management Service (if you are modifying a Grid Control Console installation) or restart the Database Control (if you are modifying an Oracle Database 10g installation).

1.3.2 Providing Textual Descriptions of Enterprise Manager Charts

Throughout Enterprise Manager, charts are used to display performance data. For most users, these charts provide a valuable graphical view of the data that can reveal trends and help identify minimum and maximum values for performance metrics.

However, charts do not convey information in a manner that can be read by a screen reader. To remedy this problem, you can configure Enterprise Manager to provide a complete textual representation of each performance chart. By default, support for the textual representation of charts is disabled. When textual description for charts is enabled, Enterprise Manager displays a small icon for each chart that can be used as a drill-down link to the textual representation.

Figure 1-5 shows an example of the icon that displays beneath Enterprise Manager charts when you have enabled the textual representation of charts.

Figure 1-5 Icon Representing the Textual Representation of a Chart

Description of Figure 1-5 follows

To enable the drill-down icon for the textual representation of charts:

  1. Locate the web.xml configuration file.

    To locate the web.xml file in a Grid Control Console installation, change directory to the following location in the Management Service home:

    ORACLE_HOME/j2ee/OC4J_EM/applications/em/em/WEB-INF
    
    

    To locate the web.xml file in a Oracle Database 10g installation, change directory to the following location in the database home:

    ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/WEB-INF
    
    
  2. Open the web.xml file with your favorite text editor and locate the following six lines of the file:

    <!-- Uncomment this to enable textual chart descriptions
    <context-param>
    <param-name>enableChartDescription</param-name>
    <param-value>true</param-value>
    </context-param>
    -->
    
    
  3. Remove comments from this section by deleting the first line and the last line of this section so that the section consists of only these 4 lines:

    <context-param>
    <param-name>enableChartDescription</param-name>
    <param-value>true</param-value>
    </context-param>
    
    
  4. Save and exit the file.

  5. Restart the Management Service (if you are modifying a Grid Control Console installation) or restart the Database Control (if you are modifying an Oracle Database 10g installation).

PKJSMLPK^UIOEBPS/configs.htm Grid Control Common Configurations

3 Grid Control Common Configurations

Oracle Enterprise Manager 10g Grid Control is based on a flexible architecture, which allows you to deploy the Grid Control components in the most efficient and practical manner for your organization. This chapter describes some common configurations that demonstrate how you can deploy the Grid Control architecture in various computing environments.

The common configurations are presented in a logical progression, starting with the simplest configuration and ending with a complex configuration that involves the deployment of high availability components, such as load balancers, Oracle Real Application Clusters, and Oracle Data Guard.

This chapter contains the following sections:

3.1 About Common Configurations

The common configurations described in this chapter are provided as examples only. The actual Grid Control configurations that you deploy in your own environment will vary depending upon the needs of your organization.

For instance, the examples in this chapter assume you are using the OracleAS Web Cache port to access the Grid Control Console. By default, when you first install Grid Control, you display the Grid Control Console by navigating to the default OracleAS Web Cache port. In fact, you can modify your own configuration so administrators bypass OracleAS Web Cache and use a port that connects them directly to the Oracle HTTP Server.

For another example, in a production environment you will likely want to implement firewalls and other security considerations. The common configurations described in this chapter are not meant to show how firewalls and security policies should be implemented in your environment.


See Also:

Chapter 5, "Enterprise Manager Security" for information about securing the connections between Grid Control components

Chapter 6, "Configuring Enterprise Manager for Firewalls" for information about configuring firewalls between Grid Control components


Besides providing a description of common configurations, this chapter can also help you understand the architecture and flow of data among the Grid Control components. Based on this knowledge, you can make better decisions about how to configure Grid Control for your specific management requirements.

The Grid Control architecture consists of the following software components:

  • Oracle Management Agent

  • Oracle Management Service

  • Oracle Management Repository

  • Oracle Enterprise Manager 10g Grid Control Console


    See Also:

    Oracle Enterprise Manager Concepts for more information about each of the Grid Control components

The remaining sections of this chapter describe how you can deploy these components in a variety of combinations and across a single host or multiple hosts.

3.2 Deploying Grid Control Components on a Single Host

Figure 3-1 shows how each of the Grid Control components are configured to interact when you install Grid Control on a single host. This is the default configuration that results when you use the Grid Control installation procedure to install the Enterprise Manager 10g Grid Control Using a New Database installation type.

Figure 3-1 Grid Control Components Installed on a Single Host

Description of Figure 3-1 follows

When you install all the Grid Control components on a single host, the management data travels along the following paths:

  1. Administrators use the Grid Control Console to monitor and administer the managed targets that are discovered by the Management Agents on each host. The Grid Control Console uses the default OracleAS Web Cache port (for example, port 7777 on UNIX systems and port 80 on Windows systems) to connect to the Oracle HTTP Server. The Management Service retrieves data from the Management Repository as it is requested by the administrator using the Grid Control Console.


    See Also:

    Oracle Application Server Web Cache Administrator's Guide for more information about the benefits of using OracleAS Web Cache

  2. The Management Agent loads its data (which includes management data about all the managed targets on the host, including the Management Service and the Management Repository database) by way of the Oracle HTTP Server upload URL. The Management Agent uploads data directly to Oracle HTTP Server and bypasses OracleAS Web Cache. The default port for the upload URL is 4889 (it if is available during the installation procedure). The upload URL is defined by the REPOSITORY_URL property in the following configuration file in the Management Agent home directory:

    AGENT_HOME/sysman/config/emd.properties (UNIX)
    AGENT_HOME\sysman\config\emd.properties (Windows)
    
    

    See Also:

    "Understanding the Enterprise Manager Directory Structure" for more information about the AGENT_HOME directory

  3. The Management Service uses JDBC connections to load data into the Management Repository database and to retrieve information from the Management Repository so it can be displayed in the Grid Control Console. The Management Repository connection information is defined in the following configuration file in the Management Service home directory:

    ORACLE_HOME/sysman/config/emoms.properties (UNIX)
    ORACLE_HOME\sysman\config\emoms.properties (Windows)
    
    

    See Also:

    "Reconfiguring the Oracle Management Service" for more information on modifying the Management Repository connection information in the emoms.properties file

  4. The Management Service sends data to the Management Agent by way of HTTP. The Management Agent software includes a built-in HTTP listener that listens on the Management Agent URL for messages from the Management Service. As a result, the Management Service can bypass the Oracle HTTP Server and communicate directly with the Management Agent. If the Management Agent is on a remote system, no Oracle HTTP Server is required on the Management Agent host.

    The Management Service uses the Management Agent URL to monitor the availability of the Management Agent, submit Enterprise Manager jobs, and other management functions.

    The Management Agent URL can be identified by the EMD_URL property in the following configuration file in the Management Agent home directory:

    AGENT_HOME/sysman/config/emd.properties (UNIX)
    AGENT_HOME\sysman\config\emd.properties (Windows)
    
    

    For example:

    EMD_URL=http://host1.acme.com:1831/emd/main/
    
    

    In addition, by default, the name of the Management Agent as it appears in the Grid Control Console consists of the Management Agent host name and the port used by the Management Agent URL.

3.3 Managing Multiple Hosts and Deploying a Remote Management Repository

Installing all the Grid Control components on a single host is an effective way to initially explore the capabilities and features available to you when you centrally manage your Oracle environment.

A logical progression from the single-host environment is to a more distributed approach, where the Management Repository database is on a separate host and does not compete for resources with the Management Service. The benefit in such a configuration is scalability; the workload for the Management Repository and Management Service can now be split. This configuration also provides the flexibility to adjust the resources allocated to each tier, depending on the system load. (Such a configuration is shown in Figure 3-2.) See Section 3.4.2.1, "Monitoring the Load on Your Management Service Installations" for additional information.

Figure 3-2 Grid Control Components Distributed on Multiple Hosts with One Management Service

Description of Figure 3-2 follows

In this more distributed configuration, data about your managed targets travels along the following paths so it can be gathered, stored, and made available to administrators by way of the Grid Control Console:

  1. Administrators use the Grid Control Console to monitor and administer the targets just as they do in the single-host scenario described in Section 3.2.

  2. Management Agents are installed on each host on the network, including the Management Repository host and the Management Service host. The Management Agents upload their data to the Management Service by way of the Management Service upload URL, which is defined in the emd.properties file in each Management Agent home directory. The upload URL bypasses OracleAS Web Cache and uploads the data directly through the Oracle HTTP Server.

  3. The Management Repository is installed on a separate machine that is dedicated to hosting the Management Repository database. The Management Service uses JDBC connections to load data into the Management Repository database and to retrieve information from the Management Repository so it can be displayed in the Grid Control Console. This remote connection is defined in the emoms.properties configuration file in the Management Service home directory.

  4. The Management Service communicates directly with each remote Management Agent over HTTP by way of the Management Agent URL. The Management Agent URL is defined by the EMD_URL property in the emd.properties file of each Management Agent home directory. As described in Section 3.2, the Management Agent includes a built-in HTTP listener so no Oracle HTTP Server is required on the Management Agent host.

3.4 Using Multiple Management Service Installations

In larger production environments, you may find it necessary to add additional Management Service installations to help reduce the load on the Management Service and improve the efficiency of the data flow.


Note:

When you add additional Management Service installations to your Grid Control configuration, be sure to adjust the parameters of your Management Repository database. For example, you will likely need to increase the number of processes allowed to connect to the database at one time. Although the number of required processes will vary depending on the overall environment and the specific load on the database, as a general guideline, you should increase the number of processes by 40 for each additional Management Service.

For more information, see the description of the PROCESSES initialization parameter in the Oracle Database Reference.


The following sections provide more information about this configuration:

3.4.1 Understanding the Flow of Management Data When Using Multiple Management Services

Figure 3-3 shows a typical environment where an additional Management Service has been added to improve the scalability of the Grid Control environment.

Figure 3-3 Grid Control Architecture with Multiple Management Service Installations

Description of Figure 3-3 follows

In a multiple Management Service configuration, the management data moves along the following paths:

  1. Administrators can use one of two URLs to access the Grid Control Console. Each URL refers to a different Management Service installation, but displays the same set of targets, all of which are loaded in the common Management Repository. Depending upon the host name and port in the URL, the Grid Control Console obtains data from the Management Service (by way of OracleAS Web Cache and the Oracle HTTP Server) on one of the Management Service hosts.

  2. Each Management Agent uploads its data to a specific Management Service, based on the upload URL in its emd.properties file. That data is uploaded directly to the Management Service by way of Oracle HTTP Server, bypassing OracleAS Web Cache.

    Whenever more than one Management Service is installed, it is a best practice to have the Management Service upload to a shared directory. This allows all Management Service processes to manage files that have been downloaded from any Management Agent. Configure this functionality from the command line of each Management Service process as follows:

    emctl config oms loader -shared <yes|no> -dir <load directory>


    Note:

    By adding a load balancer, you can avoid the following problems:
    • Should the Management Service fail, any Management Agent connected to it cannot upload data.

    • Because user accounts only know about one Management Service, users lose connectivity should the Management Service go down even if the other Management Service is up.

    See Section 3.5, "High Availability Configurations" for information regarding load balancers.


  3. Each Management Service communicates by way of JDBC with a common Management Repository, which is installed in a database on a dedicated Management Repository host. Each Management Service uses the same database connection information, defined in the emoms.properties file, to load data from its Management Agents into the Management Repository. The Management Service uses the same connection information to pull data from the Management Repository as it is requested by the Grid Control Console.

  4. Any Management Service in the system can communicate directly with any of the remote Management Agents defined in the common Management Repository. The Management Services communicate with the Management Agents over HTTP by way of the unique Management Agent URL assigned to each Management Agent.

    As described in Section 3.2, the Management Agent URL is defined by the EMD_URL property in the emd.properties file of each Management Agent home directory. Each Management Agent includes a built-in HTTP listener so no Oracle HTTP Server is required on the Management Agent host.

3.4.2 Determining When to Use Multiple Management Service Installations

Management Services not only exist as the receivers of upload information from Management Agents. They also retrieve data from the Management Repository. The Management Service renders this data in the form of HTML pages, which are requested by and displayed in the client Web browser. In addition, the Management Services perform background processing tasks, such as notification delivery and the dispatch of Enterprise Manager jobs.

As a result, the assignment of Management Agents to Management Services must be carefully managed. Improper distribution of load from Management Agents to Management Services may result in perceived:

  • Sluggish user interface response

  • Delays in delivering notification messages

  • Backlog in monitoring information being uploaded to the Management Repository

  • Delays in dispatching jobs

The following sections provide some tips for monitoring the load and response time of your Management Service installations:

3.4.2.1 Monitoring the Load on Your Management Service Installations

To keep the workload evenly distributed, you should always be aware of how many Management Agents are configured per Management Service and monitor the load on each Management Service.

At any time, you can view a list of Management Agents and Management Services using Setup on the Grid Control console.

Use the charts on the Overview page of Management Services and Repository to monitor:

  • Loader backlog (files)

    The Loader is part of the Management Service that pushes metric data into the Management Repository at periodic intervals. If the Loader Backlog chart indicates that the backlog is high and Loader output is low, there is data pending load, which may indicate a system bottleneck or the need for another Management Service. The chart shows the total backlog of files totaled over all Oracle Management Services for the past 24 hours. Click the image to display loader backlog charts for each individual Management Service over the past 24 hours.

  • Notification delivery backlog

    The Notification Delivery Backlog chart displays the number of notifications to be delivered that could not be processed in the time allocated. Notifications are delivered by the Management Services. This number is summed across all Management Services and is sampled every 10 minutes. The graph displays the data for the last 24 hours. It is useful for determining a growing backlog of notifications. When this graph shows constant growth over the past 24 hours, then consider adding another Management Service, reducing the number of notification rules, and verifying that all rules and notification methods are useful and valid.

3.4.2.2 Monitoring the Response Time of the Enterprise Manager Web Application Target

The information on the Management Services and Repository page can help you determine the load being placed on your Management Service installations. More importantly, consider how the performance of your Management Service installations is affecting the performance of the Grid Control Console.

Use the EM Website Web Application target to review the response time of the Grid Control Console pages:

  1. From the Grid Control Console, click the Targets tab and then click the Web Applications subtab.

  2. Click EM Website in the list of Web Application targets.

  3. In the Key Test Summary table, click homepage. The resulting page provides the response time of the Grid Control Console homepage URL.


    See Also:

    The Enterprise Manager online help for more information about using the homepage URL and Application Performance Management (also known as Application Performance Monitoring) to determine the performance of your Web Applications

  4. Click Page Performance to view the response time of some selected Grid Control Console pages.


    Note:

    The Page Performance page provides data generated only by users who access the Grid Control Console by way of the OracleAS Web Cache port (usually, 7777).

  5. Select 7 Days or 31 Days from the View Data menu to determine whether or not there are any trends in the performance of your Grid Control installation.

    Consider adding additional Management Service installations if the response time of all pages is increasing over time or if the response time is unusually high for specific popular pages within the Grid Control Console.


Note:

You can use Application Performance Management and Web Application targets to monitor your own Web applications. For more information, see Chapter 7, "Configuring Services".

3.5 High Availability Configurations

When you configure Grid Control for high availability, your aim is to protect each component of the system, as well as the flow of management data in case of performance or availability problems, such as a failure of a host or a Management Service.

One way to protect your Grid Control components is to use high availability software deployment techniques, which usually involve the deployment of hardware load balancers, Oracle Real Application Clusters, and Oracle Data Guard.


Note:

The following sections do not provide a comprehensive set of instructions for configuring Grid Control for high availability. The examples here are shown only to provide examples of some common configurations of Grid Control components. These examples are designed to help you understand some of your options when you deploy Grid Control in your environment.

For a complete discussion of configuring Oracle products for high availability, refer to the Oracle white paper Enterprise Manager Maximum Availability Architecture (MAA) Best Practices Enterprise Manager 10R2 available at:

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_EnterpriseManagerBestPractices.pdf


Refer to the following sections for more information about common Grid Control configurations that take advantage of high availability hardware and software solutions. These configurations are part of the Maximum Availability Architecture (MAA).

3.5.1 Load Balancing Connections Between the Management Agent and the Management Service

Before you implement a plan to protect the flow of management data from the Management Agents to the Management Service, you should be aware of some key concepts.

Specifically, Management Agents do not maintain a persistent connection to the Management Service. When a Management Agent needs to upload collected monitoring data or an urgent target state change, the Management Agent establishes a connection to the Management Service. If the connection is not possible, such as in the case of a network failure or a host failure, the Management Agent retains the data and reattempts to send the information later.

To protect against the situation where a Management Service is unavailable, you can use a load balancer between the Management Agents and the Management Services.

However, if you decide to implement such a configuration, be sure to understand the flow of data when load balancing the upload of management data.

Figure 3-4 shows a typical scenario where a set of Management Agents upload their data to a load balancer, which redirects the data to one of two Management Service installations.

Figure 3-4 Load Balancing Between the Management Agent and the Management Service

Description of Figure 3-4 follows

In this example, only the upload of Management Agent data is routed through the load balancer. The Grid Control Console still connects directly to a single Management Service by way of the unique Management Service upload URL. This abstraction allows Grid Control to present a consistent URL to both Management Agents and Grid Control consoles, regardless of the loss of any one Management Service component.

When you load balance the upload of Management Agent data to multiple Management Service installations, the data is directed along the following paths:

  1. Administrators can use one of two URLs to access the Grid Control Console just as they do in the multiple Management Service configuration.

  2. Each Management Agent uploads its data to a common load balancer URL. This URL is defined in the emd.properties file for each Management Agent. In other words, the Management Agents connect to a virtual service exposed by the load balancer. The load balancer routes the request to any one of a number of available servers that provide the requested service.

  3. Each Management Service, upon receipt of data, stores it temporarily in a local file and acknowledges receipt to the Management Agent. The Management Services then coordinate amongst themselves and one of them loads the data in a background thread in the correct chronological order.

    Also, each Management Service communicates by way of JDBC with a common Management Repository, just as they do in the multiple Management Service configuration defined in Section 3.4.

  4. Each Management Service communicates directly with each Management Agent by way of HTTP, just as they do in the multiple Management Service configuration defined in Section 3.4.

3.5.2 Load Balancing Connections Between the Grid Control Console and the Management Service

Using a load balancer to manage the flow of data from the Management Agents is not the only way in which a load balancer can help you configure a highly available Grid Control environment. You can also use a load balancer to balance the load and to provide a failover solution for the Grid Control Console.

The following sections provide more information about this configuration:

3.5.2.1 Understanding the Flow of Data When Load Balancing the Grid Control Console

Figure 3-5 shows a typical configuration where a load balancer is used between the Management Agents and multiple Management Services, as well as between the Grid Control Console and multiple Management Services.

Figure 3-5 Load Balancing Between the Grid Control Console and the Management Service

Description of Figure 3-5 follows

In this example, a single load balancer is used for the upload of data from the Management Agents and for the connections between the Grid Control Console and the Management Service.

When you use a load balancer for the Grid Control Console, the management data uses the following paths through the Grid Control architecture:

  1. Administrators use one URL to access the Grid Control Console. This URL directs the browser to the load balancer virtual service. The virtual service redirects the browser to one of the Management Service installations. Depending upon the host name and port selected by the load balancer from the virtual pool of Management Service installations, the Grid Control Console obtains the management data by way of OracleAS Web Cache and the Oracle HTTP Server on one of the Management Service hosts.

  2. Each Management Agent uploads its data to a common load balancer URL (as described in Section 3.5.1) and data is written to the shared receive directory.

  3. Each Management Service communicates by way of JDBC with a common Management Repository, just as they do in the multiple Management Service configuration defined in Section 3.4.

  4. Each Management Service communicates directly with each Management Agent by way of HTTP, just as they do in the multiple Management Service configuration defined in Section 3.

3.5.2.2 Configuring Oracle HTTP Server When Using a Load Balancer for the Grid Control Console

The Management Service is implemented as a J2EE Web application, which is deployed on an instance of Oracle Application Server. Like many Web-based applications, the Management Service often redirects the client browser to a specific set of HTML pages, such as a logon screen and a specific application component or feature.

When the Oracle HTTP Server redirects a URL, it sends the URL, including the Oracle HTTP Server host name, back to the client browser. The browser then uses that URL, which includes the Oracle HTTP Server host name, to reconnect to the Oracle HTTP Server. As a result, the client browser attempts to connect directly to the Management Service host and bypasses the load balancer.

To prevent the browser from bypassing the load balancer when a URL is redirected, edit the ServerName directive defined in the Oracle HTTP Server configuration file. This directive will be found in one of two places:

  • If you have enabled Enterprise Manager Framework Security and you are running the Management Service in a secure environment (using HTTPS and SSL), the ServerName directive you must change is located in the following configuration file:

    ORACLE_HOME/Apache/Apache/conf/ssl.conf
    
    
  • If you have not enabled Enterprise Manager Framework Security and you are running in an environment that is not secure (using HTTP), the ServerName directive you must change is located in the following configuration file:

    ORACLE_HOME/Apache/Apache/conf/httpd.conf
    
    

Change the ServerName directive so it matches the name of the load balancer virtual service that you configured.

3.5.2.3 Configuring the Management Services

The Management Service for Grid Control 10g Release 2 has a high availability feature called the Shared Filesystem Loader. In the Shared Filesystem Loader, management data files received from Management Agents are stored temporarily on a common shared location called the shared receive directory. All Management Services are configured to use the same storage location for the shared receive directory. The Management Services coordinate internally and distribute amongst themselves the workload of uploading files into the Management Repository. Should a Management Service go down for some reason, its workload is taken up by surviving Management Services.

To configure the Management Service to use Shared Filesystem Loader, you must use the emctl config oms loader command.

  1. Stop all the Management Services.

  2. Configure a shared receive directory that is accessible by all Management Services.

  3. Run emctl config oms loader -shared yes -dir <loader directory> individually on all Management Services hosts, where <loader directory> is the full path to the shared receive directory.

  4. Restart all Management Services.


Caution:

Shared Filesystem Loader mode must be configured on all the Management Services in your Grid Control deployment using the previous steps. Management Services will fail to start if all the Management Services are not configured to run in the same mode.

3.5.3 Configuring a Load Balancer

This section describes guidelines you can use for configuring a load balancer to balance the upload of data from Management Agents to multiple Management Service installations.

In the following examples, assume that you have installed two Management Service processes on Host A and Host B. For ease of installation, start with two hosts that have no application server processes installed. This ensures that the default ports are used as seen in the following table. The examples use these default values for illustration purposes.

Table 3-1 Management Service Ports

NameDefault ValueDescriptionSourceDefined By

Secure Upload Port

1159

Used for secure upload of management data from Management Agents.

httpd_em.conf and emoms.properties

Install. Can be modified by emctl secure OMS - secure port <port> command.

Agent Registration Port

4889

Used by Management Agents during the registration phase to download Management Agent wallets, for example, during emctl secure agent. In an unlocked Management Service, it can be used for uploading management data to the Management Service.

httpd_em.conf and emoms.properties

Install

Secure Console Port

4444

Used for secure (https) console access.

ssl.conf

Install

Unsecure Console Port

7777

Used for unsecure (http) console access.

httpd.conf

Install

Webcache Secure Port

4443

Used for secure (https) console access.

webcache.xml

Install

Webcache Unsecure Port

7779

Used for unsecure (http) console access.

webcache.xml

Install


By default, the service name on the Management Service-side certificate uses the name of the Management Service host. Management Agents do not accept this certificate when they communicate with the Management Service through a load balancer. You must run the following command to regenerate the certificate on both Management Services:

emctl secure -oms -sysman_pwd <sysman_pwd> -reg_pwd <agent_reg_password> -host slb.acme.com -secure_port 1159

Specifically, you should use the administration tools that are packaged with your load balancer to configure a virtual pool that consists of the hosts and the services that each host provides. In the case of the Management Services pool, specify the host name and Management Agent upload port. To insure a highly available Management Service, you should have two or more Management Services defined within the virtual pool. A sample configuration follows.

Sample Configuration

In this sample, both pools and virtual servers are created.

  1. Create Pools

    Pool abc_upload: Used for secure upload of management data from Management Agents to Management Services Members: hostA:1159, hostB:1159 Persistence: None Load Balancing: round robin Pool abc_genWallet: Used for securing new Management Agents Members: hostA:4889, host B:4889 Persistence: Active HTTP Cookie, method-> insert, expiration 60 minutes Load balancing: round robin Pool abc_uiAccess: Used for secure console access Members: hostA:4444, hostB:4444 Persistence: SSL Session ID, timeout-> 3000 seconds (should be greater than the OC4J session timeout of 45 minutes) Load balancing: round robin

  2. Create Virtual Servers

    Virtual Server for secure uploadAddress: slb.acme.com Service: 1159 Pool: abc_upload Virtual Server for Management Agent registrationAddress: slb.acme.com Service: 4889 Pool: abc_genWallet Virtual Server for UI accessAddress: sslb.acme.com Service: https i.e. 443 Pool: abc_uiAccess

  3. Modify the REPOSITORY_URL property in the emd.properties file located in the sysman/config directory of the Management Agent home directory. The host name and port specified must be that of the load balancer virtual service.


    See Also:

    "Configuring the Management Agent to Use a New Management Service" for more information about modifying the REPOSITORY_URL property for a Management Agent

  4. Declare the pool to use a load balancing policy, for example, Round Robin or Least Loaded. Do not configure persistence between Management Agents and Management Services.

This configuration allows the distribution of connections from Management Agents equally between Management Services. In the event a Management Service becomes unavailable, the load balancer should be configured to direct connections to the surviving Management Services.

Example of Configuring the Load Balancer

To successfully implement this configuration, the load balancer can be configured to monitor the underlying Management Service. On some models, for example, you can configure a monitor on the load balancer. The monitor defines the:

  • HTTP request that is to be sent to a Management Service

  • Expected result in the event of success

  • Frequency of evaluation

For example, the load balancer can be configured to check the state of the Management Service every 5 seconds. On three successive failures, the load balancer can then mark the component as unavailable and no longer route requests to it. The monitor should be configured to send the string GET /em/upload over HTTP and expect to get the response Http XML File receiver. See the following sample monitor configuration.

Sample Monitor Configuration

In this sample, three monitors are configured: mon_upload, mon_genWallet, and mon_uiAccess.

Monitor mon_uploadType: https Interval: 60 Timeout: 181 Send String: GET /em/upload HTTP 1.0\n Receive Rule: Http Receiver Servlet active! Associate with: hostA:1159, hostB:1159 Monitor mon_genWalletType: http Interval: 60 Timeout: 181 Send String: GET /em/genwallet HTTP 1.0\n Receive Rule: GenWallet Servlet activated Associate with: hostA:4889, hostB:4889 Monitor mon_uiAccessType: https Interval: 5 Timeout: 16 Send String: GET /em/console/home HTTP/1.0\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0, Windows NT 5.0)\n Receive Rule: /em/console/logon/logon;jsessionid=Associate with: hostA:4444, hostB:4444


Note:

The network bandwidth requirements on the Load Balancer need to be reviewed carefully. Monitor the traffic being handled by the load balancer using the administrative tools packaged with your load balancer. Ensure that the load balancer is capable of handling the traffic passing through it. For example, deployments with a large number of targets can easily exhaust a 100 Mbps Ethernet card. A Gigabit Ethernet card would be required in such cases.


See Also:

Your Load Balancer documentation for more information on configuring virtual pools, load balancing policies, and monitoring network traffic

3.5.4 Configuring the Management Repository

When you configure Grid Control for high availability, there are several ways to configure the Management Repository to prevent the loss of management data stored in the database. One way is to specify the size of the Management Repository tablespaces in a Real Application Cluster (RAC) database.

When you install the Management Repository into a RAC database instance, you cannot set the size of the required Enterprise Manager tablespaces. You can, however, specify the name and location of data files to be used by the Management Repository schema. The default sizes for the initial data file extents depend on using the AUTOEXTEND feature and as such are insufficient for a production installation. This is particularly problematic when storage for the RAC database is on a raw device.

If the RAC database being used for the Management Repository is configured with raw devices, there are three options for increasing the size of the Management Repository.

  • The preferred option for high availability installs is to use Oracle Automatic Storage Management to manage database storage. The location string must be specified manually (for example, +DATA/<database_name>/<datafile_name). If ASM storage is used, there is no need to disable any space management storage settings.

  • You can create multiple raw partitions, with the first one equal to the default size of the tablespace as defined by the installation process.

  • Alternatively, you can create the tablespace using the default size, create a dummy object that will increase the size of the tablespace to the end of the raw partition, then drop that object.

Regardless, if raw devices are used, disable the default space management for these objects, which is to auto-extend.

3.6 Installation Best Practices for Enterprise Manager High Availability

The following sections document best practices for installation and configuration of each Grid Control component.

3.6.1 Configuring the Management Agent to Automatically Start on Boot and Restart on Failure

The Management Agent is started manually. It is important that the Management Agent be automatically started when the host is booted to insure monitoring of critical resources on the administered host. To that end, use any and all operating system mechanisms to automatically start the Management Agent. For example, on UNIX systems this is done by placing an entry in the UNIX /etc/init.d that calls the Management Agent on boot or by setting the Windows service to start automatically.

3.6.2 Configuring Restart for the Management Agent

Once the Management Agent is started, the watchdog process monitors the Management Agent and attempts to restart it in the event of a failure. The behavior of the watchdog is controlled by environment variables set before the Management Agent process starts. The variables that control this behavior follow. All testing discussed here was done with the default settings.

  • EM_MAX_RETRIES – This is the maximum number of times the watchdog will attempt to restart the Management Agent within the EM_RETRY_WINDOW. The default is to attempt restart of the Management Agent 3 times.

  • EM_RETRY_WINDOW - This is the time interval in seconds that is used together with the EM_MAX_RETRIES environmental variable to determine whether the Management Agent is to be restarted. The default is 600 seconds.

The watchdog will not restart the Management Agent if the watchdog detects that the Management Agent has required restart more than EM_MAX_RETRIES within the EM_RETRY_WINDOW time period.

3.6.3 Installing the Management Agent Software on Redundant Storage

The Management Agent persists its intermediate state and collected information using local files in the $AGENT_HOME/$HOSTNAME/sysman/emd sub tree under the Management Agent home directory.

In the event that these files are lost or corrupted before being uploaded to the Management Repository, a loss of monitoring data and any pending alerts not yet uploaded to the Management Repository occurs.

At a minimum, configure these sub-directories on striped redundant or mirrored storage. Availability would be further enhanced by placing the entire $AGENT_HOME on redundant storage. The Management Agent home directory is shown by entering the command 'emctl getemhome' on the command line, or from the Management Services and Repository tab and Agents tab in the Grid Control console.

3.6.4 Install the Management Service Software on Redundant Storage

The Management Service contains results of the intermediate collected data before it is loaded into the Management Repository. The loader receive directory contains these files and is typically empty when the Management Service is able to load data as quickly as it is received. Once the files are received by the Management Service, the Management Agent considers them committed and therefore removes its local copy. In the event that these files are lost before being uploaded to the Management Repository, data loss will occur. At a minimum, configure these sub-directories on striped redundant or mirrored storage. When Management Services are configured for the Shared Filesystem Loader, all services share the same loader receive directory. It is recommended that the shared loader receive directory be on a clustered file system like NetApps Filer.

Similar to the Management Agent directories, availability would be further enhanced by placing the entire Management Service software tree on redundant storage. This can also be determined at the command line using the 'emctl getemhome' or by using the Management Services and Repository tab in the Grid Control console.

3.7 Configuration With Grid Control

Grid Control comes preconfigured with a series of default rules to monitor many common targets. These rules can be extended to monitor the Grid Control infrastructure as well as the other targets on your network to meet specific monitoring needs.

3.7.1 Console Warnings, Alerts, and Notifications

The following list is a set of recommendations that extend the default monitoring performed by Enterprise Manager. Use the Notification Rules link on the Preferences page to adjust the default rules provided on the Configuration/Rules page:

  • Ensure the Agent Unreachable rule is set to alert on all agent unreachable and agent clear errors.

  • Ensure the Repository Operations Availability rule is set to notify on any unreachable problems with the Management Service or Management Repository nodes. Also modify this rule to alert on the Targets Not Providing Data condition and any database alerts that are detected against the database serving as the Management Repository.

Modify the Agent Upload Problems Rule to alert when the Management Service status has hit a warning or clear threshold.

3.7.2 Configure Additional Error Reporting Mechanisms

Enterprise Manager provides error reporting mechanisms through e-mail notifications, PL/SQL packages, and SNMP alerts. Configure these mechanisms based on the infrastructure of the production site. If using e-mail for notifications, configure the notification rule through the Grid Control console to notify administrators using multiple SMTP servers if they are available. This can be done by modifying the default e-mail server setting on the Notification Methods option under Setup.

3.7.3 Component Backup

Backup procedures for the database are well established standards. Configure backup for the Management Repository using the RMAN interface provided in the Grid Control console. Refer to the R MAN documentation or the Maximum Availability architecture document for detailed implementation instructions.

In addition to the Management Repository, the Management Service and Management Agent should also have regular backups. Backups should be performed after any configuration change. Best practices for backing up these tiers are documented in the section, Section 11.3, "Oracle Enterprise Manager Backup, Recovery, and Disaster Recovery Considerations".

3.7.4 Troubleshooting

In the event of a problem with Grid Control, the starting point for any diagnostic effort is the console itself. The Management System tab provides access to an overview of all Management Service operations and current alerts. Other pages summarize the health of Management Service processes and logged errors These pages are useful for determining the causes of any performance problems as the summary page shows at a historical view of the amount of files waiting to be loaded to the Management Repository and the amount of work waiting to be completed by Management Agents.

3.7.4.1 Upload Delay for Monitoring Data

When assessing the health and availability of targets through the Grid Control console, information is slow to appear in the UI, especially after a Management Service outage. The state of a target in the Grid Control console may be delayed after a state change on the monitored host. Use the Management System page to gauge backlog for pending files to be processed.

3.7.4.2 Notification Delay of Target State Change

The model used by the Management Agent to assess the state of health for any particular monitored target is poll based. Management Agents immediately post a notification to the Management Service as soon as a change in state is detected. This infers that there is some potential delay for the Management Agent to actually detect a change in state.

PKD  PK^UIOEBPS/content.opfQ( Oracle® Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0) en-US B40002-02 Oracle Corporation Oracle Corporation Oracle® Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0) 2005-07-10T12:57:20+08:00 Oracle® Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0) PK:S V(Q(PK^UIOEBPS/notification.htm Configuring Notifications

13 Configuring Notifications

The notification system allows you to notify Enterprise Manager administrators of alerts, policy violations, and the status changes of job executions. In addition to notifying administrators, the notification system can perform actions such as executing operating system commands (including scripts) and PL/SQL procedures when an alert is triggered. This capability allows you to implement automatically specific IT practices under particular alert conditions. For example, if an alert is generated when monitoring the operational (up/down) status of a database, you may want the notification system to automatically open an in-house trouble-ticket using an OS script so that the appropriate IT staff can respond in a timely manner.

By using Simple Network Management Protocol (SNMP) traps, the Enterprise Manager notification system also allows you to send traps to SNMP-enabled third-party applications such as HP OpenView. Some administrators may want to send third-party applications a notification when a certain metric has exceeded a threshold.

This chapter covers the following:

13.1 Setting Up Notifications

All Enterprise Manager administrators can set up e-mail notifications for themselves. Super Administrators also have the ability to set up notifications for other Enterprise Manager administrators.

13.1.1 Setting Up a Mail Server for Notifications

Before Enterprise Manager can send e-mail notifications, you must first specify the Outgoing Mail (SMTP) servers to be used by the notification system. Once set, you can then define e-mail notifications for yourself or, if you have Super Administrator privileges, other Enterprise Manager administrators.

You specify the Outgoing Mail (SMTP) server on the Notification Methods page (Figure 13-1). Display the Notification Methods page by clicking Setup on any page in the Grid Control Console and clicking Notification Methods in the vertical navigation bar.


Note:

You must have Super Administrator privileges in order to set up SMTP servers.

Specify one or more outgoing mail server names, the mail server authentication credentials (User Name, Password, and Confirm Password), if required, the name you want to appear as the sender of the notification messages, and the e-mail address you want to use to send your e-mail notifications. This address, called the Sender's Mail Address, must be a valid address on each mail server that you specify. A message will be sent to this e-mail address if any problem is encountered during the sending of an e-mail notification. Example 13-1 shows sample notification method entries.

Example 13-1 Mail Server Settings

  • Outgoing Mail (SMTP) Server - smtp01.mycorp.com:587, smtp02.mycorp.com

  • User Name - myadmin

  • Password - ******

  • Confirm Password - ******

  • Identify Sender As - Enterprise Manager

  • Sender's E-mail Address - mgmt_rep@mycorp.com

Figure 13-1 Defining a Mail Server

Definition entry fields on Notification Methods page.


Note:

The e-mail address you specify on this page is not the e-mail address to which the notification is sent. You will have to specify the e-mail address (where notifications will be sent) from the Preferences General page.

After configuring the e-mail server, click Test Mail Servers to verify your e-mail setup. You should verify that an e-mail message was received by the e-mail account specified in the Sender's E-mail Address field.

Defining multiple mail servers will improve the reliability of e-mail notification delivery and spread the load across multiple systems. The Management Service makes use of each mail server to send e-mails and the behavior is controlled by the following parameters found in the $ORACLE_HOME/sysman/config/emoms.properties file.

Example 13-2 Management Service Parameters

# The maximum number of emails that can be sent in a single connection to an
# email server
# em.notification.emails_per_connection=20
#
# The maximum number of emails that can be sent in a minute
# em.notification.emails_per_minute=250

Based on the defaults in Example 13-2, the first mail server is used to send 20 e-mails before the Management Service switches to the next mail server which is used to send another 20 e-mails before switching to the next mail server. This prevents one mail server from becoming overloaded and should improve overall reliability and throughput.

13.1.2 Setting Up E-mail for Yourself

If you want to receive notifications by e-mail, you will need to specify your e-mail address(s) in the General page under the Preferences link in the Grid Control console. In addition to defining notification e-mail addresses, you associate the notification message format (long or short) to be used for your e-mail address.

Setting up e-mail involves three steps:

Step 1: Define e-mail addresses.

Step 2: Set up a Notification Schedule.

Step 3: Subscribe to receive e-mail for notification rules.

13.1.2.1 Defining E-mail Addresses

An e-mail address can have up to 128 characters. There is no upper limit with the number of e-mail addresses.

To add an e-mail address:

  1. From the Grid Control Console, click Preferences. By default the General page is selected.

  2. Click Add Another Row to create a new e-mail entry field in the E-mail Addresses table.

  3. Specify the e-mail associated with your Enterprise Manager account. All e-mail notifications you receive from Enterprise Manager will be sent to the e-mail addresses you specify.

    For example, user1@oracle.com

    Select the message format for your e-mail address. The Long Format sends a HTML formatted e-mail that contains detailed information. Example 13-3 shows a typical notification that uses the long format.

    The Short Format (Example 13-4) sends a concise, text e-mail that is limited to a configurable number of characters, thereby allowing the e-mail be received as an SMS message or page. The content of the message can be sent entirely in the subject, entirely in the body or split across the subject and body. For example, in the last case, the subject could contain the severity type (for example, Critical) and the target name. The body could contain the time the severity occurred and the severity message. Since the message length is limited, some of this information may be truncated. If truncation has occurred there will be an ellipsis end of the message.

  4. Click Apply to save your e-mail address.

Example 13-3 Long E-mail Notification for Alerts

Name=myhost.com
Type=Host
Host=myhost.com
Metric=Filesystem Space Available (%)
Mount Point =/usr
Timestamp=06-OCT-2006 16:27:05 US/Pacific
Severity=Warning
Message=Filesystem / has only 76.07% available space
Rule Name=Host Availability and Critical States
Rule Owner=SYSMAN

Example 13-4 Short E-mail Notification for Alerts

Subject is :
EM:Unreachable Start:myhost
Body is :
Nov 16, 2006 2:02:19 PM EST:Agent is Unreachable (REASON = Connection refused) 
but the host is UP

More about Short E-mail Format

Enterprise Manager does not directly support paging, SMS, etc., but instead relies on external gateways to, for example, perform the conversion from e-mail to page.

Entries in the emoms.properties file define the size and format of the short e-mail.

You must establish the maximum size your device can support and whether the message is sent in subject, body or both

emoms.properties Entries for a Short E-mail Format

# The maximum size of a short format email
# em.notification.short_format_length=155
# The format of the short email. It can be set to subject, body or both.
#
# When set to subject the entire message is sent in the subject i.e.
#  EM:<severity>:<target>:<message>:<timestamp>
# When set to body the entire message is sent in the body i.e.
#  EM:<severity>:<target>:<message>:<timestamp>
# When set to both the message is split i.e. the subject contains
#  EM:<severity>:<target>
# and the body contains
#  <message>:<timestamp>
# In all cases the message is truncated to the length specified in the
# em.notification.short_format_length parameter
# em.notification.short_format=both

13.1.2.2 Setting Up a Notification Schedule

Once you have defined your e-mail notification addresses, you will need to define a notification schedule. For example, if your e-mail addresses are user1@oracle.com, user2@oracle.com, user3@oracle.com, you can choose to use one or more of these e-mail addresses for each time period in your notification schedule.


Note:

When you enter e-mail addresses for the first time, a 24x7 weekly notification schedule is set automatically. You can then review and modify the schedule to suit your monitoring needs.

A notification schedule is a repeating schedule used to specify your on-call schedule—the days and time periods and e-mail addresses that should be used by Enterprise Manager to send notifications to you. Each administrator has exactly one notification schedule. When a notification needs to be sent to an administrator, Enterprise Manager consults that administrator's notification schedule to determine the e-mail address to be used. Depending on whether you are Super Administrator or a regular Enterprise Manager administrator, the process of defining a notification schedule differs slightly.

If you are a regular Enterprise Manager administrator and are defining your own notification schedule:

  1. From the Enterprise Manager Grid Control, click Preferences at the top of the page. By default the General page is selected.

  2. Click Notification Schedule in the vertical navigation bar. Your Notification Schedule page appears.

  3. Follow the directions on the Notification Schedule page to specify when you want to receive e-mails.

13.1.2.3 Subscribe to Receive E-mail for Notification Rules

A notification rule is a user-defined rule that defines the criteria by which notifications should be sent for alerts, policy violations, corrective action execution status, and job execution status. Specifically, in each rule, you can specify the criteria you are interested in and the notification methods (such as e-mail) that should be used for sending these notifications. For example, you can set up a rule that when any database goes down or any database backup job fails, e-mail should be sent and the "log trouble ticket" notification method should be called. Or you can define another rule such that when the CPU or Memory Utilization of any host reach critical severities, SNMP traps should be sent to another management console. During notification rule creation, you specify criteria such as the targets you are interested in, their monitored metrics, associated alert severity conditions (clear, warning, critical), policy violations, corrective action execution status, or job execution status, and the associated notification method.

To subscribe to a notification rule you create, while creating the rule, go to the Methods page and check the "Send Me E-mail" option.

Out-of-Box Notification Rules

Enterprise Manager Grid control comes with out-of-box notification rules that cover the most common alert conditions. When you install the Oracle Management Service, you are given the option to receive e-mail notifications for critical alerts. If you choose this option, and if an e-mail address for the SYSMAN user was specified, then some default notification rules are created that cover the availability and critical states for common target types and would also be configured to send e-mail notifications to the SYSMAN e-mail address for the conditions defined in the notification rules.

You can access the out-of-box notification rules by clicking on Preferences on any page in the Enterprise Manager console and clicking Public Rules in the vertical navigation bar. If the conditions defined in the out-of-box notification rules meet your requirements, you can simply subscribe to receive e-mail notifications for the conditions defined in the rule by clicking on Subscribe column in the row of the Public Rules table that corresponds to the notification rule that you are interested in. Click Apply to save your changes.

Table 13-1 lists all the default notification rules. These are all owned by the SYSMAN user and are public rules.

Table 13-1 Default Notification Rules

NameDescriptionApplies to Targets of the TypeSend Notification on the Following Availability StatesSend Notification if Any of the Metrics is at CRITICAL Alert Severity

Agent Upload Problems

System-generated notification rule for monitoring Agents that may have problems uploading data to the Management Service.

Oracle Management Service and Repository

N/A

Count of targets not uploading data

Agents Unreachable

System-generated notification rule for monitoring Agents that lose contact with the Management Service due to network problems, host problems or Agents going down.

Agents

Agent UnreachableAgent Unreachable Resolved

N/A

Application Server Availability and Critical States

System-generated notification rule for monitoring Application Servers' availability, and critical metric statuses.

Application Servers

Down

CPU Usage (%)

Database Availability and Critical States

System-generated notification rule for monitoring Databases' availability, and critical metric statuses.

Databases (single instance only)

Down

Process Limit Usage (%)

Session Limit Usage (%)

Blocking Session Count All Objects

Archiver Hung Alert Log Error Status

Data Block Corruption Alert Log Error Status

Generic Alert Log Error Status

Media Failure Alert Log Error Status

Session Terminated Alert Log Error Status

Archive Area Used (%) All Objects

Segments Not Able to Extend Count All Objects

Segments Approaching Maximum Extents Count All Objects

Tablespace Space Used (%) All Objects

Wait Time (%)

HTTP Server Availability and Critical States

System-generated notification rule for monitoring HTTP Server's availability, and critical metric statuses.

Oracle HTTP Server

Down

CPU Usage (%)

Percentage of Busy Processes

Active HTTP Connections

Request Processing Time (seconds)

Host Availability and Critical States

System-generated notification rule for monitoring Hosts' availability, and critical metric statuses.

Hosts

Agent Unreachable

Agent Unreachable Resolved

Average Disk I/O Service Time (ms)

Disk Device Busy (%)

Filesystem Space Available (%)

CPU in I/O Wait (%)

Run Queue Length (5 minute average)

CPU Utilization (%)

Memory Utilization (%)

Memory Page Scan Rate (per second)

Swap Utilization (%)

Network Interface Combined Utilization (%)

Listener Availability

System-generated notification rule for monitoring database Listeners' availability, and critical metric statuses.

Listeners

Down

N/A

OC4J Availability and Critical States

System-generated notification rule for monitoring OC4J instance's availability, and critical metric statuses.

OC4J

Down

CPU Usage (%)

OC4J Instance - Request Processing Time (seconds)

OC4J Instance - Active Sessions

Repository Operations Availability

System-generated notification rule for monitoring the availability of the DBMS jobs that are part of the Management Repository.

Oracle Management Service and Repository

Critical

DBMS Job UpDown

Violation Notification for Database Security Policies

System-generated notification rule for monitoring the secureness of the database configuration.

Databases

Critical

N/A

Web Cache Availability and Critical States

System-generated notification rule for monitoring Web Cache's instance's availability, and critical metric statuses.

Oracle Web Cache

Down

Hits (% of requests)

Web Cache CPU Usage (%)


Creating Your Own Notification Rules

If you find that the default notification rules do not meet your needs, you can define your own custom rules. The following procedure documents the process of notification rule creation for non-Super Administrators.

To create your own notification rule:

  1. From the Enterprise Manager Grid Control, click Preferences.

  2. Click My Rules in the vertical navigation bar.

    If you are not logged in as an administrator with Super Administrator privileges, you will see a link for My Rules instead of Rules as in the case of an administrator with Super Administrator privileges.

  3. Click Create.

    Enterprise Manager displays the Create Notification Rule pages. Enter the requisite information on each page to create your notification rule.

    When you specify the notification rule properties, check Make Public in the General page if you want other non-privileged users to be able to view and share that rule. For example, it allows other administrators to later specify that they should receive e-mail for this rule.

    When you specify the notification rule, you will only be able to choose from e-mail and SNMP traps. Specifying custom commands and PL/SQL procedures is an option that is only available to Super Administrators. To receive e-mail notifications for conditions defined in the rule, go to the Methods page and select the Send Me E-Mail option.

13.1.3 Setting Up E-mail for Other Administrators

eIf you have Super Administrator privileges, you can set up e-mail notifications for other Enterprise Manager administrators. To set up e-mail notifications for other Enterprise Manager administrators, you must need to:

Step 1: Ensure Each Administrator Account has an Associated E-mail Address

Each administrator to which you want to send e-mail notifications must have a valid e-mail address.

  1. Click Setup.

  2. Click Administrators from the vertical navigation bar.

  3. For each administrator, define an e-mail address. This sets up a 24x7 notification schedule for this user that uses all the e-mail addresses specified.

Enterprise Manager also allows you to specify an administrator address when editing an administrator's notification schedule.

Step 2: Define Administrators' Notification Schedules

Once you have defined e-mail notification addresses for each administrator, you will need to define their respective notification schedules. Although a default 24x7 notification schedule is created when you specified the e-mail addresses for the first time, you should review and edit the notification schedule as needed.

  1. Click Setup.

  2. From the vertical navigation bar, click Schedules (under Notification). The Notification Schedule page appears.

  3. Specify the administrator who's notification schedule you wish to edit and click Change.

  4. Click Edit Schedule Definition. The Edit Schedule Definition: Time Period page appears. If necessary, modify the rotation schedule.

  5. Click Continue. The Edit Schedule Definition: E-mail Addresses page appears.

  6. Follow the directions on the Edit Schedule Definition: E-mail Addresses page to modify the notification schedule.

  7. Click Finish when you are done.

  8. Repeat steps three through seven for each administrator.

Step 3: Assign Notification Rules to Administrators

With the notification schedules set, you now need to assign the appropriate notification rules for each designated administrator.

  1. Click Setup.

  2. From the vertical navigation bar, click Administrators.

  3. Select the desire administrator.

  4. Click Subscribe to Rules. The Subscribe admin to Public Notification Rules page appears.

  5. Select the desired notification rules and click Subscribe.

  6. Click OK when you are finished.

  7. Repeat steps three through six for each administrator.

13.2 Extending Notification Beyond E-mail

Notification Methods are the mechanisms by which alerts are sent. Enterprise Manager Super Administrators can set up e-mail notifications by configuring the 'e-mail' notification method. Most likely this would already have been setup as part of the Oracle Management Service installation.Enterprise Manager Super Administrators can also define other custom notification methods. For example, alerts may need to be forwarded to a 3rd party trouble-ticketing system. Assuming APIs to the third-party trouble-ticketing system are available, a custom notification method can be created to call a custom OS script that has the appropriate APIs. The custom notification method can be named in a user-friendly fashion, for example, "Log trouble ticket". Once that is defined, any time an administrator needs to send alerts to the trouble-ticketing system, he merely needs to invoke the now globally available notification method called "Log trouble ticket". Custom notification methods can be defined based on any custom OS script, any custom PL/SQL procedure, or by sending SNMP traps.

Only Super Administrators can define OS Command, PL/SQL, and SNMP Trap notification methods. However, any Enterprise Manager administrator can add these notification methods (once defined by the Super Administrator) to their notification rules.

Through the Notification Methods page, you can:

  • Set up the outgoing mail servers if you plan to send e-mail notifications through notification rules

  • Create other custom notification methods using OS and PL/SQL scripts and SNMP traps.

13.2.1 Custom Notification Methods Using Scripts and SNMP Traps

You can create other custom notification methods based on OS scripts, PL/SQL procedures, or SNMP traps. Any administrator can then use these methods in Notification Rules.

13.2.1.1 Adding a Notification Method based on an OS Command or Script

Complete the following four steps to define a notification method based on an OS command or script.


Note:

Notification methods based on OS commands must be configured by an administrator with Super Administrator privileges.

Step 1: Define your OS command or script.

You can specify an OS command or script that will be called by the notification system. You can use target and alert or policy violation context information, corrective action execution status and job execution status within the body of the script. Passing metric severity attributes (severity level, type, notification rule, rule owner, or rule owner, and so on) or policy violation information to OS commands/scripts allows you to customize automated responses to alerts or policy violations. For example, if an OS script opens a trouble ticket for an in-house support trouble ticket system, you will want to pass severity levels (critical, warning, and so on) to the script to open a trouble ticket with the appropriate details and escalate the problem. For more information on passing specific types of information to OS Command or Scripts, see

Step 2: Deploy the script on each Management Service host.

You must deploy the OS Command or Script on each Management Service host machine that connects to the Management Repository. The OS Command is run as the user who started the Management Service.

The OS Command or Script should be deployed on the same location on each Management Service host machine. The OS Command should be an absolute path, for example, /u1/bin/logSeverity.sh. The command is run by the user who started the Management Service. If an error is encountered during the running of the OS Command, the Notification System can be instructed to retry the sending of the notification to the OS Command by returning an exit code of 100. The procedure is initially retried after one minute, then two minutes, then three minutes and so on, until the notification is a day old, at which point it will be purged.

Example 13-5 shows the parameter in emoms.properties that controls how long the OS Command can execute without being killed by the Management Service. This is to prevent OS Commands from running for an inordinate length of time and blocking the delivery of other notifications. By default the command is allowed to run for 30 seconds before it is killed.

Example 13-5 Parameter in emoms.properties File

# The amount of time in seconds after which an OS Command started by the
# Notification System will be killed if it has not exited
# em.notification.os_cmd_timeout=30

Step 3: Register your OS Command or Script as a new Notification Method.

Add this OS command as a notification method that can be called in Notification Rules. Log in as a Super Administrator, click Setup and then Notification Methods from the vertical navigation bar. From this page, you can define a new notification based on the 'OS Command' type. See "Adding a Notification Method based on an OS Command or Script" .

The following information is required for each OS command notification method:

  • Name

  • Description

    Both Name and Description should be clear and intuitive so that the function of the method is clear to other administrators.

  • OS Command

You must enter the full path of the OS command or script in the OS command field (for example, /u1/bin/myscript.sh). For environments with multiple Management Services, the path must be exactly the same on each machine that has a Management Service. Command line parameters can be included after the full path (for example, /u1/bin/myscript.sh arg1 arg2).

Example 13-6 shows information required for the notification method.

Example 13-6 OS Command Notification Method

Name Trouble Ticketing
Description Notification method to log trouble ticket for a severity occurrence
OS Command /private/mozart/bin/logTicket.sh

Note:

There can be more than one OS Command configured per system.

Step 4: Assign the notification method to a rule.

You can edit an existing rule (or create a new notification rule), then go to the Methods page. In the list of Advanced Notification Methods, select your notification method and click 'Assign Method to Rule'. To assign multiple rules to a method or methods to a single rule, see "Assigning Rules to Methods" or "Assigning Methods to Rules".

Passing Alert and Policy Violation Information to an OS Command or Script

The notification system passes severity information to an OS script or executable using system environment variables.

Conventions used to access environmental variables vary depending on the operating system:

  • UNIX: $ENV_VARIABLE

  • Windows:%ENV_VARIABLE%

The notification system sets the following environment variables before calling the script. The script can then use any or all of these variables within the logic of the script.

Table 13-2 Environment Variables

Environment VariableDescription

TARGET_NAME

Name of the target on which the severity occurred.

TARGET_TYPE

Type of target on which the severity occurred. Targets are defined as any monitorable entity, such as Host, Database, Listener, or Oracle HTTP Server. You can view the type of a monitored target on the All Targets page.

HOST

Name of the machine on which the target resides.

METRIC

Metric generating the severity. This variable is not set for policy violations.

METRIC_VALUE

The value of the metric when the threshold was exceeded. Not set for policy violations

POLICY_RULE

The name of the policy when the threshold was exceeded. Not set for metric severities

KEY_VALUE

For metrics that monitor a set of objects, the KEY_VALUE indicates the specific object that triggered the severity. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE is 'USERS' if the USERS tablespace triggered at warning or critical severity.

KEY_VALUE_NAME

For metrics that monitor a set of objects, the KEY_VALUE_NAME indicates the type of object monitored. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE_NAME is 'Tablespace Name'.

VIOLATION_CONTEXT

A comma-separated list of name-value pairs that shows the alert context for a policy violation.

TIMESTAMP

Time when the severity occurred.

SEVERITY

Type of severity. For example, severity for a target's (availability) status metric are:

  • UP

  • DOWN

  • UNREACHABLE CLEAR

  • UNREACHABLE START

  • BLACKOUT END

  • BLACKOUT START

Other metrics can have any of the following severities:

  • WARNING

  • CRITICAL

  • CLEAR

  • METRIC ERROR CLEAR

  • METRIC ERROR START

MESSAGE

Message for the alert that provides details about what triggered the condition.

RULE_NAME

Name of the notification rule to which the OS Command notification method was assigned.

RULE_OWNER

Name of the Enterprise Manager administrator who owns the notification rule.


Your script may reference some or all of these variables.

The sample OS script shown in Example 13-7 appends environment variable entries to a log file. In this example, the script logs a severity occurrence to a file server. If the file server is unreachable then an exit code of 100 is returned to force the Oracle Management Service Notification System to retry the notification

Example 13-7 Sample OS Command Script

#!/bin/ksh

LOG_FILE=/net/myhost/logs/severity.log
if test -f $LOG_FILE
then
echo $TARGET_NAME $MESSAGE $TIMESTAMP >> $LOG_FILE
else
   exit 100
fi

Example 13-8 shows an OS script that logs alert information to the file 'alertmsg.txt'. The file is saved to the /u1/results directory.

Example 13-8 Alert Logging Script

#!/usr/bin/sh
echo "Alert logged:" > /u1/results/alertmsg.txt
echo "\n" >> /u1/results/alertmsg.txt
echo "target name is " $TARGET_NAME >> /u1/results/alertmsg.txt
echo "target type is " $TARGET_TYPE >> /u1/results/alertmsg.txt
echo "target is on host " $HOST >> /u1/results/alertmsg.txt
echo "metric in alert is " $METRIC >> /u1/results/alertmsg.txt
echo "metric index is " $KEY_VALUE >> /u1/results/alertmsg.txt
echo "timestamp is " $TIMESTAMP >> /u1/results/alertmsg.txt
echo "severity is " $SEVERITY >> /u1/results/alertmsg.txt
echo "message is " $MESSAGE >> /u1/results/alertmsg.txt
echo "notification rule is " $RULE_NAME >> /u1/results/alertmsg.txt
echo "rule owner is " $RULE_OWNER >> /u1/results/alertmsg.txt
exit 0

Example 13-9 shows a script that sends an alert to an HP OpenView console from Enterprise Manager Grid Control. When a metric alert is triggered, the Enterprise Manager Grid Control displays the alert. The HP OpenView script is then called, invoking opcmsg and forwarding the information to the HP OpenView management server.

Example 13-9 HP OpenView Script

/opt/OV/bin/OpC/opcmsg severity="$SEVERITY" app=OEM msg_grp=Oracle msg_text="$MESSAGE" object="$TARGET"

13.2.1.2 Adding a Notification Method Based on a PL/SQL Procedure

Complete the following four steps to define a notification method based on a PL/SQL procedure.

Step 1: Define the PL/SQL procedure.

The procedure must have one of the following signatures depending on the type of notification that will be received.

For alerts and policy violations:

PROCEDURE p(severity IN MGMT_NOTIFY_SEVERITY)

For job execution status changes:

PROCEDURE p(job_status_change IN MGMT_NOTIFY_JOB)

For corrective action status changes:

PROCEDURE p(ca_status_change IN MGMT_NOTIFY_CORRECTIVE_ACTION)

Note:

The notification method based on a PL/SQL procedure must be configured by an administrator with Super Administrator privileges before a user can select it while creating/editing a notification rule.

For more information on passing specific types of information to scripts or PL/SQL procedures, see the following sections:

"Passing Alert and Policy Violation Information to a PL/SQL Procedure"

"Passing Corrective Action Status Change Information"

"Passing Job Execution Status Information"

Step 2: Create the PL/SQL procedure on the Management Repository.

Create the PL/SQL procedure on the repository database using one of the following procedure specification:

PROCEDURE p(severity IN MGMT_NOTIFY_SEVERITY)
PROCEDURE p(job_status_change IN MGMT_NOTIFY_JOB)
PROCEDURE p(ca_status_change IN MGMT_NOTIFY_CORRECTIVE_ACTION)

The PL/SQL procedure must be created on the repository database using the database account of the repository owner (such as SYSMAN)

If an error is encountered during the running of the procedure, the Notification System can be instructed to retry the sending of the notification to the procedure by raising a user defined exception that uses the error code -20000. See Example 13-11, "PL/SQL Procedure Using a Severity Code". The procedure initially retried after one minute, then two minutes, then three minutes and so on, until the notification is a day old, at which point it will be purged.

Step 3: Register your PL/SQL procedure as a new notification method.

Log in as a Super Administrator, click Setup and then Notification Methods from the vertical navigation bar. From this page, you can define a new notification based on 'PL/SQL Procedure'. See "Adding a Notification Method Based on a PL/SQL Procedure".

Make sure to use a fully qualified name that includes the schema owner, package name and procedure name. The procedure will be executed by the repository owner and so the repository owner must have execute permission on the procedure.

Create a notification method based on your PL/SQL procedure. The following information is required when defining the method:

  • Name

  • Description

  • PL/SQL Procedure

You must enter a fully qualified procedure name (for example, OWNER.PKGNAME.PROCNAME) and ensure that the owner of the Management Repository has execute privilege on the procedure.

An example of the required information is shown in Example 13-10.

Example 13-10 PL/SQL Procedure Required Information

Name Open trouble ticket
Description Notification method to open a trouble ticket in the event
PLSQL Procedure ticket_sys.ticket_ops.open_ticket

Step 4: Assign the notification method to a rule.

You can edit an existing rule (or create a new notification rule), then go to the Methods page. In the list of Advanced Notification Methods, select your notification method and click 'Assign Method to Rule'. To assign multiple rules to a method or methods to a single rule, see "Assigning Rules to Methods" or "Assigning Methods to Rules".

There can be more than one PL/SQL-based method configured for your Enterprise Manager environment.

Information about the severity types that relate to a target's availability, and how metric severity and policy violation information is passed to the PLSQL procedure is covered in the next section.

Passing Alert and Policy Violation Information to a PL/SQL Procedure

Passing metric severity attributes (severity level, type, notification rule, rule owner, or rule owner, and so on) or policy violation information to PL/SQL procedures allows you to customize automated responses to alerts or policy violations.

The notification system passes information about metric severities or policy violations to a PL/SQL procedure using the MGMT_NOTIFY_SEVERITY object. An instance of this object is created for every alert or policy violation. When an alert or policy violation occurs, the notification system calls the PL/SQL procedure associated with the notification rule and passes the populated object to the procedure. The procedure is then able to access the fields of the MGMT_NOTIFY_SEVERITY object that has been passed to it.

The following table lists all metric severity attributes that can be passed:

Table 13-3 Metric Severity Attributes

AttributeDatatypeAdditional Information

TARGET_NAME

VARCHAR2(256)

Name of the target on which the severity occurred.

TARGET_TYPE

VARCHAR2(64)

Type of target on which the severity occurred. Targets are defined as any monitorable service.

TIMEZONE

VARCHAR2(64)

The target's regional timezone

HOST_NAME

VARCHAR2(128)

Name of the machine on which the target resides.

METRIC_NAME

VARCHAR2(64)

Metric or policy generating the severity.

METRIC_DESCRIPTION

VARCHAR2(128)

Meaningful description of the metric that can be understood by other administrators.

METRIC_COLUMN

VARCHAR2(64)

For table metrics, the metric column contains the name of the column in the table that is being defined. If the metric that is being defined is not a table metric, the value in this column is a single space. This attribute is not used for policy violations.

METRIC_VALUE

VARCHAR2(1024)

The value of the metric.

KEY_VALUE

VARCHAR2(1290)

For metrics that monitor a set of objects, the KEY_VALUE indicates the specific object that triggered the severity. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE is 'USERS' if the USERS tablespace triggered at warning or critical severity.

KEY_VALUE_NAME

VARCHAR2(512)

For metrics that monitor a set of objects, the KEY_VALUE_NAME indicates the type of object monitored. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE_NAME is 'Tablespace Name'.

KEY_VALUE_GUID

VARCHAR2(256)

GUID associated with a composite key value name.

CTXT_LIST

MGMT_NOTIFY_COLUMNS

Details of the alert context.

COLLECTION_TIMESTAMP

DATE

The time when the target status change was last detected and logged in the management repository.

SEVERITY_CODE

NUMBER

Numeric code identifying the severity level. See Severity Code table below.

MESSAGE

VARCHAR2(4000)

An optional message that is generated when the alert is created that provides additional information about the alert condition.

SEVERITY_GUID

RAW(16)

Severity global unique identifier.

METRIC_GUID

RAW(16)

Metric global unique identifier.

TARGET_GUID

RAW(16)

Target global unique identifier.

RULE_OWNER

VARCHAR2(64)

Name of the Enterprise Manager administrator who owns the rule.

RULE_NAME

VARCHAR2(132)

Name of the notification rule that resulted in the severity.


When a severity occurs for the target, the notification system creates an instance of the MGMT_NOTIFY_SEVERITY object and populates it with values from the severity. The severity codes in Table 13-4 have been defined as constants in the MGMT_GLOBAL package and can be used to determine the type of severity in the severity_code field of the MGMT_NOTIFY_SEVERITY object.

Table 13-4 Severity Codes

NameDatatypeValue

G_SEVERITY_COMMENT

NUMBER(2)

10

G_SEVERITY_CLEAR

NUMBER(2)

15

G_SEVERITY_WARNING

NUMBER(2)

20

G_SEVERITY_CRITICAL

NUMBER(2)

25

G_SEVERITY_UNREACHABLE_CLEAR

NUMBER(3)

115

G_SEVERITY_UNREACHABLE_START

NUMBER(3)

125

G_SEVERITY_BLACKOUT_END

NUMBER(3)

215

G_SEVERITY_BLACKOUT_START

NUMBER(3)

225

G_SEVERITY_ERROR_END

NUMBER(3)

315

G_SEVERITY_ERROR_START

NUMBER(3)

325

G_SEVERITY_NO_BEACONS

NUMBER(3)

425

G_SEVERITY_UNKNOWN

NUMBER(3)

515


Example 13-11 PL/SQL Procedure Using a Severity Code

CREATE TABLE alert_log (target_name VARCHAR2(64),
alert_msg VARCHAR2(4000),
occured DATE);

PROCEDURE LOG_CRITICAL_ALERTS(severity IN MGMT_NOTIFY_SEVERITY)
IS
BEGIN
-- Log all critical severities
   IF severity.severity_code = MGMT_GLOBAL.G_SEVERITY_CRITICAL
   THEN
        BEGIN
                INSERT INTO alert_log (target_name, alert_msg, occured)
                VALUES (severity.target_name, severity.message,
                                severity.collection_timestamp);
        EXCEPTION
        WHEN OTHERS
        THEN
        -- If there are any problems then get the notification retried
                RAISE_APPLICATION_ERROR(-20000, 'Please retry');
                END;
                COMMIT;
   END IF;
END LOG_CRITICAL_ALERTS;

13.2.1.3 Adding a Notification Method Based on an SNMP Trap

Enterprise Manager supports integration with third-party management tools through the SNMP. For example, you can use SNMP to notify a third-party application that a selected metric has exceeded its threshold.

The trap is an SNMP Version 1 trap and is described by the MIB definition shown at the end of this chapter. See "Management Information Base (MIB)".

For more comprehensive configuration information, see the documentation specific to your platform; SNMP configuration differs from platform to platform.


Note:

Notification methods based on SNMP traps must be configured by an administrator with Super Administrator privileges before any user can then choose to select one or more of these SNMP trap methods while creating/editing a notification rule.

Step 1: Define a new notification method based on an SNMP trap.

Log in to Enterprise Manager as a Super Administrator. Click Setup and then click Notification Method from the vertical navigation bar to access the Notification Methods page. From this page you can add a new method based on an SNMP trap.

You must provide the name of the host (machine) on which the SNMP master agent is running and other details as shown in the following example. In Example 13-12, the SNMP host will receive your SNMP traps.

Example 13-12 SNMP Trap Required Information

Name HP OpenView Console
Description Notification method to send trap to HP OpenView console
SNMP Trap Host Name machine1.us.oracle.com
SNMP Host Port 162
SNMP Community public
This SNMP host will receive your SNMP traps.

Note:

A Test Trap button exists for you to test your setup.

Metric severity information will be passed as a series of variables in the SNMP trap.

An example SNMP Trap is shown in Example 13-13. Each piece of information is sent as a variable embedded in the SNMP Trap.

Example 13-13 SNMP Trap

Tue Oct 28 05:00:02 2006

Command: 4
   Enterprise: 1.3.6.1.4.1.111.15.2
   Agent: 138.1.6.200
   Generic Trap: 6
   Specific Trap: 1
   Time Stamp: 8464:39.99
   Count: 11

Name: 1.3.6.1.4.1.111.15.1.1.1.2.1
   Kind: OctetString
   Value: "mydatabase"

Name: 1.3.6.1.4.1.111.15.1.1.1.3.1
   Kind: OctetString
   Value: "Database"

Name: 1.3.6.1.4.1.111.15.1.1.1.4.1
  Kind: OctetString
  Value: "myhost.com"

Name: 1.3.6.1.4.1.111.15.1.1.1.5.1
   Kind: OctetString
   Value: "Owner's Invalid Object Count"

Name: 1.3.6.1.4.1.111.15.1.1.1.6.1
   Kind: OctetString
   Value: "Invalid Object Owner"

Name: 1.3.6.1.4.1.111.15.1.1.1.7.1
   Kind: OctetString
   Value: "SYS"

Name: 1.3.6.1.4.1.111.15.1.1.1.8.1
   Kind: OctetString
   Value: "28-OCT-2006 04:59:10 (US/Eastern GMT)"

Name: 1.3.6.1.4.1.111.15.1.1.1.9.1
   Kind: OctetString
   Value: "Warning"

Name: 1.3.6.1.4.1.111.15.1.1.1.10.1
   Kind: OctetString
   Value: "12 object(s) are invalid in the SYS schema."

Name: 1.3.6.1.4.1.111.15.1.1.1.11.1
   Kind: OctetString
   Value: "Database Metrics"

Name: 1.3.6.1.4.1.111.15.1.1.1.12.1
   Kind: OctetString
   Value: "SYSMAN"

Step 2: Assign the notification method to a rule.

You can edit an existing rule (or create a new notification rule), then go to the Methods page. In the list of Advanced Notification Methods, select your notification method and click 'Assign Method to Rule'. To assign multiple rules to a method or methods to a rule, see "Assigning Rules to Methods" or "Assigning Methods to Rules".

13.3 Passing Corrective Action Status Change Information

Passing corrective action status change attributes (new status, job name, job type, notification rule, or rule owner, etc.) to PL/SQL procedures or OS commands/scripts allows you to customize automated responses to status changes. For example, you many want to call an OS script to open a trouble ticket for an in-house support trouble ticket system if a critical corrective action fails to run. In this case you will want to pass status (Problems, Aborted, etc.) to the script to open a trouble ticket and escalate the problem.

13.3.1 Passing Corrective Action Execution Status to an OS Command or Script

The notification system passes information to an OS script or executable via system environment variables. Conventions used to access environmental variables vary depending on the operating system:

  • UNIX: $ENV_VARIABLE

  • MS Windows: %ENV_VARIABLE%

The notification system sets the following environment variables before calling the script. The script can then use any or all of these variables within the logic of the script.

Table 13-5 Environment Variables

Environment VariableDescription

JOB_NAME

The name of the corrective action.

JOB_OWNER

The owner of the corrective action.

JOB_TYPE

The type of corrective action.

JOB_STATUS

The corrective action status.

TIMESTAMP

Time when the severity occurred.

NUM_TARGETS

The number of targets.

TARGET_NAMEn

The name of the nth target on which the corrective action ran. Example: TARGET_NAME1, TARGET_NAME2.

METRIC

The name of the metric in the alert that caused the corrective action to run. Not set for policy violations.

POLICY_RULE

The name of the policy rule in the alert that caused the corrective action to run. Not set for metric severities.

METRIC_VALUE

The value of the metric column in the alert that caused the corrective action to run.

VIOLATION_CONTEXT

A comma-separated list of name-value pairs that show the policy violation context.

KEY_VALUE_NAME

For metrics that monitor a set of objects, the KEY_VALUE_NAME indicates the type of object monitored. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE_NAME is 'Tablespace Name'.

KEY_VALUE

For metrics that monitor a set of objects, the KEY_VALUE indicates the specific object that triggered the severity. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE is 'USERS' if the USERS tablespace triggered at warning or critical severity.

SEVERITY

Type of alert severity. For example, severity types that relate to a target's availability are:

  • UP

  • DOWN

  • UNREACHABLE CLEAR

  • UNREACHABLE START

  • BLACKOUT END

  • BLACKOUT START

Other metrics can have any of the following severities:

  • WARNING

  • CRITICAL

  • CLEAR

  • METRIC ERROR CLEAR

  • METRIC ERROR START

RULE_NAME

Name of the notification rule that resulted in the execution of the corrective action.

RULE_OWNER

Name of the Enterprise Manager administrator who owns the notification rule.


13.3.2 Passing Corrective Action Execution Status to a PLSQL Procedure

The notification system passes corrective action status change information to a PL/SQL procedure via the MGMT_NOTIFY_CORRECTIVE_ACTION object. An instance of this object is created for every status change. When a corrective action executes, the notification system calls the PL/SQL procedure associated with the notification rule and passes the populated object to the procedure. The procedure is then able to access the fields of the MGMT_NOTIFY_CORRECTIVE_ACTION object that has been passed to it.

Table 13-6 lists all corrective action status change attributes that can be passed:

Table 13-6 Corrective Action Status Attributes

AttributeDatatypeAdditional Information

JOB_NAME

VARCHAR2(128)

The corrective action name.

JOB_OWNER

VARCHAR(256)

The owner of the corrective action.

JOB_TYPE

VARCHAR2(32)

The type of the corrective action.

JOB_STATUS

NUMBER

The new status of the corrective action. See Table 13-7, "Corrective Action Status Codes" for a list of possible status conditions.

STATE_CHANGE_GUID

RAW(16)

The GUID of the state change record.

JOB_GUID

RAW(16)

The unique id of the corrective action.

EXECUTION_ID

RAW(16)

The unique id of the corrective action execution.

TARGETS

SMP_EMD_NVPAIR_ARRAY

An array of the target name/target type pairs that the corrective action runs on.

METRIC_NAME

VARCHAR2(256)

The name of the metric/policy rule in the alert that caused the corrective action to run.

METRIC_COLUMN

VARCHAR2(64)

The name of the metric in the alert that caused the corrective action to run. This is not used for policy violations.

METRIC_VALUE

VARCHAR2(1024)

The value of the metric in the alert that caused the corrective action to run.

SEVERITY_CODE

NUMBER

The severity code of the alert that caused the corrective action to run. See Table 13-4, "Severity Codes".

KEY_VALUE_NAME

VARCHAR2(512)

For metrics that monitor a set of objects, the KEY_VALUE_NAME indicates the type of object monitored. For example for the Tablespace Space Used (%) metric that monitors tablespace objects, the KEY_VALUE_NAME is 'Tablespace Name'.

KEY_VALUE

VARCHAR2(1290)

For table metrics, this column contains the value of the key column for the row in the table whose thresholds are being defined. If the thresholds are not for a table metric, or the thresholds apply for all rows in the metric column, then the value in this column will contain a single space.

KEY_VALUE_GUID

RAW(16)

GUID associated with a composite key value name.

CTXT_LIST

MGMT_NOTIFY_COLUMNS

Details of the corrective action status change context.

RULE_OWNER

VARCHAR2(64)

The owner of the notification rule that caused the PL/SQL notification to be sent.

RULE_NAME

VARCHAR2(132)

The name of the notification rule that caused the PL/SQL notification method to be invoked.

OCCURRED_DATE

DATE

The time and date when the status change happened.


The following status codes are possible values for the job_status field of the MGMT_NOTIFY_CORRECTIVE_ACTION object.

Table 13-7 Corrective Action Status Codes

NameDatatypeValue

SCHEDULED_STATUS

NUMBER(2)

1

EXECUTING_STATUS

NUMBER(2)

2

ABORTED_STATUS

NUMBER(2)

3

FAILED_STATUS

NUMBER(2)

4

COMPLETED_STATUS

NUMBER(2)

5

SUSPENDED_STATUS

NUMBER(2)

6

AGENTDOWN_STATUS

NUMBER(2)

7

STOPPED_STATUS

NUMBER(2)

8

SUSPENDED_LOCK_STATUS

NUMBER(2)

9

SUSPENDED_EVENT_STATUS

NUMBER(2)

10

SUSPENDED_BLACKOUT_STATUS

NUMBER(2)

11

STOP_PENDING_STATUS

NUMBER(2)

12

SUSPEND_PENDING_STATUS

NUMBER(2)

13

INACTIVE_STATUS

NUMBER(2)

14

QUEUED_STATUS

NUMBER(2)

15

FAILED_RETRIED_STATUS

NUMBER(2)

16

WAITING_STATUS

NUMBER(2)

17

SKIPPED_STATUS

NUMBER(2)

18

REASSIGNED_STATUS

NUMBER(2)

20


Example 13-14 PL/SQL Procedure Using a Status Code

CREATE TABLE ca_log (jobid RAW(16),                occured DATE);

CREATE OR REPLACE PROCEDURE LOG_PROBLEM_CAS(status_change IN MGMT_NOTIFY_CORRECTIVE_ACTION)
IS
BEGIN
        -- Log all failed corrective actions
   IF status_change.job_status = MGMT_JOBS.FAILED_STATUS
   THEN
        BEGIN
                INSERT INTO ca_log (jobid, occured)
                VALUES (status_change.job_guid, SYSDATE);
        EXCEPTION
        WHEN OTHERS
        THEN
        -- If there are any problems then get the notification retried
                RAISE_APPLICATION_ERROR(-20000, 'Please retry');
                END;
                COMMIT;
   END IF;
END LOG_PROBLEM_CAS;

13.4 Passing Job Execution Status Information

Passing job status change attributes (new status, job name, job type, notification rule, or rule owner, etc.) to PL/SQL procedures or OS commands/scripts allows you to customize automated responses to status changes. For example, you many want to call an OS script to open a trouble ticket for an in-house support trouble ticket system if a critical job fails to run. In this case you will want to pass status (Problems, Aborted, etc.) to the script to open a trouble ticket and escalate the problem.

13.4.1 Passing Job Execution Status to a PLSQL Procedure

The notification system passes job status change information to a PL/SQL procedure via the MGMT_NOTIFY_JOB object. An instance of this object is created for every status change. When a job changes status, the notification system calls the PL/SQL procedure associated with the notification rule and passes the populated object to the procedure. The procedure is then able to access the fields of the MGMT_NOTIFY_JOB object that has been passed to it.

Table 13-8 lists all corrective action status change attributes that can be passed:

Table 13-8 Job Status Attributes

AttributeDatatypeAdditional Information

job_name

VARCHAR2(128)

The job name.

job_owner

VARCHAR2(256)

The owner of the job.

job_type

VARCHAR2(32)

The type of the job.

job_status

NUMBER

The new status of the job.

state_change_guid

RAW(16)

The GUID of the state change record.

job_guid

RAW(16)

The unique id of the job.

execution_id

RAW(16)

The unique id of the execution.

targets

SMP_EMD_NVPAIR_ARRAY

An array of the target name/target type pairs that the job runs on.

rule_owner

VARCHAR2(64)

The name of the notification rule that cause the notification to be sent.

rule_name

VARCHAR2(132)

The owner of the notification rule that cause the notification to be sent.

occurred_date

DATE

The time and date when the status change happened.


When a job status change occurs for the job, the notification system creates an instance of the MGMT_NOTIFY_JOB object and populates it with values from the status change. The following status codes have been defined as constants in the MGMT_JOBS package and can be used to determine the type of status in the job_status field of the MGMT_NOTIFY_JOB object.

Table 13-9 Job Status Codes

NameDatatypeValue

SCHEDULED_STATUS

NUMBER(2)

1

EXECUTING_STATUS

NUMBER(2)

2

ABORTED_STATUS

NUMBER(2)

3

FAILED_STATUS

NUMBER(2)

4

COMPLETED_STATUS

NUMBER(2)

5

SUSPENDED_STATUS

NUMBER(2)

6

AGENTDOWN_STATUS

NUMBER(2)

7

STOPPED_STATUS

NUMBER(2)

8

SUSPENDED_LOCK_STATUS

NUMBER(2)

9

SUSPENDED_EVENT_STATUS

NUMBER(2)

10

SUSPENDED_BLACKOUT_STATUS

NUMBER(2)

11

STOP_PENDING_STATUS

NUMBER(2)

12

SUSPEND_PENDING_STATUS

NUMBER(2)

13

INACTIVE_STATUS

NUMBER(2)

14

QUEUED_STATUS

NUMBER(2)

15

FAILED_RETRIED_STATUS

NUMBER(2)

16

WAITING_STATUS

NUMBER(2)

17

SKIPPED_STATUS

NUMBER(2)

18

REASSIGNED_STATUS

NUMBER(2)

20


Example 13-15 PL/SQL Procedure Using a Status Code (Job)

CREATE TABLE job_log (jobid RAW(16),               occured DATE);

CREATE OR REPLACE PROCEDURE LOG_PROBLEM_JOBS(status_change IN MGMT_NOTIFY_JOB)
IS
BEGIN
        -- Log all failed jobs
   IF status_change.job_status = MGMT_JOBS.FAILED_STATUS
   THEN
        BEGIN
                INSERT INTO job_log (jobid, occured)
                VALUES (status_change.job_guid, SYSDATE);
        EXCEPTION
        WHEN OTHERS
        THEN
        -- If there are any problems then get the notification retried
                RAISE_APPLICATION_ERROR(-20000, 'Please retry');
                END;
                COMMIT;
   END IF;
END LOG_PROBLEM_JOBS;

13.4.2 Passing Job Execution Status to an OS Command or Script

The notification system passes job execution status information to an OS script or executable via system environment variables. Conventions used to access environmental variables vary depending on the operating system:

  • UNIX: $ENV_VARIABLE

  • MS Windows: %ENV_VARIABLE%

The notification system sets the following environment variables before calling the script. The script can then use any or all of these variables within the logic of the script.

Table 13-10 Environment Variables

Environment VariableDescription

JOB_NAME

The name of the job.

JOB_OWNER

The owner of the job.

JOB_TYPE

The type of job.

JOB_STATUS

The job status.

TIMESTAMP

Time when the severity occurred.

NUM_TARGETS

The number of targets.

TARGET_NAMEn

The name of the nth target. For example, TARGET_NAME1, TARGET_NAME2.

TARGET_TYPEn

The type of the nth target. For example TARGET_TYPE1, TARGET_TYPE2.

RULE_NAME

Name of the notification rule that resulted in the severity.

RULE_OWNER

Name of the Enterprise Manager administrator who owns the notification rule.


13.5 Assigning Methods to Rules

For each notification rule, you can assign one or more notification methods to be called when any of the criteria in the notification rule is met.

  1. From the Enterprise Manager Grid Control, click Preferences at the top of the page.

  2. Click Notification Rules in the vertical navigation bar.

    The Enterprise Manager Grid Control displays the Notification Rules page. Any notification rules already created are listed in the Notification Rules table.

  3. Click Assign Methods to Multiple Rules.

  4. Perform your assignments.

Figure 13-2 Assigning Methods to Rules

This graphic shows the Assign Methods to Multiple rule page

13.6 Assigning Rules to Methods

For each notification method, you can associate one or more notification rules that will use that method to send notifications.

  1. From the Enterprise Manager Grid Control, click Preferences at the top of the page.

  2. Click Notification Rules in the vertical navigation bar.

    The Enterprise Manager Grid Control displays the Notification Rules page. Any notification rules already created are listed in the Notification Rules table.

  3. Click Assign Methods to Multiple Rules.

  4. From the View menu, select By Method.

  5. Perform your assignments.

Figure 13-3 Assign Rules to Methods

Description of Figure 13-3 follows

13.7 Management Information Base (MIB)

Enterprise Manager Grid Control can send SNMP Traps to third-party, SNMP-enabled applications. Details of the trap contents can be obtained from the management information base (MIB) variables. The following sections discuss Enterprise Manager MIB variables in detail.

13.7.1 About MIBs

A MIB is a text file, written in ASN.1 notation, which describes the variables containing the information that SNMP can access. The variables described in a MIB, which are also called MIB objects, are the items that can be monitored using SNMP. There is one MIB for each element being monitored. Each monolithic or subagent consults its respective MIB in order to learn the variables it can retrieve and their characteristics. The encapsulation of this information in the MIB is what enables master agents to register new subagents dynamically — everything the master agent needs to know about the subagent is contained in its MIB. The management framework and management applications also consult these MIBs for the same purpose. MIBs can be either standard (also called public) or proprietary (also called private or vendor).

The actual values of the variables are not part of the MIB, but are retrieved through a platform-dependent process called "instrumentation". The concept of the MIB is very important because all SNMP communications refer to one or more MIB objects. What is transmitted to the framework is, essentially, MIB variables and their current values.

13.7.2 Reading the MIB Variable Descriptions

This section covers the format used to describe MIB variables. Note that the STATUS element of SNMP MIB definition, Version 2, is not included in these MIB variable descriptions. Since Oracle has implemented all MIB variables as CURRENT, this value does not vary.

13.7.2.1 Variable Name

Syntax

Maps to the SYNTAX element of SNMP MIB definition, Version 2.

Max-Access

Maps to the MAX-ACCESS element of SNMP MIB definition, Version 2.

Status

Maps to the STATUS element of SNMP MIB definition, Version 2.

Explanation

Describes the function, use and precise derivation of the variable. (For example, a variable might be derived from a particular configuration file parameter or performance table field.) When appropriate, incorporates the DESCRIPTION part of the MIB definition, Version 2.

Typical Range

Describes the typical, rather than theoretical, range of the variable. For example, while integer values for many MIB variables can theoretically range up to 4294967295, a typical range in an actual installation will vary to a lesser extent. On the other hand, some variable values for a large database can actually exceed this "theoretical" limit (a "wraparound"). Specifying that a variable value typically ranges from 0 to 1,000 or 1,000 to 3 billion will help the third-party developer to develop the most useful graphical display for the variable.

Significance

Describes the significance of the variable when monitoring a typical installation. Alternative ratings are Very Important, Important, Less Important, or Not Normally Used. Clearly, the DBA will want to monitor some variables more closely than others. However, which variables fall into this category can vary from installation to installation, depending on the application, the size of the database, and on the DBA's objectives. Nevertheless, assessing a variable's significance relative to the other variables in the MIB can help third-party developers focus their efforts on those variables of most interest to the most DBAs.

Related Variables

Lists other variables in this MIB, or other MIBs implemented by Oracle, that relate in some way to this variable. For example, the value of this variable might derive from that of another MIB variable. Or perhaps the value of this variable varies inversely to that of another variable. Knowing this information, third-party developers can develop useful graphic displays of related MIB variables.

Suggested Presentation

Suggests how this variable can be presented most usefully to the DBA using the management application: as a simple value, as a gauge, or as an alarm, for example.

13.7.2.2 MIB Definition

Example 13-16 shows a typical MIB definition used by Enterprise Manager.

Example 13-16 MIB Definition

ORACLE-ENTERPRISE-MANAGER-4-MIB DEFINITIONS ::= BEGIN
IMPORTS
    TRAP-TYPE
        FROM RFC-1215
    DisplayString
        FROM RFC1213-MIB
    OBJECT-TYPE
        FROM RFC-1212
    enterprises
        FROM RFC1155-SMI;
oracle OBJECT IDENTIFIER ::= { enterprises  111 }
oraEM4 OBJECT IDENTIFIER ::= { oracle  15 }
oraEM4Objects OBJECT IDENTIFIER ::= { oraEM4  1 }
oraEM4AlertTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF OraEM4AlertEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
     "Information on alerts generated by Oracle Enterprise Manager. This table is
 not queryable; it exists only to document the variables included in the
 oraEM4Alert trap.  Each trap contains a single instance of each variable in the
 table."
    ::= { oraEM4Objects  1 }
oraEM4AlertEntry OBJECT-TYPE
    SYNTAX  OraEM4AlertEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
     "Information about a particular Oracle Enterprise Manager alert."
    INDEX   { oraEM4AlertIndex }
    ::= { oraEM4AlertTable  1 }
OraEM4AlertEntry ::=
    SEQUENCE {
        oraEM4AlertIndex
            INTEGER,
        oraEM4AlertTargetName
       DisplayString,
        oraEM4AlertTargetType
       DisplayString,
        oraEM4AlertHostName
       DisplayString,
        oraEM4AlertMetricName
       DisplayString,
        oraEM4AlertKeyName
       DisplayString,
        oraEM4AlertKeyValue
       DisplayString,
        oraEM4AlertTimeStamp
       DisplayString,
        oraEM4AlertSeverity
       DisplayString,
        oraEM4AlertMessage
       DisplayString,
        oraEM4AlertRuleName
       DisplayString
        oraEM4AlertRuleOwner
       DisplayString
    oraEM4AlertMetricValue
           DisplayString,
        oraEM4AlertContext
           DisplayString
    }
oraEM4AlertIndex OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "Index of a particular alert, unique only at the moment an alert is generated."
    ::= { oraEM4AlertEntry  1 }
oraEM4AlertTargetName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the target to which this alert applies."
    ::= { oraEM4AlertEntry  2 }
oraEM4AlertTargetType OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The type of the target to which this alert applies."
    ::= { oraEM4AlertEntry  3 }
oraEM4AlertHostName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the host on which this alert originated."
    ::= { oraEM4AlertEntry  4 }
oraEM4AlertMetricName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the metric or policy which generated this alert."
    ::= { oraEM4AlertEntry  5 }
oraEM4AlertKeyName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the key-column, if present, for the metric which generated this alert."
    ::= { oraEM4AlertEntry  6 }
oraEM4AlertKeyValue OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The value of the key-column, if present, for the metric which generated this alert."
    ::= { oraEM4AlertEntry  7 }
oraEM4AlertTimeStamp OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The time at which this alert was generated."
    ::= { oraEM4AlertEntry  8 }
oraEM4AlertSeverity OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The severity of the alert e.g. Critical."
    ::= { oraEM4AlertEntr*Hշy  9 }
oraEM4AlertMessage OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The message associated with the alert."
    ::= { oraEM4AlertEntry  10 }
oraEM4AlertRuleName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the notification rule that caused this notification."
    ::= { oraEM4AlertEntry  11 }
oraEM4AlertRuleOwner OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The owner of the notification rule that caused this notification."
    ::= { oraEM4AlertEntry  12 }
oraEM4AlertMetricValue OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The value of the metric which caused this alert to be generated."
    ::= { oraEM4AlertEntry  13 }
oraEM4AlertContext OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "A comma separated list of metric column names and values associated with the metric that caused this alert to be generated."
    ::= { oraEM4AlertEntry  14 }
oraEM4Traps OBJECT IDENTIFIER ::= { oraEM4  2 }
oraEM4Alert TRAP-TYPE
    ENTERPRISE  oraEM4Traps
    VARIABLES   { oraEM4AlertTargetName, oraEM4AlertTargetType,
                  oraEM4AlertHostName, oraEM4AlertMetricName,
                  oraEM4AlertKeyName, oraEM4AlertKeyValue, oraEM4AlertTimeStamp,
                  oraEM4AlertSeverity, oraEM4AlertMessage,
                  oraEM4AlertRuleName, oraEM4AlertRuleOwner,
                  oraEM4AlertMetricValue, oraEM4AlertContext }
    DESCRIPTION
     "The variables included in the oraEM4Alert trap."
    ::= 1
oraEM4JobAlertTable OBJECT-TYPE
    SYNTAX  SEQUENCE OF OraEM4JobAlertEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
     "Information on alerts generated by Oracle Enterprise Manager. This table is
 not queryable; it exists only to document the variables included in the
 oraEM4JobAlert trap.  Each trap contains a single instance of each variable in
 the table."
    ::= { oraEM4Objects  2 }
oraEM4JobAlertEntry OBJECT-TYPE
    SYNTAX  OraEM4AlertEntry
    ACCESS  not-accessible
    STATUS  mandatory
    DESCRIPTION
     "Information about a particular Oracle Enterprise Manager alert."
    INDEX   { oraEM4JobAlertIndex }
    ::= { oraEM4JobAlertTable  1 }
OraEM4JobAlertEntry ::=
    SEQUENCE {
        oraEM4JobAlertIndex
            INTEGER,
        oraEM4JobAlertJobName
       DisplayString,
        oraEM4JobAlertJobOwner
       DisplayString,
        oraEM4JobAlertJobType
       DisplayString,
        oraEM4JobAlertJobStatus
       DisplayString,
        oraEM4JobAlertTargets
       DisplayString,
        oraEM4JobAlertTimeStamp
       DisplayString,
        oraEM4JobAlertRuleName
       DisplayString
        oraEM4JobAlertRuleOwner
       DisplayString,
    oraEM4JobAlertMetricName
           DisplayString,
    oraEM4JobAlertMetricValue
           DisplayString,
        oraEM4JobAlertContext
           DisplayString,
        oraEM4JobAlertKeyName
       DisplayString,
        oraEM4JobAlertKeyValue
       DisplayString,
        oraEM4JobAlertSeverity
       DisplayString
    }
oraEM4JobAlertIndex OBJECT-TYPE
    SYNTAX  INTEGER
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "Index of a particular alert, unique only at the moment an alert is
 generated."
    ::= { oraEM4JobAlertEntry  1 }
oraEM4JobAlertJobName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the job to which this alert applies."
    ::= { oraEM4JobAlertEntry  2 }
oraEM4JobAlertJobOwner OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The owner of the job to which this alert applies."
    ::= { oraEM4JobAlertEntry  3 }
oraEM4JobAlertJobType OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The type of the job to which this alert applies."
    ::= { oraEM4JobAlertEntry  4 }
oraEM4JobAlertJobStatus OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The status of the job to which this alert applies."
    ::= { oraEM4JobAlertEntry  5 }
oraEM4JobAlertTargets OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "A comma separated list of target to which this alert applies."
    ::= { oraEM4JobAlertEntry  6 }
oraEM4JobAlertTimeStamp OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The time at which this job status changed causing this alert."
    ::= { oraEM4JobAlertEntry  7 }
oraEM4JobAlertRuleName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the notification rule that caused this notification."
    ::= { oraEM4JobAlertEntry  8 }
oraEM4JobAlertRuleOwner OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The owner of the notification rule that caused this notification."
    ::= { oraEM4JobAlertEntry  9 }
oraEM4JobAlertMetricName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the metric or policy which caused the Corrective Action to run
 that caused this alert."
    ::= { oraEM4JobAlertEntry  10 }
oraEM4JobAlertMetricValue OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The value of the metric which caused the Corrective Action to run that
 caused this alert."
    ::= { oraEM4JobAlertEntry  11 }
oraEM4JobAlertContext OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "A comma separated list of metric column names and values associated with the
 metric which caused the Corrective Action to run that caused this alert."
    ::= { oraEM4JobAlertEntry  12 }
oraEM4JobAlertKeyName OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The name of the key-column, if present, for the metric which caused the
 Corrective Action to run that generated this alert."
    ::= { oraEM4JobAlertEntry  13 }
oraEM4JobAlertKeyValue OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The value of the key-column, if present, for the metric which caused the
 Corrective Action to run that generated this alert."
    ::= { oraEM4JobAlertEntry  14 }
oraEM4JobAlertSeverity OBJECT-TYPE
    SYNTAX  DisplayString
    ACCESS  read-only
    STATUS  mandatory
    DESCRIPTION
     "The severity of the metric which caused the Corrective Action to run that
 generated this alert e.g. Critical."
    ::= { oraEM4JobAlertEntry  15 }
oraEM4JobAlert TRAP-TYPE
    ENTERPRISE  oraEM4Traps
    VARIABLES   { oraEM4JobAlertJobName, oraEM4JobAlertJobOwner,
                  oraEM4JobAlertJobType, oraEM4JobAlertJobStatus,
                  oraEM4JobAlertTargets, oraEM4JobAlertTimeStamp,
                  oraEM4JobAlertRuleName, oraEM4JobAlertRuleOwner,
                  oraEM4JobAlertMetricName, oraEM4JobAlertMetricValue,
                  oraEM4JobAlertContext, oraEM4JobAlertKeyName,
                  oraEM4JobAlertKeyValue, oraEM4JobAlertSeverity }
    DESCRIPTION
     "The variables included in the oraEM4JobAlert trap."
    ::= 2
END

13.8 Troubleshooting Notifications

To function properly, the notification system relies on various components of Enterprise Manager and your IT infrastructure. For this reason, there can be many causes of notification failure. The following guidelines and suggestions can help you isolate potential problems with the notification system.

13.8.1 General Setup

The first step in diagnosing notification issues is to ensure that you have properly configured and defined your notification environment.

OS Command, PL/SQL and SNMP Trap Notifications

Make sure all OS Command, PLSQL and SNMP Trap Notification Methods are valid by clicking the Test button. This will send a test notification and show any problems the OMS has in contacting the method. Make sure that your method was called, for example, if the OS Command notification is supposed to write information to a log file, check that it has written information to its log file.

E-mail Notifications

  • Make sure an e-mail gateway is set up under the Notification Methods page of Setup. The Sender's e-mail address should be valid. Clicking the Test button will send an e-mail to the Sender's e-mail address. Make sure this e-mail is received. Note that the Test button ignores any Notification Schedule.

  • Make sure an e-mail address is setup under General page of Preferences. Clicking the Test button will send an e-mail to specified address and you should make sure this e-mail is received. Note that the Test button ignores any Notification Schedule.

  • Make sure an e-mail schedule is defined under the Schedule page of Preferences. No e-mails will be sent unless a Notification Schedule has been defined.

  • Make sure a Notification Rule is defined to match the target, metric, severity and availability states you are interested and make sure e-mail and notification methods are assigned to the rule. A summary of the notification rule can be checked by going to the Rules page under Setup and clicking the rule name.

13.8.2 Notification System Errors

For any alerts involving problems with notifications, check the following for notification errors.

  • Any serious errors in the Notification System are logged as system errors in the MGMT_SYSTEM_ERROR_LOG table. These errors can be seen in the Errors page under Management Services and Repository under Setup.

  • Check for any delivery errors. From the Alerts section of a target home page, click on the alert message to access the metric details page. In the Alert History section, click on the Details icon for more information about the alert. The details will give the reason why the notification was not delivered. Delivery errors are stored in MGMT_NOTIFICATION_LOG with the DELIVERED column set to 'N'.

  • Severities will not be displayed in the Grid Control console if no metric values have been loaded for the metric associated with the severity.

13.8.3 Notification System Trace Messages

The Notification System can produce trace messages in sysman/log/emoms.trc file.

Tracing is configured by setting the following flag in sysman/config/emomslogging.properties file. You can set the trace level to INFO, WARN, DEBUG. For example,

log4j.em.notification=DEBUG

Trace messages contain the string "em.notification". If you are working in a UNIX environment, you can search for messages in the emoms.trc file using the grep command. For example,

grep em.notification emoms.trc

What to look for in the trace file.

The following entries in the emoms.trc file are relevant to notifications.

Normal Startup Messages

When the OMS starts, you should see these types of messages.

2006-11-08 03:18:45,385 [Orion Launcher] INFO  em.notification init.1279 - Short format maximum length is 155

2006-11-08 03:18:45,386 [Orion Launcher] INFO  em.notification init.1297 - Short format is set to both subject and body

2006-11-08 03:18:45,387 [NotificationMgrThread] INFO  em.notification run.1010 - Waiting for connection to EM Repository...

2006-11-08 03:18:46,006 [NotificationMgrThread] INFO  em.notification run.1041 - Registering for Administrative Queue Name...

2006-11-08 03:18:46,250 [NotificationMgrThread] INFO  em.notification run.1078 - Administrative Queue is ADM21

2006-11-08 03:18:46,250 [NotificationMgrThread] INFO  em.notification run.1089 - Creating thread pool: min = 6 max = 24

2006-11-08 03:18:48,206 [NotificationMgrThread] INFO  em.notification handleAdminNotification.655 - Handling notifications for EMAIL1

Notification Delivery Messages

2006-11-08 03:18:45,387 [NotificationMgrThread] INFO  em.notification run.682 - Notification ready on EMAIL1

2006-11-08 03:18:46,006 [DeliveryThread-EMAIL1] INFO  em.notification run.114 - Deliver to SYSMAN/admin@oracle.com

2006-11-08 03:18:47,006 [DeliveryThread-EMAIL1] INFO  em.notification run.227 - Notification handled for SYSMAN/admin@oracle.com

Notification System Error Messages

2006-11-08 07:26:30,242 [NotificationMgrThread] ERROR  em.notification getConnection.237 - Failed to get a connection Io exception: The Network Adapter could not establish the connection

13.8.4 E-mail Errors

The SMTP gateway is not set up correctly:

Failed to send e-mail to my.admin@oracle.com: For e-mail notifications to be sent, your Super Administrator must configure an Outgoing Mail (SMTP) Server within Enterprise Manager. (SYSMAN, myrule)

Invalid host name:

Failed to connect to gateway: badhost.us.oracle.com: Sending failed;
nested exception is:
javax.mail.MessagingException: Unknown SMTP     host: badhost.us.oracle.com;

Invalid e-mail address:

Failed to connect to gateway: rgmemeasmtp.oraclecorp.com: Sending failed;
nested exception is:
javax.mail.MessagingException: 550 5.7.1        <smpemailtest_ie@oracle.com>... Access denied

Always use the Test button to make sure the e-mail gateway configuration is valid. Check that an e-mail is received at the sender's e-mail address

13.8.5 OS Command Errors

When attempting to execute an OS command or script, the following errors may occur. Use the Test button to make sure OS Command configuration is valid. If there are any errors, they will appear in the console.

Invalid path or no read permissions on file:

Could not find /bin/myscript (stacb10.us.oracle.com_Management_Service) (SYSMAN, myrule )

No execute permission on executable:

Error calling /bin/myscript: java.io.IOException: /bin/myscript: cannot execute (stacb10.us.oracle.com_Management_Service) (SYSMAN, myrule ) 

Timeout because OS Command ran too long:

Timeout occurred running /bin/myscript (stacb10.us.oracle.com_Management_Service) (SYSMAN, myrule )

Any errors such as out of memory or too many processes running on OMS machine will be logged as appropriate.

Always use the Test button to make sure OS Command configuration is valid.

13.8.6 SNMP Trap Errors

Use the Test button to make sure SNMP Trap configuration is valid.

Other possible SNMP trap problems include: invalid host name, port, or community for a machine running an SNMP Console.

13.8.7 PL/SQL Errors

When attempting to execute an PL/SQL procedure, the following errors may occur. Use the Test button to make sure the procedure is valid. If there are any errors, they will appear in the console.

Procedure name is invalid or is not fully qualified. Example: SCOTT.PKG.PROC

Error calling PL/SQL procedure plsql_proc: ORA-06576: not a valid function or procedure name (SYSMAN, myrule) 

Procedure is not the correct signature. Example: PROCEDURE p(s IN MGMT_NOTIFY_SEVERITY)

Error calling PL/SQL procedure plsql_proc: ORA-06553: PLS-306: wrong number or types of arguments in call to 'PLSQL_PROC' (SYSMAN, myrule)

Procedure has bug and is raising an exception.

Error calling PL/SQL procedure plsql_proc: ORA-06531: Reference to uninitialized collection (SYSMAN, myrule)

Care should be taken to avoid leaking cursors in your PL/SQL. Any exception due to this condition will result in delivery failure with the message being displayed in the Details section of the alert in the Grid Control console.

Always use the Test button to make sure the PL/SQL configuration is valid.

PK~\CH*HPK^UIOEBPS/actpass_env.htm] Configuring Oracle Enterprise Manager for Active and Passive Environments

4 Configuring Oracle Enterprise Manager for Active and Passive Environments

Active and Passive environments, also known as Cold Failover Cluster (CFC) environments, refer to one type of high availability solution that allows an application to run on one node at a time. These environments generally use a combination of cluster software to provide a logical host name and IP address, along with interconnected host and storage systems to share information to provide a measure of high availability for applications.

This chapter contains the following sections:

4.1 Configuring Oracle Enterprise Management Agents for Use in Active and Passive Environments

In a Cold Failover Cluster environment, one host is considered the active node where applications are run, accessing the data contained on the shared storage. The second node is considered the standby node, ready to run the same applications currently hosted on the primary node in the event of a failure. The cluster software is configured to present a Logical Host Name and IP address. This address provides a generic location for running applications that is not tied to either the active node or the standby node.

In the event of a failure of the active node, applications can be terminated either by the hardware failure or by the cluster software. These application can then be restarted on the passive node using the same logical host name and IP address to access the new node; resuming operations with little disruption. Automating failover of the virtual host name and IP, along with starting the applications on the passive node, requires the use of the third party cluster software. Several Oracle partner vendors provide high availability solutions in this area.

4.1.1 Installation and Configuration

Enterprise Manager can be configured to support this Cold Failover Cluster configuration using the existing Management Agents communicating to the Oracle Management Service processes.

If your application is running in an Active and Passive environment, the clusterware does the job of bringing up the passive or standby database instance in case the Active database goes down. For Enterprise Manager to continue monitoring the application instance in such a scenario, the existing Management Agents need additional configuration.

The additional configuration steps for this environment involve:

  • Installing of an extra Management Agent using the logical host name and IP address generated through the cluster software.

  • Modifying the targets monitored by each Management Agent once the third Management Agent is installed.

In summary, this configuration results in the installation of three Management Agents, one for each hardware node and one for the IP address generated by the cluster software. Theoretically, if the cluster software supports the generation of multiple virtual IP addresses to support multiple high availability environments, the solution outlined here should scale to support the environment.

The following table documents the steps required to configure agents in a CFC environment:

Table 4-1 Steps Required to Configure Management Agents in a Cold Failover Cluster Environment

ActionMethodDescription/OutcomeVerification

Install the vendor specific cluster software

Installation method varies depending on the cluster vendor.

The minimal requirement is a 2-node cluster that supports Virtual or Floating IP addresses and shared storage.

Use the ping command to verify the existence of the floating IP address.

Use nslookup or equivalent command to verify the IP address in your environment.

Install Management Agents to each physical node of the cluster using the physical IP address or host name as the node name.

Use the Oracle Universal Installer (OUI) to install Management Agents to each node of the cluster.

When complete, the OUI will have installed Management Agents on each node that will be visible through the Grid Control console.

Check that the Management Agent, host, and targets are visible in the Enterprise Manager environment.

Delete targets that will be configured for high availability using the cluster software.

Using the Grid Control console, delete all targets discovered during the previous installation step that are managed by the cluster software except for the Management Agent and the host.

Grid Control Console displays the Management Agent, hardware, and any target that is not configured for high availability.

Inspect the Grid Control console and verify that all targets that will be assigned to the Management Agent running on the floating IP address have been deleted from the Management Agents monitoring the fixed IP addresses.

Install a third Management Agent to the cluster using the logical IP address or logical host name as the host specified in the OUI at install time.

Note: This installation should not detect or install to more than one node.

This Management Agent must follow all the same conventions as any application using the cluster software to move between nodes (that is, installed on the shared storage using the logical IP address).

This installation requires an additional option to be used at the command line during installation time. The 'HOSTNAME' flag must be set as in the following example:

(/144)-

>./runInstaller HOSTNAME=<Logical IP address or hostname>

Third Management Agent installed, currently monitoring all targets discovered on the host running physical IP.

To verify the Management Agent is configured correctly, type emctl status agent at the command line and verify the use of the logical IP virtual host name. Also, verify that the Management Agent is set to the correct Management Service URL and that the Management Agent is uploading the files.

When the Management Agent is running and uploading data, use the Grid Control console to verify that it has correctly discovered targets that will move to the standby node during a failover operation.

Delete any targets from the Management Agent monitoring the logical IP that will not switch to the passive node during failover.

Use the Grid Control console to delete any targets that will not move between hosts in a switchover or failover scenario. These might be targets that are not attached to this logical IP address for failover or are not configured for redundancy.

Grid Control console is now running three Management Agents. Any target that is configured for switchover using cluster software will be monitored by a Management Agent that will transition during switchover or failover operations.

The operation is also verified by inspecting the Grid Control console. All targets that will move between nodes should be monitored by the Management Agent running on the virtual host name. All remaining targets should be monitored by a Management Agent running on an individual node.

Add the new logical host to the cluster definition.

Using the All Targets tab on the Grid Control console, find the cluster target and add the newly discovered logical host to the existing cluster target definition.

It is also possible (not required) to use the Add Cluster Target option on the All Targets tab, making a new composite target using the nodes of the cluster.

The Grid Control console will now correctly display all the hosts associated with the cluster.

Place the Management Agent process running on the logical IP under the control of the cluster software.

This will vary based on the cluster software vendor.

Management Agent will transition along with applications.

A suggested order of operation is covered in the next section.

Verify that the Management Agent can be stopped and restarted on the standby node using the cluster software.


4.1.2 Switchover Steps

Each cluster vendor will implement the process of building a wrapper around the steps required to do a switchover or failover in a different fashion. The steps themselves are generic and are listed here:

  • Shut down the Management Agent

  • Shut down all the applications running on the virtual IP and shared storage

  • Switch the IP and shared storage to the new node

  • Restart the applications

  • Restart the Management Agent

Stopping the Management Agent first, and restarting it after the other applications have started, prevents Enterprise Manager from triggering any false target down alerts that would otherwise occur during a switchover or failover.

4.1.3 Performance Implications

While it is logical to assume that running two Management Agent processes on the active host may have some performance implications, this was not shown during testing. Keep in mind that if the Management Agents are configured as described in this chapter, the Management Agent monitoring the physical host IP will only have two targets to monitor. Therefore the only additional overhead is the two Management Agent processes themselves and the commands they issue to monitor a Management Agent and the operating system. During testing, it was noticed that an overhead of between 1-2% of CPU usage occurred.

4.1.4 Summary

Generically, configuring Enterprise Manager to support Cold Cluster Failover environments encompasses the following steps.

  • Install a Management Agent for each virtual host name that is presented by the cluster and insure that the Management Agent is correctly communicating to the Management Service.

  • Configure the Management Agent that will move between nodes to monitor the appropriate highly available targets.

  • Verify that the Management Agent can be stopped on the primary node and restarted on the secondary node automatically by the cluster software in the event of a switchover or failover.

4.2 Using Virtual Host Names for Active and Passive High Availability Environments in Enterprise Manager Database Control

This section provides information to database administrators about configuring an Oracle Database release 10g in Cold Failover Cluster environments using Enterprise Manager Database Control.

The following conditions must be met for Database Control to service a database instance after failing over to a different host in the cluster:

  • The installation of the database must be done using a Virtual IP address.

  • The installation must be conducted on a shared disk or volume which holds the binaries, configuration, and runtime data (including the database).

  • Configuration data and metadata must also failover to the surviving node.

  • Inventory location must failover to the surviving node.

  • Software owner and time zone parameters must be the same on all cluster member nodes that will host this database.

The following items are configuration and installation points you should consider before getting started.

  • To override the physical host name of the cluster member with a virtual host name, software must be installed using the parameter ORACLE_HOSTNAME.

  • For inventory pointer, software must be installed using the command parameter invPtrLoc to point to the shared inventory location file, which includes the path to the shared inventory location.

  • The database software, the configuration of the database, and Database Control are done on a shared volume.

4.2.1 Set Up the Alias for the Virtual Host Name and Virtual IP Address

You can set up the alias for the virtual host name and virtual IP address by either allowing the clusterware to set it up automatically or by setting it up manually before installation and startup of Oracle services. The virtual host name must be static and resolvable consistently on the network. All nodes participating in the setup must resolve the virtual IP address to the same host name. Standard TCP tools similar to nslookup and traceroute commands can be used to verify the set up.

4.2.2 Set Up Shared Storage

Shared storage can be managed by the clusterware that is in use or you can use any shared file system volume as long as it is not unsupported. The most common shared file system is NFS.

4.2.3 Set Up the Environment

Some operating system versions require specific operating system patches to be applied prior to installing release 10gR2 of the Oracle database. You must also have sufficient kernel resources available when you conduct the installation.

Before you launch the installer, specific environment variables must be verified. Each of the following variables must be identically set for the account you are using to install the software on all machines participating in the cluster.

  • Operating system variable TZ, time zone setting. You should unset this prior to the installation.

  • PERL variables. Variables like PERL5LIB should be unset to prevent the installation and Database Control from picking up the incorrect set of PERL libraries.

  • Paths used for dynamic libraries. Based on the operating system, the variables can be LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH, or DYLD_LIBRARY_PATH. These variables should only point to directories that are visible and usable on each node of the cluster.

4.2.4 Ensure That the Oracle USERNAME, ID, and GROUP NAME Are Synchronized on All Cluster Members

The user and group of the software owner should be defined identically on all nodes of the cluster. You can verify this using the following command:

$ id -a
uid=1234(oracle) gid=5678(dba)groups=5678(dba)

4.2.5 Ensure That Inventory Files Are on the Shared Storage

To ensure that inventory files are on the shared storage, follow these steps:

  • Create you new ORACLE_HOME directory.

  • Create the Oracle Inventory directory under the new Oracle home

    cd <shared oracle home>
    mkdir oraInventory
    
    
  • Create the oraInst.loc file. This file contains the Inventory directory path information required by the Universal Installer:

    1. vi oraInst.loc

    2. Enter the path information to the Oracle Inventory directory and specify the group of the software owner as the dba user. For example:

      inventory_loc=/app/oracle/product/10.2/oraInventory inst_group=dba
      

4.2.6 Start the Installer

To start the installer, point to the inventory location file oraInst.loc, and specify the host name of the virtual group. The debug parameter in the example below is optional:

run installer -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.acme.com -debug

4.2.7 Start Services

You must start the services in the following order:

  1. Establish IP address on the active node

  2. Start the TNS listener

  3. Start the database

  4. Start dbconsole

  5. Test functionality

In the event that services do not start, do the following:

  1. Establish IP on failover box

  2. Start TNS listener

    lsnrctl start
    
    
  3. Start the database

    dbstart
    
    
  4. Start Database Control

    emctl start dbconsole
    
    
  5. Test functionality

To manually stop or shutdown a service, follow these steps:

  1. Stop the application.

  2. Stop Database Control

    emctl stop dbconsole
    
    
  3. Stop TNS listener

    lsnrctl stop
    
    
  4. Stop the database

    dbshut
    
    
  5. Stop IP

PK" ]]PK^UIOEBPS/postinstall_config.htm Reconfiguring the Management Agent and Management Service

12 Reconfiguring the Management Agent and Management Service

This chapter describes how to reconfigure Enterprise Manager if you later revisit your configuration decisions after you have installed the software.

This chapter contains the following sections:

12.1 Reconfiguring the Oracle Management Agent

The following sections describe reconfiguration and tuning changes you can make to the Management Agent after you have installed Enterprise Manager. Refer to the following sections for more information:

12.1.1 Configuring the Management Agent to Use a New Management Service

When you install the Management Agent on a managed host, you associate the Management Agent with a particular Management Service. The Management Agent uses the Management Service URL address and port to identify and communicate with the Management Service.

After you install the Management Agent, you can later reconfigure the Management Agent so it is associated with a different Management Service. Reconfiguring the Management Agent requires no changes to the Management Service. The reconfigured Management Agent will begin communicating with the new Management Service after the Management Agent is restarted.

To associate the Management Agent with a new Management Service after you have installed the Management Agent:

  1. Stop the Management Agent.

  2. Locate the emd.properties file in the Management Agent home directory:

    AGENT_HOME/sysman/config/emd.properties
    
    
  3. Use a text editor to open the file and locate the REPOSITORY_URL property.

  4. Modify the value for the REPOSITORY_URL property so it references the new Management Service.

    For example:

    REPOSITORY_URL=http://mgmthost2.acme.com:4889/em/upload
    
  5. Modify the value for the emdWalletSrcUrl and emdWalletDest properties so they reference the new Management Service and the new Oracle home path, respectively:

    For example, if the new Management Service is on a host called mgmthost2.acme.com and the new Oracle home is /private/oracle/em10g, modify the properties as follows:

    emdWalletSrcUrl=http://mgmthost2.acme.com:4889/em/wallets/emd
    emdWalletDest=/private/oracle/em10g/sysman/config/server
    
    
  6. Save your changes and close the emd.properties file.

  7. Delete all the files in the following directories:

    AGENT_HOME/sysman/emd/upload/
    AGENT_HOME/sysman/emd/state/
    
    
  8. Restart the Management Agent.

12.1.2 Changing the Management Agent Port

The Management Agent uses a predefined port number to receive requests from the Management Service. This port number is defined by default when you install the Management Agent on a managed host. If you later need to modify this port, you can use the following procedure. You might need to modify this port number if you have existing software that uses the default Management Agent port.

To change the Management Agent port:

  1. Stop the Management Agent.

  2. Locate the emd.properties file in the Management Agent home directory:

    AGENT_HOME/sysman/config/emd.properties
    
    
  3. Use a text editor to open the file and locate the EMD_URL property.

    For example:

    EMD_URL=http://managed_host1.acme.com:1813/emd/main
    
    
  4. Modify the port number in the EMD_URL property so the Management Agent uses a new unused port on the managed host.

    For example:

    EMD_URL=http://managed_host1.acme.com:1913/emd/main
    
    
  5. Start the Management Agent.

12.1.3 Controlling the Amount of Disk Space Used by the Management Agent

Oracle designed the Management Agent to work within a set of disk space limits. These limits prevent the Management Agent from using too much disk space and causing performance or resource issues on your enterprise systems. However, if disk space becomes an issue, you can adjust the default settings that are used to control the amount of disk space used by the Management Agent.

As the Management Agent on a particular host gathers management data about the targets on the host, it saves the collected data on the local disk until the data is uploaded to the Management Repository. The Management Agent saves this collected data and metadata in the following directory:

AGENT_HOME/sysman/emd/upload

By default, the Management Agent will save up to 50MB of collected data in the upload directory. If the amount of collected data exceeds 50MB, data collection is stopped temporarily until the data is uploaded to the repository and more disk space becomes available.

In addition, the Management Agent checks to be sure that the percentage of disk space currently in use on the local disk does not exceed 98 percent. If this value is exceeded, the Management Agent stops collecting data and stops saving information to the Management Agent log and trace files.

You can modify these default settings as follows:

  1. Stop the Management Agent.

  2. Locate the emd.properties file in the Management Agent home directory:

    AGENT_HOME/sysman/config/emd.properties
    
    
  3. Use a text editor to open the file and modify the entries shown in Table 12-1.

  4. Save your changes and exit the file.

  5. Restart the Management Agent.

Table 12-1 Properties for Controlling the Disk Space Used by the Management Agent

PropertyExplanation

UploadMaxBytesXML

Use this property in the emd.properties file to specify the maximum number of megabytes (MB) used by the collected data in the Management Agent upload directory. When this limit is exceeded, the Management Agent will stop collecting additional management data until the next upload to the Management Repository reduces the amount of collected data in the upload directory.

UploadMaxDiskUsedPct

Use this property in the emd.properties file to specify the maximum percentage of disk space that can be in use on the local disk before the Management Agent temporarily stops collecting additional data and stops saving information to the Management Agent log and trace files.

The Management Agent will begin collecting data again when the percentage of disk space in use falls to less than the percentage specified in the UploadMaxDiskUsedPctFloor property in the emd.properties file.


12.1.4 About the Management Agent Watchdog Process

The Management Agent is the Enterprise Manager component that gathers the data you need to manage your enterprise efficiently. As a result, Enterprise Manager includes software that keeps track of the Management Agent processes and makes sure the Management Agent stays running.

For example, if the Management Agent quits unexpectedly, this self-monitoring process—referred to as the watchdog process—will restart the Management Agent automatically.

In most situations, the watchdog process works in the background and requires no configuration or maintenance. The watchdog process is controlled by the emwd.pl script located in the following directory of the Management Agent home directory:

AGENT_HOME/bin

You can identify the watchdog process by using the following commands:

$PROMPT> ps -ef | grep emwd

12.1.5 Setting the Management Agent Time Zone

In today's global economy, it is not uncommon for the systems you manage to reside in multiple locations throughout the world. For example, if your company headquarters are in New Hampshire, USA, you may need to manage systems that reside in California, Canada, and in Europe.

As Enterprise Manager collects monitoring data from Management Agents running on these remote systems, it is important that the data is correlated accurately. A software failure on a machine in Ontario, Canada might be the cause of a performance problem on a machine in Hoboken, New Jersey.

To correlate this data, it is important that Enterprise Manager obtains the correct time zone for each Management Agent that you install. The following sections describe how the Management Agent obtains the time zone and how to correct the problem if the time zone for a Management Agent is incorrect:

12.1.5.1 Understanding How the Management Agent Obtains Time Zone Information

When you install the Management Agent, the software attempts to obtain the current time zone of the host computer. If successful, the installation procedure updates the agentTZRegion property setting in the following configuration file:

AGENT_HOME/sysman/config/emd.properties

The agentTZRegion property can be set to any of the values listed in the following file, which is installed in the Management Agent home directory:

AGENT_HOME/sysman/admin/suportedtzs.lst

12.1.5.2 Resetting the Time Zone of the Management Agent Due to Inconsistency of Time Zones

You need to reset the time zone of the Management Agent when both of the following situations are true:

  • The Management Agent has been running with a particular time zone

  • Subsequently a change occurs to the time zone of the host where the Management Agent is running

To propagate the time zone change to the emd.properties file, perform the following:

  1. Execute the following script:

    ORACLE_HOME/bin/emctl reseTZ agent
    
    

    This script updates ORACLE_HOME/<hostname>_<sid>/sysman/config/emd.properties so that the value of agentTZRegion matches that of the current time zone setting of the machine.


    Note:

    The location of the emd.properties file depends on the Control Console being used:
    • For the Database Control Console, the location is usually: ORACLE_HOME/<host>_<sid>/sysman/config

    • For the Application Server Control Console, the location is: ORACLE_HOME/sysman/config

    • For the Grid Control Management Agent, the location is ORACLE_HOME/sysman/config

    • For the Real Application Cluster central Management Agent, the location is usually: ORACLE_HOME/<host>/sysman/config


  2. In addition, this command prompts you to run a script against the Enterprise Manager Repository. You must log in to the database as the Enterprise Manager repository user and run the script mgmt_target.set_agent_tzrgn. An example follows:

    SQL> exec mgmt_target.set_agent_tzrgn('em.oracle.com:1830','PST8PDT');
    SQL> commit;
    SQL> exit
    
    

    em.oracle.com:1830 represents the name of the emd target.

12.1.5.3 Troubleshooting Management Agent Time Zone Problems

Sometimes, during the Management Agent installation, the time zone detected by the Management Agent configuration tool is not recognized by the Management Agent. In other words, the time zone obtained by the configuration tool is not listed in the Management Agent list of supported time zones.

This problem prevents the Management Agent from starting and results in an error similar to the following:

Could not determine agent time zone. Please refer to the file:
ORACLE_HOME/sysman/admin/supportedtzs.lst and pick a timezone region with a
standard offset of +5:0 from GMT and update the property 'agentTZRegion' in the
file: ORACLE_HOME/sysman/config/emd.properties

This error appears in one of the log files shown in Table 12-2, depending upon which Enterprise Manager product you are using.

Table 12-2 Location of Time Zone Error in the Enterprise Manager Log Files

If you are using...Look for the Time Zone Error in This File...

Grid Control Console


emagent.nohup

Application Server Control Console


em.nohup

Database Control Console


emdb.nohup



See Also:

"Locating and Configuring Management Agent Log and Trace Files" for more information about the Management Agent log files

To configure the Management Agent to use a valid time zone:

  1. Enter the following command in the Management Agent home directory to identify the time zone currently being used by the host computer:

    AGENT_HOME/bin/emctl config agent getTZ
    
    
  2. Note the time zone that is returned by the emctl config agent getTZ command.

    This is the time zone of the host computer.

  3. Use a text editor to open the following file in the Management Agent home directory:

    AGENT_HOME/sysman/admin/supportedtzs.lst
    
    

    This file contains a list of all the time zones supported by the Management Agent.

  4. Browse the contents of the supportedtzs.lst file and note the supported time zone closest to the time zone of the host computer.

  5. Use a text editor to open the following Management Agent configuration file:

    AGENT_HOME/sysman/config/emd.properties
    
    
  6. Locate the following property near the end of the emd.properties file:

    agentTZRegion=
    
    
  7. Set the value of this property to the time zone you identified as closest to the host time zone in the supportedtzs.lst file.

    For example:

    agentTZRegion=Europe/Warsaw
    
    
  8. Save your changes and close the emd.properties file.

    You should now be able to start the Management Agent without generating the error in the log file.

12.1.5.4 Troubleshooting Management Service Time Zone Problems

Section 12.1.5.3 describes how to correct potential problems that result when the Management Agent cannot determine the proper time zone. Similar problems can occur when the Management Agent finds the correct time zone, but the time zone is not recognized by the Management Service or the database where the Management Repository resides.

When the Management Service does not recognize the time zone established by the Management Agent, Enterprise Manager generates the following error:

OMS does not understand the timezone region of the agent.
Either start the OMS using the extended list of time zones supported by 
the database or pick a value of time zone from
ORACLE_HOME/emdw/sysman/admin/nsupportedtzs.lst, update the property 'agentTZRegion' in the file
ORACLE_HOME/sysman/config/emd.properties and restart the agent.
A value which is around an offset of  -05:00 from GMT should be picked.

This error appears in one of the log files shown in Table 12-2, depending upon which Enterprise Manager product you are using.

There are two ways to correct this problem:

  • Restart the Management Repository database using the more extensive list of time zones in the timezlrg.dat database configuration file, and then start the Management Agent.


    See Also:

    "Specifying the Database Time Zone File" in the Oracle Database Administrator's Guide

  • Specify a new time zone for the Management Agent that the Management Repository database will recognize.


    See Also:

    "Troubleshooting Management Agent Time Zone Problems" for instructions on changing the time zone assigned to the Management Agent

12.1.6 Adding Trust Points to the Management Agent Configuration

For Application Server components such as Oracle Portal to run on a secure sockets layer (SSL), the appropriate security certificate must be added to the Management Agent configuration files.

Perform these steps to add the relevant security certificate:

  1. Obtain the certificate, which is in Base64encoded X.509 (.CER) format, in the b64SiteCertificate.txt file. (The file name may be different in your configuration.) An example of the contents of the file is as follows:

    ------BEGIN CERTIFICATE--------------
    MIIDBzCCAnCgAw...
    ...... base 64 certificate content .....
    ------END CERTIFICATE-----------------
    
    
  2. In the Oracle Home of the Management Agent monitoring the wallet, run the following command to add the certificate to the Management Agent:

    ${ORACLE_HOME}/bin/mkwallet -i welcome
    ${ORACLE_HOME}/sysman/config/monwallet
    ${ORACLE_HOME}/sysman/config/b64SiteCertificate.txt NZDST_CLEAR_PTP
    
    

12.2 Reconfiguring the Oracle Management Service

The following sections describe configuration changes you can make to the Management Service after you install Enterprise Manager:

12.2.1 Configuring the Management Service to Use a New Management Repository

When you install and deploy the Management Service, you associate the Management Service with a Management Repository. The Management Service uses the database host, database system identifier (SID), database port, management user, and management password to identify and communicate with the Repository.

This repository information is stored in the emoms.properties file, which can be found in the following directory where the Oracle Management Service is installed and deployed:

ORACLE_HOME/sysman/config/

The following sections describe how to modify the repository information in the emoms.properties file and provide details about how Enterprise Manager keeps the Management Repository password secure.

12.2.1.1 Changing the Repository Properties in the emoms.properties File

To associate the Management Service with a new repository, you must modify the repository properties saved in the emoms.properties configuration file:

  1. Stop the Management Service.

  2. Locate the emoms.properties file in the following directory where you installed and deployed the Management Service:

    ORACLE_HOME/sysman/config/
    
    
  3. Edit the emoms.properties file by updating the appropriate values for the properties described in Table 12-3.

    shows sample entries in the emoms.properties file.

  4. Restart the Management Service.

Table 12-3 Repository Properties in the emoms.properties File

PropertyDescription

emdRepUser

The Management Repository user name. The default value is SYSMAN.

emdRepPwd

The Management Repository password. See "About Changing the Repository Password" for information of how to change the password value.

emdRepConnectDescriptor

The Management Repository Oracle Net Connect String for the repository database. The values specified for properties emdRepSID, emdRepServer, and emdRepPort must be the same as that of HOST, PORT, and SERVICE_NAME in the connect string. If this property is not specified, then emRepS#ID, emRepServer, and emRepPort properties are used to construct the connect descriptor. If the database hosting the repository is a RAC database, then the value must be configured as explained in "Configuring the Management Services"

emdRepSID

The System Identifier (SID) for the database where the Management Repository schema resides.

emdRepServer

The name of the server or host computer where the repository database resides.

emdRepPort

The port number for the repository database.


Example 12-1 Sample Repository Properties in the emoms.properties File

oracle.sysman.eml.mntr.emdRepUser=SYSMAN
oracle.sysman.eml.mntr.emdRepPwd=sysman
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(DESCRIPTION\=(ADDRESS_
LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=system12.mycompany.com)(PORT\=1521)))
(CONNECT_DATA\=(SERVICE_NAME\=oemrep1)))
oracle.sysman.eml.mntr.emdRepSID=oemrep1
oracle.sysman.eml.mntr.emdRepServer=system12.mycompany.com
oracle.sysman.eml.mntr.emdRepPort=1521

12.2.1.2 About Changing the Repository Password

For security reasons, the password stored in the emoms.properties file is encrypted as soon as you start the Management Service. To change the repository password in the emoms.properties file, use the emctl setpasswd oms command line utility. This utility prompts you for the new password for the repository. When you press ENTER after supplying the password, the utility automatically updates the password.

To modify the repository password, do the following:

  1. Stop the Management Service using the following command:

    ORACLE_HOME/bin/emctl stop oms
    
    
  2. Change the repository in ORACLE_HOME/sysman/config/emoms.properties by using the following command:

    ORACLE_HOME/bin/emctl setpasswd oms
    
    
  3. Restart the Management Service using the following command:

    ORACLE_HOME/bin/emctl start oms
    

12.2.2 Configuring the Management Service to Use a New Port

When you install the Management Service, the port number for the Management Service is automatically set to 4889. The following procedure describes how to manually change the port number after the Enterprise Manager installation. For example, you will have to modify the port number if you attempt to install two Oracle Management Services on the same host computer.

To change the default Management Service port:

  1. Stop the Management Service.

  2. Locate the following httpd_em.conf file located in the following directory in the home directory where you installed and deployed the Management Service:

    ORACLE_HOME/sysman/config/
    
    
  3. Open the http_em.conf file with a text editor and change all occurrences of 4889 to the new port number you want to use.

  4. Save and close the http_em.conf file.

  5. Inform the DCM layer about the port change:

    ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct ohs
    
    
  6. Locate the emoms.properties file in the same sysman/config directory.

  7. Open the emoms.properties file with a text editor and change the following entry so it references the new port number of the Management Service:

    oracle.sysman.emSDK.svlt.ConsoleServerPort=4889
    
    
  8. Restart the Management Service.

  9. Reconfigure each Management Agent on your managed hosts to use the new management port.

To change the default Management Service port to a secure port:

  1. Stop the Management Service using:

    ORACLE_HOME/bin/emctl stop oms
    
    
  2. Change the secure port using the following command:

    ORACLE_HOME/bin/emctl secure oms -secure_port <newPortNo>
    
    
  3. Inform the DCM layer about the port change:

    ORACLE_HOME/dcm/bin/dcmctl updateconfig -ct ohs
    
    
  4. Start the Management Service using:

    ORACLE_HOME/bin/emctl start oms
    

12.2.3 Configuring the Management Service to Prompt You When Using Execute Commands

The Execute Host Command and Execute SQL applications enable you to execute commands against multiple hosts and multiple databases respectively.

The default, when you click the Execute button of these applications, is for the command execution to begin immediately on the specified targets. If desired, you can set up the Management Service so that a confirmation page displays when you click the Execute button.

To enable the confirmation page for each application, perform the following:

  1. Stop the Management Service.

  2. Locate the emoms.properties file where you installed the Management Service:

    ORACLE_HOME/sysman/config/emoms.properties
    
    
  3. Edit the emoms.properties file and add the appropriate lines:

    • For the Execute Host Command, add the following line:

      oracle.sysman.cmd.tgt.multiTarget.confirmExecuteHostCommand=true
      
      
    • For Execute SQL, add the following line:

      oracle.sysman.cmd.tgt.multiTarget.confirmExecuteSQL=true
      
      

    Note:

    The text in the commands is case-sensitive.

  4. Save the changes and close the emos.properties file.

  5. Restart the Management Service.

PK PK^UIOEBPS/sizing.htm Sizing and Maximizing the Performance of Oracle Enterprise Manager

11 Sizing and Maximizing the Performance of Oracle Enterprise Manager

Oracle Enterprise Manager 10g Grid Control has the ability to scale for hundreds of users and thousands of systems and services on a single Enterprise Manager implementation.

This chapter describes techniques for achieving optimal performance using the Oracle Enterprise Manager application. It can also help you with capacity planning, sizing and maximizing Enterprise Manager performance in a large scale environment. By maintaining routine housekeeping and monitoring performance regularly, you insure that you will have the required data to make accurate forecasts of future sizing requirements. Receiving good baseline values for the Enterprise Manager Grid Control vital signs and setting reasonable warning and critical thresholds on baselines allows Enterprise Manager to monitor itself for you.

This chapter also provides practical approaches to backup, recovery, and disaster recovery topics while addressing different strategies when practical for each tier of Enterprise Manager.

This chapter contains the following sections:

11.1 Oracle Enterprise Manager Grid Control Architecture Overview

The architecture for Oracle Enterprise Manager 10g Grid Control exemplifies two key concepts in application performance tuning: distribution and parallelization of processing. Each component of Grid Control can be configured to apply both these concepts.

The components of Enterprise Manager Grid Control include:

  • The Management Agent - A process that is deployed on each monitored host and that is responsible for monitoring all services and components on the host. The Management Agent is also responsible for communicating that information to the middle-tier Management Service and for managing and maintaining the system and its services.

  • The Management Service - A J2EE Web application that renders the user interface for the Grid Control Console, works with all Management Agents to process monitoring and jobs information, and uses the Management Repository as its data store.

  • The Management Repository - The schema is an Oracle Database that contains all available information about administrators, services, and applications managed within Enterprise Manager.

Figure 11-1 Overview of Enterprise Manager Architecture Components

Illustration of Enterprise Manager architecture components

For more information about the Grid Control architecture, see the Oracle Enterprise Manager 10g documentation:

The Oracle Enterprise Manager 10g documentation is available at the following location on the Oracle Technology Network (OTN):

http://otn.oracle.com/documentation/oem.html

11.2 Enterprise Manager Grid Control Sizing and Performance Methodology

An accurate predictor of capacity at scale is the actual metric trend information from each individual Enterprise Manager Grid Control deployment. This information, combined with an established, rough, starting host system size and iterative tuning and maintenance, produces the most effective means of predicting capacity for your Enterprise Manager Grid Control deployment. It also assists in keeping your deployment performing at an optimal level.

Here are the steps to follow to enact the Enterprise Manager Grid Control sizing methodology:

  1. If you have not already installed Enterprise Manager Grid Control 10g, choose a rough starting host configuration as listed in Table 11-1.

  2. Periodically evaluate your site's vital signs (detailed later).

  3. Eliminate bottlenecks using routine DBA/Enterprise Manager administration housekeeping.

  4. Eliminate bottlenecks using tuning.

  5. Extrapolate linearly into the future to plan for future sizing requirements.

Step one need only be done once for a given deployment. Steps two, three, and four must be done, regardless of whether you plan to grow your Enterprise Manager Grid Control site, for the life of the deployment on a regular basis. These steps are essential to an efficient Enterprise Manager Grid Control site regardless of its size or workload. You must complete steps two, three, and four before you continue on to step five. This is critical. Step five is only required if you intend to grow the deployment size in terms of monitored targets. However, evaluating these trends regularly can be helpful in evaluating any other changes to the deployment.

11.2.1 Step 1: Choosing a Starting Platform Grid Control Deployment

If you have not yet installed Enterprise Manager Grid Control on an initial platform, this step helps you choose a rough approximation based on experiences with real world Enterprise Manager Grid Control deployments. If you have already installed Enterprise Manager Grid Control, proceed to Step 2. Three typical deployment sizes are defined: small, medium, and large. The number and type of systems (or targets) it monitors largely defines the size of an Enterprise Manager Grid Control deployment.

Table 11-1 Management Server

Deployment SizeHostsCPUs/HostsMemory/Host (GB)

Small (100 monitored targets)

1

1 (3 GHz)

2

Medium (1,000 monitored targets)

1

2 (3 GHz)

2

Large (10,000 monitored targets)

2

2 (3 GHz) 2

2


Table 11-2 Management Repository

Deployment SizeHostsCPUs/HostMemory/Host (GB)

Small

Shares host with Management Server

Shares host with Management Server

Shares host with Management Server

Medium

1

2

4

Large

2

4

6


Table 11-3 Total Management Repository Storage

Deployment SizeMinimum Tablespace Sizes*
SYSTEM**MGMT_TABLESPACEMGMT_ECM_DEPOT_TSTEMP

*These are strictly minimum values and are intended as rough guidelines only. The actual size of the MGMT_TABLESPACE could vary widely from deployment to deployment due to variations in target type distribution, user customization, and several other factors. These tablespaces are defined with AUTOEXTEND set to ON by default to help mitigate space constraint issues. On raw file systems Oracle recommends using more than the minimum size to help prevent space constraint issues.
**The SYSTEM and TEMP tablespace sizes are minimums for Enterprise Manager only repositories. If Enterprise Manager is sharing the repository database with other application(s), these minimums may be too low.

Small

600 MB

2 GB

1 GB

1 GB

Medium

600 MB

20 GB

1 GB

2 GB

Large

600 MB

200 GB

2 GB

4 GB


The previous tables show the estimated minimum hardware requirements for each deployment size. Management Servers running on more than one host, as portrayed in the large deployment above, will divide work amongst themselves.

Deploying multiple Management Servers also provides basic fail-over capabilities, with the remaining servers continuing to operate in the event of the failure of one. Use of a Server Load Balancer, or SLB, provides transparent failover for Enterprise Manager UI clients in the event of a Management Server host failure, and it also balances the request load between the available Management Servers. SLBs are host machines dedicated for load balancing purposes. SLBs can be clustered to provide fail-over capability.

Using multiple hosts for the Management Repository assumes the use of Oracle Real Application Clusters (RAC). Doing so allows the same Oracle database to be accessible on more than one host system. Beyond the storage required for the Management Server, Management Repository storage may also be required. Management Server storage is less impacted by the number of management targets. The numbers suggested in the Enterprise Manager Grid Control documentation should be sufficient in this regard.

11.2.1.1 Network Topology Considerations

A critical consideration when deploying Enterprise Manager Grid Control is network performance between tiers. Enterprise Manager Grid Control ensures tolerance of network glitches, failures, and outages between application tiers through error tolerance and recovery. The Management Agent in particular is able to handle a less performant or reliable network link to the Management Service without severe impact to the performance of Enterprise Manager as a whole. The scope of the impact, as far as a single Management Agent's data being delayed due to network issues, is not likely to be noticed at the Enterprise Manager Grid Control system wide level.

The impact of slightly higher network latencies between the Management Service and Management Repository will be substantial, however. Implementations of Enterprise Manager Grid Control have experienced significant performance issues when the network link between the Management Service and Management Repository is not of sufficient quality. The following diagram that displays the Enterprise Manager components and their connecting network link performance requirements. These are minimum requirements based on larger real world Enterprise Manager Grid Control deployments and testing.

Figure 11-2 Network Links Related to Enterprise Manager Components

Surrounding text describes Figure 11-2 .

You can see in Figure 11-2 that the bandwidth and latency minimum requirements of network links between Enterprise Manager Grid Control components greatly impact the performance of the Enterprise Manager application.

11.2.2 Step 2: Periodically Evaluate the Vital Signs of Your Site

This is the most important step of the five. Without some degree of monitoring and understanding of trends or dramatic changes in the vital signs of your Enterprise Manager Grid Control site, you are placing site performance at serious risk. Every monitored target sends data to the Management Repository for loading and aggregation through its associated Management Agent. This adds up to a considerable volume of activity that requires the same level of management and maintenance as any other enterprise application.

Enterprise Manager has "vital signs" that reflect its health. These vital signs should be monitored for trends over time as well as against established baseline thresholds. You must establish realistic baselines for the vital signs when performance is acceptable. Once baselines are established, you can use built-in Oracle Enterprise Manager Grid Control functionality to set baseline warning and critical thresholds. This allows you to be notified automatically when something significant changes on your Enterprise Manager site. The following table is a point-in-time snapshot of the Enterprise Manager Grid Control vital signs for two sites:



EM Site 1EM Site 2
Site URL
emsite1.acme.comemsite2.acme.com




Target CountsDatabase Targets192 (45 not up)1218 (634 not up)

Host Targets833 (12 not up)1042 (236 not up)





Total Targets2580 (306 not up)12293 (6668 not up)




Loader StatisticsLoader Threads616

Total Rows/Hour1,692,0002,736,000

Rows/hour/load/thread282,000171,000

Rows/second/load thread475187

Percent of Hour Run1544




Rollup StatisticsRows per Second2,267417

Percent of Hour Run519




Job StatisticsJob Dispatchers24

Job Steps/second/dispatcher3210




Notification StatisticsNotifications per Second81

Percent of Hour Run113




Alert StatisticsAlerts per Hour5361,100




Management Service Host StatisticsAverage % CPU (Host 1)9 (emhost01)13 (emhost01)

Average % CPU (Host 2)6 (emhost02)17 (emhost02)

Average % CPU (Host 3)N/A38 (em6003)

Average % CPU (Host 4)N/A12 (em6004)

Number of CPUs per host2 X 2.8 (Xeon)4 X 2.4 (Xeon)

Memory per Host (GB)66




Management Repository Host StatisticsAverage % CPU (Host 1)12 (db01rac)32 (em6001rac)

Average % CPU (Host 2)


Average % CPU (Host 3)


Average % CPU (Host 4)


Number of CPUs per host


Buffer Cache Size (MB)


Memory per Host (GB)612

Total Management Repository Size (GB)5698

RAC Interconnect Traffic (MB/s)14

Management Server Traffic (MB/s)44

Total Management Repository I/O (MB/s)627




Enterprise Manager UI Page Response/SecHome Page36

All Host Page330+

All Database Page630+

Database Home Page22

Host Home Page22

The two Enterprise Manager sites are at the opposite ends of the scale for performance.

EM Site 1 is performing very well with high loader rows/sec/thread and high rollup rows/sec. It also has a very low percentage of hours run for the loader and the rollup. The CPU utilization on both the Management Server and Management Repository Server hosts are low. Most importantly, the UI Page Response times are excellent. To summarize, Site 1 is doing substantial work with minimal effort. This is how a well configured, tuned and maintained Oracle Enterprise Manager Grid Control site should look.

Conversely, EM Site 2 is having difficulty. The loader and rollup are working hard and not moving many rows. Worst of all are the UI page response times. There is clearly a bottleneck on Site 2, possibly more than one.

These vital signs are all available from within the Enterprise Manager interface. Most values can be found on the All Metrics page for each host, or the All Metrics page for Management Server. Keeping an eye on the trends over time for these vital signs, in addition to assigning thresholds for warning and critical alerts, allows you to maintain good performance and anticipate future resource needs. You should plan to monitor these vital signs as follows:

  • Take a baseline measurement of the vital sign values seen in the previous table when the Enterprise Manager Grid Control site is running well.

  • Set reasonable thresholds and notifications based on these baseline values so you can be notified automatically if they deviate substantially. This may require some iteration to fine-tune the thresholds for your site. Receiving too many notifications is not useful.

  • On a daily (or weekly at a minimum) basis, watch for trends in the 7-day graphs for these values. This will not only help you spot impending trouble, but it will also allow you to plan for future resource needs.

The next step provides some guidance of what to do when the vital sign values are not within established thresholds. Also, it explains how to maintain your site's performance through routine housekeeping.

11.2.3 Step 3: Use DBA and Enterprise Manager Tasks To Eliminate Bottlenecks Through Housekeeping

It is critical to note that routine housekeeping helps keep your Enterprise Manager Grid Control site running well. The following are lists of housekeeping tasks and the interval on which they should be done.

11.2.3.1 Online Weekly Tasks

  • Check the system error page and resolve the causes of all errors. Some may be related to product bugs, but resolve as many as you can. Look for applicable patches if you suspect a bug. Clear the error table from the Enterprise Manager interface when you are done or when you have resolved all that you can.

  • Check the alerts and errors for any metric collection errors. Most of these will be due to configuration issues at the target being monitored. Resolve these errors by fixing the reported problem. The error should then clear automatically.

  • Try to resolve any open alerts in the system. Also, if there are severities that are frequently oscillating between clear and warning or critical, try adjusting the threshold to stop frequent warning and critical alert conditions. Frequent alert oscillation can add significant load at the Management Server. Adjusting the threshold to a more reasonable level will help Enterprise Manager to work more efficiently for you. Adjusting the threshold for an alert may be the only way to close the alert. This is perfectly acceptable in cases where the tolerances are too tight for a metric.

  • Watch for monitored targets that are always listed with a down status. Try to get them up and working again, or remove them from Oracle Enterprise Manager.

  • Watch the Alert Log error metric for the Management Repository database for critical (ORA-0600, for example) errors. Resolve these as soon as possible. A search on Metalink using the error details almost always will reveal some clues to its cause and provide available patches.

  • Analyze the three major tables in the Management Repository: MGMT_METRICS_RAW, MGMT_METRICS_1HOUR, and MGMT_METRICS_1DAY. If your Management Repository is in an Oracle 10g database, then these tables are automatically analyzed weekly and you can skip this task. If your Management Repository is in an Oracle version 9 database, then you will need to ensure that the following commands are run weekly:

    • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_RAW', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);

    • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1HOUR', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);

    • exec dbms_stats.gather_table_stats('SYSMAN', 'MGMT_METRICS_1DAY', null, .000001, false, 'for all indexed columns', null, 'global', true, null, null, null);

11.2.3.2 Offline Monthly Tasks

  • Drop old partitions. Oracle Enterprise Manager automatically truncates the data and reclaim the space used by partitions older than the default retention times for each table. Enterprise Manager cannot drop partitions while the Management Service is running. Doing so may generate Enterprise Manager error messages due to SQL cursors being invalidated incorrectly. The following command must be run with all Management Servers down:

    • exec emd_maintenance.partition_maintenance;

  • Rebuild and defragment indexes and reorganize tables as required. You may not actually need to rebuild any indexes or tables on a monthly basis. All you should do monthly is evaluate the Management Repository for tables and indexes that have grown significantly and been purged back down to a fraction of their allocated size. Unnecessarily building tables and indexes causes the Management Repository to work harder than necessary to reallocate needed space. The tables that require reorganization are easily identifiable. These tables will be large in allocated size with a relatively small number of rows, or actual size. In a real Management Repository, you may see one table that is approximately 800MB in size but only contains 6 rows. If the table is this badly oversized, it requires reorganization. Tables can be reorganized and rebuilt using a command similar to the following example:

    • exec dbms_redefinition.start_redef_table('SYSMAN','MGMT_VIOLATION');

    This command rebuilds the table and returns its physical structure to its clean initial state. The 800 MB table is an extreme case. Smaller disparities between actual size and row count may also indicate the need for reorganization. The Management Server(s) must be down when reorganizing a table. If you reorganize the table, the indexes must also be rebuilt. This helps make index range scans more efficient again. Indexes can be reorganized using a command similar to the following example:

    • ALTER INDEX SEVERITY_PRIMARY_KEY REBUILD;

    There are a few tables (along with their indexes) that may require rebuilding more frequently than others based on the higher volume of inserts and deletes they typically see. These tables are:

    • MGMT_VIOLATION

    • MGMT_CURRENT_VIOLATION

    • MGMT_SYSTEM_ERROR_LOG

    • MGMT_SYSTEM_PERFORMANCE_LOG

    • MGMT_METRIC_ERRORS

    • MGMT_CURRENT_METRIC_ERRORS

    • MGMT_STRING_METRIC_HISTORY

    • MGMT_JOB_OUTPUT

    These Management Repository tables can be prone to uneven growth patterns and can have large areas of allocated space that are unused due to infrequent, large spikes in data volume.

    The best tool for determining whether reorganization is required is the DBMS_SPACE.SPACE_USAGE procedure. The procedure takes advantage of space bitmap structures in the locally managed tablespace MGMT_TABLESPACE to determine the fullness of blocks for segments. The following is an example script for this procedure:

    variable unformatted_blocks number;
    variable unformatted_bytes number;
    variable freeBlocks_0_25 number;
    variable freeBytes_0_25 number;
    variable freeBlocks_25_50 number:
    variable freeBytes_25_50 number;
    variable freeBlocks_50_75 number;
    variable freeBytes_50_75 number;
    variable freeBlocks_75_100 number;
    variable freeBytes_75_100 number;
    variable full_blocks number;
    variable full_bytes number;
    
    begin
    dbms_space.space_usage('SYSMAN','MGMT_JOB_OUTPUT','TABLE',
          :unformatted_blocks,:unformatted_bytes,
          :freeBlocks_0_25,:freeBytes_0_25,
          :freeBlocks_25_50,:freeBytes_25_50,
          :freeBlocks_50_75,:freeBytes_50_75,
          :freeBlocks_75_100,:freeBytes_75_100,
          :full_blocks,:full_bytes);
    end;
    /
    print unformatted_blocks;
    print freeBlocks_0_25;
    print freeBlocks_25_50;
    print freeBlocks_50_75;
    print freeBlocks_75_100;
    print full_blocks;
    

    Beginning in version 10.2 of the Oracle RDBMS, you can take advantage of the Segment Advisor functionality to automatically examine SYSMAN segments. Segment Advisor identifies candidates for rebuild and then generates the rebuild statements.

    DBMS_SPACE and Segment Advisor provide recommendations and results you can use as a guide in determing an effective course of action. However, there are times when these recommendations can and should be overridden. For example, if you know that segment free space is likely to be reused, do not reorganize a table that may have been identified for reorganization by one of the tools. It is important to keep in mind that these tools only examine the current state of space allocation for a segment. They cannot provide insight into the projected data volume of the Enterprise Manager Grid Control application at your site.

    Good housekeeping will prevent many bottlenecks from occurring on your Enterprise Manager Grid Control site, but there may be times when you should investigate performance problems on your site that are not related to housekeeping. This is where the Enterprise Manager vital signs become important.

11.2.4 Step 4: Eliminate Bottlenecks Through Tuning

The most common causes of performance bottlenecks in the Enterprise Manager Grid Control application are listed below (in order of most to least common):

  1. Housekeeping that is not being done (far and away the biggest source of performance problems)

  2. Hardware or software that is incorrectly configured

  3. Hardware resource exhaustion

When the vital signs are routinely outside of an established threshold, or are trending that way over time, you must address two areas. First, you must ensure that all previously listed housekeeping is up to date. Secondly, you must address resource utilization of the Enterprise Manager Grid Control application. The vital signs listed in the previous table reflect key points of resource utilization and throughput in Enterprise Manager Grid Control. The following sections cover some of the key vital signs along with possible options for dealing with vital signs that have crossed thresholds established from baseline values.

11.2.4.1 High CPU Utilization

When you are asked to evaluate a site for performance and notice high CPU utilization, there are a few common steps you should follow to determine what resources are being used and where.

  1. The Management Server is typically a very minimal consumer of CPU. High CPU utilization in the Enterprise Manager Grid Control almost always manifests as a symptom at the Management Repository.

  2. Use the Processes display on the Enterprise Manager Host home page to determine which processes are consuming the most CPU on any Management Service or Management Repository host that has crossed a CPU threshold.

  3. Once you have established that Enterprise Manager is consuming the most CPU, use Enterprise Manager to identify what activity is the highest CPU consumer. Typically this manifests itself on a Management Repository host where most of the Management Service's work is performed. It is very rare that the Management Service itself is the source of the bottleneck. Here are a few typical spots to investigate when the Management Repository appears to be using too many resources.

    1. Click on the CPU Used database resource listed on the Management Repository's Database Performance page to examine the SQL that is using the most CPU at the Management Repository.

    2. Check the Database Locks on the Management Repository's Database Performance page looking for any contention issues.

High CPU utilization is probably the most common symptom of any performance bottleneck. Typically, the Management Repository is the biggest consumer of CPU, which is where you should focus. A properly configured and maintained Management Repository host system that is not otherwise hardware resource constrained should average roughly 40 percent or less total CPU utilization. A Management Server host system should average roughly 20 percent or less total CPU utilization. These relatively low average values should allow sufficient headroom for spikes in activity. Allowing for activity spikes helps keep your page performance more consistent over time. If your Enterprise Manager Grid Control site interface pages happen to be responding well (approximately 3 seconds) while there is no significant (constant) loader backlog, and it is using more CPU than recommended, you may not have to address it unless you are concerned it is part of a larger upward trend.

The recommended path for tracking down the root cause of high Management Repository CPU utilization is captured under step 3.b above. This allows you to start at the Management Repository Performance page and work your way down to the SQL that is consuming the most CPU in its processing. This approach has been used very successfully on several real world sites.

If you are running Enterprise Manager on Intel based hosts, the Enterprise Manager Grid Control Management Service and Management Repository will both benefit from Hyper-Threading (HT) being enabled on the host or hosts on which they are deployed. HT is a function of certain late models of Intel processors, which allows the execution of some amount of CPU instructions in parallel. This gives the appearance of double the number of CPUs physically available on the system. Testing has proven that HT provides approximately 1.5 times the CPU processing power as the same system without HT enabled. This can significantly improve system performance. The Management Service and Management Repository both frequently have more than one process executing simultaneously, so they can benefit greatly from HT.

11.2.4.2 Loader Vital Signs

The vital signs for the loader indicate exactly how much data is continuously coming into the system from all the Enterprise Manager Agents. The most important items here are the percent of hour runs and rows/second/thread. The (Loader) % of hour run indicates whether the loader threads configured are able to keep pace with the incoming data volume. As this value approaches 100%, it becomes apparent that the loading process is failing to keep pace with the incoming data volume. The lower this value, the more efficiently your loader is running and the less resources it requires from the Management Service host. Adding more loader threads to your Management Server can help reduce the percent of hour run for the loader.

Rows/Second/Thread is a precise measure of each loader thread's throughput per second. The higher this number, the better. Rows/Second/Thread as high as 1200 have been observed on some smaller, well configured and maintained Enterprise Manager Grid Control sites. If you have not increased the number of loader threads and this number is trending down, it may indicate a problem later. One way to overcome a decreasing rows/second/thread is to add more loader threads.

The number of Loader Threads is always set to one by default in the Management Server configuration file. Each Management Server can have a maximum of 10 loader threads. Adding loader threads to a Management Server typically increases the overall host CPU utilization by 2% to 5% on a Enterprise Manager Grid Control site with many Management Agents configured. Customers can change this value as their site requires. Most medium size and smaller configurations will never need more than one loader thread. Here is a simple guideline for adding loader threads:

Max total (across all Management Servers) loader threads = 2 X number of Management Repository host CPUs

There is a diminishing return when adding loader threads. You will not yield 100% capacity from the second, or higher, thread. There should be a positive benefit, however. As you add loader threads, you should see rows/second/thread decrease, but total rows/hour throughput should increase. If you are not seeing significant improvement in total rows/hour, and there is a constantly growing loader file backlog, it may not be worth the cost of the increase in loader threads. You should explore other tuning or housekeeping opportunities in this case.

To add more loader threads you can change the following configuration parameter:

em.loader.threadPoolSize=n

Where 'n' is a positive integer [1-10]. The default is one and any value other than [1-10] will result in the thread pool size defaulting to one. This property file is located in the {ORACLE_HOME}/sysman/config directory. Changing this parameter will require a restart of the Management Service to be reloaded with the new value.

11.2.4.3 Rollup Vital Signs

The rollup process is the aggregation mechanism for Enterprise Manager Grid Control. Once an hour, it processes all the new raw data loaded into the Management Repository table MGMT_METRICS_RAW, calculates averages and stores them in the tables MGMT_METRICS_1HOUR and MGMT_METRICS_1DAY. The two vital signs for the rollup are the rows/second and % of hour run. Due to the large volume of data rows processed by the rollup, it tends to be the largest consumer of Management Repository buffer cache space. Because of this, the rollup vital signs can be great indicators of the benefit of increasing buffer cache size.

Rollup rows/second shows exactly how many rows are being processed, or aggregated and stored, every second. This value is usually around 2,000 (+/- 500) rows per second on a site with a decent size buffer cache and reasonable speedy I/O. A downward trend over time for this value may indicate a future problem, but as long as % of hour run is under 100 your site is probably fine.

If rollup % of hour run is trending up (or is higher than your baseline), and you have not yet set the Management Repository buffer cache to its maximum, it may be advantageous to increase the buffer cache setting. Usually, if there is going to be a benefit from increasing buffer cache, you will see an overall improvement in resource utilization and throughput on the Management Repository host. The loader statistics will appear a little better. CPU utilization on the host will be reduced and I/O will decrease. The most telling improvement will be in the rollup statistics. There should be a noticeable improvement in both rollup rows/second and % of hour run. If you do not see any improvement in any of these vital signs, you can revert the buffer cache to its previous size. The old Buffer Cache Hit Ratio metric can be misleading. It has been observed in testing that Buffer Cache Hit Ratio will appear high when the buffer cache is significantly undersized and Enterprise Manager Grid Control performance is struggling because of it. There will be times when increasing buffer cache will not help improve performance for Grid Control. This is typically due to resource constraints or contention elsewhere in the application. Consider using the steps listed in the High CPU Utilization section to identify the point of contention. Grid Control also provides advice on buffer cache sizing from the database itself. This is available on the database Memory Parameters page.

One important thing to note when considering increasing buffer cache is that there may be operating system mechanisms that can help improve Enterprise Manager Grid Control performance. One example of this is the "large memory" option available on Red Hat Linux. The Linux OS Red Hat Advanced Server™ 2.1 (RHAS) has a feature called big pages. In RHAS 2.1, bigpages is a boot up parameter that can be used to pre-allocate large shared memory segments. Use of this feature, in conjunction with a large Management Repository SGA, can significantly improve overall Grid Control application performance. Starting in Red Hat Enterprise Linux™ 3, big pages functionality is replaced with a new feature called huge pages, which no longer requires a boot-up parameter.

11.2.4.4 Job, Notification, and Alert Vital Signs

Jobs, notifications, and alerts are indicators of the processing efficiency of the Management Service(s) on your Enterprise Manager Grid Control site. Any negative trends in these values are usually a symptom of contention elsewhere in the application. The best use of these values is to measure the benefit of running with more than one Management Server. There is one job dispatcher in each Management Server. Adding Management Servers will not always improve these values. In general, adding Management Servers will improve overall throughput for Grid Control when the application is not otherwise experiencing resource contention issues. Job, Notification, and Alert vital signs can help measure that improvement.

11.2.4.5 I/O Vital Signs

Monitoring the I/O throughput of the different channels in your Enterprise Manager Grid Control deployment is essential to ensuring good performance. At minimum, there are three different I/O channels on which you should have a baseline and alert thresholds defined:

  • Disk I/O from the Management Repository instance to its data files

  • Network I/O between the Management Server and Management Repository

  • RAC interconnect (network) I/O (on RAC systems only)

You should understand the potential peak and sustained throughput I/O capabilities for each of these channels. Based on these and the baseline values you establish, you can derive reasonable thresholds for warning and critical alerts on them in Grid Control. You will then be notified automatically if you approach these thresholds on your site. Some Grid Control site administrators can be unaware or mistaken about what these I/O channels can handle on their sites. This can lead to Enterprise Manager Grid Control saturating these channels, which in turn cripples performance on the site. In such an unfortunate situation, you would see that many vital signs would be impacted negatively.

To discover whether the Management Repository is involved, you can use Grid Control to check the Database Performance page. On the Performance page for the Management Repository, click on the wait graph showing the largest amount of time spent. From this you can continue to drill down into the actual SQL code or sessions that are waiting. This should help you to understand where the bottleneck is originating.

Another area to check is unexpected I/O load from non-Enterprise Manager Grid Control sources like backups, another application, or a possible data-mining co-worker who engages in complex SQL queries, multiple Cartesian products, and so on.

Total Repository I/O trouble can be caused by two factors. The first is a lack of regular housekeeping. Some of the Grid Control segments can be very badly fragmented causing a severe I/O drain. Second, there can be some poorly tuned SQL statements consuming much of the site I/O bandwidth. These two main contributors can cause most of the Grid Control vital signs to plummet. In addition, the lax housekeeping can cause the Management Repository's allocated size to increase dramatically.

One important feature of which to take advantage is asynchron!

11.2.4.6 The Oracle Enterprise Manager Performance Page

There may be occasions when Enterprise Manager user interface pages are slow in the absence of any other performance degradation. The typical cause for these slow downs will be an area of Enterprise Manager housekeeping that has been overlooked. The first line of monitoring for Enterprise Manger page performance is the use of Enterprise Manager Beacons. These functionalities are also useful for web applications other than Enterprise Manager.

Beacons are designed to be lightweight page performance monitoring targets. After defining a Beacon target on an Management Agent, you can then define UI performance transactions using the Beacon. These transactions are a series of UI page hits that you will manually walk through once. Thereafter, the Beacon will automatically repeat your UI transaction on a specified interval. Each time the Beacon transaction is run, Enterprise Manager will calculate its performance and store it for historical purposes. In addition, alerts can be generated when page performance degrades below thresholds you specify.

When you configure the Enterprise Manager Beacon, you begin with a single predefined transaction that monitors the home page you specify during this process. You can then add as many transactions as are appropriate. You can also set up additional Beacons from different points on your network against the same web application to measure the impact of WAN latency on application performance. This same functionality is available for all Web applications monitored by Enterprise Manager Grid Control.

After you are alerted to a UI page that is performing poorly, you can then use the second line of page performance monitoring in Enterprise Manager Grid Control. This new end-to-end (or E2E) monitoring functionality in Grid Control is designed to allow you to break down processing time of a page into its basic parts. This will allow you to pinpoint when maintenance may be required to enhance page performance. E2E monitoring in Grid Control lets you break down both the client side processing and the server side processing of a single page hit.

The next page down in the Middle Tier Performance section will break out the processing time by tier for the page. By clicking on the largest slice of the Processing Time Breakdown pie chart, which is JDBC time above, you can get the SQL details. By clicking on the SQL statement, you break out the performance of its execution over time.

The JDBC page displays the SQL calls the system is spending most of its page time executing. This SQL call could be an individual DML statement or a PL/SQL procedure call. In the case of an individual SQL statement, you should examine the segments (tables and their indexes) accessed by the statement to determine their housekeeping (rebuild and reorg) needs. The PL/SQL procedure case is slightly more involved because you must look at the procedure's source code in the Management Repository to identify the tables and associated indexes accessed by the call.

Once you have identified the segments, you can then run the necessary rebuild and reorganization statements for them with the Management Server down. This should dramatically improve page performance. There are cases where page performance will not be helped by rebuild and reorganization alone, such as when excessive numbers of open alerts, system errors, and metric errors exist. The only way to improve these calls is to address (for example, clean up or remove) the numbers of these issues. After these numbers are reduced, then the segment rebuild and reorganization should be completed to optimize performance. These scenarios are covered in Section 11.2.3. If you stay current, you should not need to analyze UI page performance as often, if at all.

11.2.5 Step 5: Extrapolating Linearly Into the Future for Sizing Requirements

Determining future storage requirements is an excellent example of effectively using vital sign trends. You can use two built-in Grid Control charts to forecast this: the total number of targets over time and the Management Repository size over time.

Both of the graphs are available on the All Metrics page for the Management Service. It should be obvious that there is a correlation between the two graphs. A straight line applied to both curves would reveal a fairly similar growth rate. After a target is added to Enterprise Manager Grid Control for monitoring, there is a 31-day period where Management Repository growth will be seen because most of the data that will consume Management Repository space for a target requires approximately 31 days to be fully represented in the Management Repository. A small amount of growth will continue for that target for the next year because that is the longest default data retention time at the highest level of data aggregation. This should be negligible compared with the growth over the first 31 days.

When you stop adding targets, the graphs will level off in about 31 days. When the graphs level off, you should see a correlation between the number of targets added and the amount of additional space used in the Management Repository. Tracking these values from early on in your Enterprise Manager Grid Control deployment process helps you to manage your site's storage capacity proactively. This history is an invaluable tool.

The same type of correlation can be made between CPU utilization and total targets to determine those requirements. There is a more immediate leveling off of CPU utilization as targets are added. There should be no significant increase in CPU cost over time after adding the targets beyond the relatively immediate increase. Introducing new monitoring to existing targets, whether new metrics or increased collections, would most likely lead to increased CPU utilization.

11.3 Oracle Enterprise Manager Backup, Recovery, and Disaster Recovery Considerations

The newest release of Oracle Enterprise Manager Grid Control incorporates a portable browser-based interface to the management console and the Oracle application server technology to serve as the middle-tier Management Service. The foundation of the tool remains rooted in database server technology to manage the Management Repository and historical data. This new architecture requires a different approach to backup, recovery and Disaster Recovery (DR) planning. This section provides practical approaches to these availability topics and discusses different strategies when practical for each tier of Enterprise Manager.

11.3.1 Best Practices for Backup and Recovery

For the database, the best practice is to use the standard database tools for any database backup; have the database in archivelog mode, and perform regular online backup using RMAN or OS commands.

There are two cases to consider with regard to recovery:

  • Full recovery of the Management Repository is possible: No special considerations for Enterprise Manager. When the database is recovered, restart the database and Management Service processes. Management Agents will then upload pending files to the Management Repository.

  • Only point in time and incomplete recovery is possible: Enterprise Manager Management Agents will be unable to communicate to the Management Repository correctly until they are reset. This is a manual process that is accomplished by shutting down the Management Agent, deleting the agntstmp.txt and lastupld.xml files in the $AGENT_HOME/sysman/emd directories and then going to the /state and /upload subdirectories and clearing the contents. The Management Agent can then be restarted. This would need to be done for each Management Agent.

For the case of incomplete recovery, Management Agents may not be able to upload data until the previous steps are completed. Additionally, there is no indication in the interface that the Management Agents may not communicate with the Management Service after this type of recovery. This information would be available from the Management Agent logs or command line Management Agent status. If incomplete recovery is required, it is best to perform this procedure for each Management Agent.

11.3.1.1 Oracle Management Service

As the Management Service is stateless, the task is to restore the binaries and configuration files is the shortest time possible. There are two alternatives in this case.

  • Backup the entire software directory structure and restoring that in the event of failure to the same directory path. The Management Agent associated with this Management Service install should also be backed up at the same time and restored with the Management Service files if a restore is required.

  • Reinstall from the original media.

For any highly available Management Service install it is a recommended practice to make sure the /recv directory is protected with some mirroring technology. This is the directory the Management Service uses to stage files send to it from Management Agents before writing their contents to the database Management Repository. After the Management Agent finishes transmission of its XML files to the Management Service, it will delete its copy. In the event of an Management Service disk failure, this data would be lost. Warnings and alerts sent from the Management Agents would then be lost. This may require Management Agent resynchronization steps similar to those used with an incomplete database recovery.

11.3.1.2 Management Agent

This is a similar case to the Management Service except that the Management Agent is not stateless. There are two strategies that can be used:

  • A disk backup and restore is sufficient, assuming the host name has not changed. Delete the agntstmp.txt and the lastupld.xml files from the /sysman/emd directory. The /state and /upload sub-directories should be cleared of all entries before restarting. Starting the Management Agent will then force a rediscovery of targets on the host.

  • Reinstall from the original media.

As with the Management Service, it is a recommended best practice to protect the /state and /upload directories with some form of disk mirroring.

11.3.2 Best Practice for Disaster Recovery (DR)

In the event of a node failure, the database can be restored using RMAN or OS commands. To speed this process, implement Data Guard to replicate the Management Repository to a different hardware node.

11.3.2.1 Management Repository

If restoring the Management Repository to a new host, restore a backup of the database and modify the emoms.properities file for each Management Service manually to point to the new Management Repository location. In addition, the targets.xml for each Management Service will have to be updated to reflect the new Management Repository location. If there is a data loss during recovery, see the notes above on incomplete recovery of the Management Repository.

To speed Management Repository reconnection from the Management Service in the event of a single Management Service failure, configure the Management Service with a TAF aware connect string. The Management Service can be configured with a TAF connect string in the emoms.properities file that will automatically redirect communications to another node using the 'FAILOVER' syntax. An example follows:

EM=
(description=
(failover=on)
(address_list=
(failover=on)
(address=(protocol=tcp)(port=1522)(host=EMPRIM1.us.oracle.com))
(address=(protocol=tcp)(port=1522)(host=EMPRIM2.us.oracle.com)))
(address_list=
(failover=on)
(address=(protocol=tcp)(port=1522)(host=EMSEC1.us.oracle.com))
(address=(protocol=tcp)(port=1522)(host=EMSEC2.us.oracle.com)))
(connect_data=(service_name=EMrep.us.oracle.com)))

11.3.2.2 Oracle Management Service

Preinstall the Management Service and Management Agent on the hardware that will be used for Disaster Recovery. This eliminates the step of restoring a copy of the Enterprise Manager binaries from backup and modifying the Management Service and Management Agent configuration files.

Note that it is not recommended to restore the Management Service and Management Agent binaries from an existing backup to a new host in the event of a disaster as there are host name dependencies. Always do a fresh install.

11.3.2.3 Management Agent

In the event of a true disaster recovery, it is easier to reinstall the Management Agent and allow it to do a clean discovery of all targets running on the new host.

PKK0<!<PK^UIOEBPS/title.htmk Oracle Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0)

Oracle® Enterprise Manager

Advanced Configuration

10g Release 3 (10.2.0.3.0)

B40002-02

February 2007


Oracle Enterprise Manager Advanced Configuration, 10g Release 3 (10.2.0.3.0)

B40002-02

Copyright © 2003, 2007, Oracle. All rights reserved.

Contributor: Raj Aggarwal, Muralidharan Bhoopathy, Diarmuid Cawley, Phil Choi, Leo Cloutier, Sudip Datta, Erik DeMember, Kondayya Duvvuri, James Emmond, Irina Goldshteyn, Jacqueline Gosselin, Scott Grover, Rahul Gupta, Luming Han, Ana Hernandez, Narain Jagathesan, Eunhei Jang, Aparna Kamath, Ramanujam Krishnan, Dennis A. Lee, Conrad Lo, Jaydeep Marfatia, Karen McKeen, Rahul Pandey, Raghu Patti, Ravi Pinnamaneni, Pushpa Raghavachar, Sridhar T. Reddy, Prashanth Shishir, Anu Vale, Steven Viavant, James Viscusi, Jin G. Wang, Julie Wong, Michael Zampiceni

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

PK[}pkPK^UIOEBPS/remedy.htm Configuring Remedy Connector

16 Configuring Remedy Connector

Remedy Connector integrates Remedy Help Desk 6.x with Enterprise Manager. Using this connector, you can create a Remedy trouble ticket, update an existing ticket, or close a ticket based on alerts in Enterprise Manager.

This chapter provides the following information for setting up and configuring Remedy Connector:

16.1 Introduction to Remedy Connector

Remedy Connector integrates Enterprise Manager with Remedy Help Desk through either HTTP or HTTPS connection. You can create, update, or close tickets based on only the following types of alerts in Enterprise Manager:

  • Metric alerts

  • Availability alerts (includes alerts for Up, Down, Blackout Started, Blackout Ended, Agent Unreachable, Agent Unreachable Resolved, Metric Error Detected, and Mertic Error Resolved).

The following sections explain various Remedy Connector concepts that you must understand before you start using Remedy Connector.

16.1.1 Autoticketing

Whenever an alert is triggered in Enterprise Manager, Remedy Connector can automatically open or update a ticket. You can specify the set of alerts for which tickets must be opened and the alert severity for which this should happen.

This can be done in Notification Rules, the user-defined rules that define the criteria by which notifications should be sent for alerts.

After the ticket is opened, any subsequent update of the alert, for example change in alert severity will cause an annotation to the ticket. Once the alert is cleared (severity is set to Clear), then the ticket can optionally be closed.

16.1.2 Manual Ticketing

From the Enterprise Manager console, you can choose to manually open a Remedy ticket based on an open alert in Enterprise Manager. The Remedy Connector will populate the ticket with details based on the alert and the ticket template selected.

16.1.3 Ticket Templates

Ticket templates are transformation style sheets in XSLT format used to transform Enterprise Manager alerts to ticket format before the requests are sent to Remedy Help Desk.

These template are used to specify how Enterprise Manager alert attributes can be used to populate the fields of a Remedy ticket. A ticket template helps in the mapping of Enterprise Manager Alert fields into Remedy ticket fields.

In autoticketing, a notification method is created for each registered ticket template. The selected notification method determines which ticket template is used when a notification is sent out to the Connector. In the case of manual ticketing, you have to select a ticket template before submitting a request to create ticket.

The Enterprise Manager installation includes some out-of-box ticket templates to facilitate easy usage of this feature.

16.1.4 Grace Period

Grace period provides you with a configuration to prevent the creation of large number of tickets for frequently re-occurring alerts. For alerts that occur frequently within a relatively short time interval, it is often desirable to open and maintain one trouble ticket that tracks each occurrence of the alert instead of separate tickets each time.

For recurring alerts, the Grace Period is a time period during which re-occurrences of the same alert will cause an existing ticket for the alert to be updated (or re-opened) instead of causing a new ticket to be opened.

For example, an alert triggers and a ticket is opened for it. If the Grace Period is one hour and the alert is cleared at 10:00 am, then if the same alert retriggers before 11:00 am (one hour grace period), then the ticket that had been originally created for the alert will be updated/reopened rather than creating a new ticket.

16.2 Prerequisites

Before using Remedy Connector, ensure that you meet the following pre-requisites:

  • Remedy Helpdesk 6.x is installed and configured.

  • Remedy Helpdesk Web services are up and running. See "Web Service Details".

16.3 Installing Remedy Connector

Remedy Connector is installed as part of the Enterprise Manager base installation. That is, Connector installation is part of the Oracle Management Server (OMS) installation.

After you install Enterprise Manager, when you access the Enterprise Manager console as a Super Administrator, you should see Remedy Connector in the Management Connector Setup page as shown in Figure 16-1(click Setup from the Enterprise Manager console and then Management Connectors in the left pane).

The default installation is based on default Remedy Web services which do not support any annotation history through the Worklog (the history option in the Remedy ticket). For details of Worklog and registering of Worklog template, see "Using Worklog".

16.4 Configuring the Remedy Connector

  1. As Super Administrator, from the Enterprise Manager console, click Setup.

    Overview of Setup page appears.

  2. Click Management Connectors in the left pane.

    The Management Connector Setup page appears. For the Remedy Connector row, the Configured column should be blank (Figure 16-1).


    Note:

    A check mark instead indicates that the Connector is already configured.

  3. Click the Configure icon for the Remedy Connector.

    The General tab of the Configure Management Connector page appears (Figure 16-2).

  4. Provide the required settings. See "General Settings" for details.

  5. Click OK.

    The Management Connectors Home page reappears. The row for the Remedy Connector should have a check mark in the Configured column.

  6. (Optional) To check for the available ticket templates, click the configure icon again.

  7. Click the Ticket Templates tab.

    All out-of-box ticket templates should appear in the table.

If any of the ticket templates are missing, you can register it using the emctl command from ORACLE_HOME/bin directory, where ORACLE_HOME is the Oracle home directory of OMS.

Run the following command as user with execute privilege on emctl and can read the ticket template:

emctl register_ticket_template connector <ticketTemplate.xsl> <server> <port> <database sid/service name for RAC DB> <username> <password> <connectorTypeName> <connectorName> <templateName> <description>


Note:

In the case of multiple OMS installation, you need to run this command only once from any of the OMSs.

Example 16-1

emctl register_ticket_template connector Remedy_DefaultCategory_LowPriority.xsl $emHost $dbPort $dbSID sysman $sysmanPwd "Remedy Connector" "Remedy Connector" "Low Priority Template" "This template creates a ticket with low priority and default categorization"

emctl Parameters

Table 16-1 emctl Parameters

ParameterDescription

ticketTemplate.xsl

Fully qualified name of the ticket template file.

The file resides in the Connector home directory:

$OMS_HOME/sysman/connector/Remedy_Connector

Oracle recommends that you use intuitive names since there might be notification methods created with the same names and you have to choose one of them when you use autoticketing feature.

Use xsl as the file extension since the format is XSLT. For example, Remedy_DefaultCategory_LowPriority.xsl.

If the file is in a different directory, provide complete path for the file.

server

Host name of the Enterprise Manager repository.

port

Listener port of the repository.

database sid/ Service Name for RAC DB

Repository database instance ID or service name if you are using RAC database as the repository.

username

Specify SYSMAN.

password

Password for SYSMAN.

connectorTypeName

Specify "Remedy Connector". The double quotes ("") are mandatory.

connectorName

Specify "Remedy Connector". The double quotes ("") are mandatory.

templateName

An intuitive name for the ticket template that will be displayed in Enterprise Manager.

description

A short description for the ticket template. This description gets displayed in the Enterprise Manager also.


Figure 16-1 Management Connectors Page

Surrounding text describes Figure 16-1 .

Figure 16-2 Configure Management Connector Page

Surrounding text describes Figure 16-2 .

16.4.1 General Settings

The following sections explain how to provide various configuration details.

16.4.1.1 Connection Settings

The Remedy Trouble Ticket connector communicates with the Help Desk through their Web services. Mandatory fields are indicated by a * mark.

  • *Web Service Endpoints — Endpoints to createTicket, updateTicket, and getTicket Web services exposed by Remedy Help Desk. See "Web Service Details" for additional details.

  • *Remedy Username— User with the privilege to create, update, and query tickets in Remedy.

  • Remedy Password— Password associated with the supplied Remedy user.

  • Authentication— String that a Remedy administrator sets for additional security. Applies only if the Remedy Administrator has configured it on the Remedy AR server. It communicates with the server if there is a secondary authentication server that can be used to verify the Remedy credentials.

  • Locale— Language of the Remedy system (optional).

  • Time Zone— Time zone of the Remedy AR System Server (optional).


    See Also:

    Section "Remedy User preferences settings" in the Remedy Remedy AR System Server product manual Remedy Action Request System 6.3 - Developing AR System Applications: Advanced

16.4.1.2 Web Console Settings

Web Console settings are required if the users wants the Connector to provide links to Remedy Help Desk tickets created by Enterprise Manager in context of an alert.

To enable this functionality, provide the following Web console settings.

  • Enable web console — Check this box to enable launching of Remedy ticket page within context from Enterprise Manager.

  • ARServer Name— The Remedy AR Server name.

  • HelpDesk Case Form Name—The Remedy form name that the Remedy Web Services (you configured the connector to use) is based on. The Remedy default Help Desk webservices, for example, use the form HPD:HelpDesk.

  • Web Server — The name or IP address of the server that hosts Remedy Mid-Tier.

16.4.1.3 Grace Period

You can enable and disable the grace period and configure its value. By default, the grace period is disabled. See "Grace Period" for details.

This setting applies to all alerts processed by Remedy Connector.

16.4.2 Working with Ticket Templates

The following sections provide information about registering, removing, replacing and adding ticket templates.

16.4.2.1 Registering Templates

Ticket templates need to be registered before they are recognized in Enterprise Manager. For autoticketing, a notification method is created for each registered ticket template and a ticket is created and updated based on the ticket template associated with the selected notification method. In the case of manual ticketing, registered ticket templates are available for selection.

All registered ticket templates are displayed in the Configure Management Connector Ticket Templates page. By default, all out-of-box ticket templates are registered. To register additional ticket templates that you create, use the following emctl command:

emctl register_ticket_template connector <ticketTemplate.xml> <server> <port> <database sid> <username> <password> <connectorTypeName> <connectorName> <templateName> <description>


See Also:

"emctl Parameters"

16.4.2.2 Viewing Template Code

Click a template name to view the XSLT code for the template.

The ticket templates are in XSLT format. A basic knowledge of XSLT is required to understand the code.

16.4.2.3 Removing Template


Important:

If the template you delete has a notification rule associated with it, the notification will fail.

  1. Select the template and click Remove.

  2. At prompt, confirm the removal.

  3. Before you exit the page, click OK for the deletion to take effect.


    Note:

    Unless you click OK before you exit, the template is not deleted. Next time you go to the Ticket Template page, the templates reappear.

    Though the ticket template is removed from the Enterprise Manager repository, it is still available on OMS in the Connector home directory. You can re-register the ticket template later if required.

16.4.2.4 Replacing Templates

To replace an existing ticket template, do the following in sequence:

  • Delete the ticket template

  • Register the new template using emctl

16.4.2.5 Adding New Templates

To add templates other than the out-of-box templates provided by Oracle, users should define new templates and register them using emctl.

16.5 Creating Remedy Trouble Tickets

You can have trouble tickets created automatically, or you can create them manually. The following sections explain how to create both types.

16.5.1 Creating Trouble Ticket Automatically

Perform the following steps to create a ticket automatically:

  1. Review the Out-of-Box Templates.

  2. Select an appropriate ticket template having the desired mapping of Enterprise Manager alert fields to the Remedy ticket fields.

  3. If you do not have a ticket template that satisfies your requirement, create one and register it.

  4. Create a notification rule using the following steps:


    Important:

    Do not select more than one ticket template for this notification rule.

    1. From the Enterprise Manager console, click Preferences.

    2. In the left pane, under Notification, click Rules, then Create.

    3. In the Create Notification Rule General page, specify the rule name, description and the targets for which this rule should apply.

    4. In the Create Notification Rule Availability page select the availability states for which you want to create tickets.

    5. In the Create Notification Rule Metrics page, select the metrics and their associated alert severities for which you want to create and update tickets.

      Ensure that you select all relevant alert severities if you want the ticket to be updated when the alert severity changes. For example, to open a ticket for critical alert on CPU Utilization(%) metric, and the ticket to be updated if the CPU Utilization(%) changes to warning or clear severity, then in the notification rule, select Critical, Warning, or Clear severities for the CPU Utilization(%) metric.

    6. In Create Notification Rule Methods page, choose the ticket template from the Advanced Notification Methods table (Table 16-1).

      In the table, registered ticket templates appear as Java Callback type notification methods under the same name as the ticket template's file name. This ticket template will be used to open tickets for all availability and metric alerts specified in this notification rule.

      This makes the ticket templates available for use to open tickets.

The following process occurs after you create the notification rule for your alerts:

  • A notification is sent to the Remedy Connector when a metric alert that matches your rule triggers. The Remedy connector creates/updates a ticket according to the ticket template as set in the notification rule.

  • The ticket is created or updated on the Remedy Trouble Ticket system.

  • In Enterprise Manager, the alert annotation is updated. A comment is added to the Metric Details page of the alert to indicate that a ticket was created or updated, along with the ticket ID and ticket page URL.

A ticket is updated if there is an existing active ticket for an alert. In Figure 16-4, the first screen shows the ticket in Remedy console and the second screen, the alert as displayed in Enterprise Manager.

Figure 16-3 Notification Methods

Surrounding text describes Figure 16-3 .

Figure 16-4 Remedy Ticket and the Alert as Displayed in Enterprise Manager

Surrounding text describes Figure 16-4 .
Surrounding text describes Figure 16-4 .
</div>

16.5.2 Creating a Ticket Manually

Perform the following steps to create a ticket manually:

  1. After a metric alert occurs, go to the associated metric details page for the alert. To access this page, click the alert message in the Enterprise Manager console (Figure 16-5).

  2. Click the Create/View Ticket link in the Related Links section.

    The Create Ticket page appears if no active ticket exists for the alert.

  3. Select a ticket template and then click Submit (Figure 16-6).

    If you do not see the desired template, then you can register one using the emctl. "Registering Templates"

    If creating or updating the ticket is successful, the ticket ID appears in the Last Comment column of the Alert History table for the metric alert.If the Web console settings are configured and enabled, the ticket ID appears as a link to the ticket page in the Remedy Help Desk. If there is no annotation, then the ticket creation fails and error information is logged in the file emoms.log.


Note:

You cannot manually update the ticket using Remedy Connector. You have to manually update the ticket in the Remedy AR server for any subsequent alert change.

Figure 16-5 Metric Details Page

Surrounding text describes Figure 16-5 .

Figure 16-6 Create Ticket Page

Surrounding text describes Figure 16-6 .

16.6 Enabling SSL for HTTPS

Follow the steps provided in this section if you choose HTTPS as the protocol to establish a connection between Remedy AR server and Enterprise Manager.

16.6.1 Generating a Certificate Request File

Generate a certificate request file for the Remedy AR server and send it to the Certificate authority, for example VeriSign.


Note:

The certificate request file is dependent on the Web server used by Remedy.

16.6.2 Importing the Certificate from the Certificate Authority

After you get the certificate, import it to the Web server used by Remedy. The import mechanism varies depending on the Web server used by Remedy Help Desk.

16.6.3 Adding Signed Certificates to Wallet Manager


Note:

Oracle Wallet Manager is available at $ORACLE_HOME/bin on OMS. See Oracle Application Server Administrator's Guide for details.

Do the following on Enterprise Manager:

  1. As Super Administrator, create a wallet using orapki utility using the following command at OMS host:

    orapki wallet create -wallet client -auto_login


    Note:

    orapki is available at $ORACLE_HOME/bin on OMS.

  2. Add the trusted certificate to the wallet by using the following command:

    orapki wallet add -wallet client -trusted_cert -cert verisignCert.cer

  3. To view the content of the wallet, run the following command:

    orapki wallet display -wallet client

    Ensure that ewallet.p12 is available.

  4. In Oracle Wallet Manager, then open the client certificate ewallet.p12.

  5. Go to Select Trusted Certificates and select Operations on the main menu.

  6. Select Export All Trusted Certificates.

  7. Save the file as certdb.txt.

  8. Place the file certdb.txt in the connector home root directory ($OMS_HOME/sysman/connector).

    If the file certdb.txt already exists in the root directory, open the file and add the contents of your certdb.txt to the existing content.

Now this file can be used by the Java SSL for communication between Enterprise Manager and Remedy AR server in HTTPS mode.


See Also:

For information on creating wallet, see "Creating and Viewing Oracle Wallets with orapki" in the Oracle Database Advanced Security Administrator's Guide, 10g Release 2 (10.2).

16.7 Navigating Between Remedy and Enterprise Manager

The following sections explain how to switch from one console to the other.

16.7.1 Navigating from Remedy to Enterprise Manager

From a ticket page, click the link in the Description field to the Alert Details page in the ticket message body (Figure 16-7). This takes you to the Enterprise Manager console login page. After you provide Enterprise Manager username and password, you will be forwarded to the alert related to this ticket.


Note:

  • The Enterprise Manager user whose name you specify should at least have View privileges on the target on which the alert was raised.
  • On the Remedy console, if the URL appears as text, then you will need to cut and paste the URL into the browser.


Figure 16-7 Alert Details in Remedy Console

Surrounding text describes Figure 16-7 .

16.7.2 Navigating from the Enterprise Manager to Remedy

  1. In the Enterprise Manager console, click the alert message to go to the metric details page for the alert.

  2. In the Alert History table, locate the ticket ID link in the Last Comment column.

  3. (If not found) Click the icon in the Details column to get more information about the alert.

  4. On the page that comes up, locate the ticket ID in the Alert Details table.

  5. Click the ticket ID link. You are forwarded to the Remedy Web console login page.

  6. Provide valid Remedy account details.

    The ticket page associated with that alert is displayed.


Note:

If you do not use Remedy Web console, uncheck Enable web console option in the Web Console Settings section so that ticket ID is shown in plain text. Otherwise it is displayed as a link that does not work.

16.8 Out-of-Box Templates

This section provides details of the out-of-box ticket templates shipped along with the Remedy Connector. The ticket templates specify the mappings between Enterprise Manager alert attributes and Remedy ticket attributes.

All out-of-box templates cause the following actions to occur when a ticket is created for an alert:

  • Write alert information to Description (Remedy ticket description).

  • Set the Remedy ticket summary based on the alert message. On update, the ticket summary field is updated to include the latest alert message information.

  • Set the Category, Item, and Type fields in Remedy to default.

  • Set the Priority (ticket's priority) to the value indicated by the file name of the ticket template. For instance, Remedy_DefaultCategory_HighPriority.xsl sets the ticket priority to High.

Following are the out-of-box templates:

  • Remedy_DefaultCategory_LowPriority.xsl

  • Remedy_DefaultCategory_MediumPriority.xsl

  • Remedy_DefaultCategory_HighPriority.xsl

  • Remedy_DefaultCategory_UrgentPriority.xsl

Following are the out-of-box templates with the AutoClose suffixed to the file names. They set the ticket status to Close when the event severity value becomes Clear.

  • Remedy_DefaultCategory_LowPriority_AutoClose.xsl

  • Remedy_DefaultCategory_MediumPriority_AutoClose.xsl

  • Remedy_DefaultCategory_HighPriority_AutoClose.xsl

  • Remedy_DefaultCategory_UrgentPriority_AutoClose.xsl

Following are the out-of-box templates with Wlog suffixed to the file names. They are customized for the Web services with worklog enabled.

On update, the Description (Remedy ticket description) is updated with the latest event information and the work log is updated with the latest severity and timestamp information.

  • Remedy_DefaultCategory_LowPriority_w_Wlog.xsl

  • Remedy_DefaultCategory_MediumPriority_w_Wlog.xsl

  • Remedy_DefaultCategory_HighPriority_w_Wlog.xsl

  • Remedy_DefaultCategory_UrgentPriority_w_Wlog.xsl

  • Remedy_DefaultCategory_LowPriority_AutoClose_w_Wlog.xsl

  • Remedy_DefaultCategory_MediumPriority_AutoClose_w_Wlog.xsl

  • Remedy_DefaultCategory_HighPriority_AutoClose_w_Wlog.xsl

  • Remedy_DefaultCategory_UrgentPriority_AutoClose_w_Wlog.xsl

16.8.1 Reading Ticket Templates

The Table 16-2 illustrates the creation of a ticket using Remedy_DefaultCategory_HighPriority_AutoClose.xsl. This illustration will help you to read a ticket template.

Table 16-2 Ticket Creation (Remedy_DefaultCategory_HighPriority_AutoClose.xsl Mappings)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


High*

Region


Blank

Request Urgency


High*

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Requester Name

HDUser


Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message


Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-3 Ticket Updates (Remedy_DefaultCategory_HighPriority_AutoClose.xsl Mappings)

Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned.

Summary

Message, Severity


Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_HighPriority_AutoClose.xsl Source Code with Annotations

Use the mapping table (Table 16-2) as a reference to read the following XSLT.

<?xml version='1.0' encoding='UTF-8'?><xsl:transform version="1.0"               xmlns:xsl="http://www.w3.org/1999/XSL/Transform"               xmlns:ns0="http://xmlns.oracle.com/sysman/connector/tt"               targetNamespace="http://xmlns.oracle.com/sysman/connector/tt"               elementFormDefault="qualified">   <!--  This template creates an incident type ticket with default categorization  (Category: Default, Type:Default, Item:Default), and high priority. On update,  the description and message fields are updated, and the ticket is closed if the  associated alert has cleared.   -->   <xsl:template match="ns0:EventModel">    <xsl:choose>       <!-- Create the ticket if there is no ticket ID. -->      <xsl:when test="normalize-space(ns0:TicketId) = ''">        <urn:Create_Helpdesk_Case xmlns:urn="urn:HelpDesk_Submit_Service">            <!-- EDIT THE TAG VALUES BELOW TO CHANGE HOW A TICKET IS FILLED                DURING TICKET CREATION. REFER TO THE REMEDY HELPDESK MANUAL                FOR DESCRIPTION OF THESE HELPDESK SUPPORT DATAFIELDS -->         <urn:Case_Type>Incident</urn:Case_Type>          <urn:Category>Default</urn:Category>          <urn:Department></urn:Department>          <urn:Description>              Ticket created by EM Remedy Connector.              --------------------------------------              EM User: <xsl:value-of select="ns0:EMUser"/>               Event Information:              Target Type: <xsl:value-of select="ns0:TargetType"/>              Metric Column: <xsl:value-of select="ns0:MetricColumn"/>              Metric Name: <xsl:value-of select="ns0:MetricName"/>              <xsl:choose>              <xsl:when test="normalize-space(ns0:KeyColumn) != ''">              Key Column: <xsl:value-of select="ns0:KeyColumn"/>              Key Values: <xsl:value-of select="ns0:KeyValues"/>              </xsl:when>              </xsl:choose>              Severity: <xsl:value-of select="ns0:Severity"/>              Collection Time: <xsl:value-of select="ns0:CollectionTime"/>              Target Host: <xsl:value-of select="ns0:TargetHost"/>              <xsl:choose>              <xsl:when test="normalize-space(ns0:NotificationRuleName) != ''">              Notification Rule: <xsl:value-of select="ns0:NotificationRuleName"/>              </xsl:when>              </xsl:choose>              URL: <xsl:value-of select="ns0:EventPageURL"/>          </urn:Description>          <urn:Escalated></urn:Escalated>          <urn:Hotlist></urn:Hotlist>          <urn:Item>Default</urn:Item>          <urn:Office></urn:Office>          <urn:Orig_Submitter>            <xsl:value-of select="ns0:HDUser"/>          </urn:Orig_Submitter>          <urn:Pending></urn:Pending>          <urn:Phone_Number></urn:Phone_Number>          <urn:Priority>High</urn:Priority>          <urn:Region></urn:Region>          <urn:Request_Urgency>High</urn:Request_Urgency>          <urn:Requester_Login_Name>            <xsl:value-of select="ns0:HDUser"/>
          <urn:Requester_Login_Name>            <xsl:value-of select="ns0:HDUser"/>          </urn:Requester_Login_Name>          <urn:Requester_Name>            <xsl:value-of select="ns0:HDUser"/>          </urn:Requester_Name>          <urn:Site></urn:Site>          <urn:Source>NMP</urn:Source>          <urn:Status>New</urn:Status>          <urn:Summary>            <xsl:value-of select="ns0:Message"/>          </urn:Summary>          <urn:Type>Default</urn:Type>          <urn:WorkLog></urn:WorkLog>          <urn:Create_Time></urn:Create_Time>        </urn:Create_Helpdesk_Case>      </xsl:when>      <!-- Update the ticket otherwise.. -->      <xsl:otherwise>        <urn:SetBy_Case_ID xmlns:urn="urn:HelpDesk_Modify_Service">         <!--                           UNCOMMENT THE TAGS YOU WISH TO HAVE MODIFIED WHENEVER THE TICKET IS UPDATED, AND GIVE THEM DESIRED VALUES            -->         <!-- <urn:Accounting_Code></urn:Accounting_Code>           -->         <!--  <urn:Assignee_Login_Name></urn:Assignee_Login_Name>  -->         <!--  <urn:Case_Type></urn:Case_Type>                      -->         <!--  <urn:Category></urn:Category>                        -->         <!--  <urn:Department></urn:Department>                    -->          <!--  <urn:Description></urn:Description>                           -->          <!-- <urn:Escalated></urn:Escalated>                      -->          <!-- <urn:Hotlist></urn:Hotlist>                          -->          <!-- <urn:Item></urn:Item>                                -->          <!-- <urn:Office></urn:Office>                            -->          <!-- <urn:Pending></urn:Pending>                          -->          <!-- <urn:Phone_Number></urn:Phone_Number>               -->          <!-- <urn:Priority></urn:Priority>                        -->          <!-- <urn:Region></urn:Region>                            -->          <!-- <urn:Request_Urgency></urn:Request_Urgency>          -->          <!-- <urn:Requester_Login></urn:Requester_Login>          -->          <!-- <urn:Requester_Name></urn:Requester_Name>            -->          <!-- <urn:Site></urn:Site>                                -->          <!-- <urn:Solution_Description></urn:Solution_Description>-->          <!-- <urn:Solution_Summary></urn:Solution_Summary>        -->          <!-- <urn:Source></urn:Source>                            -->          <xsl:choose>            <xsl:when test="ns0:Severity = 'Clear'">              <urn:Status>Closed</urn:Status>            </xsl:when>            <xsl:when test="ns0:GracePeriodCheckMade = 'Yes'">              <urn:Status>Assigned</urn:Status>            </xsl:when>          </xsl:choose>          <!-- <urn:Submitted_By></urn:Submitted_By>                -->          <urn:Summary>            <xsl:value-of select="ns0:Message"/> Severity:<xsl:value-of select="ns0:Severity"/>          </urn:Summary>          <!-- <urn:Type></urn:Type>                                -->          <urn:Case_ID>            <xsl:value-of select="ns0:TicketId"/>          </urn:Case_ID>         </urn:SetBy_Case_ID>      </xsl:otherwise>    </xsl:choose>  </xsl:template></xsl:transform>

16.8.1.1 Templates Explained

The tables in this section map the fields in all out-of-box ticket templates shipped along with the Remedy Connector.

Remedy_DefaultCategory_LowPriority.xsl

Table 16-4 Ticket Creation ( Remedy_DefaultCategory_LowPriority.xsl)

RemedyTicket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Low

Region


Blank

Request Urgency


Low

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-5 Ticket Updates (Remedy_DefaultCategory_LowPriority.xsl)

Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_MediumPriority.xsl

Table 16-6 Ticket Creation ( Remedy_DefaultCategory_MediumPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. For example, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)��

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Medium

Region


Blank

Request Urgency


Medium

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-7 Ticket Updates ( Remedy_DefaultCategory_MediumPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCaterogry_HighPriority.xsl

Table 16-8 Ticket Creation (Remedy_DefaultCaterogry_HighPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


High

Region


Blank

Request Urgency


High

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-9 Ticket Updates (Remedy_DefaultCaterogry_HighPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCaterogry_UrgentPriority.xsl

Table 16-10 Ticket Creation (Remedy_DefaultCaterogry_UrgentPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Urgent

Region


Blank

Request Urgency


Urgent

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-11 Ticket Update (Remedy_DefaultCaterogry_UrgentPriority.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Following are the templates with the AutoClose suffixed to the file names. They set the ticket status to Close when the event severity value becomes Clear:

Remedy_DefaultCaterogry_LowPriority_AutoClose.xsl

Table 16-12 Ticket Creation (Remedy_DefaultCaterogry_LowPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Low

Region


Blank

Request Urgency


Low

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-13 Ticket Update (Remedy_DefaultCaterogry_LowPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCaterogry_MediumPriority_AutoClose.xsl

Table 16-14 Ticket Creation (Remedy_DefaultCaterogry_MediumPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType,

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Medium

Region


Blank

Request Urgency


Medium

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-15 Ticket Updates (Remedy_DefaultCaterogry_MediumPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCaterogry_HighPriority_AutoClose.xsl

Table 16-16 Ticket Creation (Remedy_DefaultCaterogry_HighPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


High

Region


Blank

Request Urgency


High

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-17 Ticket Updates (Remedy_DefaultCaterogry_HighPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_UrgentPriority_AutoClose.xsl

Table 16-18 Ticket Creation (Remedy_DefaultCategory_UrgentPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Urgent

Region


Blank

Request Urgency


Urgent

Requester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log


Blank

Create Time


Blank


Table 16-19 Ticket Updates (Remedy_DefaultCategory_UrgentPriority_AutoClose.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Summary

Message, Severity

The alert message in context with the severity appended.

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Following are the templates with Wlog suffixed to the file names. They are customized for the worklog Web_service.

On update, the Description (Remedy ticket description) is updated with the latest event information and the work log is updated with the latest severity and timestamp information.

Remedy_DefaultCaterogry_LowPriority_w_Wlog.xsl

Table 16-20 Ticket Creation (Remedy_DefaultCaterogry_LowPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)��

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Urgent

Region


Blank

Request Urgency


Urgent

UrgentRequester Login Name



HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-21 Ticket Updates (Remedy_DefaultCaterogry_LowPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated).



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_MediumPriority_w_Wlog.xsl

Table 16-22 Ticket Creation (Remedy_DefaultCategory_MediumPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)��

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Medium

Region


Blank

Request Urgency


Medium

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-23 Ticket Updates (Remedy_DefaultCategory_MediumPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_HighPriority_w_Wlog.xsl

Table 16-24 Ticket Creation (Remedy_DefaultCategory_HighPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


High

Region


Blank

Request Urgency


High

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-25 Ticket Updates (Remedy_DefaultCategory_HighPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_UrgentPriority_w_Wlog.xsl

Table 16-26 Ticket Creation (Remedy_DefaultCategory_UrgentPriority_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Urgent

Region


Blank

Request Urgency


Urgent

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context


Default*


Type



Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-27 Ticket Updates (Remedy_DefaultCategory_UrgentPriority_w_Wlog.xsl)

Remedy Ticket AttributesAlert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_LowPriority_AutoClose_w_Wlog.xsl

Table 16-28 Ticket Creation (Remedy_DefaultCategory_LowPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Low

Region


Blank

Request Urgency


Low

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-29 Ticket Updates (Remedy_DefaultCategory_LowPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_MediumPriority_AutoClose_w_Wlog.xsl

Table 16-30 Ticket Creation (Remedy_DefaultCategory_MediumPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Medium

Region


Blank

Request Urgency


Medium

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-31 Ticket Updates (Remedy_DefaultCategory_MediumPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_HighPriority_AutoClose_w_Wlog.xsl

Table 16-32 Ticket Creation (Remedy_DefaultCategory_HighPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


High

Region


Blank

Request Urgency


High

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-33 Ticket Updates (Remedy_DefaultCategory_HighPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if the USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.

Worklog

Severity, CollectionTime

The values in context

Case ID

TicketId (the connector adds this into the alert context before handling the ticketing action. Required by the Remedy Web service to identify the ticket that must be updated)



In the tables, * mark denotes a literal string and ** indicates if the attribute applies.

Remedy_DefaultCategory_UrgentPriority_AutoClose_w_Wlog.xsl

Table 16-34 Ticket Creation (Remedy_DefaultCategory_UrgentPriority_AutoClose_w_Wlog.xsl)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Case Type


"Incident"*

Category


"Default"*

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load)

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if USERS tablespace triggered at warning or critical severity.)

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values from the alert context.

Escalated


Blank

Hotlist


Blank

Item


"Default"*

Office


Blank

Orig Submitter

HDUser

The username that is provided in "Remedy Username" field during the configuration.

Pending


Blank

Phone Number


Blank

Priority


Urgent

Region


Blank

Request Urgency


Urgent

UrgentRequester Login Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Requester Name

HDUser

The username that is provided in "Remedy Username" field of the Connection Settings configuration.

Site


Blank

Source


NMP* (Network Management Program)

Status


New*

Summary

Message

The alert message in context

Type


Default*

Work Log

Severity, CollectionTime

The alert severity and collection time in context.

Create Time


Blank


Table 16-35 Ticket Updates (Remedy_DefaultCategory_UrgentPriority_AutoClose)

Remedy Ticket AttributesEnterprise Manager Alert AttributesValue

Description

EMUser (notification rule owner when the ticket is created through auto-ticketing, and is the EM log-in user when the ticket is created through manual-ticketing)

TargetType

MetricColumn (name of the metric, for example, CPU Utilization(%))

MetricName (Category of the metric. For CPU Utilization(%) metric, this would be 'Load')

KeyColumn** (For metrics that monitor a set of objects, KeyColumn indicates the type of object monitored. For example, for theTablespace Space Used (%) metric that monitors tablespaceobjects, the KeyColumn is 'Tablespace Name)

KeyValues** (For metrics that monitor a set of objects, the KeyValues indicate the specific object that triggered the severity. Forexample, for the Tablespace Space Used (%) metric that monitors tablespace objects, the KeyValues is 'USERS' if USERS tablespace triggered at warning or critical severity.)-

Severity

CollectionTime

TargetHost

NotificationRuleName

EventPageURL (URL to the metric details page in context of the alert)

Values of the alert in context

Status

Severity

  • If severity is Clear, then set the ticket to the status Closed.

  • If the grace period test has already been done, and the alert is still within the grace period, then reopen the ticket by setting the ticket to the status Assigned; otherwise, leave the status as it is.