7 Configuring Services

7.4.1 Availability Definition

You can modify the availability definition (service test-based or system-based) for the selected service. If availability is based on service tests, you can specify whether the service should be available when:

• All key service tests are successful (Default)

• At least one key service test is successful

If availability is based on the key system components, you can specify whether the service should be available when:

• All key components are up (Default)

• At least one key component is up

You can also mark one or more components as key system components that will be used to compute the availability of the service. Key system components are used to determine the possible root cause of a service failure. For more information, refer to "Root Cause Analysis Configuration".

You can also indicate whether the service test is a key test by enabling the Key Service Test checkbox. Only key service tests are used to compute the availability of the service. You can then select the beacons that will be used to execute the key tests and determine the availability of the service.

7.4.2 Performance Metrics

Performance metrics are used to measure the performance of the service. If a service test has been defined for this service, then the response time measurements as a result of executing that service test can be used as a basis for the service's performance metrics. Alternatively, performance metrics from the underlying system components can also be used to determine the performance of the service. You can do the following:

• Add a performance metric for a service test. After selecting a metric, you can choose to:

  • Use the metric values from one beacon. Choose this option if you want the performance of the service to be based on the performance of one specific location.

  • Aggregate the metric across multiple beacons. Choose this option if you want to consider the performance from different locations. If you choose this option, you need to select the appropriate aggregation function:

    Table 7-2 Beacon Aggregation Functions

    Function	Description
    Maximum	The maximum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the worst performance across all beacons.
    Minimum	The minimum value of the metric from data collected across all beacons will be used. Use this function if you want to measure the best performance across all beacons.
    Average	The average value of the metric will be used. Use this function if you want to measure the 'average performance' across all beacons.
    Sum	The sum of the metric values will be calculated. Use this function if you want to measure the sum of all response times across each beacon.

    
    

    Note:

    If you are configuring a Web transaction, you can specify the Source which can be transaction, step group or step. Based on this selection, the metric you add will be applicable at the transaction, step group, or step level.

• Add a performance metric for the underlying system components on which the service is hosted. After selecting a metric for a target, you can choose to:

  • Use the metric from a specific component. Choose this option if you want the performance of the service to be based on the performance of one specific system component.

  • Aggregate the metric across multiple components. Choose this option if you want to consider the performance from multiple components. If you choose this option, you need to select the appropriate aggregation function.

    Table 7-3 System Aggregation Functions

    Function	Description
    Maximum	The maximum value of the metric across all components will be used as the value of this performance metric for the service.
    Minimum	The minimum value of the metric across all components will be used as the value of this performance metric for the service.
    Average	The average value of the metric across all components will be used.
    Sum	The sum of values of metrics across all components will be calculated.

    
    

    Note:

    When a system is deleted, performance metrics associated with the system will not be collected.

• Edit a performance metric that has been defined. For service test-based performance metrics, you can modify the beacon function that should be used to calculate the metric values. For system-based performance metrics, you can modify the target type, metric, and whether the aggregation function should be used. You can also modify the Critical and Warning thresholds for the metric.

• Delete a performance metric that has been defined.

7.4.3 Usage Metrics

Usage metrics are used to measure the user demand for the service. Usage metrics are collected based on the usage of the underlying system components on which the service is hosted. You can do the following:

• Add a usage metric. After selecting a metric for a target, you can choose to:

  • Use the metric from a specific component. Use this option if you want to monitor the usage of a specific component.

  • Aggregate the metric across multiple components. Use this option if you want to statistically calculate the usage across multiple components. If you choose this option, you need select the appropriate aggregation function.

    Table 7-4 Aggregation Functions - Usage Metrics

    Function	Description
    Maximum	The maximum value of the metric across all components will be used as the value of this usage metric for the service.
    Minimum	The minimum value of the metric across all components will be used as the value of this usage metric for the service.
    Average	The average value of the metric across all components will be used.
    Sum	The sum of the values of metrics across all components will be calculated.

    
    

• Edit a usage metric that has been defined.

• Delete a usage metric that has been defined.

7.4.4 Business Metrics

Business metrics are used to measure the performance of business in an organization. These metrics are based on business indicators that can assess the business performance. You can define one or more system based metrics and specify critical and warning thresholds for these metrics. You can define business metrics for Generic Services and Aggregate Services.

You can do the following:

• Add a business metric. After selecting a metric for a target, you can choose to:

  • Use the metric from a specific component. Use this option if you want the business metric to be based on the performance of one specific system component

  • Aggregate the metric across multiple components. Use this option if you want to measure the business performance from multiple components. Select the appropriate aggregation function from the drop down list. If you choose this option, you need select the appropriate aggregation function.

    Table 7-5 Aggregation Functions - Usage Metrics

    Function	Description
    Maximum	The maximum value of the metric across all components will be used as the value of this business metric for the service.
    Minimum	The minimum value of the metric across all components will be used as the value of this business metric for the service.
    Average	The average value of the metric across all components will be used.
    Sum	The sum of the values of metrics across all components will be calculated.

    
    

• Edit a business metric that has been defined.

• Delete a business metric that has been defined.

You can define system based metrics only. You can configure non-system based metrics by using the Data Exchange feature which facilitates data transfer between Enterprise Manager Grid Control and other external monitoring systems. For details, refer to the Oracle Enterprise Manager Integration Guide.

7.4.5 Service Tests and Beacons

You can add additional service tests and specify one or more beacons that will execute these service tests. To add a service test or modify an existing service test, click the Service Test and Beacons link on the Monitoring Configuration page. The Service Tests and Beacons page appears. You can do the following:

• Add one or more service tests for your service. Select the Test Type and click Add. Some of the test types that can be defined are FTP, Web Transaction, DNS, SOAP and others. The Create Service Test page is displayed. Refer to the Enterprise Manager Online Help for details on the various types of service tests.

  Note:

  While defining a SOAP (Simple Object Access Protocol) service test, if the WSDL URL to be accessed is outside the company's intranet, proxy settings need to be added to the $OMS_HOME/sysman/config/emoms.properties file.

  For example, to set up www-proxy.us.oracle.com as proxy, specify the values as follows:

  proxyHost=www-proxy.us.oracle.com
  proxyPort=80
  dontProxyFor=us.oracle.com,oraclecorp.com
  
  

  The proxyUser,proxyPwd,proxyRealm,and proxyPropsEncrypted properties are used to configure an authenticated proxy. After you have modified the proxy settings, you must restart the Oracle Management Service for the changes to be effective.

• After you have created the service test, you must enable it. If your service test is not enabled, it will not be executed by any of the beacons.

• Create, add, or remove a beacon. When you identify the beacon locations, select locations on your internal network or on the Internet that are important to your e-business. These are typical locations where your end users are located. For example, if your business is hosted in Canada and you have customers in the United States, use a beacon installed on a host computer in the United States to measure the availability and performance of your applications.

• After you have created the service test, you can verify it by clicking Verify Service Test.

  Note:

  You can define one or more service tests as key tests. These key tests are used to monitor the availability and performance of your service. Only service tests that are enabled can be designated as key tests. To set up a service test as a key test, click the Availability Definition link at the bottom of the page.

  For more details on creating different types of service tests, refer to the Enterprise Manager Online Help.

7.4.6 Root Cause Analysis Configuration

You can use Root Cause Analysis (RCA) to filter a set of events to determine the cause of a higher level system, service, or application problem. RCA can help you to eliminate apparent performance problems that may otherwise appear to be root causes but which are only side effects or symptoms of the actual root cause of the problem, allowing you to more quickly identify problem areas. You can view the RCA results on the Home page or Topology page of any service that is currently down. The Topology page allows you to see a graphical representation of the service, system and component dependencies with the targets highlighted that RCA has implicated as causing the service failure.

Before running RCA, you can choose to:

• Configure the tool to run automatically whenever a service fails.

• Disable RCA by changing the default Analysis Mode to Manual.

• Define component tests for the service and thresholds for individual tests.

To configure Root Cause Analysis, follow these steps:

1. From the Service Home page, click Monitoring Configuration.

2. From the Monitoring Configuration page, click Root Cause Analysis Configuration.

3. If the current mode is set to Automatic, click Set Mode Manual to disable RCA. If you choose to perform the analysis manually, you can perform the analysis from the Service home page at anytime by choosing Perform Analysis if the service is down. If the current mode is set for Manual, click Set Mode Automatic to enable RCA when the state of the service and its components change

4. Click the link in the Component Tests column of the table for the key component you want to manage. You can then manage component tests for the service on the Component Tests page by adding, removing, or editing tests. Refer to the Enterprise Manager Online Help for details on defining component tests.

   Note:

   When you disable RCA and set it back to automatic mode, RCA does not store the previous history results for you, thus providing no history for later reference.

7.8.1 Configuring End-User Performance Monitoring Using Oracle HTTP Server Based on Apache 2.0 or Apache HTTP Server 2.0

To enable End-User Performance Monitoring, you can use either of the following Apache server versions:

• Oracle HTTP Server Based on Apache 2.0

• Apache HTTP Server 2.0 or higher (This can be downloaded from http://www.apache.org)

Before configuring either of these Apache server versions, you must perform the following steps:

1. In the Agent Home page, select either Oracle HTTP Server or Apache HTTP Server as a target type.

2. Add the target of the corresponding type and make sure the following properties are set in the Monitoring Configuration page:

   • For Oracle HTTP Server, fill in the version number (stdApache10.1.2), Log file directory and Log file name.

   • For Apache HTTP Server 2.0, fill in the install home directory, Log file directory and Log file name.

     Note:

     If the Oracle HTTP Server is installed before the Management Agent has been installed, and is up and running during agent installation, then the target will be discovered automatically. Otherwise you need to manually create the Oracle HTTP Server target and specify the following properties: Machine name, Port number, Version of the Apache Server, Oracle home path, Log file directory (for EUM), Log file name (for EUM) where EUM refers to End-User Performance Monitoring.

3. Make sure you have created the Web application with this Web server target. For details on creating a Web application, refer to the pre-requisites in the "Configuring End-User Performance Monitoring" section.

To configure the Apache server and enable collection of end-user performance data, follow the steps given below:

1. Navigate to the Web Application Home page in the Grid Control Console and click Monitoring Configuration.

2. Click Manage Web Server Data Collection. You will see a table which lists the Web Servers including Oracle HTTP Server Based on Apache 2.0 or higher, Apache HTTP Server version 2.0 or higher, or OracleAS Web Cache.

   Figure 7-3 Manage Web Server Data Collection

   
   

3. Select the Oracle HTTP Server or Apache HTTP Server from the table and click Configure. Enter the host credentials required for modifying the Apache configuration file.

4. After logging in, you will see a table containing the list of sites that are being hosted by the Apache server. These include a list of virtual hosts defined by the user in the Apache Configuration file. The up and the down arrows under the Monitoring Status column shows the corresponding site is currently being monitored. For each site, check or uncheck the Enable Monitoring checkbox to indicate whether this site is to be monitored. For the site that is to be monitored, enter the log file name in the text box to indicate the location in which the end-user performance data is to be stored. By default, the log file will be created under the logs/directory under Apache root directory. To save the log file in a different directory, enter a file name with the absolute path.

5. Make sure that the log file name and the location you specify here match the Log file name and Log file directory in the Monitoring Configuration page of the Oracle HTTP Server or Apache HTTP Server target.

6. You can also use the one button accelerator to enable all sites or disable all sites all at once.

7. To selectively disable or enable certain URLs on a specific site, select the site, click Set URLs. Click Insert Before or Insert After to create a URL rule and place it in the desired place among all URL rules. A URL rule contains a URL Pattern, URL Pattern Type, and a check box indicating if this URL is to be monitored or not. For example, a URL rule with URL Pattern "abc" and URL Pattern Type "Ends With" and Monitor unchecked means that any URL ending with "abc" will not be monitored by End-User Performance Monitoring. The user can also delete a URL rule, move a URL rule up or down to increase or decrease its priority.

8. After you have made the configuration changes, click OK to go to the Apache Restart page. Restarting the Apache server will finalize all configuration changes, and end-user performance data will be logged by the Apache server.

9. After you have configured the Apache server, you will return to the Manage Web Server Data Collection page. You can now enable the collection of end-user performance data. For more details, refer to "Starting and Stopping End-User Performance Monitoring". If you do not see data after End-User Performance Monitoring has been enabled, refer to the "Verifying and Troubleshooting End-User Performance Monitoring".

7.8.2 Configuring End-User Performance Monitoring Using Oracle Application Server Web Cache

Enterprise Manager uses data from Oracle Application Server Web Cache to gather statistics about the performance of pages within your Web applications. As a result, you must configure Oracle Application Server Web Cache to ensure that it logs your Web site activity and that the data is in the correct format.

When Oracle Application Server Web Cache is properly configured, Enterprise Manager can begin collecting the end-user performance data and load it into the Oracle Management Repository.

The following sections describe how to configure and collect end-user performance data if you are using the OracleAS Web Cache:

• Configuring Oracle Application Server Web Cache 10.1.2

• Configuring Oracle Application Server Web Cache 9.0.4

• Configuring End-User Performance Monitoring Using Earlier Versions of Oracle Application Server Web Cache

• Configuring End-User Performance Monitoring Using Standalone Oracle Application Server Web Cache

7.8.3 Starting and Stopping End-User Performance Monitoring

After you have configured the Web server to enable collection, you can then start collecting end-user performance data.

1. Navigate to the Web Application home page in the Grid Control Console and click Monitoring Configuration.

2. Click Manage Web Server Data Collection. Enterprise Manager displays the Manage Web Server Data Collection page.

3. In the Interval (minutes) column, enter the interval at which Enterprise Manager will collect performance data.

4. Check the Collection Enabled checkbox.

5. Click Apply, review the changes and confirm by clicking Apply again. End-User Performance Monitoring collection is enabled and data will soon be uploaded to the database and shown under the Page Performance page.

To stop collecting end-user performance data:

1. Navigate to the Manage Web Server Data Collection page.

2. Clear the check box in the Collection Enabled column of the table and click Apply.

3. Click Apply again to confirm the changes.

7.8.4 Verifying and Troubleshooting End-User Performance Monitoring

To verify that End-User Performance Monitoring is working properly:

1. Wait a period of time to allow Enterprise Manager to begin collecting end-user performance data and to start loading the data into the Management Repository. Specifically, you should wait until the next upload of data from the Management Agent to the Management Service. The Management Service then loads the data into the Management Repository. For more information about how Enterprise Manager gathers and uploads to the repository, see Oracle Enterprise Manager Concepts.

2. Navigate to the Web Application home page, select a Web application and navigate to the Page Performance tab. Verify that there is data in the Slowest Response Times table.

3. Another way to verify the existence of end-user performance data, is to note the value of the Number of Unprocessed Samples. Samples for an hour that has not ended are referred to as Unprocessed Samples. For example, data is processed for the time period between 10 am to 11 am, 11 am to 12 pm and so on. Therefore, data from 10 am to 11 am will be considered as Unprocessed Samples if the 11 am boundary has not been crossed or if there is no incoming end-user traffic after 11 am. If this is a non-zero value, click Process Samples. End-user performance data is displayed in the Slowest Response Times table.

4. If you still do not see any data on the Page Performance page, consider the following troubleshooting tips:

   1. Be sure you have completed all the steps required to configure End-User Performance Monitoring. Make sure that the Web server you are using to collect end-user performance data, is either OracleAS Web Cache or Oracle HTTP Server Based on Apache 2.0 (stdApache10.1.2), or Apache HTTP Server (2.0 or higher). You can see the Web server version in the Monitoring Configuration page.

   2. To monitor Web pages from a third party Application Server, follow the instructions for installing an Apache 2.0 server with the Application Server.

   3. Install End-User Performance Monitoring after installing the plug-in for the Application Server.

      • When using the Apache Configuration page, log in using the same account used to install Apache.

      • If the Apache server is running on a port less than 1024, the server must be started as root. Apache can be started as root with a lower privileged account by changing ownership of bin/httpd to root and setting its setuid flag. When Apache is started as root, the 'User' and 'Group' directives in httpd.conf need to be set to the user who installed the Apache server.

        Note:

        Only pages with a Content-Type header of text or HTML will be monitored. Pages that pass through the Apache Server with a Content-Encoding header (like gzip) will not be monitored because the JavaScript tag cannot be added to these pages.

      • If your Web site uses IFrames and End-User Monitoring is not working on those pages, you will need to switch to the newer JavaScript version with IFrame support. In the <apache root>/conf/eum.conf file, follow the directions for enabling IFrame support.

   4. Be sure there is enough activity on your site. If no user is visiting and using your Web application, there may be no end-user performance data to collect or to upload to the Management Repository.

   5. Be sure you have waited long enough for the Management Agent on the Web server host to upload data to the repository. Check the Management Agent home page to determine the last time the Management Agent successfully uploaded data to the Management Repository.

   6. Check the html source of the URLs that you wanted to monitor: make sure the tag <SCRIPT SRC="/oracle_smp_chronos/oracle_smp_chronos.js"></SCRIPT> has been appended to the HTML source of these URLs.

      • If it is present, proceed to the next step.

      • If it is not present, check the configuration of your OracleAS Web Cache, Oracle HTTP Server, or Apache HTTP Server. Make sure that all configurations are correct, the site has been enabled, and the Web server has been successfully restarted after saving any configuration changes.

   7. Go to the OracleAS Web Cache or Apache server target home page, click Monitoring Configuration, and check if the log file in the defined Log file directory contains any recent data.

      • If it does not have data, go to the next step.

      • If the log file does contain data and the Web server is OracleAS Web Cache, login to Oracle Application Server Control or Web Cache Manager and make sure that the access log is in WCLF or End-User Performance Monitoring format.

   8. Verify that the OracleAS Web Cache / Apache server Monitoring Configuration properties that specify the location and name of the log file are accurate.

   9. Check the Web Server target Home page for any collection errors. Often, the collection error will provide information describing why performance data cannot be collected.

   10. Navigate to the All Metrics page for the Web server target and check to be sure the APM Mining Performance Details metrics are being collected successfully.

7.8.5 Enabling End-User Performance Monitoring for Third-Party Application Servers

For enabling End-User Performance Monitoring for third-party application servers like IBM WebSphere Application Server, BEA WebLogic Managed Server, and JBoss Application Server, after you configure one of the Web servers as explained in this chapter, you have to enable the Application Server Diagnostics Pack for the Web applications hosted on these servers.

To do so, perform the following steps:

1. Click Setup on the top-right corner of the Grid Control console and navigate to the Overview of Setup page.

2. Click Management Pack Access from the panel to the left.

3. On the Management Pack Access page, select the All Targets option in the View Options section of this page.

4. Select Web Application from the Search menu, and click Go. The table lists all the Web applications monitored.

5. For the Web application for which you want to enable End-User Performance Monitoring, check Application Server Diagnostics Pack and Pack Access Agreed, and then click Apply.

6. Now return to the Web Application Home Page and click Page Performance to see the end-user performance monitoring data that has been collected.

   Note:

   End-User Performance Monitoring for a Web application is not supported if the J2EE container hosting that application is SSL enabled. This applies to Oracle J2EE containers, that is OC4J, and any non-Oracle J2EE containers for third-party application servers like BEA WebLogic Managed Server, IBM WebSphere Application Server, or JBoss Application Server. To activate End-User Performance Monitoring for such a Web application, disable SSL for that J2EE container.

   For information about configuring SSL for Oracle Application Servers, refer to the Security Guide for your Oracle Application Server release. Documentation for all the Oracle Application releases is available from the Oracle Technology Network: http://www.oracle.com/technology/documentation/index.html.

   For information about configuring SSL for third-party servers, refer to your third-party documentation.

7.9.1 Recording and Monitoring Forms Transactions

A Forms transaction consists of a set of user actions within a single application when using Forms. For example, an Update Employee Salary transaction may consist of several user actions like open salary form, update salary form, and save salary form. You can record multiple Forms transactions by using the intuitive playback recorder that automatically records a series of Forms actions.

Before recording a Forms transaction, you must do the following:

• Set the permissions of the .java.policy file on each Windows client. See Setting the Permissions of the .java.policy File.

• Ensure that a trusted Enterprise Manager certificate is used. See Using a Trusted Enterprise Manager Certificate.

• Add a certificate to the Enterprise Manager Agent to play back secure Forms transactions. See Adding a Forms Certificate to the Enterprise Manager Agent .

• Configure the Forms server so that Forms transactions can be recorded. See Configuring the Forms Server .

After you have performed these steps, you can install the transaction recorder to record and play back the Forms transaction. See Installing the Transaction Recorder to Record and Play Back Forms Transactions.

7.9.2 Monitoring the End-User Performance of Forms Applications

The End-User Performance Monitoring utility allows you to measure the response time of your applications by viewing information about how quickly the responses are delivered to the end users. When you access a Forms application, the End-User Performance Monitoring utility measures the response time of Forms actions such as Commit, Query, Runform, Callform, Newform, and Openform.You can monitor the Forms actions and view reports based on the response times experienced by the user. You can also define a Watch List of the most important Forms actions to monitor and view the response metrics of these critical operations at a glance.

Before you can begin monitoring the End-User Performance of a Forms Application, you must configure the Forms and Web server to enable data collection for End-User Performance Monitoring. To configure the Forms Application for End-User Performance Monitoring, follow these steps:

• Configure the Forms server to enable End-User Performance Monitoring.

• Configure the Web server (OracleAS Web Cache or Oracle HTTP Server / Apache HTTP Server) so that it can be used for End-User Performance Monitoring.

• Enable the collection of end-user performance data.

7.10.1 Selecting OC4J Targets for Request Performance Diagnostics

Before you configure the OC4J target to collect request performance data, follow the steps given below to add the target to the Web application.

1. Configure the system where the OC4J targets are defined for the Web application target.

2. Navigate to the Web application Home page and click Monitoring Configuration.

3. Click System Configuration. From the list of system components displayed on this page, select one or more OC4J targets and select the checkbox in the Key Components column. The OC4J targets can now be configured and used to collect request performance data.

7.10.2 Configuring Interactive Transaction Tracing

When you use transactions to monitor your Web application, some of the transactions you create often involve application components such as servlets, Java Server Pages (JSPs), Enterprise Java Beans (EJBs), and database connections. Often, the best way to solve a performance problem is to trace these more complex transactions and analyze the time spent processing each application component.

Enterprise Manager provides a mechanism for tracing these transactions. Use the Service Tests and Beacons link on the Monitoring Configuration page of the Web application target to create your transactions and to trace the transactions as they are processed by the servlets, JSPs, EJBs, or database connections of your application.

However, before you can take advantage of transaction tracing, you must first enable tracing for the OC4J instance used to deploy the application. Each OC4J instance of an OC4J cluster must be configured independently. The OC4J instances of the OC4J clusters selected as key components of the Web application target are displayed on the Manage Web Server Data Collection page.

To enable tracing for an OC4J instance:

1. Navigate to the Web Application Home page and click Monitoring Configuration.

2. Click Manage OC4J Data Collection.

   Enterprise Manager displays the Manage OC4J Data Collection page.

3. Select the OC4J to configure and click Enable Logging.

   Enterprise Manager opens another browser window and displays the Tracing Properties page for the OC4J instance in the Application Server Control.

   If you are prompted to log in to the Application Server Control Console, enter the credentials for the ias_admin administrator's account.

4. Select the following options on the Tracing Properties page:

   • Enable JDBC/SQL Performance Details

   • Enable Interactive Trace

   You can use the default values for most of the tracing properties.

   Note:

   Turning on the Enable JDBC/SQL Performance Details option allows to you drilldown to actual SQL statements but this may require more resources.

5. Click Apply.

   If this is the first time you are enabling OC4J tracing for this application server, Enterprise Manager displays a message stating that the transtrace application is being deployed. The Application Server Control then prompts you to restart the OC4J instance.

6. Click Yes to restart the instance and enable the tracing properties.

7. Return to the Grid Control Console.

   Tracing is now enabled for the selected OC4J instance.

7.10.3 Configuring OC4J Tracing for Request Performance Data

You must configure OC4J instances to enable tracing so that request performance data can be collected. Each OC4J instance of an OC4J cluster must be configured independently. The OC4J instances of the OC4J clusters selected as key components of the Web application target are displayed on the Manage Web Server Data Collection page. To configure the OC4 instances, follow these steps:

1. Navigate to the Web Application home page and click Monitoring Configuration.

2. Click Manage OC4J Data Collection.

   Enterprise Manager displays the Manage OC4J Data Collection page.

3. For the OC4J instance that you used to deploy your application, select the check box in the Collection Enabled column.

4. In the Interval (minutes) column, enter the interval at which to collect OC4J tracing data.

   The recommended interval setting is 60 minutes.

5. Select the OC4Js to configure and click Enable Logging.

   Enterprise Manager opens another browser window and displays the Tracing Properties page for the OC4J instances in the Application Server Control.

   If you are prompted to log in to the Application Server Control Console, enter the credentials for the ias_admin administrator's account.

6. Select the following options on the Tracing Properties page:

   • Enable JDBC/SQL Performance Details

   • Enable Historical Trace

   You can use the default values for most of the tracing properties. However, Oracle recommends that you set the Frequency to Generate Trace File (seconds) field to 3600 seconds (equivalent to 60 minutes).

   Note:

   Modifying the value in the Trace File Directory field is not supported.

7. Click Apply.

   If this is the first time you are enabling OC4J tracing for this application server, Enterprise Manager displays a message stating that the transtrace application is being deployed. The Application Server Control then prompts you to restart the OC4J instance.

8. Click Yes to restart the instance and enable the tracing properties.

9. Return to the Grid Control Console.

   Request Performance data should begin to appear on the Request Performance page as soon as data for the OC4J instance is collected and uploaded into the Management Repository.

7.10.4 Additional Configuration for Monitoring UIX Applications

If you used Oracle User Interface XML (UIX) to build your application, there is an additional configuration step you must perform before you can monitor the requests of your application.

Before you can monitor the requests of your UIX application, you must do the following:

1. Enable tracing for the OC4J instance you used to deploy your application, as described in "Configuring OC4J Tracing for Request Performance Data".

2. Locate the following configuration file in the Application Server home directory where you deployed your UIX application:

   $ORACLE_HOME/j2ee/OC4J_instance_name/config/oc4j.properties
   
   

   For example, if you deployed your application in the OC4J instance called "home," locate the following configuration file:

   $ORACLE_HOME/j2ee/home/config/oc4j.properties
   
   

3. Open the oc4j.properties file using your favorite text editor and add the following line to the end of the file:

   oracle.dms.transtrace.dollarstrippingenabled=true
   
   

4. Save your changes and close the oc4j.properties file.

5. Restart the OC4J instance.

7.11.1 Configuring Service Tests and Beacons

You can configure the service tests and beacons associated with the template by using the options in the Tests page. A service test-based template contains the following elements:

• Variables: A variable may occur at multiple locations in the service tests. The Variables table allows you to specify default values for all the variables. These default values will be stored in the template along with the variables. You can specify values other than the default while applying the template to a target. You can perform the following operations:

  • Add a variable. The variable can consist of letters, numbers and underscores only.

  • Rename a variable. When you rename a variable, all variable references in the service tests will be replaced with the new name.

  • Remove variables for properties within service tests. If you remove a non-password variable, all references to the variable in test properties will be replaced with the variable's default value

  • Replace Text in test properties with a variable definition.

• Service Tests: You can edit the test definition and define variables for various properties. You can select the tests from the original target that are to be part of the template by clicking the Add / Remove button. You can specify whether the service test is a key test and if it should be enabled. You can also click Monitoring Settings to drill down to this page and define metrics and thresholds for the service tests.

• Beacons: Use the Add / Remove button to specify which beacons are to be included in the template. You can also specify whether each beacon is a key beacon.

Refer to the Enterprise Manager Online Help for detailed instructions on these operations.

7.12.1 Defining Service Level Rules

When you create a service, the default service rule is applied to the service. However, you must edit the service level rule for each service to accurately define the assessment criteria that is appropriate for your service. To define a service level rule:

1. Click the Targets tab and Services subtab. The Services main page is displayed.

2. Click the service name link to go to the Service Home page.

3. In the Related Links section, click Edit Service Level Rule.

4. On the Edit Service Level Rule page, specify the expected service level and the actual service level and click OK. The expected service level specifies the percentage of time a service meets the performance, usage, availability, and business criteria defined in the Service Level Rule. The actual service level defines the baseline criteria used to define service quality and includes business hours, availability, performance criteria, usage criteria, and business criteria.

7.12.2 Viewing Service Level Details

You can view service level information directly from the either of the following:

• Enterprise Manager Grid Control Console -From any Service Home page, you can click on the Actual Service Level to drill down to the Service Level Details page. This page displays what Actual Service Level is achieved by the service over the last 24 hours/ 7 days / 31 days, compared to the Expected Service Level. In addition, details on service violation and time of each violation are presented in both graphical and textual formats.

• Information Publisher - Information Publisher provides an out-of-box report definition called the Services Dashboard that provides a comprehensive view of any service. From the Report Definition page, click on the Services Monitoring Dashboard report definition to generate a comprehensive view of an existing service. By default, the availability, performance, status, usage, business, and Service Level of the service are displayed. The Information Publisher also provides service-specific report elements that allow you to create your own custom report definitions. The following report elements are available:

  • Service Level Details: Displays Actual Service Level achieved over a time-period and violations that affected it.

  • Service Level Summary: Displays service level violations that occurred over selected time-period for a set of services.

  • Services Monitoring Dashboard: Displays status, performance, usage, business, and service level information for a set of services.

  • Services Status Summary: Information on one or more services' current status, performance, usage, business, and component statuses.

    Refer to the Online Help for more details on the report elements.