D17244GC11 - Oracle Enterprise Manager 10g Grid Control Vol 2

Oracle Enterprise Manager 10gGrid Control

Volume II • Student Guide

D17244GC11

Edition 1.1

March 2005

D41403

Copyright © 2005, Oracle. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and 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 applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988).

This material or any portion of it may not be copied in any form or by any means without the express prior written permission of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties.

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 FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).

The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle Parkway, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free.

Oracle and all references to Oracle Products are trademarks or registered trademarks of Oracle Corporation.

All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.

AuthorsAniket RautAbhijit Dass

Technical Contributors:Ana Hernandez Christian Bauwens Christina Mullins Dave LeRoyIrina Goldshteyn Julie Wong Martin Pena Matt Taylor Nagavalli PataballaNicole HabaOlaf Fermum Srinivas PutrevuSudip Datta Valerie K. Kane Yi Lu

GES Contributors:

Christopher Wensley Gary Vance 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

PublisherMichael Sebastian

1 IntroductionObjectives 1-2Grid Computing 1-3Oracle Ecosystem 1-5Enterprise Grid Computing 1-6Implement One from Many 1-7Manage Many as One 1-9Management Controls 1-11Oracle Enterprise Manager 10g Grid Control 1-12Course Objectives 1-13Summary 1-14

2 ArchitectureObjectives 2-2 Grid Control Components 2-3Managed Targets 2-5Oracle Management Agent 2-6Oracle Management Service 2-8Oracle Management Repository 2-10Accessing the Grid Control Console 2-11Grid Control Console: Home 2-12Grid Control Console: Targets 2-13Grid Control Console: Deployments 2-14Grid Control Console: Alerts 2-16Grid Control Console: Jobs 2-17Grid Control Console: Management System 2-18EM2Go 2-19Managing Very Large Grids 2-20Summary 2-21

3 Installing the Grid Control FrameworkObjectives 3-2Oracle Management Repository 3-3Oracle Management Service 3-4Oracle Management Agent 3-5Installation Overview 3-6Preinstallation Checks: Hardware 3-7Preinstallation Checks: Operating System 3-8Installation 3-10Select Product 3-11Enterprise Manager 10g Grid Control Using a New Database 3-12Super Administrator 3-15Repository Database Passwords 3-16

Contents

iii

MetaLink and Proxy Information 3-17Database Identification 3-18Database Files 3-19Configuration Assistants 3-20Enterprise Manager 10g Grid Control Using an Existing Database 3-21Add Repository to Existing Database 3-22Enterprise Manager 10g Grid Control Additional Management Service 3-24Connect OMS to Existing Repository 3-25Demonstration 3-26End of Installation 3-27Custom Port Selection 3-29Summary 3-31Practice 3 Overview: Installing the Grid Control Framework 3-32

4 Installing the Oracle Management AgentObjectives 4-2Grid Control Components 4-3OMA Installation Options 4-4Interactive Installation 4-5Selecting an OMS 4-6Silent Installation 4-7Response File 4-9Downloadable Management Agent 4-10Preinstallation Steps for agentDownload 4-11agentDownload 4-12Postinstallation 4-14Configuring Monitoring Credentials 4-15Key Configuration Files 4-16Target Discovery 4-17Summary 4-19Practice 4 Overview: Installing the Oracle Management Agent 4-20

5 Managing Grid ControlObjectives 5-2Controlling the Management Framework 5-3Starting the Grid Control Framework 5-4Stopping the Grid Control Framework 5-5Controlling the OMR Database Listener 5-6Controlling the OMR Database 5-8Controlling the OMS 5-10opmnctl 5-11emctl 5-13dcmctl 5-14Application Server Control 5-16Starting Application Server Control 5-17OMS Home Page 5-18Starting, Stopping, and Restarting the OMS 5-19OMS Component Home Pages 5-20Starting, Stopping, and Restarting OMS Components 5-21Obtaining Common OMS Metrics 5-22Controlling the OMA 5-23

iv

Demonstration 5-25Summary 5-26Practice 5 Overview: Managing Grid Control 5-27

6 Configuring Grid Control AdministratorsObjectives 6-2Groups 6-3Types of Groups 6-4Creating Groups 6-6Monitoring Groups 6-8Monitoring Group Performance 6-9Monitoring Group Targets 6-10Super Administrator 6-11Creating Administrators 6-12Creating Roles 6-13Notifying Administrators About Issues 6-15Setting Up Notification Methods 6-16Defining E-Mail Addresses 6-18Defining a Notification Schedule 6-19Notification Rules 6-21Using Public Notification Rules 6-22Creating a Notification Rule 6-23Preferred Credentials 6-25Setting Preferred Credentials 6-26Managing Target Subtabs 6-27Modifying Metric Columns 6-28Summary 6-29Practice 6 Overview: Configuring Groups and Grid Control Administrators 6-30

7 Monitoring Grid ControlObjectives 7-2Monitoring Grid Control 7-3Management System: Overview 7-4Loader and Notification Backlogs 7-5Management Repository Details 7-6Repository Operations 7-7Management Services 7-8Management Service Status 7-9Management Agents 7-10Metric Collection Errors 7-11Troubleshooting Grid Control 7-12Troubleshooting the OMR 7-13Troubleshooting the OMS 7-15Troubleshooting the OMA 7-17Summary 7-18Practice 7 Overview: Monitoring Grid Control 7-19

8 Monitoring the EcosystemObjectives 8-2Monitoring the Ecosystem: Overview 8-3Monitoring 8-4Target Monitoring 8-5

v

Availability Monitoring 8-6 Examining Metrics in Alerts 8-7Reviewing Historical Trends: Slowest Page Response 8-8Metrics and Thresholds 8-9Changing a Threshold 8-10Changing Multiple Thresholds 8-11Copying Thresholds to Another Target 8-12Metric Baselines 8-13Creating Metric Baselines 8-14Automating Responses to Alerts 8-15Defining a Response Action 8-16Defining a Response Action for Target Down 8-17Notifications 8-18Accessing Sent Notifications 8-19Reviewing Your Notification 8-20Blackouts 8-21Creating a Blackout 8-22Reviewing Blackouts 8-23Summary 8-24Practice 8 Overview: Monitoring the Ecosystem 8-25

9 Using the Job SystemObjectives 9-2Jobs 9-3Job Types 9-4Viewing Job Activity 9-5Creating a Host Command Job 9-7Creating a SQL Script Job 9-8Accessing Jobs 9-9Runs Versus Executions 9-10Reviewing Job Execution Results 9-11Job Library 9-13Searching for Jobs 9-14Jobs Purge Policy 9-15Summary 9-17Practice 9 Overview: Using the Job System 9-18

10 Host Monitoring and ManagementObjectives 10-2Doing More with More 10-3Monitoring Hosts with Grid Control 10-4What Is a Host? 10-5Viewing a List of Hosts in Your Grid 10-6Host Home Page 10-7Viewing Performance Information 10-8Using Metrics to Monitor Host Performance 10-9Changing Thresholds of Predefined Metrics 10-10Viewing a List of Targets 10-11Viewing Host Configuration 10-12Comparing Hosts 10-13Comparing Hosts: Different 10-14

vi

Using Telnet to Verify Host Information 10-15Summary 10-16Practice 10 Overview: Host Monitoring and Management 10-17

11 Database Monitoring and ManagementObjectives 11-2Ways to Manage Your Database 11-3Grid Control Versus Database Control 11-4Accessing Grid Control Versus Database Control 11-6Using Database Groups to Manage Multiple Database Targets 11-7Comparing Metrics of Multiple Database Targets 11-8Database Home Page 11-9Configuring an Oracle8i or Oracle9i Database Target 11-10Administering Databases with Grid Control 11-12Case Study: Managing by Exception 11-13Case Study 11-14Summary 11-18Practice 11 Overview: Database Monitoring and Management 11-19

12 Application Server ManagementObjectives 12-2Managing Application Servers Using Grid Control 12-3Grid Control Versus Application Server Control 12-4Accessing Grid Control Versus Accessing Application Server Control 12-6Application Server Control Tasks for Managing Application Servers 12-7Administering the Application Server Instance 12-8Reviewing the List of J2EE Applications 12-9Centrally Managing Ports 12-10Configuring Infrastructure Services 12-11Topology Viewer 12-12Deploying an OC4J Application 12-13Practice 12a Overview: Deploying the Petstore Application 12-15Reviewing Your Application’s Performance Metrics in Application Server

Control 12-18Applications Deployed to the OC4J Instance 12-19Viewing Log Files to Help Diagnose Problems 12-20Grid Control Tasks for Managing Application Servers 12-21Summary View of Application Servers from Grid Control 12-22Performance Diagnosis with Diagnostic Drilldowns 12-23Reviewing Historical Performance Data 12-24Drill Down to OC4J Home Page 12-25Drill Down to Applications 12-26Drill Down to Applications Performance 12-27Analyzing J2EE Diagnostic Reports 12-28Example Report: Top Servlets 12-29Using Groups to Manage Application Server Targets 12-30Monitoring Performance Across Multiple Application Servers 12-31Summary 12-33Practice 12b Overview: Application Server Management 12-34

vii

13 Application Service Level ManagementObjectives 13-2Application Service Level Management 13-3Monitor from the End User’s Viewpoint 13-4Monitor from the Application Administrator’s Perspective 13-5Application Administrator Requirements 13-6Manage Systems Holistically 13-7Manage Application Availability 13-9Beacons 13-10Define Availability 13-11Monitor Application Performance 13-12Monitor Transaction Response Time 13-13Drill Down for More Transaction Details 13-14Monitor End-User Response Times 13-15Investigate URL Performance Bottlenecks 13-16Analyze URL Performance 13-17Diagnose Performance Problems 13-18Interactive Transaction Trace 13-19Diagnose Middle-Tier Performance Issues 13-20Drill Down for Diagnostic Details 13-21Analyze the Processing Call Stack 13-22Correlate Performance 13-23Application Service Level Management Requirements 13-24Configuring Web Applications 13-25Add a Web Application Target 13-26Create Transactions 13-28Create Beacons 13-30Define Availability 13-31Configure End-User Response-Time Monitoring 13-32Configure OracleAS Web Cache Logging 13-33Configure OracleAS Web Cache Logging (Optional) 13-34Configure Middle-Tier Performance Monitoring 13-35Enable OC4J Logging 13-36Summary 13-37Practice 13 Overview: Application Service Level Management 13-38

14 Oracle Collaboration Suite ManagementObjectives 14-2Using Grid Control and EM Website to Manage Oracle Collaboration Suite 14-3Managing a Single Oracle Collaboration Suite Instance 14-4Application Server Home Page 14-5Grid Control Versus EM Website 14-6Managing Oracle Collaboration Suite in Grid Control 14-7Installing and Configuring Oracle Collaboration Suite in Grid Control 14-8Organizing Oracle Collaboration Suite Components Using Groups 14-9Using the OCSGroup Page 14-10

viii

Drill Down to Review the Alerts 14-11Drill Down to Review Component Availability 14-12Review Member Targets List 14-13Monitoring Oracle Collaboration Suite Components 14-14Email Component Home Page 14-15List of Email Components 14-16WebMail Web Application Page 14-17Email Performance 14-18Email IMAP Operations 14-19Calendar Component Group Page 14-20Calendar Web Application 14-21Calendar Performance 14-22Web Conference Component Group Page 14-23Web Conference Web Application 14-24Page Performance of Web Application 14-25Summary 14-26

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

ix

Cloning a Database Instance: Source Working Directory 15-31Cloning a Database Instance: Archiving Mode 15-32Cloning a Database Instance: Select Destination 15-33Cloning a Database Instance: Destination Options 15-34Cloning a Database Instance: Schedule 15-35Cloning a Database Instance: Review 15-36Cloning a Database Instance: Viewing the Job Results 15-37Summary 15-38Practice Overview: Managing Your Configuration 15-39

16 Grid Control SecurityObjectives 16-2Grid Control Security 16-3Enterprise Manager Framework Security 16-4Securing OMA–OMS Communications 16-5Accepting Secure Uploads 16-6Configure Management Services 16-7Test the Secure Upload Port 16-9Configure Management Agents 16-10Verify That Management Agents Are Secure 16-12Managing Agent Registration Passwords 16-13Refuse Nonsecure Uploads 16-14Securing OMS–OMR Communications 16-16Enable ASO for the OMR 16-17Enable ASO for Each OMS 16-18Enable ASO for the OMA 16-19Securing Product Control Consoles 16-20Working Through Firewalls 16-23Configuring the OMA for Proxy Communication 16-24Authenticating Grid Control Administrators 16-26Oracle Single Sign-On 16-27Configuring the OMS for SSO 16-28Enterprise User Security 16-29Configuring the OMS for Enterprise User Security 16-30Demonstration 16-31Summary 16-32Practice 16 Overview: Grid Control Security 16-33Practice 16: Grid Control Security 16-34

17 EM2GoObjectives 17-2Administer from Anywhere 17-3EM2Go 17-4Administering EM2Go 17-5Navigating EM2Go 17-6Target Home Pages 17-7Administering Databases with EM2Go 17-8

x

Resolving Database Issues with EM2Go 17-9Administering Hosts With EM2Go 17-10Administering Application Servers with EM2Go 17-11Summary 17-12

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

19 High-Availability OptionsObjectives 19-2High Availability 19-3Highly Available OMR 19-4Configuring OMS Connections to a RAC 19-5Highly Available OMS 19-6Configuring OMA Connections to a Clustered OMS 19-7Summary 19-8

20 Migrating to Grid ControlObjectives 20-2Migrating to Grid Control 20-3Deploying the Management Agents 20-4Automating the OMA Installation 20-5Postinstallation Requirements 20-7

xi

Migrate Existing Administrator Accounts 20-8Summary 20-9

21 Putting It All TogetherObjectives 21-2Practice 21: Putting It All Together 21-3Summary 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

Oracle Enterprise Manager 10g Grid Control 12-2


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

ObjectivesThis 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 UsingGrid Control

Management Services(J2EE Web Application)

Grid Control

MonitoredTargets

HTTP(s)

HTTP(s)HTTP(s)

HTTP(s)

Application Server

Control #1

Application Server

Control #2

JDBC

ManagementRepository

ManagementAgent

ManagementAgent

ManagementAgent

Monitoring Application Servers Using Grid ControlOracle 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

Yes

No

Many

Many

One per host in separate home

Centralized

Separate

Grid Control

Application Configuration

Server Configuration

# of Targets

Target Type

Management Agent

Management Repository

Install

Feature

Yes

Yes

One

Application Server

One per Application Server 10g Home

No

Application Server 10g

Application Server Control

Grid Control Versus Application Server ControlApplication Server Control is installed and available with every Oracle Application Server 10ginstallation 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

NoYes

NoYes

NoYes

NoYes

NoYes

NoYes

YesYes

YesNo

Application Server ControlGrid Control

Mobil Access via EM2Go

Configuration Management

Job System

Application Service Level Management

Historical Monitoring and Alerts

Groups

Real-Time Monitoring

Application Server Farm/Cluster aware

Feature

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 VersusAccessing Application Server Control

You access Enterprise Manager differently depending on whether you use Grid Control or Application Server Control.Example:

instance3

instance1

Instance2

Application Server Instance

ashost2

ashost1

Host

http://ashost1.domain:1810

http://ashost1.domain:1811

http://<oms_host>.domain:7777/em

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

Application ServerControl URL

Grid Control URL

Accessing Grid Control Versus Accessing Application Server ControlTo 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 ServersUsing 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 theApplication Server Instance

Application Server Instance Home page:

Administering the Application Server InstanceThe 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 ApplicationsThe 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 PortsThe 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 ServicesThe 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 ViewerTopology 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/topologyjspor

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 ControlTo 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 ApplicationBackgroundIn 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: InventoryDBconnection-driver=oracle.jdbc.driver.OracleDriverurl=jdbc:oracle:thin:@<yourdbhostpc>:1521:orclusername=estoreuserpassword=estorelocation=jdbc/InventoryDataSourcexa-location=jdbc/xa/InventoryXADSejb-location=jdbc/InventoryDB

Name: EstoreDBconnection-driver=oracle.jdbc.driver.OracleDriverurl=jdbc:oracle:thin:@<yourdbhostpc>:1521:orclusername=estoreuserpassword=estorelocation=jdbc/EstoreDataSourcexa-location=jdbc/xa/EstoreXADSejb-location=jdbc/EstoreDB

Name: SignOnDBconnection-driver=oracle.jdbc.driver.OracleDriverurl=jdbc:oracle:thin:@<yourdbhostpc>:1521:orclusername=estoreuserpassword=estorelocation=jdbc/SignOnDataSourcexa-location=jdbc/xa/EstoreXADSejb-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 ControlThe 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 Deployedto the OC4J Instance

The Applications property page displays applications that are deployed to the OC4J instance.

Applications Deployed to the OC4J InstanceThe 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 applicationYou 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 Filesto Help Diagnose Problems

You can view the log files for Application Server components.

Viewing Log Files to Help Diagnose ProblemsLog 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 ServersUsing 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 ControlYou 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 arolled-up view of the performance of the Application Server instance.

Performance Diagnosis with Diagnostic DrilldownsEach 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 DataUnderstanding 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 timeTo 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 PageThe 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 ApplicationsThe 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 PerformanceYou 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 ReportsIn 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 ServletsTop 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 ManageApplication Server Targets

Groups manage a set of Application Server targets cohesively as one unit.

Using Groups to Manage Application Server TargetsGroups 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 AcrossMultiple Application Servers

Monitoring Performance Across Multiple Application ServersUsing 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

This practice covers the following topics:• Viewing historical performance• Creating a group• Comparing metrics across application servers


Practice 12b: Application Server ManagementBackgroundAs 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?





Objectives

After completing this lesson, you should be able to do 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

Application Service Level ManagementWhen 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 ViewpointFrom 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 theApplication 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 PerspectiveThe 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 RequirementsAs 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 HolisticallyFrom 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 AvailabilityGrid 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 AvailabilityAvailability 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 PerformanceGrid 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 TimeFor 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 DetailsDrill 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 TimesTransaction 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/productwould 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 BottlenecksClicking 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 PerformanceFrom 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 ProblemsGrid 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 TracePlay 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 IssuesGrid 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 DetailsClick 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 PerformanceClick 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.



Application Service Level Management Requirements

Transaction performance monitoring:• Microsoft Internet Explorer 5.5 (or later versions)

for the transaction recorderEnd-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 RequirementsIn 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.4Oracle 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 ApplicationsIn 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 TargetTo 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 TransactionsYou 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 BeaconsBeacons 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 AvailabilityThe 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 MonitoringIf 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

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.



Configure OracleAS Web Cache Logging (Optional)

1. Stop OracleASWeb Cache.

2. Archive anyexisting logsusing the originalCLF format.

3. Start OracleASWeb 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 MonitoringIf 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 LoggingFrom the Application Server Control OC4J home page, click Administration > Server Properties > Tracing Properties.

Enable OC4J LoggingIf 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: Application Service Level Management

This practice covers the following topics:• 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

NoteBecause 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 ManagementBackgroundIn 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 sysmanoracle1 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

After completing this lesson, you should be able to do 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

ObjectivesThis 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

Management Service

Grid Control

Application Server

Using Grid Control and EM Website to Manage Oracle Collaboration SuiteGrid 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 SingleOracle Collaboration Suite Instance

• Management UI shipped with Oracle Application Server 9.0.2/9.0.3 is called “Enterprise Manager Website.”

• EM Website is extended to support Oracle Collaboration Suite administration tasks.

• EM Website provides real-time monitoring of a single Oracle Collaboration Suite middle tier.

EM Website

Application Server

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 PageUsing 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

Yes, in Oracle Collaboration Suite Oracle Home

Yes, in its own Oracle Home

Management Agent

NoYesConfiguration Management

NoYesManagement Repository

NoYesApplication Service Level Management

NoYesJob System

YesYesReal-Time MonitoringNoYesHistorical Monitoring and

Alerts

With Oracle Collaboration Suite

SeparateInstallation

YesNoApplication ConfigurationYesNoServer ConfigurationOneManyNumber of Targets

Application Server and applications

ManyTarget Types

EM WebsiteGrid ControlFeature

Grid Control Versus EM WebsiteEM 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 ControlAfter 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 ConfiguringOracle 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 ControlAfter 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 GroupsCreate 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 PageThe 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 AlertsTo 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 AvailabilityTo 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 ListTo 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 ComponentsThis 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 PageTo 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 ComponentsYou 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 PageThe 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 PerformanceClick 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 OperationsClick 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 PageDrill 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 ApplicationUse 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 PerformanceClick 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 PageFrom 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 ApplicationBy 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 ApplicationOn the Page Performance property page for the Web Conference Web application, you can review the application’s page performance.



Summary

In this lesson, you should have learned how to:• 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

After completing this lesson, you should be able to do 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

ObjectivesThis 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 ThemselvesProviding 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 ConfigurationBusiness 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 InformationThe 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 DataGrid 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 DataBy 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 InventorySystem 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 DetailsFor 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 ConfigurationsOn 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 SystemsEnterprise 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 ResultsThe 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 ChangesAdministrators 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 criticalpatch

advisories.

Apply patch.

Patches on MetaLink

Evaluate applicability.

3

Update inventory.4

2

1

Critical Patch AdvisoriesOracle 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.

Apply the patch.

Patches on MetaLink

3

Update inventory.4

Select the desired patch.

2

Retrieve the list of

available patches.

1

Applying PatchesAn 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 WizardEnterprise 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 CriteriaIf 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.



Using the Patch Wizard: 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 PatchesWhen 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.



Using the Patch Wizard: Select Destination

Select the targets on which the patch must be applied.

Using the Patch Wizard: Select DestinationThe 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.



Using the Patch Wizard: Set Credentials

To apply the patch, specify the host credentials.

Using the Patch Wizard: Set CredentialsSpecify 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/OraHome1for 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.



Using the Patch Wizard: Stage or Apply

Select “Run Script to Apply Patch.” Then click Next.

Using the Patch Wizard: Stage or ApplyIf 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.



Using the Patch Wizard: Schedule

Specify when the patch must be applied.

Using the Patch Wizard: ScheduleOn 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.



Using the Patch Wizard: Summary

Review the Summary, and click Finish.

Using the Patch Wizard: SummaryThe 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

practices• Policy violations• System standardization

Policy

Policy ManagementEnterprisewide 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 LibraryPolicy 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 ViolationsBy 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:

Update inventory.3

Select software and instances to

clone.1

Clone to selected targets.

2

Cloning an Oracle HomeThe 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 clonedinstance 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 timeOraHome1DB1: OrclDB2: Orcl2 (cloned)

Cloning a Database InstanceThe 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 TypeUse 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.



Cloning a Database Instance:Source Working Directory

Cloning a Database Instance: Source Working DirectoryThe 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



Cloning a Database Instance:Archiving Mode

Cloning a Database Instance: Archiving ModeThe 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.



Cloning a Database Instance:Select Destination

Cloning a Database Instance: Select DestinationOn 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.



Cloning a Database Instance:Destination Options

Cloning a Database Instance: Destination OptionsOn 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.



Cloning a Database Instance:Schedule

Cloning a Database Instance: ScheduleOn 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.



Cloning a Database Instance:Review

Cloning a Database Instance: ReviewOn 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.



Cloning a Database Instance:Viewing the Job Results

Cloning a Database Instance: Viewing the Job ResultsThere are many tasks that are run during database cloning. The job results list displays the various tasks and their results.



Summary

In this lesson, you should have learned how to:• View a configuration• Search for a configuration• Compare configurations• Review change tracking• Apply a patch• Manage policy violations• Clone an Oracle home or database



Practice 15 Overview: Managing Your Configuration

This practice covers the following topics:• Browsing and exporting a host configuration• Comparing hosts• Comparing databases• Managing policies


Practice 15: Managing Your ConfigurationBackgroundAs 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

After completing this lesson, you should be able to do 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

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 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

OHSWebCache

OC4JEM

OMS

OMR

Encryptedchannel

Encryptedchannel

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 CommunicationsThere 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 nonsecurecommunication.



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 UploadsUse 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.

$ emctl secure omsOHSWeb

Cache

OC4JEM

OMS

Configure Management ServicesPrior 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 stopallopmnctl: 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 omsTZ set to US/MountainOracle 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 startallopmnctl: 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 | AliveWebCache | WebCache | 31899 | AliveOC4J | OC4J_EM | 31890 | AliveOC4J | home | 31884 | Alivedcm-daemon | dcm-daemon | 16941 | AliveLogLoader | logloaderd | N/A | DownHTTP_Server | HTTP_Server | 31883 | Alive

4. Retrieve the secure upload port:$ emctl secure statusTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.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 emctlwas 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 receiverHttp 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 portTo 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:

1. Stop the management agent.$ $AGENT_HOME/bin/emctl stop agentTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.Stopping agent ... stopped.2. Execute emctl secure agent.$ $AGENT_HOME/bin/emctl secure agentTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.


Configure Management Agents (continued)Enter Agent Registration password :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.propertiesThe command may also be entered with the agent registration password:$ $AGENT_HOME/bin emctl secure agent <agent registration password>

3. Start the management agent.$ $AGENT_HOME/bin/emctl start agentTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.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 AgentsAre Secure

Verify that agents are configured for secure upload.

Verify That Management Agents Are SecureExamine 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 PasswordsManagement 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.1. Stop all OMS services.2. Configure the OMS to refuse uploads via HTTP.3. Start all OMS services.

$ emctl secure lock

Refuse Nonsecure UploadsSo 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:$ $GRID_HOME/opmn/bin/opmnctl stopallopmnctl: stopping opmn and all managed processes...

2. Configure the OMS to refuse uploads via HTTP:$ $GRID_HOME/bin/emctl secure lockTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.


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:$ $GRID_HOME/opmn/bin/opmnctl startallopmnctl: 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 | AliveWebCache | WebCache | 14467 | AliveOC4J | OC4J_EM | 14456 | AliveOC4J | home | 14455 | Alivedcm-daemon | dcm-daemon | 14207 | AliveLogLoader | logloaderd | N/A | DownHTTP_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:1. Stop all OMS services.2. Unlock the OMS using emctl secure unlock.3. Start all OMS services.



Securing OMS–OMR Communications

To secure communications between the OMS and OMR, enable the Oracle Advanced Security Option (ASO) for:1. OMR2. OMS3. OMA monitoring the OMR database

Securing OMS–OMR CommunicationsGrid 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.orato request encryption:• SQLNET.ENCRYPTION_SERVER• SQLNET.CRYPTO_SEED

OMR

SQLNET.ENCRYPTION_SERVER=REQUESTEDSQLNET.CRYPTO_SEED="abcdefg123456789"

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=REQUESTEDSQLNET.CRYPTO_SEED="abcdefg123456789"

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=TRUEoracle.net.encryption_types_client=(DES40C)oracle.net.encryption_client=REQUESTED

Stop and restart the OMS to implement the new parameters.

Enable ASO for Each OMSEnable ASO connections for the OMS by adding the following entries to:ORACLE_HOME/sysman/config/emoms.properties:

Requests an encrypted connection if the database server supports it

Type/length of encryption. DES56C, DES40C, RCA_40, RCA_56, RCA_128 and RCA_256 are supported. 3DES and AES are not supported in the current release.

Enables encryption of OMS/OMR database connections

Remarks

oracle.net.encryption_client

oracle.net. encryption_types_client

Parameter

oracle.sysman.emRep.dbConn. enableEncryption



Enable ASO for the OMA

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

SQLNET.CRYPTO_SEED="abcdefg123456789"

Enable ASO for the OMA Create a text file called sqlnet.ora in AGENT_HOME/network/admin. Add one entry to this file:

SQLNET.CRYPTO_SEED="abcdefg123456789"

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 ConsolesApplication 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 iasconsoleTZ set to US/MountainOracle Enterprise Manager 10g Application Server Control 9.0.4.0.0Copyright (c) 2002, 2003 Oracle Corporation. All rights reserved.Stopping Oracle 10g Application Server Control .. Stopped.

2. Secure Application Server Control.$ emctl secure emTZ set to US/MountainOracle Enterprise Manager 10g Application Server Control 9.0.4.0.0Copyright (c) 2002, 2003 Oracle Corporation. All rights reserved.


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.Configuring Agent for HTTPS... Done.EMD_URL set in /u01/app/oracle/product/10.1.0/asj2ee_1/sysman/

config/emd.propertiesConfiguring the website ... Done.Updating targets.xml ... Done.

3. Start Application Server Control.$ emctl start iasconsoleTZ set to US/MountainOracle Enterprise Manager 10g Application Server Control 9.0.4.0.0Copyright (c) 2002, 2003 Oracle Corporation. All rights reserved.Starting Oracle 10g Application Server Control ..... Started.

To secure Database Control:1. Stop Database Control.$ emctl stop dbconsoleTZ set to US/MountainOracle Enterprise Manager 10g Database Control Release 10.1.0.2.0Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.http://eddnr5p4.us.oracle.com:5500/em/console/aboutApplicationStopping Oracle Enterprise Manager 10g Database Control ..Stopped.

2. Secure Database Control.TZ set to US/PacificOracle Enterprise Manager 10g Database Control Release 10.1.0.2.0Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.http://edrsr10p1.us.oracle.com:5500/em/console/aboutApplicationEnter Enterprise Manager Root Password :Enter Agent Registration 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...Configuring Agent for HTTPS... Done.EMD_URL set in

/u01/app/oracle/product/10.1.0/db_1/edrsr10p1.us.oracle.com_orcl/sysman/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 dbconsoleTZ set to US/PacificOracle Enterprise Manager 10g Database Control Release 10.1.0.2.0Copyright (c) 1996, 2004 Oracle Corporation. All rights reserved.https://edrsr10p1.us.oracle.com:5500/em/console/aboutApplicationStarting 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.

OHSWebCache

OC4JEM

OMSProxy server

Working Through FirewallsIf 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 forProxy Communication

To configure the OMA so that it communicates via a proxy server, perform the following steps:1. Stop the management agent.2. Add proxy information to

AGENT_HOME/sysman/config/emd.properties:– REPOSITORY_PROXYHOST– REPOSITORY_PROXYPORT

3. Start the management agent.

Proxy server

Configuring the OMA for Proxy CommunicationConfiguring 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.comREPOSITORY_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 forProxy 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.

OHSWebCache

OC4JEM

OMSProxy server

Configuring the OMS for Proxy CommunicationTo configure the OMS so that it uses a proxy server to communicate with the OMA, perform the following steps:

1. Stop the OMS:$ $GRID_HOME/opmn/bin/opmnctl stopall

2. Add proxy information to GRID_HOME/sysman/config/emoms.properties:proxyHost=www-proxy.mycompany.comproxyPort=80dontProxyFor=.secureDomain, .otherDomain, …

Add addresses for management agents within the firewall (servers not requiring proxy communications) to the dontProxyFor list.

3. Start the OMS:$ $GRID_HOME/opmn/bin/opmnctl startall



Authenticating Grid Control Administrators

Grid Control administrators are:• Authenticated as OMR database users• Created and managed through the Grid Control

consoleIf 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 throughSingle 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-OnIn 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 downSince 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> -–port <SSO DB Listener Port> -–sid <SSO DB SID> -–pass <DB password for orasso> -–das <URL for OIDDAS server> OHSWeb

Cache

OC4JEM

OMS

Configuring the OMS for SSOTo configure Grid Control so that administrators are authenticated using Single Sign-On:

1. Stop the OMS:$ $GRID_HOME/opmn/bin/opmnctl stopall

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:$ $GRID_HOME/opmn/bin/opmnctl startall

Note: To find the password for the orasso database user, refer to “Obtaining the SingleSign-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.

Oracle Internet Directory

GridControl

Enterprise User SecurityEach 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 forEnterprise User Security

To configure an OMS for use with Enterprise User Security, perform the following steps:1. Stop all OMS services.2. Edit emoms.properties to enable Enterprise User

Security.3. Start OMS services.

OHSWebCache

OC4JEM

OMS

Configuring the OMS for Enterprise User SecurityEach OMS must be configured for use with Enterprise User Security.

1. Stop all OMS services:$ $GRID_HOME/opmn/bin/opmnctl stopall

2. Edit GRID_HOME/sysman/config/emoms.properties. Add the following entry:oracle.sysman.emSDK.sec.DirectoryAuthenticationType=EnterpriseUser

3. Start OMS services:$ $GRID_HOME/opmn/bin/opmnctl startall

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.

DemonstrationDuring 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:

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 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

In this lesson, you should have learned how to:• 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



Practice 16 Overview:Grid Control Security

This practice covers the following topics:• Configuring the OMA for secure communications

between the OMA and OMS• Verifying communications are secure


Practice 16: Grid Control SecurityBackgroundThe 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

After completing this lesson, you should be able to do 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 AnywhereBusiness-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 pageis divided into:– Alerts and Availability– Targets– Jobs

• Tap underlined linksto drill down for moreinformation

• Use horizontal and verticalscrollbars to view large pages

Navigating EM2GoUnlike 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 EM2GoAlthough 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

1

2

43

EM2Go enables remote administration of databases.

Resolving Database Issues with EM2GoEM2Go 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

2

4

3

5

6

Administering Hosts with EM2GoEM2Go 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 ORCLbackground 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 Serverswith EM2Go

EM2Go provides:• Availability monitoring• Alert reporting• Performance summaries

Administering Application Servers with EM2GoYou 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

In this lesson, you should have learned how to:• 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

After completing this lesson, you should be able to do 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 MetricsGrid 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 MetricsTo 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 ScriptsThe 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.shem_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=15000echo em_result=$FREEMEMif [ $FREEMEM -lt $LOW_LIMIT ]; then

echo "em_message=Free Memory is low"fi

Now when the script is run:$ ./getfreemem.shem_result=14292em_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-DefinedOperating System Metric

Creating the User-Defined Operating System MetricTo 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 MetricsWith 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 MetricTo 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 MetricsTo 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 TargetsGrid 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 TargetBefore 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 FileEach 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 FileThe 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 DefinitionsBefore 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 iLINTUse 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 naTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.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/metadata/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/metadata/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 naTZ set to US/MountainOracle Enterprise Manager 10g Release 10.1.0.2.0.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_collection/potato_server.xmlValidating target metadata file /u01/app/oracle/product/10.1.0/agent/sysman/admin/metadata/potato_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 InstancesWhen 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 BrowserThe 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.

7 daysmgmt_raw_keep_windowComponent metric data

31 daysmgmt_hour_keep_windowOne-hour aggregates of metric data

365 daysmgmt_day_keep_windowOne-day aggregates of metric data

24 hoursmgmt_rt_keep_windowRaw ASLM response-time data

7 daysmgmt_rt_hour_keep_windowOne-hour aggregates of ASLM data

31 daysmgmt_rt_day_keep_windowOne-day aggregates of ASLM data

24 hoursmgmt_rt_dist_hour_keep_windowOne-hour aggregates of ASLM data

31 daysmgmt_rt_dist_day_keep_windowOne-day aggregates of ASLM data

Default Value

ParameterData



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

In this lesson, you should have learned how to:• Add user-defined metrics• Monitor custom targets• Produce custom reports



Practice 18 Overview: Extending and Customizing Grid Control

This practice covers the following topics:• 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 ControlBackgroundAs 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 10ghigh-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 consoleBecause 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

Standby

OMR

Highly Available OMRReal 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 RACWhen 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.

Load Balancer

WebCache

WebCache

WebCache

OHS

OHS

OHS

OC4J

OC4J

OC4J

EM

EM

EM

Highly Available OMSGrid 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 OMSWhen 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 thehigh-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 to 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.

Migrating 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 AgentsDeploying 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 OracleEnterprise 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 nameb. 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/agentNODE07 /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 RequirementsOnce 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 AccountsOnce 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

In this lesson, you should have learned how to:• 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

Oracle Enterprise Manager 10g: Grid Control 21-2


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


Practice 21: Putting It All TogetherBackgroundIn 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 Together9. 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 arefaquser/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 application3. Define availability and use the same beacon you created earlier4. 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

Documents

grid control console

grid control objectives

grid control components

oracle management repository

oracle management service

oracle products

oracle parkway

oracle ecosystem