D17244GC11 - Oracle Enterprise Manager 10g Grid Control Vol 2

Oracle Enterprise Manager 10g
Grid Control
Volume II • Student Guide
D17244GC11
Edition 1.1
March 2005
D41403
Authors Copyright © 2005, Oracle. All rights reserved.
Aniket Raut This documentation contains proprietary information of Oracle Corporation. It is

provided under a license agreement containing restrictions on use and disclosure and
Abhijit Dass
is also protected by copyright law. Reverse engineering of the software is prohibited.
If this documentation is delivered to a U.S. Government Agency of the Department of
Defense, then it is delivered with Restricted Rights and the following legend is
Technical Contributors: applicable:
Ana Hernandez Restricted Rights Legend

Christian Bauwens
Christina Mullins Use, duplication or disclosure by the Government is subject to restrictions for
commercial computer software and shall be deemed to be Restricted Rights software
Dave LeRoy under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013,
Irina Goldshteyn Rights in Technical Data and Computer Software (October 1988).
Julie Wong
This material or any portion of it may not be copied in any form or by any means
Martin Pena
without the express prior written permission of Oracle Corporation. Any other copying
Matt Taylor is a violation of copyright law and may result in civil and/or criminal penalties.
Nagavalli Pataballa
Nicole Haba If this documentation is delivered to a U.S. Government Agency not within the
Department of Defense, then it is delivered with “Restricted Rights,” as defined in
Olaf Fermum FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
Srinivas Putrevu
Sudip Datta The information in this document is subject to change without notice. If you find any
Valerie K. Kane problems in the documentation, please report them in writing to Education Products,
Oracle Corporation, 500 Oracle Parkway, Redwood Shores, CA 94065. Oracle
Yi Lu Corporation does not warrant that this document is error-free.
Oracle and all references to Oracle Products are trademarks or registered trademarks
GES Contributors: of Oracle Corporation.
Christopher Wensley All other products or company names are used for identification purposes only, and
Gary Vance may be trademarks of their respective owners.
Javier Saiz
Lakshmi Narapareddi
Tim Samosa
Reviewers:
Bruce Ernst
Christine Jeal
Donna Keesling
Janet Stern
Joel Goodman
Mary Bryksa
Stephan Lindblad
Sue Jang
Thomas Hoogerwerf
Trevor Bowen
Wolfgang Krueger
Publisher
Michael Sebastian
Contents
1 Introduction
Objectives 1-2
Grid Computing 1-3
Oracle Ecosystem 1-5
Enterprise Grid Computing 1-6
Implement One from Many 1-7
Manage Many as One 1-9
Management Controls 1-11
Oracle Enterprise Manager 10g Grid Control 1-12
Course Objectives 1-13
Summary 1-14
2 Architecture
Objectives 2-2
Grid Control Components 2-3
Managed Targets 2-5
Oracle Management Agent 2-6
Oracle Management Service 2-8
Oracle Management Repository 2-10
Accessing the Grid Control Console 2-11
Grid Control Console: Home 2-12
Grid Control Console: Targets 2-13
Grid Control Console: Deployments 2-14
Grid Control Console: Alerts 2-16
Grid Control Console: Jobs 2-17
Grid Control Console: Management System 2-18
EM2Go 2-19
Managing Very Large Grids 2-20
Summary 2-21
3 Installing the Grid Control Framework
Objectives 3-2
Oracle Management Repository 3-3
Oracle Management Service 3-4
Oracle Management Agent 3-5
Installation Overview 3-6
Preinstallation Checks: Hardware 3-7
Preinstallation Checks: Operating System 3-8
Installation 3-10
Select Product 3-11
Enterprise Manager 10g Grid Control Using a New Database 3-12
Super Administrator 3-15
Repository Database Passwords 3-16
iii
MetaLink and Proxy Information 3-17
Database Identification 3-18
Database Files 3-19
Configuration Assistants 3-20
Enterprise Manager 10g Grid Control Using an Existing Database 3-21
Add Repository to Existing Database 3-22
Enterprise Manager 10g Grid Control Additional Management Service 3-24
Connect OMS to Existing Repository 3-25
Demonstration 3-26
End of Installation 3-27
Custom Port Selection 3-29
Summary 3-31
Practice 3 Overview: Installing the Grid Control Framework 3-32
4 Installing the Oracle Management Agent
Objectives 4-2
Grid Control Components 4-3
OMA Installation Options 4-4
Interactive Installation 4-5
Selecting an OMS 4-6
Silent Installation 4-7
Response File 4-9
Downloadable Management Agent 4-10
Preinstallation Steps for agentDownload 4-11
agentDownload 4-12
Postinstallation 4-14
Configuring Monitoring Credentials 4-15
Key Configuration Files 4-16
Target Discovery 4-17
Summary 4-19
Practice 4 Overview: Installing the Oracle Management Agent 4-20
5 Managing Grid Control
Objectives 5-2
Controlling the Management Framework 5-3
Starting the Grid Control Framework 5-4
Stopping the Grid Control Framework 5-5
Controlling the OMR Database Listener 5-6
Controlling the OMR Database 5-8
Controlling the OMS 5-10
opmnctl 5-11
emctl 5-13
dcmctl 5-14
Application Server Control 5-16
Starting Application Server Control 5-17
OMS Home Page 5-18
Starting, Stopping, and Restarting the OMS 5-19
OMS Component Home Pages 5-20
Starting, Stopping, and Restarting OMS Components 5-21
Obtaining Common OMS Metrics 5-22
Controlling the OMA 5-23
iv
Demonstration 5-25
Summary 5-26
Practice 5 Overview: Managing Grid Control 5-27
6 Configuring Grid Control Administrators
Objectives 6-2
Groups 6-3
Types of Groups 6-4
Creating Groups 6-6
Monitoring Groups 6-8
Monitoring Group Performance 6-9
Monitoring Group Targets 6-10
Super Administrator 6-11
Creating Administrators 6-12
Creating Roles 6-13
Notifying Administrators About Issues 6-15
Setting Up Notification Methods 6-16
Defining E-Mail Addresses 6-18
Defining a Notification Schedule 6-19
Notification Rules 6-21
Using Public Notification Rules 6-22
Creating a Notification Rule 6-23
Preferred Credentials 6-25
Setting Preferred Credentials 6-26
Managing Target Subtabs 6-27
Modifying Metric Columns 6-28
Summary 6-29
Practice 6 Overview: Configuring Groups and Grid Control Administrators 6-30
7 Monitoring Grid Control
Objectives 7-2
Monitoring Grid Control 7-3
Management System: Overview 7-4
Loader and Notification Backlogs 7-5
Management Repository Details 7-6
Repository Operations 7-7
Management Services 7-8
Management Service Status 7-9
Management Agents 7-10
Metric Collection Errors 7-11
Troubleshooting Grid Control 7-12
Troubleshooting the OMR 7-13
Troubleshooting the OMS 7-15
Troubleshooting the OMA 7-17
Summary 7-18
Practice 7 Overview: Monitoring Grid Control 7-19
8 Monitoring the Ecosystem
Objectives 8-2
Monitoring the Ecosystem: Overview 8-3
Monitoring 8-4
Target Monitoring 8-5
v
Availability Monitoring 8-6
Examining Metrics in Alerts 8-7
Reviewing Historical Trends: Slowest Page Response 8-8
Metrics and Thresholds 8-9
Changing a Threshold 8-10
Changing Multiple Thresholds 8-11
Copying Thresholds to Another Target 8-12
Metric Baselines 8-13
Creating Metric Baselines 8-14
Automating Responses to Alerts 8-15
Defining a Response Action 8-16
Defining a Response Action for Target Down 8-17
Notifications 8-18
Accessing Sent Notifications 8-19
Reviewing Your Notification 8-20
Blackouts 8-21
Creating a Blackout 8-22
Reviewing Blackouts 8-23
Summary 8-24
Practice 8 Overview: Monitoring the Ecosystem 8-25
9 Using the Job System
Objectives 9-2
Jobs 9-3
Job Types 9-4
Viewing Job Activity 9-5
Creating a Host Command Job 9-7
Creating a SQL Script Job 9-8
Accessing Jobs 9-9
Runs Versus Executions 9-10
Reviewing Job Execution Results 9-11
Job Library 9-13
Searching for Jobs 9-14
Jobs Purge Policy 9-15
Summary 9-17
Practice 9 Overview: Using the Job System 9-18
10 Host Monitoring and Management
Objectives 10-2
Doing More with More 10-3
Monitoring Hosts with Grid Control 10-4
What Is a Host? 10-5
Viewing a List of Hosts in Your Grid 10-6
Host Home Page 10-7
Viewing Performance Information 10-8
Using Metrics to Monitor Host Performance 10-9
Changing Thresholds of Predefined Metrics 10-10
Viewing a List of Targets 10-11
Viewing Host Configuration 10-12
Comparing Hosts 10-13
Comparing Hosts: Different 10-14
vi
Using Telnet to Verify Host Information 10-15
Summary 10-16
Practice 10 Overview: Host Monitoring and Management 10-17
11 Database Monitoring and Management
Objectives 11-2
Ways to Manage Your Database 11-3
Grid Control Versus Database Control 11-4
Accessing Grid Control Versus Database Control 11-6
Using Database Groups to Manage Multiple Database Targets 11-7
Comparing Metrics of Multiple Database Targets 11-8
Database Home Page 11-9
Configuring an Oracle8i or Oracle9i Database Target 11-10
Administering Databases with Grid Control 11-12
Case Study: Managing by Exception 11-13
Case Study 11-14
Summary 11-18
Practice 11 Overview: Database Monitoring and Management 11-19
12 Application Server Management
Objectives 12-2
Managing Application Servers Using Grid Control 12-3
Grid Control Versus Application Server Control 12-4
Accessing Grid Control Versus Accessing Application Server Control 12-6
Application Server Control Tasks for Managing Application Servers 12-7
Administering the Application Server Instance 12-8
Reviewing the List of J2EE Applications 12-9
Centrally Managing Ports 12-10
Configuring Infrastructure Services 12-11
Topology Viewer 12-12
Deploying an OC4J Application 12-13
Practice 12a Overview: Deploying the Petstore Application 12-15
Reviewing Your Application’s Performance Metrics in Application Server
Control 12-18
Applications Deployed to the OC4J Instance 12-19
Viewing Log Files to Help Diagnose Problems 12-20
Grid Control Tasks for Managing Application Servers 12-21
Summary View of Application Servers from Grid Control 12-22
Performance Diagnosis with Diagnostic Drilldowns 12-23
Reviewing Historical Performance Data 12-24
Drill Down to OC4J Home Page 12-25
Drill Down to Applications 12-26
Drill Down to Applications Performance 12-27
Analyzing J2EE Diagnostic Reports 12-28
Example Report: Top Servlets 12-29
Using Groups to Manage Application Server Targets 12-30
Monitoring Performance Across Multiple Application Servers 12-31
Summary 12-33
Practice 12b Overview: Application Server Management 12-34
vii
13 Application Service Level Management
Objectives 13-2
Application Service Level Management 13-3
Monitor from the End User’s Viewpoint 13-4
Monitor from the Application Administrator’s Perspective 13-5
Application Administrator Requirements 13-6
Manage Systems Holistically 13-7
Manage Application Availability 13-9
Beacons 13-10
Define Availability 13-11
Monitor Application Performance 13-12
Monitor Transaction Response Time 13-13
Drill Down for More Transaction Details 13-14
Monitor End-User Response Times 13-15
Investigate URL Performance Bottlenecks 13-16
Analyze URL Performance 13-17
Diagnose Performance Problems 13-18
Interactive Transaction Trace 13-19
Diagnose Middle-Tier Performance Issues 13-20
Drill Down for Diagnostic Details 13-21
Analyze the Processing Call Stack 13-22
Correlate Performance 13-23
Application Service Level Management Requirements 13-24
Configuring Web Applications 13-25
Add a Web Application Target 13-26
Create Transactions 13-28
Create Beacons 13-30
Define Availability 13-31
Configure End-User Response-Time Monitoring 13-32
Configure OracleAS Web Cache Logging 13-33
Configure OracleAS Web Cache Logging (Optional) 13-34
Configure Middle-Tier Performance Monitoring 13-35
Enable OC4J Logging 13-36
Summary 13-37
Practice 13 Overview: Application Service Level Management 13-38
14 Oracle Collaboration Suite Management

Objectives 14-2
Using Grid Control and EM Website to Manage Oracle Collaboration Suite 14-3
Managing a Single Oracle Collaboration Suite Instance 14-4
Application Server Home Page 14-5
Grid Control Versus EM Website 14-6
Managing Oracle Collaboration Suite in Grid Control 14-7
Installing and Configuring Oracle Collaboration Suite in Grid Control 14-8
Organizing Oracle Collaboration Suite Components Using Groups 14-9
Using the OCSGroup Page 14-10
viii
Drill Down to Review the Alerts 14-11
Drill Down to Review Component Availability 14-12
Review Member Targets List 14-13
Monitoring Oracle Collaboration Suite Components 14-14
Email Component Home Page 14-15
List of Email Components 14-16
WebMail Web Application Page 14-17
Email Performance 14-18
Email IMAP Operations 14-19
Calendar Component Group Page 14-20
Calendar Web Application 14-21
Calendar Performance 14-22
Web Conference Component Group Page 14-23
Web Conference Web Application 14-24
Page Performance of Web Application 14-25
Summary 14-26
15 Managing Your Configuration

Objectives 15-2
Questions Administrators Ask Themselves 15-3
Analyzing Your Configuration 15-4
Viewing Configuration Information 15-5
Automatic Collection of System Data 15-6
Refreshing Collected Data 15-7
Reporting System Inventory 15-8
Drilling Down for Details 15-9
Searching Configurations 15-10
Comparing Systems 15-11
Reviewing Comparison Results 15-12
Tracking Historical Changes 15-13
Critical Patch Advisories 15-14
Applying Patches 15-15
Using the Patch Wizard 15-16
Using the Patch Wizard: Search by Criteria 15-17
Using the Patch Wizard: Evaluate the List of Patches 15-18
Using the Patch Wizard: Select Destination 15-19
Using the Patch Wizard: Set Credentials 15-20
Using the Patch Wizard: Stage or Apply 15-21
Using the Patch Wizard: Schedule 15-22
Using the Patch Wizard: Summary 15-23
Policy Management 15-24
Managing the Policy Library 15-25
Reviewing Policy Violations 15-26
Cloning an Oracle Home 15-27
Cloning a Database Instance 15-29
Cloning a Database Instance: Source Type 15-30
ix
Cloning a Database Instance: Source Working Directory 15-31
Cloning a Database Instance: Archiving Mode 15-32
Cloning a Database Instance: Select Destination 15-33
Cloning a Database Instance: Destination Options 15-34
Cloning a Database Instance: Schedule 15-35
Cloning a Database Instance: Review 15-36
Cloning a Database Instance: Viewing the Job Results 15-37
Summary 15-38
Practice Overview: Managing Your Configuration 15-39
16 Grid Control Security

Objectives 16-2
Grid Control Security 16-3
Enterprise Manager Framework Security 16-4
Securing OMA–OMS Communications 16-5
Accepting Secure Uploads 16-6
Configure Management Services 16-7
Test the Secure Upload Port 16-9
Configure Management Agents 16-10
Verify That Management Agents Are Secure 16-12
Managing Agent Registration Passwords 16-13
Refuse Nonsecure Uploads 16-14
Securing OMS–OMR Communications 16-16
Enable ASO for the OMR 16-17
Enable ASO for Each OMS 16-18
Enable ASO for the OMA 16-19
Securing Product Control Consoles 16-20
Working Through Firewalls 16-23
Configuring the OMA for Proxy Communication 16-24
Authenticating Grid Control Administrators 16-26
Oracle Single Sign-On 16-27
Configuring the OMS for SSO 16-28
Enterprise User Security 16-29
Configuring the OMS for Enterprise User Security 16-30
Demonstration 16-31
Summary 16-32
Practice 16 Overview: Grid Control Security 16-33
Practice 16: Grid Control Security 16-34
17 EM2Go
Objectives 17-2
Administer from Anywhere 17-3
EM2Go 17-4
Administering EM2Go 17-5
Navigating EM2Go 17-6
Target Home Pages 17-7
Administering Databases with EM2Go 17-8
x
Resolving Database Issues with EM2Go 17-9
Administering Hosts With EM2Go 17-10
Administering Application Servers with EM2Go 17-11
Summary 17-12
18 Extending and Customizing Grid Control

Objectives 18-2
User-Defined Metrics 18-3
User-Defined Operating System Metrics 18-4
Operating System Monitoring Scripts 18-5
Creating the User-Defined Operating System Metric 18-7
Database User-Defined Metrics 18-8
Creating the User-Defined Database Metric 18-9
Viewing User-Defined Metrics 18-10
Monitoring Custom Targets 18-11
Adding a Custom Target 18-12
Target-Type Metadata File 18-13
Target-Type Default Collections File 18-14
Validating New Target Definitions 18-15
Validating Target Definitions with iLINT 18-16
Adding New Target Instances 18-18
Enabling the Metric Browser 18-19
Producing Custom Reports 18-20
Base Views 18-21
Central Policy Views 18-22
Monitoring Views 18-23
Metric Data Retention 18-25
Inventory Views 18-27
Summary 18-29
Practice 18 Overview: Extending and Customizing Grid Control 18-30
Practice 18: Extending and Customizing Grid Control 18-31
19 High-Availability Options
Objectives 19-2
High Availability 19-3
Highly Available OMR 19-4
Configuring OMS Connections to a RAC 19-5
Highly Available OMS 19-6
Configuring OMA Connections to a Clustered OMS 19-7
Summary 19-8
20 Migrating to Grid Control

Objectives 20-2
Migrating to Grid Control 20-3
Deploying the Management Agents 20-4
Automating the OMA Installation 20-5
Postinstallation Requirements 20-7
xi
Migrate Existing Administrator Accounts 20-8
Summary 20-9
21 Putting It All Together

Objectives 21-2
Practice 21: Putting It All Together 21-3
Summary 21-5
Appendix A: Practice Solutions
Appendix B: Basic Linux and vi Commands
Appendix C: SQL Statement Syntax
Appendix D: Acronyms and Terms
Appendix E: Next Steps – Continuing Your Education
xii
Application Server Management
Copyright © 2005, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to do

the following:
• Identify the differences between Application
Server Control and Grid Control
• List the tasks that are performed using Application
Server Control
• Deploy a J2EE application
• List Application Server tasks that are performed
using Grid Control
• Review the historical performance data of your
application
• Compare the performance across application
servers
Objectives
This lesson explores the differences between Oracle Enterprise Manager 10g Application Server
Control and Oracle Enterprise Manager 10g Grid Control. You deploy a J2EE application using
Application Server Control and review its performance. You also evaluate the application
server’s performance over time and compare its metrics with other application servers in the grid.

Managing Application Servers Using
Grid Control
Grid Control Management
Repository
HTTP(s)
Management Services
(J2EE Web Application)
JDBC
HTTP(s) HTTP(s)
HTTP(s)
Management Management
Monitored Agent Management
Agent Agent
Targets
Application Application
Server Server
Control #1 Control #2
Monitoring Application Servers Using Grid Control

Oracle Enterprise Manager 10g Grid Control contains the Oracle Management Service and
Oracle Management Repository. From an application server point of view, the application
servers each have their own Application Server Control and are automatically discovered
through the Management Agent as monitored targets in Grid Control.
Communication between each tier is done via HTTP(s), which seamlessly enable any part of the
framework to work with and through firewalls that allow HTTP communications to pass through
them.

Grid Control Versus Application Server
Control
Feature Grid Control Application Server Control
Install Separate Application Server 10g
Management
Centralized No
Repository
One per host in One per Application Server

Management Agent
separate home 10g Home
Target Type Many Application Server
# of Targets Many One
Server Configuration No Yes
Application
Yes Yes
Configuration
Grid Control Versus Application Server Control

Application Server Control is installed and available with every Oracle Application Server 10g
installation except for the Identity Management Metadata Repository–only installation. The Java
version of DBA Studio is installed so that database administrators can manage the database.
Using Application Server Control, you can monitor and administer real-time performance for a
single Oracle Application Server 10g instance.
This table depicts some features of Application Server management and indicates whether Grid
Control and Application Control have those features.

Grid Control Versus Application Server
Control
Feature Grid Control Application Server Control
Application Server
No Yes
Farm/Cluster aware
Real-Time Monitoring Yes Yes
Groups Yes No
Historical Monitoring
Yes No
and Alerts
Application Service
Yes No
Level Management
Job System Yes No
Configuration Management Yes No
Mobil Access via EM2Go Yes No
Grid Control Versus Application Server Control (continued)

Within Grid Control, you can access and monitor multiple application server targets in real time,
and you can define groups that are comprised of multiple application server targets. For an
Oracle Application Server 10g instance, you can manage the application server using
Application Server Control and Grid Control concurrently.

Accessing Grid Control Versus
Accessing Application Server Control
You access Enterprise Manager differently depending

on whether you use Grid Control or Application Server
Control.
Example:
Host Grid Control URL Application Application Server
Server Instance Control URL
ashost1 http://<oms_host>.domain:7777/em instance1 http://ashost1.domain:1810
Instance2 http://ashost1.domain:1811
ashost2 http://<oms_host>.domain:7777/em instance3 http://ashost2.domain:1810
Accessing Grid Control Versus Accessing Application Server Control

To access all your application servers using Grid Control, enter the Grid Control URL
http://<oms_host>.domain:7777/em. For each host that has the Management Agent
installed, the application server automatically appears as an application server target.
To access each application server using Application Server Control, you access the URL
http://<ashost>.domain:1810, which shows you the Application Server Home page
for that particular Application Server instance only. If you have more than one application server
on a host, you are provided with another Application Server Control for that instance.
In the example in the slide, there are two hosts. For ashost1, you have two Application Server
instances, each with its own Application Server Control URL. The second host, ashost2, also
has its Application Server Control URL. All Application Server instances can be centrally
monitored through Grid Control with the same URL.

Application Server Control Tasks for
Managing Application Servers
The following tasks can be performed using

Application Server Control:
• Starting and stopping the application server and
its components
• Enabling and disabling application server
components
• Modifying server configurations
• Deploying and maintaining J2EE applications
• Others
Application Server Control Tasks for Managing Application Servers

Using Application Server Control, you can perform many administration tasks for one particular
Application Server instance. In this course, you examine some of these tasks. More details are
discussed in the Oracle Application Server 10g: Administration I course.

Administering the
Application Server Instance
Application Server Instance Home page:
Administering the Application Server Instance

The Application Server Instance Home page in Application Server Control provides access to
real-time performance monitoring and administrative features for a single instance of Oracle
Application Server. From the Application Server Home page, you can:
• Check the status of the Application Server instance and all of its components
• Start and stop the application server
• Enable and disable components
• Check resource usage
• Configure components
• Create and delete Oracle Application Server Containers for J2EE (OC4J) instances
For details about how to perform each of these preceding tasks, see the Oracle Application 10g:
Administration I course.

Reviewing the List of J2EE Applications
J2EE Applications property page
Reviewing the List of J2EE Applications

The J2EE Applications property page displays a list of all applications deployed across all
OC4Js for this Application Server instance. To obtain more information about an application,
you can select either the J2EE application or the OC4J instance to view more details.
• From the Application home page, you can monitor the performance, Web modules, and
EJB modules of the application. You can also use the Application home page to access
administrative features, such as application properties, resource, and security.
• From the OC4J home page, you can monitor the performance of the OC4J instance and use
the Administration links to configure the OC4J server or deploy additional applications.

Centrally Managing Ports
Ports property page
Centrally Managing Ports

The Ports property page lists all the ports that are currently in use by the components of this
Application Server instance. This page allows you to centrally view and modify port values
across the Application Server components and also understand dependencies between ports
across components. This is important when you are troubleshooting port conflicts among the
various Application Server components.
When you install Oracle Application Server, the installation procedure assigns specific port
numbers to each Application Server component that you install. In most cases, the port numbers
assigned to a component are within a predefined range that has been reserved for the component.
If you later need to modify the ports for a particular component, you must:
• Be sure that you are assigning a port number that is not already in use. If one or more
components are assigned the same port number, the components may not start or the
components could malfunction after startup.
• Be sure that all port dependencies have been satisfied. In other words, you must make sure
that the necessary changes are made to other components that may rely on the port number
you are changing.
To change a port, click the pencil icon in the Configure column for the port you want to change.
Review the text on the screen or click Help to obtain information related to port changes.

Configuring Infrastructure Services
Infrastructure property page
Configuring Infrastructure Services

The Infrastructure property page provides information about the relationship between this
instance of Application Server and the rest of your enterprise. This page allows you to configure
or change infrastructure services such as Oracle Identity Management (OID), Single Sign-On
(SSO), and the metadata repository that is associated with the Application Server instance.
• Identity Management: You can configure OID during the installation or you can
configure it later. Identity Management provides Internet Directory and Single Sign-on
capabilities.
• Central Management: You can centrally manage this Application Server instance with a
separately installed Oracle Management Agent.
• Oracle Application Server clusters managed using Database Repository: You can
configure a J2EE and Web Cache instance so that it uses a metadata repository. When you
use a metadata repository, you can take advantage of Oracle Application Server clusters.
Note: This section appears only if you have installed the J2EE and Web Cache Oracle
Application Server installation type.

Topology Viewer
Topology Viewer
Topology Viewer is a graphical, real-time view of application server processes managed by
Oracle Process Manager and Notification (OPMN). Topology Viewer, available on the Oracle
Technology Network (OTN), is an add-on feature of Oracle Enterprise Manager 10g Application
Server Control. From Topology Viewer, an administrator can perform the following:
• View status of the Application Server Farm, Clusters, and member components.
• Start/Stop/Restart Application Server processes.
• Monitor performance across the Application Server environment.
• Drilldown to component home pages for more details.
After installation, you can access either a JSP version or applet version of the Topology Viewer.
Both versions offer the same functionality (though in a slightly different format) with one
exception - only the applet version of Topology Viewer allows you to customize the colors used
within the topology interface.
To access the Topology Viewer, enter the following URL:
http://<ashost>:1810/emd/console/ias/topology/topologyjsp
or
http://<ashost>:1810/emd/console/ias/topology/topologyapplet
From either version of the Topology Viewer, you can see a clear visualization of your
Application Server environment. You can scroll down to see critical performance information for
the Application Server components.
Deploying an OC4J Application
• In this course, you perform the following tasks

using Application Server Control:
– Create an OC4J instance.
– Add a data source.
– Deploy a J2EE application.
• After the application is deployed, you can monitor
its performance using Application Server Control
or Grid Control.
Deploying an OC4J Application Using Application Server Control

To monitor the performance of an OC4J application, you need to deploy the application using
Application Server Control. The tasks are as follows:
• Create an OC4J instance
• Add a data source
• Deploy the J2EE application
To create an OC4J instance:
1. On the Application Server Control Home page, click Create OC4J Instance.
2. Enter an OC4J instance name, and then click Create.
3. Click OK.
To add a data source:
1. Select the OC4J instance where you want to deploy your application.
2. Click the Administration tab.
3. Under Application Defaults, select Data Sources.
4. Click Create.
5. Enter the application data source information, and then click Create.
Note: Your application may require the creation of more than one data source.

Deploying an OC4J Application Using Application Server Control (continued)
To deploy the J2EE application:
1. From the OC4J instance, click Applications.
2. Click Deploy EAR file.
3. Click Browse and select the .ear file of the application you want to deploy. Enter an
application name and click Continue.
4. For the WebTier URL Mapping, enter a slash (/) and then a name (for example: /estore),
and then click Next.
5. If needed, enter a different JNDI location for each resource reference, and then click Next.
6. Select the User Manager option that you want, and then click Next.
7. Review your entries and click Deploy.
8. After your application is successfully deployed, click OK.

Practice 12a Overview:
Deploying the Petstore Application
This practice covers the following topics:

• Creating a Petstore OC4J instance
• Adding three data sources for the Petstore
application
• Deploying the Petstore application
• Testing the Petstore application

Practice 12a: Deploying the Petstore Application
Background
In this practice, you deploy the Petstore application using Application Server Control.
Tasks
• Create a Petstore OC4J instance
• Add three data sources for the Petstore application
• Deploy the Petstore application
• Test the Petstore application
1. Create an OC4J instance called Petstore.
2. Start the Petstore OC4J instance
3. Create three data sources:
Name: InventoryDB
connection-driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@<yourdbhostpc>:1521:orcl
username=estoreuser
password=estore
location=jdbc/InventoryDataSource
xa-location=jdbc/xa/InventoryXADS
ejb-location=jdbc/InventoryDB
Name: EstoreDB
username=estoreuser
password=estore
location=jdbc/EstoreDataSource
xa-location=jdbc/xa/EstoreXADS
ejb-location=jdbc/EstoreDB
Name: SignOnDB
username=estoreuser
password=estore
location=jdbc/SignOnDataSource
xa-location=jdbc/xa/EstoreXADS
ejb-location=jdbc/EstoreDB
4. Deploy the /home/oracle/labs/petstore.ear file with the URL mapping

/estore.

Practice 12a: Deploying the Petstore Application (continued)
5. Create the estoreuser user. Enter the following command:
grant connect, resource to estoreuser identified by estore;
6. Access the Petstore application and load the application data using the URL
http://<appserver_host>:7778/estore.

Reviewing Your Application’s Performance
Metrics in Application Server Control
Real-time metrics are provided on the OC4J Home page.
Reviewing Your Application’s Performance Metrics in Application Server Control

The OC4J Home page provides a single view of the instance and a launch point for
administration of the various elements in the J2EE application environment. This page contains
the following information:
• Status of the OC4J on which applications are deployed
• Amount of CPU and memory that the OC4J is using
• JDBC usage: connections and transaction information
• Response of servlets, JSPs, and EJBs

Applications Deployed
to the OC4J Instance
The Applications property page displays applications

that are deployed to the OC4J instance.
Applications Deployed to the OC4J Instance

The Applications property page displays a list of all OC4J applications that are deployed to the
OC4J instance, including the status of each application measured by the number of active
requests and average processing time. This page is used to deploy, view, and maintain
applications.
You can perform the following tasks from this page:
• Deploy a new OC4J application: An intuitive, easy-to-use wizard steps you through the
application deployment process.
• Deploy a WAR file: You can specify a WAR file, add the necessary structure required to
convert it to an EAR file, and then deploy it to OC4J. The WAR file deployment tool
deploys the resulting WAR file to one or more OC4J instances. The WAR deployment tool
supports cluster deployment, which enables an archive to be simultaneously deployed to all
the OC4J instances defined within a cluster.
• Edit, redeploy, or undeploy an OC4J application
You can click any application name in the Applications table for more specific information about
the selected application.
Click on the application to get specific metric information and more information about web and
EJB modules associated with the application.

Viewing Log Files
to Help Diagnose Problems
You can view the log files for Application Server
components.
Viewing Log Files to Help Diagnose Problems

Log files assist in monitoring system activity and in diagnosing system problems. The View
Logs page is a valuable tool for locating and viewing Oracle Application Server component log
files.
To view the logs:
1. Select Logs at the bottom or top of the page.
2. Depending on where you selected the Logs link, the component for which you want to
view logs may or may not be selected. Verify that the components you want are selected,
and then click Search.
3. Select the log file that you want to view.
The Log Viewer is part of the log file management features of Oracle Application Server. In
addition to viewing the content of specific log files from the View Logs page, you can also use
related pages to enable and start the Log Loader, which saves diagnostic information from
specific component log files in the Log Repository.

Grid Control Tasks for Managing
Application Servers
The following tasks can be performed using Grid

Control:
• Monitoring distributed Application Server
instances centrally
• Analyzing historical trends using performance
data in the Management Repository
• Monitoring performance with automated alert
notifications and J2EE diagnostics
• Monitoring Web application transaction
performance and tracing, and client response time
• Accessing Application Server Control to perform
administration tasks
Grid Control Tasks for Managing Application Servers

Using Grid Control, you can perform many monitoring and analytical tasks for all monitored
targets from any browser. In this section of the lesson, you examine some of these tasks. The task
Monitoring Web Application transaction performance and tracing, and client response time,
however, is discussed in the next lesson, Application Service Level Management.

Summary View of Application Servers
from Grid Control
On the Targets tab, select Application Servers.
Summary View of Application Servers from Grid Control

You can view and compare various metrics of multiple Application Server targets by selecting
the Application Servers subtab on the Targets tab. If you want to customize the performance
metrics that are displayed on this summary view, select Preferences > Column Metrics.

Performance Diagnosis
with Diagnostic Drilldowns
The Application Server Home page provides a
rolled-up view of the performance of the Application
Server instance.
Performance Diagnosis with Diagnostic Drilldowns

Each monitored target has a home page that provides consolidated performance and availability
information for that target. If the target consists of other components, its home page provides the
rolled-up view of the status and performance of the target as a whole, and includes aggregate
performance of each component.
For example, the home page for an Application Server instance provides a rolled-up view of the
performance of that instance, including the aggregate performance of each of its components.
You can easily identify components that may require diagnostic investigation and drill down into
those components for more detailed performance information.

Reviewing Historical Performance Data
On the Application Server Home page, click

Performance and then select a time period.
Reviewing Historical Performance Data

Understanding how your application server has performed over the last 7 to 31 days provides
useful information for analyzing trends. This can help you figure out where changes can be made
to optimize performance of your application server. Information that is available from the
Performance property page includes:
• How much memory and CPU the application server uses on the host computer over time
• A set of key response and load metrics that help you determine how the Web Cache, Oracle
HTTP Server, and OC4J components perform over time
To view historical performance data about your application server:
1. On the Targets tab, select Application Servers.
2. Select your application server from the list.
3. Click the Performance property page.
4. Select the time period you are interested in analyzing from the View Data list.
5. Click each chart to drill down and analyze the information in more detail.

Drill Down to OC4J Home Page
The OC4J Home page provides a roll-up of status and

performance metrics for the container and its
applications.
Drill Down to OC4J Home Page

The OC4J Home page presents a roll-up of status and performance metrics for the container and
its applications, providing information such as:
• How long the container has been running and what applications are active
• Container resource usage (such as the percentage of CPU and memory resources being
consumed)
• Volume and average processing time of application requests and transactions
The composite data presented in the roll-up is broken down for each deployed application. You
can easily determine which application is incurring the highest volume of requests or longest
response time.

Drill Down to Applications
Click the Applications property page to see the list of

active applications.
Drill Down to Applications

The composite data presented in the roll-up is broken down for each deployed application. You
can easily determine which application is incurring the highest volume of requests or longest
response time.

Drill Down to Applications Performance
Select the active application to view its performance.
Drill Down to Applications Performance

You can drill into the application to view the performance of individual objects such as servlets
and EJBs. This may help you isolate the source of the problem more easily.

Analyzing J2EE Diagnostic Reports
Analyzing J2EE Diagnostic Reports

In the Related Links section of the OC4J instance Performance page, you see a list of links to a
series of reports: response servlets and JSPs; response EJBs; top servlets, JSPs, and EJB methods;
and Java Virtual Machine (JVM) and datasource metrics.
Click a link to view metric information grouped around a specific category. For example, the
Top JSPs page displays the most requested or slowest-to-process JSPs for the OC4J instance.

Example Report: Top Servlets
Example Report: Top Servlets

Top Servlets displays those servlets that are the most requested or the slowest to process. You
can select the period to view data. Note that this page displays only real-time data.
In the the View list, you can choose the following:
• Requests Processed: Displays the servlets that have been requested the most times
• Processing Time: Displays the servlets that have taken the most time to process

Using Groups to Manage
Application Server Targets
Groups manage a set of Application Server targets
cohesively as one unit.
Using Groups to Manage Application Server Targets

Groups manage a set of Application Server targets cohesively as a single unit. Groups are useful
for an integrated view of all the information about the application servers for which a particular
administrator is responsible.
On the Group Home page, you can quickly view key information about members of a group,
eliminating the need to navigate to individual member targets to check on availability and
performance. You can view the entire group on a single screen and drill down to obtain further
details.

Monitoring Performance Across
Multiple Application Servers
Monitoring Performance Across Multiple Application Servers

Using groups, you can compare multiple targets against each other in the context of one metric
so that you can see in one chart how the targets are performing. Then you can view different time
periods to see the performance over time and the trends that are occurring. In addition, you can
grant privileges, create a blackout, or set notification rules on a group rather than each target
individually.
Because all targets cannot be shown in a single graph, you must select the targets whose metric
values are displayed in the chart. The targets can be chosen in the following ways: the first five
targets (in alphabetical order), peak targets (those with the highest value for the metric), targets
with the highest average for the metric, targets with the lowest average for the metric, or any set
of selected targets.
If you suspect a potential performance problem with a particular target, you may choose to chart
that target as well as the group’s average and maximum (or minimum) values to determine how
the target compares with respect to other members of the group.
You can also change the chart to display any other metric that applies to the targets in the group.
If the metric you choose was not selected as a summary metric during group creation, then the
group’s average, minimum, and maximum values for that metric are not calculated and therefore
are unavailable for the chart.

Monitoring Performance Across Multiple Application Servers (continued)
To compare performance for multiple application servers, you need to perform the following
tasks:
• Create a group and include the application servers that you want to compare
• View the group’s performance
• Compare metrics for a particular metric

Summary
In this lesson, you should have learned how to:

• Identify the differences between Application
Server Control and Grid Control
• Deploy a J2EE application using Application
Server Control
• Review the historical performance data of your
application
• Compare the performance across application
servers

Practice 12b Overview:
Application Server Management

• Viewing historical performance
• Creating a group
• Comparing metrics across application servers

Practice 12b: Application Server Management
Background
As an administrator for your application server, you need to know how it performs over time and
how it compares to the performance of other application servers.
Tasks
• View historical performance
• Create a group
• Compare metrics across application servers
1. Connect to Grid Control as administrator Team#_A.
2. For your application server, what is the average CPU usage for the past 24 hours?
3. What is the average memory usage for the past seven days?
4. Create a group called asgroup# and include your assigned application server and another
one in the class. Include all metrics available.
5. Compare CPU usage metrics across application servers.
6. Which servlet in the Petstore application has the highest number of process requests?

Application Service Level Management

Objectives

the following:
• Monitor the availability and performance of Web
applications
• Diagnose application problems using ASLM
• Configure Grid Control to provide:
– Availability management
– Performance management
– Diagnostic services

With Application Service Level Management (ASLM),

you can:
• Manage application availability
• Monitor application performance
• Diagnose application response-time issues

When you implement ASLM, you can:
• Manage whether or not a Web application is considered available
• Monitor performance issues
- Sample, record, and analyze information about the response times that your
application’s end users are experiencing
- Record step-by-step instructions for completing typical user transactions
- Periodically test those transactions to monitor response time and ensure that the
transactions can be completed successfully
• Diagnose response-time issues in your middle tier, drilling down from the end-user view of
a URL to locate problems with individual Java Server Pages (JSP), servlets, Enterprise Java
Beans (EJB), and Java Database Connectivity (JDBC) calls that service that URL

Monitor from the End User’s Viewpoint
• End users don’t care if the:

– Database is up
– Web Cache is functioning
– HTTP Server is working
– J2EE container is running
• End users care if they can:
– Access applications
– Complete transactions
– Receive expected application
response times
Monitor from the End User’s Viewpoint

From the end users’ viewpoint, a system is operational if they can connect, log in, and complete
transactions. If they can’t use an application, the application is down.
From the end users’ viewpoint, an application does not perform well if they don’t get their pages
back quickly. It doesn’t matter that the database is tuned to perfection or the HTTP server is
blindingly fast. The only thing that matters to end users is that they get the pages they need as
quickly as they are used to getting them.
Grid Control gives you the capability to administer your systems from the end users’ perspective.

Monitor from the
Application Administrator’s Perspective
Administrators care if:

• The application and any of its system components
are not available
• The application and any of its system components
are performing poorly on the server
• Downtime or poor application performance is
affecting end users
Monitor from the Application Administrator’s Perspective

The application administrator’s job is on the line if the application and any of its system
components are not available or are performing poorly, or if the end user is experiencing poor
performance.

Application Administrator Requirements
Administrators must:
• Be alerted in advance before problems seriously
affect users
• Understand the impact of performance problems
on end users
• Quickly diagnose problems
Application Administrator Requirements

As an application administrator, you must be alerted through advance notifications before
problems can affect your users. You must understand the effect of performance problems on end
users. Most importantly, you must be able to diagnose problems quickly and, in turn, resolve
them.

Manage Systems Holistically
Administer the grid holistically with ASLM:

• Monitor the end user’s view of an application
• Correlate performance issues between all
components of an application
• Trace transactions and URLs through the entire
stack rather than in only a single component
Manage Systems Holistically

From a business standpoint, it does not matter if 99% of the IT infrastructure supporting an
application is functioning perfectly if the 1% that is down causes the application to be
unavailable for use. Administrators often fall into the trap of managing each of their application
servers, databases, and host servers as individual components instead of looking at the big
picture.
One reason administrators have tended to treat their systems as separately managed pieces is that,
prior to Grid Control, there really was no easy way to holistically manage performance and
availability at the application level. Each piece of the infrastructure had its own stand-alone
management tool. When users complained of slow performance (or, worse, of an application
being down), it was difficult to establish where the performance degradation originated—often
leading to accusations of blame among different administrators.
Grid Control changes that. With Grid Control, you define Web applications as managed targets.
As part of a Web application’s definition, you specify the component targets used to deliver the
application. When performance problems arise, Grid Control uses its knowledge of component-
to-application relationships to correlate metrics between different components so that you can
match a change in application response time to performance variations on different servers and
services that provide the application.

Manage Systems Holistically (continued)
The true measure of an application’s availability is the end user’s ability to complete work
within the application. With Grid Control, you can create and monitor transactions.
A transaction is simply a series of operations (URLs and user actions) that constitute a business
process or task. With Grid Control, you can record the steps used to complete a transaction, store
the recording, and schedule periodic replays of the transaction. During the replay, the transaction
is automatically stepped through URL by URL, duplicating the actions that an end user would
perform. Grid Control monitors the response time of each screen and the success of the overall
transaction. If transactions fail or if response time exceeds a threshold limit, Grid Control can tell
you that there is a problem.

Manage Application Availability
You can periodically probe an application to ensure

that it can complete business-critical transactions.
Manage Application Availability

Grid Control tests each monitored Web application periodically to ensure that the application can
complete a user transaction. In addition to testing for the success of the transaction, Grid Control
records the time it takes for the application to return a response.
A Web application’s home page lets you see the most critical information at a glance. The page
contains status information (up, down, or status pending), availability information, the
application’s home page URL and where the URL is being tested from, and a graph of the
application’s response time.
Beneath the status information is a list of alerts generated by the application (like any managed
target, the Web application includes monitored metrics for which you can set critical and
warning threshold values). In addition to alerts that are generated by the Web application, there
is a list of related alerts from all components servicing the application.

Beacons
Monitor availability from your key user communities:
Beacons
Beacons are a function of the Management Agent that has the responsibility of replaying
transactions at specified intervals. In addition, beacons measure the performance and response
times of the transaction from that physical beacon location.
Grid Control makes it easy to stage beacons in geographical areas where you have a
concentration of users. Beacons monitor transactions, reporting on transaction availability and
response time.
Comparing response times from different beacons helps you gauge the effect of network latency
and other network connectivity issues. This may make the application seem to be unavailable or
poorly performing from your end users’ viewpoint even though performance in the data center is
fine.

Define Availability
Define application availability based on a key business

transaction that is tested from critical end-user
communities:
Define Availability
Availability and response-time definitions differ from one Web application to another. In some
cases, the ability to access a static page may be the most critical measure of performance and
availability. In others, the ability to complete a complex multistep transaction may be the key.
With Grid Control, you can easily record and monitor multioperation transactions that model the
way your end users work. Grid Control lets you define the transaction that is most important to
you and your end users. Availability is defined by the key availability transaction and its ability
to be played successfully from at least one key user community or beacon. Administrators have
the flexibility to define what availability means for their application by defining the
representative availability transaction and the beacons from which availability is determined. If
you don’t specifically choose a transaction to define availability, Grid Control uses the
application’s home page by default. If beacons are not explicitly assigned to the Web application,
there is always a local beacon running the transaction by default. The local beacon is defined by
the monitoring agent as selected by the administrator when creating the Web application using
the wizard. The local beacon or the designated monitoring agent typically should be the beacon
or agent that is as close to the application as possible.

Monitor Application Performance
Monitor an application’s performance from different

viewpoints:
• Individual transaction performance
• End-user response times
• Application system component level
Monitor Application Performance

Grid control monitors an application’s performance from several different viewpoints.
• Individual transaction performance: While only one key transaction is used to determine an
application’s availability, you can define and monitor other transactions that are important
to your application. When response-time thresholds have been exceeded, Grid Control can
alert you to problems with any transaction.
• End-user response times: Grid Control also monitors the actual end-user experience.
• Application system component level: Because of the integration of ASLM with Enterprise
Manager 10g system-monitoring capabilities, you are able to monitor the individual
components that make up the Web application at the system level.

Monitor Transaction Response Time
Monitor Transaction Response Time

For each transaction you choose to monitor, Grid Control tracks:
• Status of the transaction (capability to complete all of the steps)
• Total time to complete the transaction
• Average response time for the pages in the transaction
• Response time for the slowest page in the transaction
• Transaction performance from various user communities or beacons

Drill Down for More Transaction Details
View detailed current and average metric values:
Drill Down for More Transaction Details

Drill down into a transaction for more details on performance and response time.
The Transaction Detail page shows you time-based graphs of key response and availability
metrics, as well as summary charts of average and current values.

Monitor End-User Response Times
Sample actual end-user response times:

• Identify impact of poorly performing URLs
• Identify slowest pages of your application
• Analyze response time by page, domain, region,
visitors, Web server, or a combination of these
Monitor End-User Response Times

Transaction performance metrics give you insight into an application’s performance but may not
show the actual response time that is observed by end users.
Most enterprise Web content delivery systems use some form of page caching as the entry point
to the application server. These caching systems improve the end user’s experience by
decreasing system response time for repeatable, frequently accessed content. Oracle Application
Server uses OracleAS Web Cache.
If your application is working with OracleAS Web Cache, you can monitor response times from
the end user’s viewpoint.
In the example shown in the slide, end users see a relatively slow response time from
/petstore/control/product. This URL is accessed relatively infrequently (only twice
in this system).
This type of information focuses your tuning and troubleshooting efforts on the things that affect
your end users the most. Improving the performance of /petstore/control/product
would benefit a very small percentage of the user base, but improving the performance of
/petstore/control/category would have a much greater impact.

Investigate URL Performance Bottlenecks
Drill down into a URL for more information:
Investigate URL Performance Bottlenecks

Clicking an end-user response URL takes you to detailed information about the URL, including
the response-time history, distribution of responses across your farm of Web servers, and load on
each individual Web server.
The detail page also provides statistical information on the URL to help you easily identify cases
where performance has degraded.

Analyze URL Performance
Analyze URL Performance

From the URL detail page, you may choose to analyze end-user response times even further.
Click Analyze More to view a breakdown of response and server time.
Then click Analyze More to view response time statistics by domains accessing your system, by
geographical regions, by Web servers, or even by individual visitors. With the Analyze feature,
you can view the response times experienced by a specific set of visitors within one or more
filtering axes such as URL, domain, region, visitor, and Web server.
This type of information can help you spot variations across different network topologies.

Diagnose Performance Problems
Interactive transaction trace:

• Trace transactions on demand
• Find transaction performance bottlenecks quickly
Middle-tier performance drilldowns:
• Evaluate historical J2EE activity breakouts
• Click to drill down to EJB and SQL levels
• Correlate performance
Diagnose Performance Problems

Grid Control provides interactive transaction tracing and middle-tier drilldown capabilities that
help you diagnose problems quickly so that you can fix the problem within an acceptable time
period.

Interactive Transaction Trace
Interactive Transaction Trace

Play transactions with trace enabled to step through a transaction page by page. During the
transaction replay, detailed information on response and processing time is collected and
presented for review when the transaction is complete.
Note: Recording and tracing transactions require the Transaction Recorder, which runs on
Microsoft Internet Explorer 5.5 or later versions.
In the example shown in the slide, you play the transaction with trace, which provides detailed
information about the transaction after execution. You can evaluate data in the Server Time
Details table and sort by JDBC/SQL time. You can then drill down to identify which SQL
statements are taking the most time and causing bottlenecks.

Diagnose Middle-Tier Performance Issues
Diagnose Middle-Tier Performance Issues

Grid Control collects detailed J2EE activity data each time a user accesses a page (or URL) of
your Web application. The processing times reflect the time needed to prepare Web application
content in the middle tier, such as time spent in the application server and back-end data sources.
This data can be used to identify the slowest and most popular URLs and enable you to focus
development efforts on problem pages that have the greatest customer impact.
You can drill down and examine a URL to determine the processing time and additional
performance details for each servlet, JSP, JDBC, and EJB component, down to the root cause of
the problem at the SQL statement level. You can also correlate the processing time and load with
other factors such as CPU, memory, I/O, and response times and load. This correlation also
includes other metrics of the components that make up your Web application. Details of the full
call-processing stack of every accessed URL is also provided for rapid root-cause diagnosis.
In the example in the slide, 23% of the response time for this URL is devoted to processing
JDBC requests. Click the JDBC time to drill into the details.

Drill Down for Diagnostic Details
Drill Down for Diagnostic Details

Click the portion of the processing time that has the greatest impact (in this case, JDBC). You
find that there is a single data source being used for this transaction and that the majority of the
processing time is being spent on connecting to the data source.
Click the top SQL statement that is consuming the highest percentage of processing time. If the
problem was with SQL time, this page also lists the individual SQL statements being submitted
along with the processing time for each statement. With this information, a database
administrator can tune the statement performance (perhaps with the addition of an index, the
reorganization of a table, or partitioning) to reduce the processing time.

Analyze the Processing Call Stack
Analyze the Processing Call Stack

Selecting the Processing Call Stack reveals a step-by-step chart of the different calls made to
render the URL. This chart gives you even more information to help you select the correct areas
to tune or troubleshoot.
In the example in the slide, the servlet, JSP, JDBC and actual SQL statements are revealed in
addition to statistics for each call. The majority of the processing time is spent servicing JDBC
connections.
If you click any of the component calls, you drill down to even more detail about the call along
with (in most cases) context-sensitive advice about how to improve performance.

Correlate Performance
Compare performance metrics against each other on a

sliding time scale:
Correlate Performance
Click Correlate Performance to compare performance metrics against each other on a sliding
time scale. Select the metrics you want to correlate and compare effects with potential causes
(such as a peak in CPU utilization) for a particular host.
This ability to correlate performance details between the different components servicing an
application is crucial to successfully tuning or troubleshooting complex applications.

Requirements
Transaction performance monitoring:

• Microsoft Internet Explorer 5.5 (or later versions)
for the transaction recorder
End-user performance monitoring:
• OracleAS Web Cache 9.0.2, 9.0.3, or 9.0.4
Interactive transaction tracing and middle-tier page
performance:
• Oracle Application Server 9.0.4
Application Service Level Management Requirements

In order to record and playback transactions, you need to have Microsoft Internet Explorer 5.5
(or later versions).
To monitor end-user performance, you need OracleAS Web Cache 9.0.2, 9.0.3 or 9.0.4
Oracle Application Server 9.0.4 is needed for interactive transaction tracing and middle-tier
performance.

Configuring Web Applications
To configure a Web application for monitoring:

1. Create the Web application.
2. Create transactions (optional).
3. Create and assign beacons to Web applications
(optional).
4. Define availability (optional).
5. Configure end-user response-time monitoring
(optional).
6. Configure middle-tier performance
monitoring (optional).
Configuring Web Applications

In this section, you examine the steps that are required to create and configure a Web application
to monitor the performance of an application and diagnose performance problems quickly.

Add a Web Application Target
Add a Web Application Target

To add a Web application target:
1. Click Web Applications on the Targets home page, and then click Add to invoke the Create
Web Application Wizard.
2. Enter the URL for the Web application’s home page. If necessary, enter information about
the proxy server needed to reach the Web application’s home page. Click Next.
Note: It is a good practice to test this URL. Copy it to a browser and verify that you can
access the application prior to clicking Next.
3. Add the components used to deliver the Web application. The component list should
include all components used to service the application, including OracleAS Web Cache,
Oracle HTTP Server, OC4J, Database, Database Listener, and any infrastructure
components such as Oracle Internet Directory and Single Sign-On. You must enter at least
one component. If you are monitoring a Web application not hosted by your systems,
simply choose an agent to perform the monitoring, and then click Next.
4. Choose a monitoring agent. The wizard offers you a choice of all agents servicing the
application’s components. Choose an agent that is physically collocated with the majority
of the application’s components, and then click Next.
5. Review the summary and click Finish to create the Web application.

Add a Web Application Target (continued)
After the Web Application is added, Grid Control immediately begins monitoring the homepage
URL, tracking availability and response-time metrics for the home page as a single-page
transaction. It may take between 5 and 15 minutes for Grid Control to collect enough
information about the new Web application to determine its status and begin presenting
response-time metric data.
In some cases, there are no other configuration steps required. For example, you may choose to
monitor the URL for an application not hosted on your own servers. In most cases, you can
continue configuring the Web application to include middle-tier and end-user performance
monitoring. You do not need to wait for Grid Control to confirm the Web application’s status
before continuing.

Create Transactions
Create and monitor transactions that model end-user

actions:
Create Transactions
You may choose to monitor application transactions to track both response time and the
availability of the transactions. To add monitored transactions to your Web application:
1. Connect to Grid Control using Microsoft Internet Explorer 5.5 or later. The creation of a
Web transaction uses the Transaction Recorder, which requires APIs contained in Internet
Explorer and not available from other supported browsers such as Mozilla or Netscape.
2. Navigate to your Web application target, click Transaction Performance, Manage
Transactions, and then click Create.
3. Enter a name for the transaction. This name should reflect the type of transaction being
tested. You may also choose to enter a description of the transaction. Click Next.
4. Record your transaction. Click Start to open a new browser and begin recording. Using the
new browser window, step through the application as you would expect a customer to do. If
your application requires authentication at some point, you should ensure that there is a
dummy user for the transaction to log in as (Petstore has a dummy user, or credit card,
already created). If you have logged in, make sure that you log out as well in the
transaction; otherwise, you may have too many sessions open. When the transaction is
created, click Stop to close the transaction window, and then click Verify to check the steps
you just recorded.

Create Transactions (continued)
When you click verify, you see a new browser window open and step through the
transactions you recorded. If you spot something that needs to be changed, click Start to
begin again. If you are satisfied with the recording, click Next.
5. Enter the interval that you want Grid Control to check this transaction with. You may also
enter warning and critical threshold values for this transaction. If this Web application uses
basic authentication, enter the username and password. Click Next.
6. Review the summary for your Web transaction and click Finish to add the transaction and
begin monitoring.
7. Select the new transaction and click Start to begin monitoring. Click OK and return to the
Transaction Performance page.
8. If you want to use this new transaction to define your application’s availability, click
Define Availability. Select the new transaction and click Apply.
Grid Control monitors as many transactions as you care to add, but it uses only one of them to
define availability. You should generally select a business-important, commonly used transaction
to define availability.
As always, it takes Grid Control several minutes to begin reporting response-time statistics for
the new transaction.

Create Beacons
Create beacons to test response time and availability:
Create Beacons
Beacons are components that test Web application transactions. Any Oracle management agent
that is associated with your grid can serve as a beacon.
To create a beacon, click Management System, Agents, and select the agent you want to
configure as a beacon. Select Beacon from the drop-down list of targets, and then click Go.
Simply give the beacon a name and enter any proxy information the beacon needs to reach the
targets that it is monitoring. Click OK, and the beacon is created.
To monitor a transaction from the new beacon, click Targets, Web Applications, and select the
Web application you want to monitor. On the Web application’s home page, click
Administration and Manage Beacons. Add or remove beacons that monitor the Web application.

Define Availability
Choose the beacons and transaction to define the

availability of the Web application:
Define Availability
The Define Availability page specifies which beacons are used to measure the availability of
your Web application and which transaction is used by the beacons to measure availability.
When a beacon is selected to define the availability of your Web application, response-time data
for the beacon appears in the chart on the Web application home page. If none of the selected
availability beacons can reach your Web application, Enterprise Manager generates an alert
indicating that the Web application is no longer available.
The transaction that you select in the Availability Transaction section of the page is the
transaction that each selected beacon runs automatically and continuously to determine the
availability of your Web application.

Configure End-User
Response-Time Monitoring
To configure end-user response-time monitoring:

1. Enable data collection.
2. Specify a collection interval.
3. Configure OracleAS Web Cache logging.
Configure End-User Response-Time Monitoring

If the Web application makes use of OracleAS Web Cache, you may want to collect information
about end users’ response time. To collect this information, click Page Performance on the Web
application’s home page, and then click Configure Web Application Web Caches.
Select Collecting and enter the interval at which you want metric data to be collected. The
interval should be small enough that your metric data’s granularity is suitable for tuning and
troubleshooting, but not so short that you adversely affect the amount of data to mine. In most
systems, an interval of five minutes or more is appropriate.
You should first configure the OracleAS Web Cache instances hosting this application to support
collection of end-user performance data.

Configure OracleAS Web Cache Logging

Open Web Cache Manager by clicking Enable Logging or by opening a new browser window
and accessing the Web Cache Control home page.
If you click Enable Logging, you should see the Web Cache home page. Click “Log on to Web
Cache Manager.” Authenticate using the Web Cache administrator user ID and password or the
same password that you would use for Application Server Control.
Click Access Logs (in the menu at the left of the page). Ensure that access logging is enabled (it
should be by default). Edit the access log configuration to ensure that the logs are written using
the Web Cache Log Format (WCLF). If you are not already doing so, you should also establish a
rollover policy for your access logs.
Click End-User Performance Monitoring (in the menu at the left of the page). Ensure that
performance monitoring is enabled for cache-specific and site-specific configurations.
Note: End-user response-time data is collected for only those sites that are specifically identified
in OracleAS Web Cache. If your users access your Web site with a site name that is different
from the site name specified here, no data for those collections are observed in Grid Control.

(Optional)
1. Stop OracleAS
Web Cache.
2. Archive any
existing logs
using the original
CLF format.
3. Start OracleAS
Web Cache.
$ cd $ORACLE_HOME/webcache/logs
$ mkdir archive
$ mv *log archive/.
Configure OracleAS Web Cache Logging (continued)

In Web Cache Manager, click Apply Changes to save any configuration modifications that you
have made.
You can optionally stop OracleAS Web Cache. Open a terminal session to the host servicing
OracleAS Web Cache. If you had to modify the log format (from CLF to WCLF), you should
archive the old logs so that end-user response-time analysis can proceed with correctly formatted
data. After the old logs have been archived, restart OracleAS Web Cache.
Exit Web Cache Manager and return to Grid Control. Click Apply on the Configure Web
Application Web Caches page. When asked if you want to proceed, click Apply again.
End-user response-time data starts to be collected. In order for a URL to appear with response-
time statistics, the URL must:
• Be accessed by users at least 10 times per hour
• Be accessed by a browser that is capable of rendering JavaScript
• Have been accessed before and after the hour mark (the hour mark depends on the roll-up
times and not necessarily on the hour)

Configure Middle-Tier
Performance Monitoring
To enable middle-tier performance monitoring:

1. Enable data collection.
2. Establish a collection interval.
3. Enable OC4J logging.
Configure Middle-Tier Performance Monitoring

If the Web application makes use of Oracle Application Server Containers for J2EE (OC4J), you
may want to collect information about the application’s performance within the J2EE container.
To collect this information, click Page Performance on the Web application’s home page, and
then click Configure Web Application OC4Js.
Select Collecting and enter the interval at which you want metric data to be collected. The
interval should be small enough that your metric data’s granularity is suitable for tuning and
troubleshooting, but not so short that you adversely affect the amount of data to be mined. In
most systems, an interval of about 60 minutes is appropriate. Note: in this course you use a
smaller value of 5 minutes so that the collection is done more quickly.
Do not click Apply yet. You should first configure the OC4J instances that are hosting this
application to enable logging.

Enable OC4J Logging
From the Application Server Control OC4J home page,
click Administration > Server Properties > Tracing
Properties.
Enable OC4J Logging

If you clicked Enable Logging, you should see the appropriate properties page. If you are
navigating through Application Server Control manually, open the OC4J home page, click
Administration, Server Properties, and then click Tracing Properties in the Related Links region
at the bottom of the page.
Select Enable JDBC/SQL Performance Details, Enable Interactive Trace, and Enable Historical
Trace. Click Apply and, when asked if you want to restart OC4J, click Yes.
After enabling OC4J logging for all OC4J components servicing the application, return to Grid
Control and click Apply on the Configure Web Application OC4J page. When asked if you want
to proceed, click Yes.
Like availability statistics, middle-tier performance monitoring statistics are not available
immediately after configuring them because (1) the raw OC4J performance data must be dumped,
(2) the agent must collect the data, and (3) the data must be rolled up and summarized.

Summary
In this lesson you should have learned how to:

• Add Web applications to Grid Control
• Configure Grid Control to:
– Monitor availability performance
– Monitor transaction performance
– Monitor end-user performance
– Interactively trace transactions
– Diagnose middle-tier performance problems
• Monitor availability and performance of Web
applications
• Quickly diagnose J2EE application problems

Practice 13 Overview:

• Adding a Web application
• Loading a transaction *
• Monitoring your transaction
• Creating a beacon
• Adding a beacon to a Web application
• Defining availability of beacons and transaction
• Configuring end-user response-time monitoring
• Configuring middle-tier performance monitoring
Note
Because there is no Internet Explorer browser available in the classroom, students import
transactions using a script. Normally, the Transaction Recorder is used to record, play, and trace
transactions.

Practice 13: Application Service Level Management
Background
In this practice, you create and configure a Web application for the Petstore application that you
deployed in the previous lesson.
Tasks
• Add a Web application
• Load a transaction
• Monitor your transaction
• Create a beacon
• Add the beacon to the Web application
• Define availability of beacons and the transaction
• Configure end-user response-time monitoring
• Configure middle-tier performance monitoring
1. Connect to Grid Control as administrator Team#_A.
2. Add a Web application called T#_Petstore using the URL

http://<appserver_host>:7778/estore/ and add the following targets to the
Web application:
- Web Cache
- Database
- Listener
- Host (both)
- Application server
3. Load a transaction into your Web application using the following script:
Java txnutil imp T#_Petstore <gridhost> 1521 emrep sysman

oracle1 petstore_txns
4. Start to monitor your application.
5. Create a beacon called Beacon#.
6. Add your beacon to your Web application.
7. Define the availability of your beacons and transaction.
8. Configure end-user response-time monitoring to collect every five minutes.
9. Configure middle-tier performance monitoring to collect every five minutes.

Oracle Collaboration Suite Management

Objectives

the following:
• Identify the differences between EM Website and
Grid Control and understand when to use each
• Organize Oracle Collaboration Suite components
using groups
• Monitor Oracle Collaboration Suite components
Objectives
This lesson covers the differences between EM Website and Grid Control. You examine the
tasks that are required to configure Oracle Collaboration Suite in Grid Control so that you can
monitor its availability and performance.

Using Grid Control and EM Website to
Manage Oracle Collaboration Suite
EM Website
Grid Control
Application
Management Server
Service
Using Grid Control and EM Website to Manage Oracle Collaboration Suite

Grid Control is the central console. Its HTML interface is served by the Oracle Management
Service (OMS), which is a J2EE application deployed on Oracle Application Server. From Grid
Control, you can monitor your entire Oracle Collaboration Suite, or you can drill down to view
the status and performance of individual applications such as Oracle Email and Oracle Calendar
as well as their components (including SMTP servers and Web applications).
To perform an administrative task on an Oracle Collaboration Suite application, click Administer
on the Oracle Collaboration Suite home page. The EM Website for that application then appears.

Managing a Single
Oracle Collaboration Suite Instance
EM Website
• Management UI shipped with

Oracle Application Server
9.0.2/9.0.3 is called “Enterprise
Manager Website.”
Application
• EM Website is extended to Server
support Oracle Collaboration
Suite administration tasks.
• EM Website provides real-time
monitoring of a single Oracle
Collaboration Suite middle tier.
Managing an Oracle Collaboration Suite Instance

The Enterprise Manager Website was the application server GUI management tool that was
shipped and installed with Oracle Application Server 9.0.2 and 9.0.3.
Oracle Collaboration Suite Release 2 is based on Oracle Application Server 9.0.2, so the
Enterprise Manager Website that comes with 9.0.2 was extended to cover some Oracle
Collaboration Suite administration tasks, such as configuring application parameters. These
include, for example, update domain properties for Oracle Files or stop/start/reinitialize Unified
Messaging services.

Application Server Home Page
Application Server Home Page

Using the Enterprise Manager home pages, you can manage a single Oracle Collaboration Suite
middle tier, including all of its components and applications. In addition, you can manage a
group of Oracle Collaboration Suite middle tiers that share and take advantage of one Oracle
Collaboration Suite infrastructure (also known as a farm).

Grid Control Versus EM Website
Feature Grid Control EM Website
Separate With Oracle
Installation
Collaboration Suite
Management Repository Yes No
Management Agent Yes, in its own Oracle Yes, in Oracle
Home Collaboration Suite
Oracle Home
Target Types Many Application Server and
applications
Number of Targets Many One
Server Configuration No Yes
Application Configuration No Yes
Real-Time Monitoring Yes Yes
Historical Monitoring and Yes No
Alerts
Application Service Level Yes No
Management
Job System Yes No
Configuration Management Yes No
Grid Control Versus EM Website

EM Website is installed and available with each Oracle Collaboration Suite installation. Using
EM Website, you can monitor and administer a single Oracle Collaboration Suite middle tier.
Note: EM Website manages one middle tier of Oracle Collaboration Suite. However, you can
use the Farm page to navigate to different instances.
In Grid Control, you can access multiple Oracle Collaboration Suite targets as well as define
groups which are comprised of multiple Oracle Collaboration Suite targets. Groups are useful in
seeing an integrated view of all the information about the Oracle Collaboration Suite
components for which a particular administrator is responsible. In Grid Control, you view the
entire suite and individual applications and targets, and you monitor them. From EM Website,
you perform administration tasks.
This table depicts the main features of Oracle Collaboration Suite management, indicating
whether Grid Control and EM Website support that functionality.

Managing Oracle Collaboration Suite in
Grid Control
Use Grid Control to manage Oracle Collaboration Suite

in the following ways:
• Install and configure Oracle Collaboration Suite
application components
• Monitor platform components and components
that are specific to Oracle Collaboration Suite
• Compare systems and apply patches
Managing Oracle Collaboration Suite in Grid Control

After you have configured Oracle Collaboration Suite in Grid Control, you can manage your
targets in the following ways:
• You can group Oracle Collaboration Suite application components together to evaluate and
monitor all the targets as a single entity.
• You can monitor the platform components such as database, application server, and host. In
addition, you can monitor Oracle Collaboration Suite components using the custom user
interface for each target type.
• You can manage the enterprise configuration through system comparisons and patch
management. This topic is covered in the next lesson, “Managing your Configuration.”

Installing and Configuring
Oracle Collaboration Suite in Grid Control
To install and configure Oracle Collaboration Suite in

Grid Control, perform the following steps:
• Install Management Agent on each Oracle
Collaboration Suite host machine
• Define application targets
• Create a Web application
• Create an application group
• Add the application group to OCSGroup
Follow B13601-01 Oracle Enterprise Manager:
Managing Oracle Collaboration Suite Guide
Configuring Oracle Collaboration Suite in Grid Control

After installing Oracle Collaboration Suite and Grid Control, perform the following steps:
1. Install Management Agent on each Oracle Collaboration Suite host. For your targets to be
discovered in Grid Control, you need to install the management agent on each host where
Oracle Collaboration Suite components reside. The management agent can be installed
using the Oracle Universal Installer or the downloadAgent script from the Grid Control
machine. Follow the instructions contained in the Oracle Enterprise Manager Grid Control
Installation and Basic Configuration Guide.
2. Define application targets. For each application, there are a set of targets that need to be
defined. Follow the Oracle Enterprise Manager: Managing Oracle Collaboration Suite
guide.
3. Create a Web application for each Oracle Collaboration Suite component to determine
transaction and page performance. Application Service Level Management is used for
application and end-user monitoring.
4. Create a group for each Oracle Collaboration Suite component so that you can monitor
each individual application as a whole.
5. Add all application groups to an overall OCSGroup. By creating one overall group, you can
evaluate and monitor Oracle Collaboration Suite as a single entity.

Organizing Oracle Collaboration Suite
Components Using Groups
• Create a host group.

• Create a database group.
• Create an Application Server group.
• Create an Oracle Collaboration Suite group.
• Create groups for the individual applications.
Organizing Oracle Collaboration Suite Components Using Groups

Create groups and subtabs to organize the Oracle Collaboration Suite targets. Consider creating
the following:
• Host group (type of host group) called OCSHOSTS that contains all the hosts that are
running Oracle Collaboration Suite components
• Database group (type of database group) called OCSDB that contains all the database that
support your Oracle Collaboration Suite deployment (infrastructure and information store
databases)
• Application Server group (type of group) called OCSAS that contains all the application
servers that support your Oracle Collaboration Suite deployment (infrastructure and middle
tier)
• Oracle Collaboration Suite group (type of group) called OCSGroup that contains all the
groups that you previously created (hosts, databases, application servers)
• Individual application groups (type of group) containing all the components for each
Oracle Collaboration Suite component: for example, Email, Calendar, Web Conferencing,
and so on
Note: These group names are only suggestions.

Using the OCSGroup Page
The OCSGroup page provides information about the

overall health of the Oracle Collaboration Suite
environment.
Using the OCSGroup Page

The OCSGroup Page provides an “at-a-glance” view of the entire suite. This page provides a
review of the overall health of the Oracle Collaboration Suite environment. You can learn if
there are any targets that are down or alerts that are outstanding. You can also see the job status
for any Oracle Collaboration Suite–related targets as well as deployment information.

Drill Down to Review the Alerts
On the OCSGroup page, click Critical in the Alerts list.
Drill Down to Review the Alerts

To see a list of the critical alerts, click the number in the Alerts area of the Group Home page.
Look at the critical alerts to see which components are causing problems.
Click OCSGroup to return to the Group Home page.

Drill Down to Review Component
Availability
On the OCSGroup page, click the red area in the

availability chart.
Drill Down to Review Component Availability

To see a list of components that are currently down, click the red area in the chart or in the
legend. Drill into each target to see the details of why it is down.
Click OCSGroup to return to the Group Home page.

Review Member Targets List
Review Member Targets List

To see a list of targets in the group, click Member Targets. This page lists the targets and their
availability, alerts, policy violations, and type. Drill into a target to see details.

Monitoring Oracle Collaboration Suite
Components
Drill-down scenarios are provided for the following

Oracle Collaboration Suite components:
• Oracle Email
• Oracle Calendar
• Oracle Web Conferencing
Monitoring Oracle Collaboration Suite Components

This section provides scenarios or drill-down paths for some of the Oracle Collaboration Suite
components using Grid Control. Each slide shows a screenshot of what an administrator
examines to monitor the Oracle Collaboration Suite component.

Email Component Home Page
Email Component Home Page

To see details for Oracle Email, click the Email component on the group page. The Email Home
page displays all the alerts and components associated with the Email component. Some metrics
are available that evaluate the health of each component.
Scroll down to see the entire list of Email components.

List of Email Components
List of Email Components

You notice that you have components SmtpInServer and SmtpInService. An e-mail
server refers to a specific process running on a specific host. An e-mail service refers to the
service provided by a collection of processes.
To monitor your WebMail instances, you see a Web application target called Webmail. Click
Webmail.

WebMail Web Application Page
WebMail Web Application Page

The WebMail Web application target can be used to monitor your WebMail instances. You
monitor the WebMail availability and performance with ASLM transactions. You can measure
the response time of pages in your Web applications using End-User Performance Monitoring.
Click the Back button to return to the Email Home page. Scroll to the top of the page.

Email Performance
Email Performance
Click the Performance property page on the Email Home page to view several graphs that
provide useful information on how your Email component is performing.
Click Back to return to the Email Home page.

Email IMAP Operations
Email IMAP Operations

Click the IMAP Operations property page. This page evaluates the number of IMAP operations
to see how many users are accessing Email and what IMAP actions they are performing.
Click OCSGroup to return to the Group page.

Calendar Component Group Page
Calendar Component Group Page

Drill down into the Calendar group from the OCSGroup. The Calendar page displays all the
Calendar components and metrics for evaluating the health of the application.
Click the Web application in the list of components.

Calendar Web Application
Calendar Web Application

Use the Calendar Web application target to monitor your Calendar instance. You monitor
Calendar availability and performance with ASLM transactions. You measure the response time
of pages in your Web applications using End-User Performance Monitoring.
Click Back to return to the Calendar group.

Calendar Performance
Calendar Performance
Click the Performance property page. Understanding your Calendar component’s performance
helps to find issues before they become problems. Drill down into each metric chart or click
Compare Metrics to compare against another Oracle Calendar installation.
Click OCSGroup to return to the group page.

Web Conference Component Group Page
Web Conference Component Group Page

From the OCSGroup, click the Web Conferencing component to see all of its components. Status,
alerts, and other statistical information is also provided.
Click the Web application.

Web Conference Web Application
Web Conference Web Application

By selecting the Web Conference Web application, you see how the application is performing.
You can define transactions and evaluate the page performance of the Web Conference
component.
Click the Page Performance property page.

Page Performance of Web Application
Page Performance of Web Application

On the Page Performance property page for the Web Conference Web application, you can
review the application’s page performance.

Summary

• Identify the differences between EM Website and
Grid Control
• Organize Oracle Collaboration Suite components
using groups
• Monitor Oracle Collaboration Suite components

Managing Your Configuration

Objectives

the following:
• View a configuration
• Search for a configuration
• Compare configurations
• Review change tracking
• Apply a patch
• Manage policy violations
• Clone an Oracle home or database
Objectives
This lesson helps you manage your configurations. You learn how to view, search, and compare
configurations. In addition, you learn the steps to review changes made to your configuration, to
apply patches to targets, and to manage policy violations against targets. You learn the process to
clone an Oracle home and database instance.

Questions Administrators Ask Themselves
• Which servers have a particular version of the

Oracle database installed?
• Which instances have a given patch applied?
• Which Oracle databases have a specific
initialization parameter setting?
• Which hosts have a specific operating system
patch applied?
• When things stop working, what has changed?
• Which databases are using a particular feature
(Oracle Database 10g only)?
Questions Administrators Ask Themselves

Providing answers to these questions is important for determining the tasks that are necessary to
optimize the efficiency and performance of your enterprise environment.

Analyzing Your Configuration
Grid Control provides administrators with:

• Automatic collection of system data
• System inventory reporting
• System comparisons
• Historical change tracking
• Patching and critical patch advisories
• Policy management
• Installation cloning
Analyzing Your Configuration

Business decisions frequently require changes to existing software configurations and upgrades
of hardware and software. Such decisions require an instant view of all host hardware, operating
systems, and software installed across an enterprise grid from a single console. With ready
access to this information, administrators can easily determine what changes must be made and
then deploy those changes quickly and accurately.

Viewing Configuration Information
On the Deployments page, you can view:
Viewing Configuration Information

The Deployments page in Grid Control simplifies monitoring and management of your host
configurations, database configurations, and enterprise configuration. It serves as a starting point
from where you can access many of Enterprise Manager’s configuration features.
Note: Although the Deployments page is not available in Enterprise Manager Database Control,
users of Enterprise Manager Database Control have access to many of Enterprise Manager’s
configuration features through links on Database Control pages.
On the Deployments page, you can:
• View information about critical patch advisories
• Display summary views of your enterprise configuration
• Access other host configuration, database configuration, and enterprise configuration
features
• Access patching features
• Access cloning features
• Manage policy violations and the policy library

Automatic Collection of System Data
Data collected includes:

• Host hardware specifications
• Operating system information
• Oracle software inventory and configuration
Automatic Collection of System Data

Grid Control collects detailed configuration information about all designated host systems across
the enterprise. Data collected includes information about:
• Host hardware specifications, including number of CPUs and their clock speed (also the
size of memory), hard disk specifications, and network information
• Operating system parameter settings, file system specifications, and installed packages and
patches
• Oracle software installed on the host, including version and information about patch sets
and interim patches, and software configuration specifications
This comprehensive system information is stored in the Oracle Management Repository and is
the foundation of Enterprise Manager’s configuration management system.

Refreshing Collected Data
• Automatically refreshed daily (default)

• Manual
Refreshing Collected Data

By default, the configuration data is refreshed daily. In addition, users may refresh this data at
any time.
To refresh the data manually, perform the following steps:
1. Click the Deployments tab.
2. Click Refresh Host Configuration.
3. Select the hosts for which you want to refresh the data, and then click Move.
4. Click Refresh Hosts.

Reporting System Inventory
On the Deployments page, the Deployments Summary

section shows:
• Hardware
• Operating systems
• Database installations
• Application server installations
Reporting System Inventory

System administrators often struggle to quickly and reliably track the hardware and software
installed in their company’s grid. In the Deployments Summary section of the Deployments page,
you can view the hardware, operating systems, and database and application server installations
for all targets that are discovered in your grid.

Drilling Down for Details
Drilling Down for Details

For each Deployments Summary, you can drill down to see more details. Some examples of the
information that you can see include:
• Hardware: Memory size, local disk capacity, and number of CPUs
• Operating system: Vendor, maximum swap space, mount location, and installed packages
• Database installations: Oracle home, host, and database home page
• Application server installations: Oracle home, host, and application server home page

Searching Configurations
Searching Configurations
On the Deployments page, click Search Configurations.
The Search Configurations page is the starting point for different types of searches that involve
one or more targets in your enterprise configuration. Most of the search queries are predefined,
but you can modify the search criteria to customize different search queries.
Click the link for one of the predefined search queries to access a page on which you can specify
the criteria for that search query. Click Help on that search query page to obtain more
information about the search query.
In addition, you can perform an advanced search and specify a SQL statement to query the
enterprise configuration management views in the Oracle Management Repository. If you want
to perform an advanced search but do not want to create the entire SQL query yourself, you can
choose one of the predefined searches and, optionally, make modifications to it. At any time,
click Search Using SQL to display the SQL statement that is used to carry out the predefined
search with the search criteria that you have specified. Execute and modify the SQL query as
often as necessary until it returns the desired results.

Comparing Systems
Using Grid Control, you can:

• Compare host to host
• Compare host to multiple hosts (job)
• Compare databases
Comparing Systems
Enterprise Manager provides tools for an enterprise-wide comparison of systems so that
administrators can quickly and easily identify any potential differences. This helps to keep
systems synchronized and simplifies investigations into why systems that are presumed to be
identical may behave differently.
Administrators often need to create new systems that are equivalent in performance to existing
systems. This information can then be used as a blueprint for creation of new systems.
Using Grid Control, you can perform the following comparisons:
• Host to host: Identifies configuration differences between two hosts
• Host to multiple hosts (job): Compares one host to multiple other hosts. This comparison
executes a job that can be run immediately or scheduled for a later time.
• Databases: Identifies differences between two database configurations

Reviewing Comparison Results
Example: Host-to-host comparison
Reviewing Comparison Results

The Comparison Results Summary page summarizes the comparison results. You can view the
summary of the comparison on this page, and you can navigate to more detailed information
about differences in the comparison items.
In this example, you see a host-to-host comparison. One of the differences between these hosts is
the Oracle software that is installed. The first host has Oracle Application Server installed, and
the second host has Oracle Database installed.

Tracking Historical Changes
What happened to the performance of your system?
Tracking Historical Changes

Administrators are sometimes faced with a situation where a system that once worked well,
suddenly does not perform at an acceptable level. Determining the exact change responsible for
the decrease in system’s performance may take hours. Grid Control makes it simple by tracking
all changes to hardware and software installations and configurations. As a result, the
administrator can view changes that have been made since the last time the system functioned
appropriately, and can apply the appropriate solution to get the system back to an acceptable
level.

Critical Patch Advisories
You are automatically notified about critical patches to

targets.
Receive critical
1 patch Update
advisories. 4 inventory.
3 Apply
patch.
2 Evaluate
applicability.
Patches on
MetaLink
Critical Patch Advisories

Oracle patch advisories describe critical software patches for Oracle products. To help ensure a
secure and reliable configuration, you must apply all relevant and current critical Oracle patches.
To promote critical patch application, Enterprise Manager performs an assessment of
vulnerabilities by examining your enterprise configuration to determine which Oracle homes
have not applied one or more critical patches.
Critical patch advisories provide real-time discovery of new patches published on MetaLink.
These critical patches can dramatically reduce security vulnerabilities. With Grid Control, an
administrator can determine the applicability and choose whether to apply the patch. After the
patch is applied, the Management Repository is updated and the software and hardware
inventory is refreshed.

Applying Patches
Select the desired patch that you want to apply.
Retrieve the
1 list of
available
patches. Update
4 inventory.
3 Apply the
patch.
2 Select the
desired patch.
Patches on
MetaLink
Applying Patches
An administrator can also use the Patch Wizard to search, download, and apply patches. Using
the Patch Wizard, patches can be searched in the context of a specific target or, if desired, the
administrator can query for a specific patch. After the necessary patch is located, Enterprise
Manager Grid Control can download and apply it. Optionally, Enterprise Manager can execute
an end user–provided script to install the patch.

Using the Patch Wizard
On the Deployments page, select Patch.
Using the Patch Wizard

Enterprise Manager simplifies patching because you can stage (or stage and apply) Oracle
patches and patch sets. The first step in the process is to select the Oracle patch or patch set that
you want from the MetaLink Web site.
If you do not know the patch number that you are looking for, click Search by Criteria.

Using the Patch Wizard:
Search by Criteria
Using the Patch Wizard: Search by Criteria

If you specify a particular release of a product, Enterprise Manager searches for all the interim
patches and the latest patch that are applicable to that release.
Enter the criteria in the Search by Criteria section, and then click Search.

Evaluate the List of Patches
You can view details or view results of each patch in
the list to determine whether you want to apply it.
Using the Patch Wizard: Evaluate the List of Patches

When the patch search is completed, the patches that meet the search criteria are displayed in the
Search Results table. Select a patch, and click Next to continue the process of staging the patch
on one or more targets.
To stage and apply patches effectively by using Enterprise Manager, you must know what steps
are necessary to install the patch and you must be familiar with patch details.
To learn more about a patch, select it in the Search Results section. You can then do the
following:
• Click View Details for the patch to see more detailed information about the patch. This
information is provided by Oracle MetaLink.
• Click View Readme to read the Readme for the patch. The Readme may include
information such as system requirements for the patch, components that are fixed by the
patch, bugs that are addressed by the patch, known issues with the patch, and other
information that Oracle Corporation wants you to know before you install the patch.

Select Destination
Select the targets on which the patch must be applied.
Using the Patch Wizard: Select Destination

The patch that you selected can be applied to one or more targets. Select the destination type for
which the patch is to be applied. Then, select the targets on which you want the patch to be
applied. Click Next.

Set Credentials
To apply the patch, specify the host credentials.
Using the Patch Wizard: Set Credentials

Specify a valid host (operating system) username and password for the host or hosts on which
the patch is to be staged.
When the Patch Wizard stages a patch that it can map to a target, it stages the patch in the
EMStagedPatches subdirectory of the Oracle home for that target. For example, if the Patch
Wizard stages database patch 1390304 in the Oracle home location of /private/OraHome1
for a host, then the patch is copied to the following directory:
/private/OraHome1/EMStagedPatches/1390304
The protections set up for the Oracle home directory must enable the user whose host (operating
system) username and password credentials you specify to create a subdirectory in the Oracle
home directory and write files to that subdirectory.
The username and password credentials are verified when you go to the next page in the Patch
Wizard.

Stage or Apply
Select “Run Script to Apply Patch.” Then click Next.
Using the Patch Wizard: Stage or Apply

If you are using the Patch Wizard only to stage the patch (that is, if you are not going to use the
Patch Wizard to apply the patch), click Next.
If you want the patch to be applied, select Run Script to Apply Patch, and then click Next.

Schedule
Specify when the patch must be applied.
Using the Patch Wizard: Schedule

On the Schedule page, start an Enterprise Manager job to stage (or stage and apply) the selected
patch on the hosts for the specified targets.
Use the Date and Time fields to schedule the patch job. The default date and time that are
specified in these fields are the current date and current time. This means that when the patch job
is submitted (on the last page of the Patch tool), the Enterprise Manager job system runs the
patch job immediately. If you change to a date or time in the future, the job system starts the job
at that time.

Summary
Review the Summary, and click Finish.
Using the Patch Wizard: Summary

The Summary page provides the following information:
• Which patch is to be applied
• How much space is needed to stage and apply the patch
• What destinations the patch is applied to
• Basic job information
To stage and apply the patch, click Finish.

Policy Management
Oracle provides 45 policies

that evaluate the following:
• Security vulnerabilities
• Configuration best Policy
practices
• Policy violations
• System standardization
Policy Management
Enterprisewide compliance with Oracle best-practice security and configuration policies can be
automatically monitored with the Configuration Management Pack Policy Manager. This saves
hours of tedious and repetitive work for administrators. Oracle provides policies that span hosts
and their operating systems, Oracle database installations, and instances as well as application
servers. Example policies include:
• Database SPFILE not used
• Insufficient number of control files
• Password complexity not enabled
• Detect open host ports
Policy compliance is evaluated continually even as new targets come online. Administrators are
immediately informed about any policy violations. Individial policies can be deactivated
enterprisewide or on a per-target basis.

Managing the Policy Library
On the Deployments page, click Manage Policy Library.
Managing the Policy Library

Policy rules exist for different target types, such as hosts, Oracle databases, and listeners. The
Manage Policy Library page displays a list of all the policy rules that Enterprise Manager uses to
check for target compliance in your enterprise.
You can view the priority, category, and description of each policy rule. For each rule, you can
know from the Target Type column which target type is evaluated for compliance with the rule.
You can choose to disable or enable the evaluation of each rule. If you disable the evaluation of
a particular rule, then Enterprise Manager does not evaluate any of the targets that would
normally be evaluated for compliance with that rule. For example, if you disable a particular
database rule, then Enterprise Manager does not evaluate any database targets for compliance
with that rule.
The Disabled By column displays the username of the person who disabled each disabled rule.

Reviewing Policy Violations
Specify search criteria, and click Search.
Click the policy

rule to see its
impact and the
recommendations
for its resolution.
Reviewing Policy Violations

By default, all the policy violations in your enterprise configuration appear in the Results section.
You can specify a set of search criteria to display only the policy violations that meet the criteria
in the Results section.
Click Apply after you have set each of the violations to the desired state (Ignore or clear). If you
click Revert, the violations return to the states they had when you opened the page.
Violations that have been set to Ignore do not appear in default lists of violations.
Note: The Mark All Ignored and Clear All Ignored buttons affect all the violations in the Results
section (including the violations on subsequent pages of the Results table when there are
multiple pages of violations).
To view more detailed information about the violations of a particular rule for a specific target,
click the link in the Policy Rule column for that target.

Cloning an Oracle Home
Duplicating Oracle homes across hosts:
Select
software and
Update
1 instances to 3 inventory.
clone.
2 Clone to
selected
targets.
Cloning an Oracle Home

The Oracle Configuration Management Pack provides users with a convenient and flexible way
to intelligently duplicate Oracle software installations (or Oracle homes) across hosts. The
Oracle Home Cloning Wizard can designate an Oracle software home on a source system and
select one or more destination hosts on which users want to clone that home.
The cloning of an Oracle home is performed in an intelligent manner; that is, the environment-
dependent home properties (such as the host name, IP address, and listener settings) are
automatically adjusted during the cloning process. In addition, the Oracle Universal Installer
inventory that keeps track of all Oracle installations on a system is automatically updated as part
of the cloning process. Cloning operations can be scheduled as Enterprise Manager jobs to be run
during off-hours to minimize network load.
To clone an Application Server 10g Oracle home, you must apply a patch to the Oracle
Management Service (OMS) for the platform that you want to clone. For example, if you want to
clone a Linux Application Server Oracle home, you must install the Linux version of the patch
regardless of the platform on which the OMS is running. Refer to patch 3597580 for Unix
platforms and patch 3678691 for the Windows platform.

Cloning an Oracle Home (continued)
For details about cloning an Application Server Oracle home, refer to the Application Server 10g
(9.0.4) Cloning white paper located on Oracle Technology Network (OTN) at the URL
http://otn.oracle.com/products/ias/pdf/cloning_white_paper.pdf.
The white paper highlights certain restrictions associated with cloning an Application Server
Oracle home, such as the following:
• Oracle supports cloning of Application Server release 9.0.4 only; it does not support
cloning Application Server release 9.0.2 or 9.0.3.
• Oracle supports cloning of only J2EE and Web Cache midtiers; it does not support cloning
of other midtiers such as Portal and Wireless or Business Intelligence and Forms.
• Oracle supports cloning of J2EE and Web Cache midtiers that are not associated with an
OracleAS Farm or an OracleAS Cluster. So to clone, you must first leave the OracleAS
Farm or OracleAS Cluster, or both.
• A cloned application server instance has the same instance name as the source
instance. This means that the source instance and the cloned instance cannot be part of the
same cluster or farm. However, you can manually change the instance name of the cloned
instance after cloning.

Cloning a Database Instance
Cloning a database instance to an existing Oracle

home:
• Provides testing environment for developers
• Saves time
• Provides infrastructure for Data Guard
management
• Provides high availability for the source database
• Backs up the whole database and restores it at
any time
OraHome1
DB1: Orcl
DB2: Orcl2 (cloned)
Cloning a Database Instance

The Clone Database Wizard duplicates the current database by first backing up and then
transferring the current database files to a destination Oracle home. Cloning a database provides
the following benefits:
• Provides a testing environment for developers: A cloned database can be used for testing
and debugging purposes while the original database is kept available.
• Saves time: You do not need to install a new database instance and then import the data to
create an identical database. Also, you can clone the same instance to multiple Oracle
homes by using the saved working directory without reconnecting to the source database
instance.
• Provides an infrastructure for Data Guard management: Data Guard embeds database
cloning to create a standby database as part of the Data Guard management process.
• Provides high availability for the source database while it is cloned: The source
database instance is kept running during the cloning operations.
• Backs up the whole database and restores it at any time: The saved working directory
contains everything needed to restore the target database. You can save the backup on disk
and create a new database from it at any time. No existing target database instance is
required.

Cloning a Database Instance:
Source Type
On the Deployments page, click Clone Database.
Cloning a Database Instance: Source Type

Use the starting page of the wizard to designate the source for the cloning operation. You can
select a current database instance or a saved working directory from a previous clone operation.
Note: You can clone Oracle8i Database, release 8.1.7 or later.

Source Working Directory
Cloning a Database Instance: Source Working Directory

The Source Working Directory page specifies the directory on the source host in which the
backup files are stored during the clone operation. You can retain this directory for future clones
to avoid creating another backup.
Any new backup set that you create, you must designate its location in the Working Directory
Location field. The Clone Database Wizard automatically calculates the amount of temporary
disk space that is required for both creating the new backup set and retaining the backup set (if
you choose to clone the database to multiple targets). You can choose to delete or retain the
backup set after the completion of the cloning procedure. You must enter the host credentials of
the user who is running the Oracle server process of the source database

Archiving Mode
Cloning a Database Instance: Archiving Mode

The Archiving Mode page specifies whether to leave the database in NOARCHIVELOG mode or
switch it to ARCHIVELOG mode. You see this page of the wizard only if the source database is
running in NOARCHIVELOG mode. Append the location of the archived logs mentioned in
Archived Logs Destination in the Init Parameter file.
If you choose to leave the database in NOARCHIVELOG mode, the job shuts down the database
and restarts it in mounted mode. When the clone operation is complete, the database is reopened.
If you switch the database to ARCHIVELOG mode, the job shuts down and switches the database
to ARCHIVELOG mode, appends the specified log archive destination settings to the specified
Init Parameter file, restarts the database, and then performs the clone operation. When the job
completes, the database remains in ARCHIVELOG mode.

Select Destination
Cloning a Database Instance: Select Destination

On the Select Destination page, you must provide the destination database name and system
identifier (SID) for the new database, and then provide the destination Oracle home and
destination host credentials. You can also clone the database to the same machine as the source
database.
Use the Search for Host field to locate Oracle home locations from various hosts, and then select
the Oracle home that you want to use in the Select column of the row for that host.

Destination Options
Cloning a Database Instance: Destination Options

On the Destination Options page, you can set the location for data files, control files, log files,
and temp files (either individually or for all files of a type) by using the Customize option. You
can select the method used to make the backup files accessible to the destination host by
choosing to transfer the files directly to the working directory, or you can choose to use the files
directly from a specified shared directory. You can also specify the network configuration file
location and register the database as an Enterprise Manager target.

Schedule
Cloning a Database Instance: Schedule

On the Schedule page, provide a job name and description for the clone job. In addition, you
designate the date on which you want the job to run.

Review
Cloning a Database Instance: Review

On the Review page, view the parameters selected or assigned for the source database,
destination Oracle home, and job. Click “Submit job” to initiate the submission.

Viewing the Job Results
Cloning a Database Instance: Viewing the Job Results

There are many tasks that are run during database cloning. The job results list displays the
various tasks and their results.

Summary

• View a configuration
• Search for a configuration
• Compare configurations
• Review change tracking
• Apply a patch
• Manage policy violations
• Clone an Oracle home or database

Managing Your Configuration

• Browsing and exporting a host configuration
• Comparing hosts
• Comparing databases
• Managing policies

Practice 15: Managing Your Configuration
Background
As an administrator for your application server, you must know how it performs over time and
how it compares with the performance of other application servers.
Tasks
• Browsing and exporting a host’s configuration
• Comparing hosts
• Comparing databases
• Managing policies
1. Browse the configuration information collected for one of your host targets, and then
export the information to a file.
2. Compare your two hosts to determine the differences in their configurations.
3. Compare the configurations of your database and your neighbor’s database.
4. Perform a search by using SQL query that uses the Initialization Parameters Settings
option.

Grid Control Security

Objectives

the following:
• Enable secure communications throughout the
Grid Control framework
• Configure Grid Control for use with proxy servers
and through firewalls
• Authenticate Grid Control administrators using
Single Sign-On
• Configure Grid Control for use with Enterprise
User Security

Grid Control security has two primary goals:

• Ensuring secure transfer of data between Grid
Control components
• Denying unauthorized users access to Grid
Control monitoring data and administrative
controls

Grid Control security usually has two primary goals:
• Ensuring that information transferred between Grid Control components is not readable by
unauthorized users. This goal is met by enabling Enterprise Manager Framework Security.
• Ensuring that only users with proper privileges have access to critical monitoring and
administrative data. Grid Control achieves this goal by requiring username and password
credentials for access to the Grid Control, Database Control, and Application Server
Control consoles. Grid Control can leverage the Oracle Identity Management infrastructure
in two ways:
- Authenticating users with Oracle Single Sign-On
- Authenticating users through Enterprise User security
An additional goal is ensuring that Grid Control functions within a secure environment, working
through firewalls, proxy servers, and switched port devices without requiring network
administrators to decrease the network security posture.

Enterprise Manager Framework Security
Provides secure (encrypted) communications between

Grid Control components:
• OMA <-> OMS
• OMS <-> OMR
OC4J
EM
OMR
Web OHS
Cache OMS
Encrypted Encrypted
channel channel
Enterprise Manager Framework Security

Enterprise Manager Framework Security works by encrypting communications between the Grid
Control components.
Communications between the OMA and OMS are encrypted leveraging the Public Key
Infrastructure (PKI) using industry-standard Secure Socket Layer (HTTPS).
Communications between the OMS and OMR are encrypted using Oracle’s Advanced Security
Option.

Securing OMA–OMS Communications
Securing communications between the OMA and OMS

is a three-step procedure:
1. Configure management services to accept secure
uploads.
2. Configure management agents to upload securely.
3. Configure management services to refuse
nonsecure uploads.
Securing OMA–OMS Communications

There are three steps involved in securing communications between the management agents and
management services:
1. Configuring management services to accept secure uploads from the management agents.
This step must be completed for all management services that accept uploads.
2. Configure all management agents to upload securely. This step must be completed for
every management agent.
3. Remove the ability for the management services to accept nonsecure uploads. This step
should be completed for each management service.
It is possible to have a mixture of secure and nonsecure communications between agents and
management services. For example, if some management agents reside on hosts outside the
secure portion of the network, those agents may be configured to use secure communication
whereas hosts inside the secure portion of the network may be configured to use nonsecure
communication.

Accepting Secure Uploads
Configuring a management service to accept secure

uploads includes:
• Generating a root key
• Modifying the OMS’ HTTP server to accept
uploads via HTTPS
• Enabling OMS authentication of OMA requests
Accepting Secure Uploads

Use emctl to prepare the OMS to accept secure communications.
This operation generates a root key for use in creating x509 PKI certificates to encrypt
communications. Additionally, the management service’s Oracle HTTP server is modified to
accept HTTPS traffic from the OMAs on a new port, and an agent registration password is stored
to authenticate management agents wishing to upload data to the secure OMS.
Prior to securing the OMS, the administrator should have already chosen an agent registration
password.

Configure Management Services
To configure the OMS to accept secure uploads:

1. Stop all OMS services.
2. Execute emctl secure oms:
a. Enter the SYSMAN password.
b. Specify the Agent Registration Password.
c. Enter the fully qualified host name of the OMS.
3. Start all OMS services.
4. Retrieve the secure upload port. OC4J
EM
$ emctl secure oms

Web OHS
Cache OMS
Configure Management Services

Prior to executing emctl secure oms, the administrator should already know the password
for SYSMAN and should choose an agent registration password.
Note: When prompted for the “Enterprise Manager Root Password”, enter the
password for SYSMAN:
1. Stop all OMS services using opmnctl:
$ $GRID_HOME/opmn/bin/opmnctl stopall
opmnctl: stopping opmn and all managed processes...
2. Generate the root key, configure the HTTP server for secure communications, and enter the
OMA authentication password with emctl:
$ $GRID_HOME/bin/emctl secure oms
TZ set to US/Mountain
Oracle Enterprise Manager 10g Release 10.1.0.2.0.
Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.
Enter Enterprise Manager Root Password :
Enter Agent Registration password :
Enter a Hostname for this OMS : eddnr5p12.us.oracle.com

Configure Management Services (continued)
Checking Repository... Done.
Checking Repository for an existing Enterprise Manager Root Key...
Done.
Generating Enterprise Manager Root Key (this takes a minute).Done.
Fetching Root Certificate from the Repository... Done.
Generating Registration Password Verifier in the Repository..Done.
Generating Oracle Wallet Password for Enterprise Manager OMS...
Done.
Generating Oracle Wallet for Enterprise Manager OMS... Done.
Generating Oracle Wallet for iAS HTTP Server... Done.
Updating HTTPS port in emoms.properties file... Done.
Generating Oracle Wallet Distribution Service... Done.
Generating HTTPS Virtual Host for Enterprise Manager OMS... Done.
3. Start OMS services using opmnctl:

$ $GRID_HOME/opmn/bin/opmnctl startall
opmnctl: starting opmn and all managed processes...
Verify that OMS services started successfully:

$ $GRID_HOME/opmn/bin/opmnctl status
Processes in Instance: EnterpriseManager0.eddnr5p12.us.oracle.com

-------------------+--------------------+-------+---------
ias-component | process-type | pid | status
-------------------+--------------------+-------+---------
WebCache | WebCacheAdmin | 31891 | Alive
WebCache | WebCache | 31899 | Alive
OC4J | OC4J_EM | 31890 | Alive
OC4J | home | 31884 | Alive
dcm-daemon | dcm-daemon | 16941 | Alive
LogLoader | logloaderd | N/A | Down
HTTP_Server | HTTP_Server | 31883 | Alive
4. Retrieve the secure upload port:

$ emctl secure status
Checking the security status of the OMS at location set in
/u01/app/oracle/product/10.1.0/gridcon_1/sysman/config/
emoms.properties...Done.
OMS is secure on HTTPS Port 4888

Test the Secure Upload Port
Test the secure upload port using a browser:

https://omsserver.mycompany.com:<secure port>/em/upload
Test the Secure Upload Port

Test the secure upload port with a Web browser. Because the certificate generated by emctl
was not issued by a trusted certificate authority (such as Verisign or Thawte), you will receive an
error letting you know the certificate cannot be authenticated. This does not affect the use of the
certificate to encrypt communications and may be safely ignored.
Click Yes to view the secure upload URL. You should see the following message displayed in
the web browser:
Http XML File receiver
Http Recceiver Servlet active!

Configure Management Agents
Securing a management agent involves:

• Obtaining a certificate wallet from the OMS
• Obtaining an agent key that is registered with the
OMS
• Reconfiguring the management agent to use the
OMS’ secure upload port
To secure the OMA, perform the following:
1. Stop the management agent.
2. Execute emctl secure agent.
3. Start the management agent.
4. Verify that the management agent is now secure.
Configure Management Agents

After secure uploads have been enabled for the management services, the management agents
should be reconfigured to take advantage of the secure upload capability.
To secure the management agent:
$ $AGENT_HOME/bin/emctl stop agent
Stopping agent ... stopped.
2. Execute emctl secure agent.
$ $AGENT_HOME/bin/emctl secure agent

Configure Management Agents (continued)
Requesting an HTTPS Upload URL from the OMS... Done.
Requesting an Oracle Wallet and Agent Key from the OMS... Done.
Check if HTTPS Upload URL is accessible from the agent... Done.
Configuring Agent for HTTPS... Done.
EMD_URL set in
/u01/app/oracle/product/10.1.0/agent/sysman/config/emd.properties
The command may also be entered with the agent registration password:
$ $AGENT_HOME/bin emctl secure agent <agent registration password>

$ $AGENT_HOME/bin/emctl start agent
Starting agent ....... started.
4. Verify that the management agent is now operating in secure mode. Navigate to the
management agent’s home page in Grid Control to verify that the agent is secure.

Verify That Management Agents
Are Secure
Verify that agents are configured for secure upload.
Verify That Management Agents Are Secure

Examine the Secure Upload column of the Agents properties page on the Management Services
tab of Grid Control. Agents configured for secure upload will have “Yes” in the column.
This step is particularly important when the Grid Control framework is first shifted to secure
mode, not only to ensure that all agents have been secured, but also to validate that all agents
were started again after being secured.

Managing Agent Registration Passwords
Use Grid Control to:

• Change agent registration passwords
• Create or remove additional registration
passwords
Managing Agent Registration Passwords

Management agent passwords are changed through Grid Control. Click Setup, Registration
Passwords, and then Edit to modify the password.
Grid Control can be configured to allow more than one password for agent registration. Click
Add Registration Passwords to create additional agent registration passwords. Additional
passwords can be set to expire after a set period or even configured for one-time use.
The initial password may be modified via command line through the OMS’ emctl:
$ $GRID_HOME/bin/emctl secure setpwd <sysman password> <new
agent registration password>

Refuse Nonsecure Uploads
Configure the OMS to refuse unencrypted uploads.

2. Configure the OMS to refuse uploads via HTTP.
$ emctl secure lock
Refuse Nonsecure Uploads

So far you have configured the OMS to accept secure uploads and configured the management
agents to use encrypted communications through the secure upload port. If you do nothing else,
the OMS can accept both secure and nonsecure uploads using either HTTP or HTTPS. The final
step in securing communications between the management agents and management services is to
disable the previously used unencrypted communications channel so that the OMS only accepts
uploads via HTTPS.
This step is optional and should only be performed if all management agents uploading to an
OMS are using a secure upload port.
1. Stop all OMS services:
opmnctl: stopping opmn and all managed processes...
2. Configure the OMS to refuse uploads via HTTP:

$ $GRID_HOME/bin/emctl secure lock

Refuse Nonsecure Uploads (continued)
Checking the security status of the OMS... Done.

Updating HTTPS Virtual Host for Enterprise Manager OMS... Done.
OMS Locked. Agents must be Secure and upload over HTTPS Port 4888.
Starting the HTTP Server... Done.
3. Start all OMS services:

opmnctl: starting opmn and all managed processes...
$ $GRID_HOME/opmn/bin/opmnctl status
Processes in Instance: EnterpriseManager0.eddnr5p0.us.oracle.com

-------------------+--------------------+-------+---------
ias-component | process-type | pid | status
-------------------+--------------------+-------+---------
WebCache | WebCacheAdmin | 14459 | Alive
WebCache | WebCache | 14467 | Alive
OC4J | OC4J_EM | 14456 | Alive
OC4J | home | 14455 | Alive
dcm-daemon | dcm-daemon | 14207 | Alive
LogLoader | logloaderd | N/A | Down
HTTP_Server | HTTP_Server | 14282 | Alive
Note: This procedure only refuses HTTP upload traffic to the OMS. It does not affect HTTP
traffic to the EM application which renders the Grid Control console, nor does it prevent access
to the agent_download script. Depending on your security requirements, you may also want
to secure access to the EM application. To do so, follow standard practices for securing a Web
application deployed to the Oracle Application Server. Refer to the Oracle Application Server
Security Guide for more information on securing Web applications.
To restore the OMS’ ability to receive nonsecure uploads on the original upload port:
2. Unlock the OMS using emctl secure unlock.

Securing OMS–OMR Communications
To secure communications between the OMS and OMR,

enable the Oracle Advanced Security Option (ASO) for:
1. OMR
2. OMS
3. OMA monitoring the OMR database
Securing OMS–OMR Communications

Grid Control uses Oracle Advanced Security Option (ASO) to encrypt communications between
the OMS and OMR. Implementing ASO for Grid Control involves three steps:
1. Enable ASO for the OMR database.
2. Enable ASO for each OMS.
3. Enable ASO for the management agent monitoring the OMR.

Enable ASO for the OMR
Modify ORACLE_HOME/network/admin/sqlnet.ora
to request encryption:
• SQLNET.ENCRYPTION_SERVER
• SQLNET.CRYPTO_SEED
SQLNET.ENCRYPTION_SERVER=REQUESTED
SQLNET.CRYPTO_SEED="abcdefg123456789"
OMR
Enable ASO for the OMR

ASO is configured through the sqlnet.ora configuration file located in
ORACLE_HOME/network/admin. Add two entries to this file:
SQLNET.ENCRYPTION_SERVER=REQUESTED
The cryptographic seed key must be between 10 and 70 characters in length. Do not add
SQLNET.ENCRYPTION_TYPES_SERVER.

Enable ASO for Each OMS
ASO for the OMS is configured through entries in

ORACLE_HOME/sysman/config/emoms.properties.
oracle.sysman.emRep.dbConn.enableEncryption=TRUE
oracle.net.encryption_types_client=(DES40C)
oracle.net.encryption_client=REQUESTED
Stop and restart the OMS to implement the new

parameters.
Enable ASO for Each OMS

Enable ASO connections for the OMS by adding the following entries to:
ORACLE_HOME/sysman/config/emoms.properties:
Parameter Remarks
oracle.sysman.emRep.dbConn. Enables encryption of OMS/OMR database

enableEncryption connections
oracle.net. Type/length of encryption. DES56C, DES40C,
encryption_types_client RCA_40, RCA_56, RCA_128 and RCA_256 are
supported. 3DES and AES are not supported in the
current release.
oracle.net.encryption_client Requests an encrypted connection if the database
server supports it

Enable ASO for the OMA
Create AGENT_HOME/network/admin/sqlnet.ora as
a text file with the following entry:
• SQLNET.CRYPTO_SEED
Enable ASO for the OMA

Create a text file called sqlnet.ora in AGENT_HOME/network/admin. Add one entry to
this file:
The cryptographic seed key should match the entry in the OMR’s sqlnet.ora file.

Securing Product Control Consoles
Stand-alone Database Control and Application Server

Control consoles may also be configured for secure
operation:
• Stop the stand-alone console:
– emctl stop iasconsole
– emctl stop dbconsole
• Secure the stand-alone console:
– emctl secure em (for Application Server Control)
– emctl secure dbconsole (for Database Control)
• Start the stand-alone console:
– emctl start iasconsole
– emctl start dbconsole
Securing Product Control Consoles

Application Server installations have their own Enterprise Manager control console (Application
Server Control). Database installations may opt to install their own control consoles (Database
Control).
To secure Application Server Control:
1. Stop Application Server Control.
$ emctl stop iasconsole
Oracle Enterprise Manager 10g Application Server Control 9.0.4.0.0
Stopping Oracle 10g Application Server Control .. Stopped.
2. Secure Application Server Control.

$ emctl secure em

Securing Product Control Consoles (continued)
Generating Standalone Console Java Keystore... Done.
Fetching Standalone Console Root Certificate... Done.
Generating Standalone Console Agent Key... Done.
Storing Standalone Console Agent Key... Done.
Generating Oracle Wallet for the Standalone Console Agent... Done.
EMD_URL set in /u01/app/oracle/product/10.1.0/asj2ee_1/sysman/
config/emd.properties
Configuring the website ... Done.
Updating targets.xml ... Done.
3. Start Application Server Control.

$ emctl start iasconsole
Starting Oracle 10g Application Server Control ..... Started.
To secure Database Control:

1. Stop Database Control.
$ emctl stop dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.1.0.2.0
http://eddnr5p4.us.oracle.com:5500/em/console/aboutApplication
Stopping Oracle Enterprise Manager 10g Database Control ..Stopped.
2. Secure Database Control.

TZ set to US/Pacific
http://edrsr10p1.us.oracle.com:5500/em/console/aboutApplication
Enter Enterprise Manager Root Password :
Enter a Hostname for this OMS : edrsr10p1.us.oracle.com
Checking Repository... Done.

Checking Repository for an existing Enterprise Manager Root Key...
Done.
Generating Enterprise Manager Root Key (this takes a minute)...
Done.
Fetching Root Certificate from the Repository... Done.
Generating Registration Password Verifier in the Repository...
Done.
Updating HTTPS port in emoms.properties file... Done.
Generating Java Keystore... Done.
Securing OMS ... Done.

Securing Product Control Consoles (continued)
Generating Oracle Wallet Password for Agent.... Done.
Generating wallet for Agent ... Done.
Copying the wallet for agent use... Done.
Storing agent key in repository... Done.
Storing agent key for agent ... Done.
Configuring Agent...
EMD_URL set in
/u01/app/oracle/product/10.1.0/db_1/edrsr10p1.us.oracle.com_orcl/s
ysman/config/emd.properties
Configuring Agent ... Done.
Configuring Key store.. Done.
Note: When prompted for the Enterprise Manager Root Password, enter the SYSMAN password
for the database. Do not enter the SYSMAN password for Grid Control. When prompted to enter
the “hostname for this OMS” enter the hostname of the server hosting Database Control,
not the Grid Control OMS.
3. Start Database Control.

emctl start dbconsole
TZ set to US/Pacific
https://edrsr10p1.us.oracle.com:5500/em/console/aboutApplication
Starting Oracle Enterprise Manager 10g Database Control
...................Started.
Note: Database Control continues to use the original port assigned during the installation. The
protocol simply changes from HTTP to HTTPS. Because the certificate generated during this
procedure is not from a commonly recognized certificate authority, you will receive a warning
when accessing Database Control. Remember that SSL encryption does not require that a
certificate be issued by a recognized authority. You can ignore the warning and connect to
Database Control.

Working Through Firewalls
If there is a firewall between the OMS and management

agents, you can do either of the following:
• Configure OMA and OMS to communicate via a
proxy server.
• Open ports in the firewall so that the OMA and
OMS may communicate directly.
OC4J
EM
Web OHS
Proxy server Cache OMS
Working Through Firewalls

If a management agent is separated from the management service by a firewall, there are two
possible solutions to permit communications between the two components.
The simplest is to open ports in the firewall so that the management service can communicate
with the management agent on the management agent’s port (usually port 1830 or 1831) and so
that the management agent can communicate with the management service via the upload port
(usually port 4889 or 4888). Because each new port opened in a firewall opens another avenue
for attack of the protected network, network administrators rarely wish to implement this
solution.
A frequently used solution that supports a more secure network is to have the two components
communicate via a proxy server.
Enabling communication via a proxy server requires configuring both the OMA and the OMS.

Configuring the OMA for
Proxy Communication
To configure the OMA so that it communicates via a

proxy server, perform the following steps:
2. Add proxy information to
AGENT_HOME/sysman/config/emd.properties:
– REPOSITORY_PROXYHOST
– REPOSITORY_PROXYPORT
Proxy server
Configuring the OMA for Proxy Communication

Configuring the management agent to communicate via a proxy server requires:
1. Stopping the management agent:
$ $AGENT_HOME/bin/emctl stop agent
2. Editing AGENT_HOME/sysman/config/emd.properties:
REPOSITORY_PROXYHOST=www-proxy.mycompany.com
REPOSITORY_PROXYPORT=80
3. Starting the management agent:
$ $AGENT_HOME/bin/emctl start agent
With this configuration, the OMA will send all upload requests to the proxy server, and the
proxy server is then responsible for forwarding the request to the OMS. Because the Grid
Control framework uses industry-standard HTTP and HTTPS protocols, no special hardware or
proxy device is required.

Configuring the OMS for
Proxy Communication
To configure the OMS so that it communicates via a

proxy server, perform the following steps:
1. Stop the OMS.
2. Add proxy information to
GRID_HOME/sysman/config/emoms.properties
3. Start the OMS.
OC4J
EM
Web OHS
Proxy server Cache OMS
Configuring the OMS for Proxy Communication

To configure the OMS so that it uses a proxy server to communicate with the OMA, perform the
following steps:
1. Stop the OMS:
2. Add proxy information to GRID_HOME/sysman/config/emoms.properties:
proxyHost=www-proxy.mycompany.com
proxyPort=80
dontProxyFor=.secureDomain, .otherDomain, …
Add addresses for management agents within the firewall (servers not requiring proxy
communications) to the dontProxyFor list.
3. Start the OMS:

Authenticating Grid Control
Administrators
Grid Control administrators are:

• Authenticated as OMR database users
• Created and managed through the Grid Control
console
If desired, administrators may be created, managed,
and authenticated via Oracle Single Sign-On.
Authenticating Grid Control Administrators

When Grid Control is first installed, there are three preconfigured Grid Control administrators:
• SYSMAN (the Enterprise Manager root user)
• SYS
• SYSTEM
These three users correspond to three database users in the OMR database. When a Grid Control
administrator logs in to the Grid Control console, the login is performed at the database level.
While Grid Control users may only be created through the Grid Control interface, their
passwords may be changed either in the database or through Grid Control.
If your grid includes Oracle Single Sign-On (SSO) you may choose to use this service to manage
Grid Control administrators. With SSO, a Grid Control administrator only needs to log in once
and can then access multiple OMSs, as well as other applications registered through
Single Sign-On.

Oracle Single Sign-On
• Single Sign-On (SSO) is a component of Oracle

Application Server that enables users to log in to
Web applications using a single username and
password.
• Configuring Grid Control to use Single Sign-On is
a two-step process:
1. Configure the OMS to use SSO.
2. Add Grid Control users.
Oracle Single Sign-On

In the Internet environment, you must remember a username and password to authenticate and
access any application. As the number of Web application increases, the number of usernames
and passwords also increases. It becomes very difficult to manage multiple usernames and
passwords. Oracle Single Sign-On (SSO) solves this problem for you.
SSO enables you to gain access to multiple applications for which you have registered using a
single username and password. Once authenticated by SSO, you can access all the applications
you have registered without reentering a username and password.
Oracle Single Sign-On provides many benefits:
• Reduced administrative and management costs because you do not have to manage
multiple user accounts
• Easier login for end users because they have to remember only one username and password
• Improved security because users need only one username and password and are thus less
likely to use simple passwords or to write these passwords down
Since Grid Control is a Web application, SSO may be used to authenticate Grid Control users.
Note: SSO is discussed in detail in the course Oracle Application Server 10g: Administration I.

Configuring the OMS for SSO
To configure the OMS to use SSO:

1. Stop the OMS.
2. Reconfigure the OMS to use SSO.
3. Start the OMS.
emctl config sso -

–host <SSO Server> - OC4J
EM
–port <SSO DB Listener Port> -
–sid <SSO DB SID> -
–pass <DB password for orasso> -
Web OHS
–das <URL for OIDDAS server> Cache OMS
Configuring the OMS for SSO

To configure Grid Control so that administrators are authenticated using Single Sign-On:
1. Stop the OMS:
2. Reconfigure the OMS to use SSO (all on one line):
$ $GRID_HOME/bin/emctl config sso -
–host ssoserver.mycompany.com -
–port 1521 –sid iasdb –pass orassopassword -
–das http://iasinfrastructure.mycompany.com:7777
3. Start the OMS:
Note: To find the password for the orasso database user, refer to “Obtaining the Single
Sign-On Password” in the Oracle Application Server Single Sign-On Administrator’s Guide.

Enterprise User Security
• With Enterprise User Security, database users are

authenticated through a centralized directory.
• Instead of storing management credentials for
each target database, the OMS may be configured
to use Enterprise User Security.
Grid
Control
Oracle Internet
Directory

Each Oracle database typically has its own store of user information, including usernames,
passwords, and privileges. With Enterprise User Security, a central repository of user
information is maintained in the Oracle Internet Directory (OID). Database users need only be
created once within OID and given the appropriate privileges to have access to multiple
databases.
Like Single Sign-On, Enterprise User Security simplifies administration because only one store
of user information must be kept up to date. Also like Single Sign-On, users are more likely to
use a password that is secure since they will need to remember only one password for all the
databases they connect to. Unlike Single Sign-On, the database user must authenticate for each
database connection.
Grid Control stores credentials for each managed database target. If a password changes at the
managed target, Grid Control will be unable to connect and must prompt the administrator to
enter the password unless the stored credentials are manually updated. In organizations where
Enterprise User Security is deployed, Grid Control can leverage the user information stored with
Enterprise User Security instead of maintaining a separate set of credentials for each database.

Configuring the OMS for
To configure an OMS for use with Enterprise User

Security, perform the following steps:
2. Edit emoms.properties to enable Enterprise User
Security.
3. Start OMS services.
OC4J
EM
Web OHS
Cache OMS
Configuring the OMS for Enterprise User Security

Each OMS must be configured for use with Enterprise User Security.
1. Stop all OMS services:
2. Edit GRID_HOME/sysman/config/emoms.properties. Add the following entry:

oracle.sysman.emSDK.sec.DirectoryAuthenticationType=EnterpriseUser
3. Start OMS services:

The next time you attempt to drill down to a managed database, Grid Control will attempt to
connect to the target database through Enterprise User Security. If the connection is unsuccessful,
Grid Control will prompt for database credentials.

Demonstration
This demonstration shows you how to configure

management services to accept secure uploads.
Demonstration
During the practice session for this lesson, you will configure your management agents to
communicate securely with the Oracle Management Service. Before the OMAs can be
configured for secure communications, the OMS must first be configured to accept secure
uploads.
In this demonstration the instructor will perform the following steps:
2. Execute emctl secure oms:
a. Enter the SYSMAN password.
b. Specify the Agent Registration Password.
c. Enter the fully qualified host name of the OMS.
4. Retrieve the secure upload port by executing emctl secure status.
5. Test the secure upload port by connecting via a Web browser:
https://<oms host>.us.oracle.com:<secure port>/em/upload

Summary

• Enable secure communications throughout the
Grid Control framework
• Configure Grid Control for use with proxy servers
and through firewalls
• Authenticate Grid Control administrators using
Single Sign-On
• Configure Grid Control for use with Enterprise
User Security


• Configuring the OMA for secure communications
between the OMA and OMS
• Verifying communications are secure

Practice 16: Grid Control Security
Background
The data uploaded by the Oracle Management Agent reveals extensive information about system
configuration and performance. In most cases, the upload data stream should be encrypted to
ensure security of the data.
Tasks
• Stop the OMA
• Configure the OMA for secure uploads
• Check the OMA’s status
1. Your agent registration password for this class is grid10g.
2. Stop your OMA.
3. Configure your OMA for secure uploads. Execute the following command:
./emctl secure agent
Note: Your instructor should have configure the OMS for secure uploads. If he/she has not
performed this task, he/she needs to complete that task before you can complete this step.
4. Start your agent again. Execute the following command:

./emctl start agent
5. Verify that your OMA is now operating in secure mode.

EM2Go

Objectives

the following:
• Connect to EM2Go
• Navigate the EM2Go interface
• Identify supported browsers for EM2Go
• Use EM2Go to monitor and administer managed
targets

Administer from Anywhere
• Grid administration is often a 24/7/365.25 task.

• Organizations that require round-the-clock system
availability address the need for administration in
different ways:
– Rotating shifts of on-site administrators
– On-call administrators
• EM2Go enables on-call administrators to monitor
and administer the grid remotely.
Administer from Anywhere

Business-critical systems require administrators to be available at any time to respond to failures
and performance issues. Companies address the need for round-the-clock administrator access in
different ways.
Some companies with large IT staffs simply create rotating shifts of administrators, so that at any
given time there are sufficient people present to respond to any problem. Large companies with a
global presence often spread system administration among different technology centers around
the globe so that at any given time at least one center is available to respond to problems.
Round-the-clock on-site administration is expensive and can be cost-prohibitive for many
companies. Keeping someone from each area of IT specialization on site is often impractical.
Many companies will staff an after-hours trouble desk with a single person to detect problems,
and have staff on call to respond when needed. For those companies, there is usually a need to
provide some capability to administer the system remotely.

EM2Go
Access Grid Control’s

EM2Go with any wireless
device using Microsoft
Pocket Internet Explorer:
• Requires no special
configuration
• Includes the most critical
functionality of Grid
Control
EM2Go
One way to provide remote access system administration is through EM2Go, which is a version
of the Grid Control application specifically designed for the small screen.
Connect to EM2Go with a portable device running Microsoft Pocket Internet Explorer. EM2Go
does not provide full access to all Grid Control functions, but does allow an administrator to
perform most critical tasks, including reviewing host configuration information, identifying top
resource consumers, starting and stopping database and listener targets, reviewing alert
notification for all targets, and carrying out most common database administration tasks.

Administering EM2Go
EM2Go requires:
• No separate installation
• No special configuration
• No extra administration
• No additional servers
Administering EM2Go
EM2Go is automatically installed and configured when the OMS is installed. There is no
separate configuration or administration required. Simply connect to Grid Control at the usual
Grid Control URL with a supported browser to access EM2Go.

Navigating EM2Go
• The EM2Go home page

is divided into:
– Alerts and Availability
– Targets
– Jobs
• Tap underlined links
to drill down for more
information
• Use horizontal and vertical
scrollbars to view large pages
Navigating EM2Go
Unlike the Grid Control console, EM2Go is not divided into tabs of property pages. Instead, the
initial home page presents an overview of the most critical information for an on-call
administrator:
• What targets are down?
• How many alerts are current? How severe are they?
Tapping the underlined link next to each alert category opens the corresponding target home
page.
The EM2Go home page also presents links to the different types of targets (similar to the Targets
properties page in the Grid Control console). Tapping a target type opens the summary page for
that target type.

Target Home Pages
Target home pages display:

• Target availability
• Alert and policy violations
• Performance summaries
You tap a target name to drill down
to the target home page.
Target Home Pages

Use the search function to narrow down the list of targets. Simply enter a portion of the target
name and tap Go. If your search narrows the list of targets to a single target, EM2Go
immediately takes you to the home page for that target. If multiple targets satisfy the search
criteria, EM2Go displays a summary of the targets that includes the target name, availability, and
target type. Tapping an underlined target name takes you to the target properties page. Drill-
down capability is not available for targets that are not underlined.
The target home page displays appropriate options for the selected target type. For database
targets, the home page allows an administrator to start and stop the database, solve out-of-space
problems with tablespaces, resolve lock conflicts, and much more.
A listener home page provides statistics on listener performance and allows you to start or stop
the listener.
Application server targets do not have individual home pages. The summary list of application
server provides availability and performance information including CPU and memory
consumption.

Administering Databases with EM2Go
EM2Go supports all critical DBA tasks:

• Monitoring performance and alerts
• Checking and modifying initialization parameters
• Monitoring user sessions
– Top SQL, Active SQL
– Blocking locks
– Kill sessions
• Administering storage structures
– Tablespaces and data files
– Redo logs
• Executing ad hoc SQL
Administering Databases with EM2Go

Although EM2Go provides access to a subset of the full Grid Control monitoring capabilities, it
provides them in an intuitive, easy-to-navigate graphical interface. The EM2Go interface
includes all commonly required DBA tasks. Additionally, access to the complete spectrum of
DBA tasks is available with the ability to execute ad hoc SQL commands.
EM2Go pages enable DBAs to:
• View alert log contents
• Monitor performance trends
• Modify initialization parameters
• Execute ad hoc SQL commands (and return the results of those commands)
• Monitor database locks and (when necessary) identify and clear blocking locks
• Identify Top Sessions and Top SQL
• Administer all database files including control files, data files, and redo log files
• Control rollback segments

Resolving Database Issues with EM2Go
EM2Go enables remote administration of databases.

1 3 4
Resolving Database Issues with EM2Go

EM2Go lets the on-call administrator manage almost all database functions.
In the example in the slide, you use EM2Go to resolve a common problem with an instance:
1. EM2Go alerts you to a problem with one of your databases. There is a session that is
blocking two other sessions. You need more information than the alert provides, so you
select Database Locks from the list of available links and tap GO.
2. EM2Go automatically displays blocking locks first since they are most likely to be of
interest to the administrator. You can see that session 252 is blocking sessions 265 and 241.
You tap session 252 for more information.
3. Session 252’s home page reveals that the session is currently inactive and idle. The last
activity for this session occurred several hours ago. Your business rules allow you to
terminate inactive sessions that are blocking other users, so you tap Kill Session.
4. EM2Go confirms that you really want to kill the session and offers you the opportunity to
allow the session to complete its current transaction. You choose to kill the session
immediately and tap Yes.

Administering Hosts with EM2Go
EM2Go enables remote administration of host servers.

1 4
3 6
Administering Hosts with EM2Go

EM2Go lets the on-call administrator manage many host functions remotely, including
monitoring performance and alerts, identifying top processes, tracking metric trends, and
executing operating system commands.
In the example in the slide, you use EM2Go to resolve a problem with a host server:
1. EM2Go alerts you to a problem with one of your host servers. The file system is filling up
(only 19% remains free).
2. You need more information than the alert provides, so you select Execute OS Commands
from the list of available links and tap GO.
3. Security for operating system commands is provided by requiring a host login. You log in
to the server as the super user.
4. A little investigation reveals that there are over 4 GB worth of trace files in the ORCL
background dump destination.
5. You determine that the trace files are not needed and delete them to free up disk space.
6. The background dump destination now consumes only 100 KB of disk space.
EM2Go executes any noninteractive host commands that are available to the operating system
user that you log in as. Although you are not able to use GUI tools or edit text files, you can
perform many of the most critical tasks needed for remote host administration.

Administering Application Servers
with EM2Go
EM2Go provides:
• Availability monitoring
• Alert reporting
• Performance summaries
Administering Application Servers with EM2Go

You may use EM2Go to monitor application servers including verifying availability, reviewing
alerts, and checking CPU and memory usage.
Individual application server components are stopped, started, and restarted in EM2Go through
opmnctl commands issued as host operating commands

Summary

• Connect to EM2Go
• Navigate the EM2Go interface
• Identify supported browsers for EM2Go
• Use EM2Go to monitor and administer managed
targets

Extending and Customizing Grid Control

Objectives

the following:
• Add user-defined metrics
• Monitor custom targets
• Produce custom reports

User-Defined Metrics
Grid Control supports two types of user-defined

metrics:
• Operating system metrics
• Database metrics
User-Defined Metrics
Grid Control monitors a rich set of metrics, but there is often a need to monitor a metric that is
uniquely important to your system. With user-defined metrics, you can extend the reach of
Enterprise Manager’s monitoring to conditions specific to your particular environment.
Grid control supports two types of user-defined metrics: operating system and database.
Operating system user-defined metrics are derived through monitoring scripts. Database user-
defined metrics are derived through SQL statements.
Adding a user-defined metric to Grid Control is a simple matter of creating an operating system
script or crafting a SQL statement that monitors the condition you are interested in, then telling
Grid Control to run the script or statement at periodic intervals.
Once a user-defined metric is defined, the results are collected at a specified interval and stored
within the Oracle Management Repository. With the exception of real-time monitoring, all other
monitoring features (namely, threshold-based alerting, proactive notifications, historical
collections and analysis, seamless integration with the Grid Control) are automatically available
to the metric. If you already have your own library of custom monitoring scripts, you can
leverage these monitoring features by integrating your scripts as user-defined metrics.

User-Defined Operating System Metrics
Monitoring an operating system user-defined metric

with Grid Control is a two-step procedure:
1. Create a script to monitor the desired condition.
2. Create a user-defined metric in Grid Control that
uses your custom script.
User-Defined Operating System Metrics

To add a user-defined operating system metric, perform the following steps:
1. Write an operating system script that monitors the condition you are interested in.
2. Instruct Grid Control to execute the script periodically and monitor the results.

Operating System Monitoring Scripts
• Scripts may be written in any scripting language

that is supported on the platform you are
monitoring.
• Place scripts in a directory where the OMA has full
access privileges to read and execute.
• Scripts should perform the following functions:
– Check the status of the monitored object.
– Evaluate the results of the status check.
– Return results to Grid Control in the proper format.
em_result=<numeric value>
em_message=<message describing script result>
Operating System Monitoring Scripts

The monitoring script may be written in any scripting language that is supported by the platform
being monitored. Once the script is created, ensure that it is executable and place it in a directory
where the Oracle Management Agent has sufficient permissions to read and execute the script.
The script must produce output in a format that Grid Control can understand. The results of the
script should be printed to standard output using the script output tag em_result. The output is
checked for the first em_result encountered. Subsequent result tags are ignored.
A simple monitoring script for a Linux system might check the amount of free system memory
and contain the following command:
cat /proc/meminfo|grep MemFree|awk '{print "em_result="$2}'
When this script is made executable and is run, it produces output that meets the requirements
for a user-defined metric:
$ chmod 755 getfreemem.sh
$ ./getfreemem.sh
em_result=14292

Operating System Monitoring Scripts (continued)
The script may also return a descriptive text message to Grid Control. Text messages are
displayed as alerts and must be preceded with the script output tag em_message. If no message
output tag is included in the script, Grid Control automatically generates a message using the
format em_message=The value is $em_result. Continuing with the example on the
preceding page, you could modify your script to check the results and, if they are too low,
produce an error message:
FREEMEM=$(cat /proc/meminfo|grep MemFree|awk '{print $2}')
LOW_LIMIT=15000
echo em_result=$FREEMEM
if [ $FREEMEM -lt $LOW_LIMIT ]; then
echo "em_message=Free Memory is low"
fi
Now when the script is run:
$ ./getfreemem.sh
em_result=14292
em_message=Free Memory is low
Note: As delivered, Grid Control monitors operating system memory usage along with most
other metrics in which a system administrator is likely to be interested. This example is for
illustration purposes only.

Creating the User-Defined
Operating System Metric
Creating the User-Defined Operating System Metric

To add an operating system user-defined metric, perform the following steps:
1. Navigate to the host target that you want to monitor.
2. Click User-Defined Metrics in the Related Links region of the host’s home page.
3. Click Create.
4. Define the new metric by entering a metric name, the type of data being monitored, and the
script that is to be executed to collect the metric data, including the path. Do not use
environment variables to indicate the script path.
5. Enter the operating system credentials that are to be used to execute the script.
6. Enter the thresholds used to produce alerts, as well as the comparison operator for those
thresholds. Because you are monitoring free memory in this case, you are most concerned
if the result drops below the threshold values, so select < (less than). If you are monitoring
a very volatile metric, you can reduce the number of false alerts by configuring Grid
Control to alert you only if a certain number of consecutive readings cross the threshold
boundary.
7. Schedule collection of the metric data. The smallest allowed collection interval is five
minutes.
8. Click OK to create the user-defined metric.

Database User-Defined Metrics
To monitor a database user-defined metric:

1. Write a SQL statement that checks the condition
you are interested in.
2. Create a user-defined metric in Grid Control that
executes the SQL statement.
Database User-Defined Metrics

With user-defined database metrics, you can extend Grid Control to monitor virtually any
condition within your database. Adding a new database metric involves writing a SQL statement
to check the condition you want to monitor, and then adding a user-defined metric that executes
that statement at periodic intervals and collects the results.
The SQL statement must return a single value: a single column on a single line. Unlike operating
system monitoring scripts, the SQL statement should not return results with a monitoring tag. All
that is required is the result set.
For example, suppose you want to monitor the number of users consuming space in the
temporary tablespace. Your SQL statement might be as simple as:
SQL> SELECT sum(current_users) FROM v$sort_segment;
Your monitoring statement can return numeric or text values. Statements may include aggregate
functions such as sum or avg. They may also call stored PL/SQL functions.
While the example show above monitored something of interest to the DBA, you may create
user-defined metrics to monitor business data as well. For example, if the count of orders with a
promised delivery date less than the system date is greater than five, you might want to notify
someone in shipping about the problem.

Creating the User-Defined Database Metric
Creating the User-Defined Metric

To create a user-defined database metric, perform the following steps:
1. Navigate to the database target you want to monitor.
2. Click User-Defined Metrics in the Related Links region of the database’s home page.
3. Click Create.
4. Enter the name of the metric you want to add, the type of data to be returned, and the SQL
statement you crafted to monitor the condition you are interested in.
5. Enter the database username and password that are to be used to execute the SQL statement.
6. Enter a comparison operator, warning threshold, and critical threshold. If this is a volatile
measurement, you may want to require multiple consecutive occurrences of a threshold
violation before an alert is generated.
7. Enter a collection schedule for the metric. The minimum possible collection interval is five
minutes.
8. Click OK to create the metric.

Viewing User-Defined Metrics
Viewing User-Defined Metrics

To view your user-defined metric, click User-Defined Metrics in the Related Links region of the
host or database home page to view a list of custom metrics for that target. Then click the metric
that you want to examine.
No data appears until at least three samples of the metric have been taken.

Monitoring Custom Targets
Grid Control can be extended to monitor custom

targets such as:
• Routers
• Load balancers
• Proxy servers
• Storage devices
• Software
Monitoring Custom Targets

Grid Control monitors most components of the grid automatically. Because of the wide variety
of systems in use, however, there are often additional components (both software and hardware)
that may be of interest.
In some cases, these additional components can be monitored through the use of simple user-
defined operating system metrics. For example, if you want to monitor the availability of the
XYZ software component, you might add an operating system metric that uses XYZ’s control
utility to check status and to alert you if the result is not equal to running.
In many cases, you want to monitor a more complex set of metrics that are already produced by
the target of interest. With Grid Control, you can define a custom target for those cases. When
you define a custom target, you may leverage several common monitoring APIs to extract
information about the target you want to add, including:
• SQL
• SNMP (Simple Network Monitoring Protocol)
• DMS (Dynamic Monitoring Service)
• HTTP
• XML
• CIMOM (Common Information Management Object Model)

Adding a Custom Target
To add a custom target to Grid Control, perform the

following steps:
1. Create the target-type metadata file.
2. Set up default metric collections.
3. Validate the new target-type definitions.
4. Add new target instances to the Grid Control
framework.
Adding a Custom Target

Before a custom target can be added to Grid Control, you must first describe the custom target.
This involves creating two XML files:
• Target-type metadata file: This file describes the target to be modified and lists all
metrics that are to be monitored, along with how those metrics are collected and computed.
• Target-type default collections file: This file describes the default threshold values for
each metric defined in the target-type metadata file. It also contains the default collection
interval. Although these defaults may be overridden after a new target instance is added to
Grid Control, the default file must exist.
Once these two files have been created, use the metric browser (a subsystem of the OMA) to test
the validity of the two files and ensure that metrics described in the metadata file can be
successfully retrieved.
After the new target type files have been validated, you can add new instances of the target using
the Grid Control console.

Target-Type Metadata File
The target-type metadata file contains:

• Target description
• Metrics that Grid Control monitors for the new
target type
• Methods used to retrieve and compute those
metrics
Target-Type Metadata File

Each type of target monitored by Grid Control must have a metadata file that describes the target,
enumerates the metrics monitored for the target, and explains how to collect and compute those
metrics.
These files are stored in $AGENT_HOME/sysman/admin/metadata and must match the
documentation type declarations (DTD) stored in $AGENT_HOME/sysman/admin/dtd.
Constructing a properly formatted target-type metadata file requires substantial background
knowledge about XML and related technologies and is beyond the scope of this course.
For more information about XML, see the course titled Oracle 10g: XML Fundamentals for
Developers.

Target-Type Default Collections File
The target-type default collections file:

• Includes default warning and critical thresholds
for each metric
• Tells the OMA how frequently to collect the
metrics
Target-Type Default Collections File

The target-type default collections file must have the same name as the target-type metadata file
and must be placed in $AGENT_HOME/sysman/admin/default_collection.
Each metric defined in the target-type metadata file must appear in the target-type default
collections file. The default collections file includes the collection interval, default threshold
values (both warning and critical), comparison operator, and alert message for each metric.
The two files should have the same name. For ease of maintenance, you should choose a name
that describes the target type being added. For example, if you are adding a new target type
called “Potato Server,” you might name both files potato_server.xml.

Validating New Target Definitions
Validate new target definitions for proper format and

content:
1. Validate target definitions with iLINT.
2. Add a target instance of the new type.
3. Enable the Metric Browser and validate metrics.
Validating New Target Definitions

Before putting a custom target definition in production, you should make sure that the target-
type metadata XML file that you created correctly accesses the target and returns information.

Validating Target Definitions with iLINT
Validate new target definitions for proper format:
$AGENT_HOME/bin/emctl ilint -
-o collection_test -d 0 -
-m new_target_metadata.xml -
-i na
Validating Target Definitions with iLINT

Use the Integrated Lexical Interpreter (iLINT) to validate the target metadata and default
collections XML files. iLINT is a component of the Enterprise Manager Control Utility that can
be used to validate the target metadata and default collections XML files.
iLINT requires four arguments to validate XML files:
• –o <test name>: User-assigned name of the test being performed. Using –o <test
name> instructs iLINT to automatically locate the required files instead of using fully
qualified paths.
• -i <instance name> : If the test is being performed on a monitored component,
which target description file describes the component being checked? Because this is a
static test with no components added to Grid Control, specify na for not applicable.
• -d <diagnostic level>: iLINT supports four levels of diagnostic checking:
- 0: Error messages only
- 1: Warning and error messages
- 2: Informational messages only
- 3: Debug (all messages)
For status checks of XML files, select a diagnostic level of 0.
• -m <name of the file being checked>: The name of the new target metadata
file. The file must be located in $AGENT_HOME/sysman/admin/metadata.

Validating Target Definitions with iLINT (continued)
iLINT checks the target definition files and informs you of any syntactical errors:
$AGENT_HOME/bin/emctl ilint -o test -d 0 -m potato_server.xml
-i na
Copyright (c) 1996, 2004 Oracle Corporation. All rights
reserved.
Not parsing Target Instance File (targets.xml)
2004-04-27 10:11:58 Thread-3052852384 ORAXML-115,
File=/u01/app/oracle/product/10.1.0/agent/sysman/admin/metadat
a/potato_server.xml, Line=3, Msg=LPX-00115: Warning: element
"TargetMetadata" is missing required attribute "TYPE" (01006)
2004-04-27 10:11:58 Thread-3052852384 ORAXML-222,
File=/u01/app/oracle/product/10.1.0/agent/sysman/admin/metadat
a/potato_server.xml, Line=3, Msg=LPX-00222: error received
from SAX callback function (01006)
2004-04-27 10:11:58 Thread-3052852384 ERROR ilint: PARSING OF
TARGET METADATA FAILED
*** Target Metadata File oracle_potato_server.xml FAILED
VALIDATION ***
In the preceding output from iLINT, you can see that the target metadata file failed because it
was missing the TYPE attribute. Editing the file, you see that where the TYPE attribute should
exist, the TAPE attribute occurs instead (a typographical error).
<!DOCTYPE TargetMetadata SYSTEM "../dtds/TargetMetadata.dtd">
<TargetMetadata META_VER="1.0" TAPE="oracle_potato_server">
<Display>
<Label NLSID="potatoserver_name">Potato Server</Label>
</Display>
Edit the file, correct the error, and rerun iLINT:
$AGENT_HOME/bin/emctl ilint -o test -d 0 -m potato_server.xml
-i na
Copyright (c) 1996, 2004 Oracle Corporation. All rights
reserved.
Not parsing Target Instance File (targets.xml)
Validating Target Collection File
/u01/app/oracle/product/10.1.0/agent/sysman/admin/default_coll
ection/potato_server.xml
Validating target metadata file
/u01/app/oracle/product/10.1.0/agent/sysman/admin/metadata/pot
ato_server.xml ...
Target Metadata File potato_server.xml Validated Successfully

Adding New Target Instances
To add a new instance of the custom target:

1. Open the agent’s home page.
2. Select the target type from the Add list.
3. Enter properties for the new target.
Adding New Target Instances

When the target-type metadata and default collections files have been verified and the files have
been copied to the appropriate directories, new targets can be added with the Grid Control
console.
1. Navigate to the home page for the management agent that you plan to use to monitor the
new target type.
2. Click the Add drop-down list. Your new target-type appears in the list of available target
types. Click the target type, and then click Go.
3. Enter the target properties. The list of properties varies from target to target and is defined
in the target-type metadata file.
After entering all properties, click Go to add the target. Monitoring begins immediately, but Grid
Control does not begin displaying statistics for the new target until metrics have been collected
three times (after at least 15 minutes).

Enabling the Metric Browser
http://<OMA host>:<OMA Port>/emd/browser/main
Using the Metric Browser

The Metric Browser is an integral component of the Oracle Management Agent. By default, the
Metric Browser is disabled for security reasons. To enable the browser, edit the OMA
configuration file $AGENT_HOME/sysman/config/emd.properties. Uncomment the
line enableMetricBrowser=true.
While editing the file, locate the following line:
EMD_URL=http://<hostname>:<OMA port>/emd/main/
Then find the OMA port, which is usually port 1831 or port 1830.
With the Metric Browser enabled, restart the management agent and use a Web browser to
connect to the Metric Browser at the following location:
http://<OMA host name>:<OMA port>/emd/browser/main
When you first connect, you see a list of targets that the OMA is monitoring. Click a target to
view the named metric classes being monitored (from the list of metric classes in the target-type
metadata file). Then click a metric name to drill down to the actual values.
After validating the metric descriptions and collection methods from your new target-type
metadata file, you should normally disable the Metric Browser by recommenting the line
# enableMetricBrowser=true.

Producing Custom Reports
• Grid Control’s management repository contains:

– Configuration data
– Historical metric data
– Alert information
– Managed target availability information
• You can mine repository information to generate
custom reports.
Producing Custom Reports

The management repository stores a wealth of information about the grid’s performance,
availability, and configuration. Grid Control uses this information to render the Grid Control
console pages and reports, but the information is also easily accessible through predefined
repository views.
The contents of the management repository can be mined to produce custom reports with
standard tools such as Oracle Reports, SQL*Plus, or any other reporting tool that can access an
Oracle database. By using these custom reports, you can provide pertinent, application-specific
information at the right level of granularity and density for a wide variety of users, including IT
staff, developers, and executives.

Base Views
Grid Control base views present information that is

stored in the management repository in usable form.
Base views are categorized as:
• Central policy views
• Monitoring views
• Inventory views
Base Views
There are over 4,000 objects in the SYSMAN schema, including 354 tables and 249 views. A few
key views—known as the base views—are designed to present information from the management
repository in a form that is both intuitive and directly usable for customized reporting.
The base views are divided into three categories:
• Central policy views: A group of two views providing information on central policies such
as target blackouts and metric collection
• Monitoring views: Eight views providing time-based information about collected metrics
and availability
• Inventory views: A group of ten views providing information on managed targets,
including the target name, type, installed software versions, and configuration information

Central Policy Views
• Central policy views provide information on:

– Blackout schedules
– Metric threshold settings
– Metric collection frequency
• Central policy views are the following:
– mgmt$blackout_history
– mgmt$metric_collection
Central Policy Views

There are two central policy views: mgmt$blackout_history and
mgmt$metric_collection.
• Use mgmt$blackout_history to obtain a record of blackout periods for any managed
targets. This view also provides a list of targets that were blacked out during a given period.
• Use mgmt$metric_collection to provide threshold settings for individual metrics
and metric collection settings on a per-target basis. This view also contains a count of the
number of consecutive times that critical and warning thresholds have been exceeded for
each metric.

Monitoring Views
Eight monitoring views contain time-based information

on:
• Alerts and availability
– Current
– History
• Metric data
– Detail
– Current
– Hourly
– Daily
Monitoring Views
There are eight monitoring views that provide information on alerts, availability, and metric data.
• Availability: Two views provide information about managed target availability, including
the status of the target and the time that the status was reported.
- mgmt$availability_current: One row for each managed target showing the
current status of the target as last reported by the management agent
- mgmt$availability_history: Historical record of status changes for all
managed targets, including the reported status and the time that it was reported
• Alerts: Two views provide information about alerts, including the target the alert applies to,
the metric causing the alert, and the time that the alert was collected.
- mgmt$alert_current: Information about all noncleared alerts that have been
logged with the OMR
- mgmt$alert_history: Historical information about all alerts logged with the
OMR, including when the alert was reported, the status of the alert, and the alert
message
• Metric data: Four views provide information about metric data.
- mgmt$metric_details: A rolling sample of raw metric data collected

Monitoring Views (continued)
during the past 25 hours. This view contains one row for each metric sample taken
during the past 25 hours (typically thousands of rows per target).
- mgmt$metric_current: The last sampled metric value for each monitored
metric on each managed target
- mgmt$metric_hourly: Summary data for each managed target’s metrics for the
past 31 days, grouped by hour. Data is summarized to provide the average, minimum,
maximum, and standard deviation values as well as the number of samples taken
during the hour.
- mgmt$metric_daily: Summary data for each managed target’s metrics for the
past 365 days, grouped by day. Data is summarized to provide the average, minimum,
maximum, and standard deviation values as well as the number of samples taken
during the day.

Metric Data Retention
• Metric data is purged from the management

repository to conserve space:
– Raw data is purged every 7 days.
– Hourly aggregates are purged every 31 days.
– Daily aggregates are purged every 365 days.
• Modify these retention policies by updating the
mgmt_parameters table in the OMR.
Metric Data Retention

Enterprise Manager aggregates your management data by hour and by day to minimize the size
of the management repository. Before the data is aggregated, each data point is stored in a raw
data table. Raw data is rolled up, or aggregated, into a one-hour aggregated metric table. One-
hour records are then rolled up into a one-day table.
After Enterprise Manager aggregates the data, the data is then considered eligible for purging. A
certain period of time has to pass for data to actually be purged. This period of time is called the
retention time.
The raw data with the highest insert volume has the shortest default retention time, which is set
to 7 days. As a result, a raw data point is eligible for purging 7 days after it is aggregated into a
one-hour record. One-hour aggregate data records are purged 31 days after they are rolled up to
the one-day data table. The highest level of aggregation—one day—is kept for 365 days before
being purged.
The results of Application Service Level Management (ASLM) are also aggregated to conserve
space. Retention intervals for ASLM data differ slightly from retention of component metric data,
with raw data retained for 24 hours, one-hour aggregate data retained for 7 days, and one-day
aggregates retained for 31 days.

Metric Data Retention (continued)
To modify the default retention period for metric or ASLM data, add an entry to the
mgmt_parameters table. For parameters with default values, no entry appears in the table.
Data Parameter Default

Value
Component metric data mgmt_raw_keep_window 7 days
One-hour aggregates of metric data mgmt_hour_keep_window 31 days
One-day aggregates of metric data mgmt_day_keep_window 365 days
Raw ASLM response-time data mgmt_rt_keep_window 24 hours
One-hour aggregates of ASLM data mgmt_rt_hour_keep_window 7 days
One-day aggregates of ASLM data mgmt_rt_day_keep_window 31 days
One-hour aggregates of ASLM data mgmt_rt_dist_hour_keep_window 24 hours
One-day aggregates of ASLM data mgmt_rt_dist_day_keep_window 31 days

Inventory Views
Ten inventory views provide information about

managed targets in the grid. These views answer such
questions as the following:
• What types of targets make up the grid?
• How many of a given target type are contained in
the grid?
• What software is installed on a host?
• What is the IP address for each server in the grid?
Inventory Views
There are ten inventory views:
• mgmt$target: Contains a list of managed targets including target name, target type, the
management agent that services the target, the server that hosts the target, and the time at
which the last upload completed
• mgmt$target_type: Provides a list of known target types and associated metrics
• mgmt$target_composite: Contains a breakdown of components belonging to
composite targets. A composite target is a managed target consisting of one or more
components which are also managed targets. An example of a composite target is an Oracle
application server. Each application server includes at least an Oracle HTTP Server and
Oracle Application Container for J2EE, and may include many other components.
• mgmt$target_properties: Provides a list of properties and property values for
managed targets. Different target types are associated with different properties. For
example, database targets have properties such as SID, LOG_ARCHIVE_MODE, and
BACKGROUND_DUMP_DESTINATION. Host targets have properties such as OS,
BOOTTIME, and IP_ADDRESS.
• mgmt$target_components: Lists the software that is installed for a given target,
including version and ORACLE_HOME

Inventory Views (continued)
• mgmt$software_homes: Lists all ORACLE_HOME directories for each host server
• mgmt$software_patchsets: Provides information about software patchsets that
have been applied to an ORACLE_HOME
• mgmt$software_components: Lists all software components that are installed in
an ORACLE_HOME
• mgmt$software_component_patch: Provides information about patches that are
applied to each software component
• mgmt$software_dependencies: Shows dependencies between different software
components

Summary

• Add user-defined metrics
• Monitor custom targets
• Produce custom reports

Extending and Customizing Grid Control

• Adding a user-defined operating system metric
• Adding a user-defined database metric
• Extracting data from the metadata repository

Practice 18: Extending and Customizing Grid Control
Background
As delivered, Grid Control monitors a rich set of metrics, but there is often a need to monitor a
metric that is uniquely important to your system. With user-defined metrics, you can extend the
reach of Enterprise Manager’s monitoring to conditions that are specific to your particular
environment.
Tasks
• Create a user-defined metric for your host
• Create a user-defined metric for your database
• Access information in your OMR
1. Create a user-defined metric for your host called Free_Memory# that runs the
getfreemem.sh script to display the amount of free memory you have.
2. Create a user-defined metric called sort_users# for your database that selects the sum
of current users from v$sort_segments.
3. How many targets are unreachable?
4. How many Oracle homes are there?

High-Availability Options

Objectives
After completing this lesson, you should be able to

describe the high-availability options that are available
for the:
• Oracle Management Repository
• Oracle Management Service

High Availability
Grid Control leverages the standard Oracle 10g

high-availability production options:
• Real Application Clusters
• Application Server Clusters
High Availability
Grid Control leverages the standard Oracle 10g high-availability options.
The Oracle Management Repository (OMR) is hosted within an Oracle database. Use Real
Application Clusters (RAC) to configure a highly available OMR.
The OMR may also take advantage of the Oracle database’s disaster recovery options, including
Oracle Data Guard. With Oracle Data Guard, the repository data can be safeguarded against
catastrophic events such as natural disasters.
The Oracle Management Service serves two purposes:
• Processing information uploads from the management agents and loading that information
into the OMR
• Rendering the Grid Control console
Because in the OMS both of these functions are accomplished using a standard J2EE application,
high availability for the OMS is achieved by clustering the OMS behind a load balancer.

Highly Available OMR
Configure the OMR for high availability and

survivability:
• RAC
• Data Guard
OMR
Standby
Highly Available OMR

Real Application Clusters make the management repository more fault tolerant (higher
availability) and also help the repository scale for better performance.
• Fault tolerance: A RAC uses multiple database instances to open a database. Because the
different instance may be placed on separate servers, any single server failure should not
cause the management repository to be unavailable.
• Scalability: Database listeners on each server listen for all instances in the cluster. When a
listener receives a request to connect to the management repository database, it routes that
request to the instance with the lightest load.

Configuring OMS Connections to a RAC
When using a Real Application Cluster as the OMR:

• Initially configure the OMS to connect to a single
instance of the RAC
• After installation, modify emoms.properties to
enable failover between RAC instances
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(
DESCRIPTION\=(ADDRESS_LIST\=(
ADDRESS\=(PROTOCOL\=TCP)(
HOST\=omr1.mycompany.com)(PORT\=1521))(
ADDRESS\=(PROTOCOL\=TCP)(
HOST\=omr2.mycompany.com)(PORT\=1521)))(
CONNECT_DATA\=(SERVICE_NAME\=emRAC.mycompany.com)))
Configuring OMS Connections to a RAC

When the OMS is installed, there is no option to configure connection failover between RAC
instances. Simply install as if you were connecting the OMS to a single-instance database. After
installation, edit $ORACLE_HOME/sysman/config/emoms.properties. Modify
oracle.sysman.eml.mntr.emdRepConnectDescriptor as follows. Take the
following connect descriptor from a single-instance address connecting to an SID:
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(
DESCRIPTION\=(
ADDRESS_LIST\=(
ADDRESS\=(PROTOCOL\=TCP)
(HOST\=omr1.mycompany.com)(PORT\=1521)))(
CONNECT_DATA\=(SID\=emrep)))
Change it to a multi-instance connect descriptor (with a separate address for each instance)
connecting to the RAC’s SERVICE_NAME, as shown in the slide.
Note: All of the connect descriptor must be entered on the same line. The descriptor shown here
is broken across multiple lines to improve readability.

Highly Available OMS
Configure the Oracle Application Server hosting the

Grid Control application as an Application Server
Cluster to ensure high availability.
WebCache OHS OC4J

EM
Load Balancer
WebCache OHS OC4J

EM
WebCache OHS OC4J

EM
Highly Available OMS

Grid Control is a J2EE application that is hosted by an Oracle Application Server 10g instance.
As with any J2EE application, high availability is ensured through clusters of interconnected
redundant components.
In the diagram in the slide, a load balancer routes incoming requests for the OMS to any of three
OracleAS Web Cache instances. If one of the instances fails, requests are sent to the remaining
two instances.
OracleAS Web Cache routes requests to any of three Oracle HTTP Servers. If one of the servers
fails, requests are sent to the remaining two instances.
The Oracle HTTP Server routes requests to any of three OC4Js, each having the EM application
deployed. If one of the containers fail, requests are routed to the remaining two containers.
With this type of configuration, it takes multiple failures of the same OMS component to disable
Grid Control. There are also high-availability solutions for load balancers that can remove them
as single points of failure.

Configuring OMA Connections to a
Clustered OMS
When connecting an Oracle Management Agent to a

clustered Oracle Management Service, modify
emd.properties to connect through the load
balancer:
REPOSITORY_URL=
https://loadbalancer.mycompany.com:4888/em/upload/
Configuring OMA Connections to a Clustered OMS

When the OMS is converted to a clustered configuration, all existing management agents must
be modified to connect through the front-end load balancer. Edit
$AGENT_HOME/sysman/config/emd.properties and provide the URL for the load
balancer in the REPOSITORY_URL parameter.
Management agents that are added after the OMS has been clustered can be configured to
connect through the load balancer when the agent is installed if you are installing from the
product media. If you are installing using the agentDownload script, you must initially
connect directly to the OMS and later modify emd.properties to connect through the load
balancers..

Summary
In this lesson, you should have learned about the

high-availability options that are available for the:
• Oracle Management Repository
• Oracle Management Service

Migrating to Grid Control

Objectives
After completing this lesson, you should be able to:

• Use legacy releases of Oracle Enterprise Manager
to install the Oracle Management Agent (OMA)
• Migrate legacy Oracle Enterprise Manager
administrator accounts to Oracle Enterprise
Manager 10g Grid Control

Migrating from previous Oracle Enterprise Manager

releases to Grid Control is a two-step process:
1. Deploy the OMA to all managed servers.
2. Migrate existing Oracle Enterprise Manager
administrator accounts to Grid Control.

Enterprises using large numbers of servers and already using a previous release of Oracle
Enterprise Manager may wish to leverage their existing release of Oracle Enterprise Manager to
migrate to Grid Control. Migrating an existing Enterprise Manager framework to the Oracle
Enterprise Manager 10g environment involves two steps:
1. Make targets within your managed environment monitorable using the new framework by
installing Oracle Enterprise Manager 10g management agents on hosts that are running
your managed targets.
2. Migrate information about users, privileges, groups, and preferred credentials from the old
management repository to the new Oracle Enterprise Manager 10g Management
Repository.
Stored jobs, event thresholds, and privileges on targets other than host servers, databases, and
listeners are not transferable from older versions of Oracle Enterprise Manager to Grid Control.
Once you have completed migrating to the new framework, you may wish to change the default
metric thresholds for groups of managed targets within your enterprise and review administrator
privileges on targets that could not be migrated.

Deploying the Management Agents
Legacy releases of Oracle Enterprise Manager can

automate deployment of the OMA by:
• Creating Tool Command Language (TCL) jobs to
install the OMA
• Creating operating system jobs to complete the
postinstallation steps
Deploying the Management Agents

Deploying Oracle Enterprise Manager 10g management agents on machines running targets
managed by an older version of Enterprise Manager makes these targets monitorable with Oracle
Enterprise Manager 10g. To deploy the management agents using older versions of Oracle
Enterprise Manager, you should:
• Create a TCL job that installs the management agents
• Create operating system jobs that run root.sh for the management agents

Automating the OMA Installation
Create a job to install the OMA:
Automating the OMA Installation

Create a new job to install the OMA. Open the Oracle Enterprise Manager 2.2, 9.0.1, or 9.2
console (you must connect to an Oracle Management Service).
1. Click Create Job in the legacy Oracle Enterprise Manager console.
- Name the job agentInstallJob.
- Select the target-type of node.
- Add all nodes where you want to install the Grid Control management agent.
2. Click Tasks, and then select Run TCL Script from the list of available tasks.
3. Click Parameters. In the Parameters field, enter the following parameters (in order):
a. OMS host name
b. OMS HTTP upload port (typically 4889)
c. Directory type (–o <AGENT_HOME directory> if the management agent is installed
in the same directory on all nodes, and –f <file name> if different hosts will use
different directories). For the –f option, you must create a text file that maps nodes to
the appropriate installation directories using the format <node name>
<AGENT_HOME directory>:

Automating the OMA Installation (continued)
NODE02 /u02/app/oracle/product/10.1.0/agent
NODE07 /oracle/agent/agent
NODE13 /oracle/product/10.1.0/agent
* /u01/app/oracle/product/10.1.0/agent
In this case, the job uses the specified directories for the servers named NODE02, NODE07,
and NODE13. For all other servers, the default directory (preceded by *) is used.
Grid Control supplies a TCL script to create the job. Import the contents of
$ORACLE_HOME/sysman/agent_download/agentInstallJob.tcl to the TCL
script window on the Parameters page.
4. Click Schedule and enter the date and time for execution of the job.
5. Click Submit to submit the job for execution.

Postinstallation Requirements
Create a job to run root.sh for each of the newly

installed OMAs:
Postinstallation Requirements
Once the management agents have been installed on all nodes, you must run root.sh on all
UNIX and Linux hosts so that the agents can interact with the operating system to execute Grid
Control jobs.
Create another operating system job using the legacy Oracle Enterprise Manager console. This
time you should select Run OS Command for the task and enter <AGENT_HOME>/root.sh as
the command to be run. If your hosts did not use a common directory as the AGENT_HOME, you
must create separate jobs for each different directory structure.
For Oracle Enterprise Manager 9.2 consoles, override the preferred credentials to run the job as
root. Preferred credential override was new in version 9.2. For Oracle Enterprise Manager 2.2
and 9.0.1, you must run the job as a user with preferred credentials allowing root access.

Migrate Existing Administrator Accounts
Use the repository migration utility (repo_mig) to

transfer the following from a previous release to Grid
Control:
• User accounts with passwords
• Privileges
• Groups
• Preferred credentials.
$ repo_mig –migrate
EM_user/password@old_repository_host:port:sid
sysman/password@OMR_host:port:sid
Migrate Existing Administrator Accounts

Once the management agents have been deployed and configured, the next step is to migrate
information about users, privileges, groups, and preferred credentials from the legacy Oracle
Enterprise Manager repository to the OMR.
The repository migration utility migrates information from legacy repositories to the Grid
Control repository. The utility requires three arguments:
• Action (migrate or preview)
• Source credentials and connect string
• OMR credentials and connect string

Summary

• Use legacy releases of Oracle Enterprise Manager
to install the Oracle Management Agent
• Migrate legacy Oracle Enterprise Manager
administrator accounts to Oracle Enterprise
Manager 10g Grid Control

Putting It All Together

Objectives
After completing this lesson, you should be able to:

• Apply the skills and knowledge you learned
throughout the course
• Solidify tasks performed using Grid Control during
the course
Oracle Enterprise Manager 10g: Grid Control 21-2

Practice 21: Putting It All Together
Background
In this practice, you apply all the skills you learned throughout the course.
Tasks:
• Configure an administrator, assign privileges and set preferences
• Create a Group and evaluate the results
• Manage Metrics
• Create a Blackout
• Create a Job
• Deploy an Application
• Create and Configure a Web Application
1. Create an Administrator called Team#_B. For Team#_B, add your assigned database, the
OMR database and application server and give the administrator ADD ANY TARGET,
USE ANY BEACON and MONITOR ENTERPRISE MANAGER access. Give View,
Operator and Full privilege to all targets except OMR database, OMS and OMR Host and
the OMS and Repository only give View privilege.
2. Logged in as the Team#_B administrator, create a notification schedule for working

8:00A.M. – 3:00 P.M. Monday, Wednesday and Friday. On Tuesday and Thursday, you
work from 12:00P.M. – 6:00P.M. Create a notification schedule so that you receive an
email no matter when you work.
3. Create a database group called dbgroup#_B and add your database as well as another
one from the list.
4. Review the group you just created and answer the following questions:
- Are there any alerts to be concerned about?
- How many policy violations are there?
- Is there any job activity?
- Which database has the most activity?
5. Add your dbgroup#_B to the Target tab and make it first in the list.
6. Create a new tablespace called tblsp#_B and set a Tablespace File Usage (%) threshold for
the new tablespace to a warning of 50% and critical of 68%.
7. Compare the CPU Utilization metric between your assigned database and the OMR
database.
8. Your application server needs to be upgraded. Create a blackout for this target. Verify the
home page.

Practice 21: Putting It All Together
9. Create a Host Command job that lists the location of the agent (pwd) and provide access to
another administrator.
10. Stop the blackout for your application server target.
11. Deploy the FAQ Application.
a. Create an OC4J Instance called FAQ#.

b. Start the FAQ# OC4J instance.
c. Modify the OracleDS datasource and make sure your host and database (orcl) is
specified in the JDBC URL and that the username and password are
faquser/faquser.
d. Deploy the FAQApp.ear file with a URL Mapping of /FAQApp.
e. Create the faquser user and run the script CreateTables.sql to create the
tables needed to run the application.
f. Test the application and generate some activity
12. Create a Web application called FAQApp#.
1. Load some transactions. Transactions are contained in faqapp_txns.

2. Start to monitor your application
3. Define availability and use the same beacon you created earlier
4. Configure end-user response-time monitoring and middle-tier performance
monitoring.
5. Generate some activity.

Summary
In this course, you should have learned how to:

• Install and manage the Grid Control framework
• Utilize additional capabilities provided by Grid
Control over and above those provided by
individual product control consoles
• Follow the steps required to secure the Grid
Control management framework
• Establish ASLM and use it to pinpoint application
performance issues

D17244GC11 - Oracle Enterprise Manager 10g Grid Control Vol 2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D17244GC11 - Oracle Enterprise Manager 10g Grid Control Vol 2

Uploaded by

Copyright:

Available Formats

Oracle Enterprise Manager 10g

Volume II • Student Guide

Aniket Raut This documentation contains proprietary information of Oracle Corporation. It is

Ana Hernandez Restricted Rights Legend

14 Oracle Collaboration Suite Management

15 Managing Your Configuration

16 Grid Control Security

18 Extending and Customizing Grid Control

20 Migrating to Grid Control

21 Putting It All Together

Appendix A: Practice Solutions

Appendix B: Basic Linux and vi Commands

Appendix C: SQL Statement Syntax

Appendix D: Acronyms and Terms

Appendix E: Next Steps – Continuing Your Education

Copyright © 2005, Oracle. All rights reserved.

After completing this lesson, you should be able to do

Copyright © 2005, Oracle. All rights reserved.

Oracle Enterprise Manager 10g Grid Control 12-2

Copyright © 2005, Oracle. All rights reserved.

Monitoring Application Servers Using Grid Control

Oracle Enterprise Manager 10g Grid Control 12-3

Install Separate Application Server 10g

One per host in One per Application Server

Target Type Many Application Server

# of Targets Many One

Server Configuration No Yes

Copyright © 2005, Oracle. All rights reserved.

Grid Control Versus Application Server Control

Oracle Enterprise Manager 10g Grid Control 12-4

Real-Time Monitoring Yes Yes

Job System Yes No

Configuration Management Yes No

Mobil Access via EM2Go Yes No

Copyright © 2005, Oracle. All rights reserved.

Grid Control Versus Application Server Control (continued)

Oracle Enterprise Manager 10g Grid Control 12-5

You access Enterprise Manager differently depending

ashost1 http://<oms_host>.domain:7777/em instance1 http://ashost1.domain:1810

ashost2 http://<oms_host>.domain:7777/em instance3 http://ashost2.domain:1810

Copyright © 2005, Oracle. All rights reserved.

Accessing Grid Control Versus Accessing Application Server Control

Oracle Enterprise Manager 10g Grid Control 12-6

The following tasks can be performed using

Copyright © 2005, Oracle. All rights reserved.

Application Server Control Tasks for Managing Application Servers

Oracle Enterprise Manager 10g Grid Control 12-7

Copyright © 2005, Oracle. All rights reserved.

Administering the Application Server Instance

Oracle Enterprise Manager 10g Grid Control 12-8

J2EE Applications property page

Copyright © 2005, Oracle. All rights reserved.

Reviewing the List of J2EE Applications

Oracle Enterprise Manager 10g Grid Control 12-9

Copyright © 2005, Oracle. All rights reserved.

Centrally Managing Ports

Oracle Enterprise Manager 10g Grid Control 12-10

Infrastructure property page

Copyright © 2005, Oracle. All rights reserved.

Configuring Infrastructure Services

Oracle Enterprise Manager 10g Grid Control 12-11

Copyright © 2005, Oracle. All rights reserved.

• In this course, you perform the following tasks