Contents

List of Examples

List of Figures

List of Tables

Title and Copyright Information

Preface

Intended Audience

Purpose of the Document

Documentation Accessibility

Related Documents

Conventions

1 Getting Started

Installing Enterprise Manager Grid Control

Adding Additional Oracle Management Service

Installing Oracle Management Agent

Upgrading Enterprise Manager Grid Control or Oracle Management Service

Upgrading Oracle Management Agent

2 Things to Know

Procuring Enterprise Manager Grid Control Software

How Do You Access the Software from DVD?

Accessing Software from DVD

Setting Mount Point for DVD

How Do You Procure the Software from Oracle Technology Network?

Downloading Software

Verifying File Size

Extracting Contents

Verifying Platform Information

Procuring Oracle Management Agent Software

Automatically Downloading Management Agent Software Using Download Agent Software Application

What Is Agent Download Application?

What Prerequisites You Must Meet?

How Do You Download the Management Agent Software?

Manually Downloading Management Agent Software from OTN

Understanding Installation Basics

What Different Installation Modes Can You Use?

What Is Enterprise Manager Grid Control Installation Wizard?

What Installation Types Are Offered by the Installation Wizard?

What Ports Are Used for Installation?

What Default Ports Are Used?

How Can You Customize Ports?

What Precautions Must You Take While Customizing Port Numbers?

How Can You Change the Language Used in Enterprise Manager Grid Control Console?

What Data Files Are Created While Configuring Oracle Management Repository?

How Do You Delete Data Files?

Understanding Oracle WebLogic Server Requirement

How Do I Install Oracle WebLogic Server?

How Do I Verify Whether Oracle WebLogic Server Is Installed?

Is Oracle WebLogic Server Cluster Supported?

Is the Existing Admin Server in Oracle WebLogic Server Used?

When and Why Do You Need Oracle WebLogic Server Credentials?

When and Why Do You Need Node Manager Credentials?

How Do You Find Admin Server Port While Installing an Additional OMS

How Do You Verify Whether Admin Server Is Running?

How Do You Start Admin Server?

Understanding Installation Directories

What Is Oracle Inventory Directory?

What Is Oracle Middleware Home?

What Is Oracle Management Service Instance Base Location?

What Is Oracle Home?

What Is Installation Base Directory?

What Is EMSTATE Directory?

What Is /TMP C:\Temp Directory Used For?

Understanding Additional Components Installed

What Is Oracle Configuration Manager?

Manually Collecting and Uploading Configuration Information

Enabling Oracle Configuration Manager After Installing Enterprise Manager Grid Control

What Are Software Updates?

How Can You Download the Software Updates?

When Can You Apply the Software Updates?

Where Are the Software Updates Downloaded?

Understanding Configuration Assistants

What Are Configuration Assistants?

What Configuration Assistants Are Run by the Installation Wizard?

What Is Agent Configuration Assistant Used For?

What Do You Do When Configuration Assistants Fail?

Understanding Prerequisite Checks

What Prerequisite Checks Are Run by Default?

How Can You Run Prerequisite Checks in Standalone Mode?

Understanding Limitations of Enterprise Manager Grid Control

Can You Access Unlicensed Components?

What Are the Limitations with DHCP-Enabled Machines?

Understanding Other Miscellaneous Concepts

What Is a Host List File?

What SYSDBA Privileges Are Required for Creating Repository Schema?

What Scripts Are Run During the Installation Process?

Part I Installing Enterprise Manager System

3 Installing Enterprise Manager System

Overview

Before You Begin

Prerequisites

Setting Database Initialization Parameters

Installation Procedure

After You Install

4 Installing Enterprise Manager Software Only in Graphical Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

5 Installing Enterprise Manager Software Only in Silent Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

Part II Adding Additional Oracle Management Service

6 Adding Additional Oracle Management Service

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

7 Installing Oracle Management Service Software Only in Graphical Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Install Additional OMS

Install Add-Ons

After You Install OMS

Configure OMS

After You Configure OMS

8 Installing Oracle Management Service Software Only in Silent Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Install Additional OMS

Install Add-Ons

After You Install OMS

Configure OMS

After You Configure OMS

Part III Installing Oracle Management Agent

9 Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

10 Installing Oracle Management Agent Using Shared Oracle Home

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

11 Cloning Oracle Management Agent Using Agent Cloning Wizard

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

12 Installing Oracle Management Agent Using Response File

Overview

Prerequisites

Installation Procedure

After You Install

13 Installing Oracle Management Agent Using agentDownload Script

Overview

Prerequisites

Installation Procedure

After You Install

14 Installing Oracle Management Agent on a Cluster Using Response File or agentDownload Script

Overview

Before You Begin

Prerequisites

Installation Procedure

Installing Using Response File

Editing Parameters for Installing Oracle Management Agent on a Cluster

Updating the Node List After Installing the Management Agent

Installing Using agentDownload Script

After You Install

15 Installing Oracle Management Agent Using Shared Oracle Home Using nfsagentinstall Script

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

16 Cloning Oracle Management Agent Using ZIP File

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

17 Cloning Oracle Management Agent on Clusters Using ZIP File

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Part IV Advanced Configuration

18 Introduction to Enterprise Manager Advanced Configuration

Types of Advanced Configuration Tasks

Understanding the Enterprise Manager Directory Structure

Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Grid Control 11g Release 1

About the Oracle Management Service Home Directory

About the Oracle Management Agent Home (AGENT_HOME) Directory

Summary of the Important Directories in the Oracle Management Service Home

Understanding the Enterprise Manager Directories Installed with the Management Agent

Summary of the Important Directories in the Oracle Management Agent Home

Understanding the Oracle Management Agent Directory Structure on Windows

Identifying the Oracle Home When Using the emctl Command

Enabling Enterprise Manager Accessibility Features

Enabling Enterprise Manager Accessibility Mode

Providing Textual Descriptions of Enterprise Manager Charts

19 Configuring Enterprise Manager for Firewalls

Considerations Before Configuring Your Firewall

Firewall Configurations for Enterprise Management Components

Firewalls Between Your Browser and the Grid Control Console

Configuring the Management Agent on a Host Protected by a Firewall

Configuring the Management Agent to Use a Proxy Server

Configuring the Firewall to Allow Incoming Communication From the Management Service

Configuring the Management Service on a Host Protected by a Firewall

Configuring the Management Service to Use a Proxy Server

About the dontProxyfor Property

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

Firewalls Between the Management Service and the Management Repository

Firewalls Between the Grid Control and a Managed Database Target

Firewalls Used with Multiple Management Services

Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

Enabling ICMP Echo Requests on Firewalls

Configuring Firewalls When Managing Oracle Application Server

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

Additional Considerations for Windows XP

20 Additional Configuration Tasks

Understanding Default and Custom Data Collections

How Enterprise Manager Stores Default Collection Information

Enabling Multi-Inventory Support for Configuration Management

AGENT_HOME Versus AGENT_STATE Directories

Manually Configuring a Database Target for Complete Monitoring

Modifying the Default Login Timeout Value

Configuring Clusters and Cluster Databases in Grid Control

Configuring Clusters

Configuring Cluster Databases

Discovering Instances Added to the Cluster Database

Troubleshooting

Collecting Client Configurations

Configuring the Client System Analyzer

Client System Analyzer in Oracle Grid Control

Deploying Client System Analyzer Independently

Configuration Parameters

Associating the Parameters with an Application

Rules

Customization

CSA Deployment Examples

Using Multiple Collection Tags

Privilege Model for Viewing Client Configurations

Using the Customization API Example

Using the CSA Servlet Filter Example

Sample Deployments

Configuring Privilege Delegation Providers

Creating a Privilege Delegation Setting

Creating a Sudo Setting Using EMCLI

Creating a PowerBroker Setting Using EMCLI

Applying Privilege Delegation Settings

Applying Settings to Host Targets Using EMCLI

Applying Settings to a Composite Target

Disabling Host Privilege Delegation Provider Settings Using EMCLI

Sudo Configuration: Sudoers File

Configuring Privilege Delegation Providers Using Grid Control Console

Configuring Sudo Settings For a Host Using Enterprise Manager Grid Control Console

Configuring PowerBroker Settings For a Host Using the Grid Control Console

Applying Settings to Multiple Host Targets Using the Grid Control Console

Disabling Host Privilege Delegation Provider Settings For One or More Hosts Using Grid Control Console

Part V Upgrading Enterprise Manager System

21 Upgrading to Enterprise Manager 11g

Overview

Before You Begin

Prerequisites

Upgrade Procedure

After You Upgrade

22 Upgrading Enterprise Manager System with Add-Ons Installed in Graphical Mode

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

After You Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

23 Upgrading Enterprise Manager System with Add-Ons Installed in Silent Mode

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

After You Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

Part VI Upgrading Oracle Management Agent

24 Upgrading Oracle Management Agent Using Agent Upgrade Wizard

Overview

Before You Begin

Prerequisites

Upgrade Procedure

Additional Parameters You Can Specify for Agent Upgrade

After You Upgrade

25 Upgrading Oracle Management Agent Using a Response File

Overview

Before You Begin

Prerequisites

Upgrade Procedure

After You Upgrade

26 Upgrading Oracle Management Agent Using agentDownload Script

Overview

Before You Begin

Prerequisites

Upgrade Procedure

Arguments You Can Pass While Running agentDownload Script

27 Upgrading Shared Oracle Management Agent

Overview

Prerequisites

Upgrade Procedure

After You Upgrade

28 Upgrading Oracle Management Agent with Add-Ons

Overview

Before You Begin

Prerequisites

Upgrade Management Agent

After You Upgrade

Configuration Procedure

After You Configure

Part VII Deinstalling Enterprise Manager System

29 Deinstalling Enterprise Manager System in Graphical Mode

Prerequisites

Deinstallation Procedure

After You Deinstall

30 Deinstalling Enterprise Manager System in Silent Mode

Prerequisites

Deinstallation Procedure

After You Deinstall

Part VIII Deinstalling Oracle Management Agent

31 Deinstalling Oracle Management Agent in Graphical Mode

Prerequisites

Deinstallation Procedure

Deinstalling Standalone or Cluster-Based Oracle Management Agents

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

After You Deinstall

32 Deinstalling Oracle Management Agent in Silent Mode

Prerequisites

Deinstallation Procedure

Deinstalling Standalone or Cluster-Based Oracle Management Agents

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

Deinstalling Shared Oracle Management Agent

After You Deinstall

Part IX Using Enterprise Manager Grid Control

33 Using Enterprise Manager Grid Control

Accessing Enterprise Manager Grid Control

Logging In

Enabling or Disabling Licenses

Accessing Online Help

Part X Appendixes

A Meeting Hardware Requirements

B Meeting Package, Kernel Parameter, and Library Requirements

Package Requirements for Oracle Management Service

Package Requirements for Oracle Management Agent

Kernel Parameter Requirements for Oracle Management Service and Oracle Management Agent

Library Requirements for Oracle Management Service

C Creating Operating System Groups and Users Requirements

What Operating System Groups and Users Are Required?

How To Create the Operating System Groups and Users?

Creating the Oracle Inventory Group

Determining Whether the Oracle Inventory Group Exists

Creating the Oracle Inventory Group

Creating the OSDBA Group

Creating an OSOPER Group (Optional)

Creating the Oracle Software Owner User

Determining Whether an Oracle Software Owner User Exists

Creating an Oracle Software Owner User

Modifying an Oracle Software Owner User

Verifying that the User nobody Exists

D Setting Up SSH Connectivity

Overview

Setting Up SSH Server (SSHD) on Microsoft Windows

Before You Begin

Installing Cygwin

Setting Up SSH on Microsoft Windows Using sshUserSetupNT.sh

Setting Up the Timezone Variable on Remote Hosts

Set the TZ variable and Restart the SSH Daemon

Set the TZ Variable in the "Shell rc" File

E Validating Command Locations

Overview of Property Files

Property Files Loaded from platformInfo.properties File

Other Property Files Loaded

Validating Command Locations

Validating Command Locations on the OMS Host

Validating Command Locations on the Destination Host

F Passing Additional Parameters

Additional Parameters Supported by agentDownload Script

Additional Parameters Supported by Agent Deployment Wizard for Custom Location

G Configuring Database and ASM Targets for Monitoring

H Setting Up Proxy Configuration for Oracle Management Service

I Reconfiguring Oracle Management Agent and Discovering New Targets

Discovering New Targets with Standalone Management Agents

Converting Standalone Management Agents to Cluster-Based Management Agents

Convering in Graphical Mode

Converting in Silent Mode

Discovering New Targets with Cluster-Based Management Agents

Reconfiguring Cluster-Based Management Agents

J Understanding Optional Arguments Run with ConfigureGC.pl Script

K Using RepManager Utility

Overview

Prerequisites

Supported Actions and Commands

L Installation and Configuration Log Files

Enterprise Manager Grid Control Installation Logs

Installation Logs

Configuration Logs

General Configuration Logs

Repository Configuration Logs

Secure Logs

Oracle Management Service Logs

Agent Deployment Log Files

Connectivity Logs

Application Prerequisite Logs

System Prerequisite Logs

Other Installation Logs

M List of Deprecated Features

Index

List of Examples

20-1 Sample RULES

20-2 Using Collection Tags for Selecting a Rule File

20-3 Customization API

20-4 Inventory Code

20-5 Context Parameter Values for CSA Servlet Filter

20-6 Context Parameter Definitions Mapping Rules to Collection Tags

20-7 Using EMCLI to Create a Sudo Setting

20-8 Using EMCLI to Create a Sudo Setting

20-9 Using EMCLI to Apply Privilege Delegation Settings to a Host Target

20-10 Using EMCLI to Apply Privilege Delegation Settings to a Composite Target

List of Figures

2-1 Enterprise Manager Grid Control Installation Wizard

18-1 Directory Structure in the Management Service Home

18-2 Icon Representing the Textual Representation of a Chart

19-1 Firewall Port Requirements (Default)

19-2 Firewall Between Your Browser and the Grid Control Console

19-3 Firewall Between Your Browser and the Grid Control Console

19-4 Configuration Tasks When the Management Agent Is Behind a Firewall

19-5 Configuration Tasks When the Management Agent is Behind a Firewall

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

19-7 Configuration Tasks When the Management Service is Behind a Firewall

19-8 Firewall Between the Management Service and the Management Repository

19-9 Firewall Between the Grid Control and a Managed Database Target

19-10 Firewall Between Grid Control and Managed Database Target

20-1 Host Privilege Delegation Setting for Sudo

20-2 Host Privilege Delegation Setting for PowerBroker

20-3 Manage Privilege Delegation Settings Template Window

20-4 Manage Privilege Delegation Settings Page

List of Tables

1-1 Use Cases for Installing a Complete Enterprise Manager System

1-2 Use Cases for Adding an Additional Oracle Management Service

1-3 Use Cases for Installing a Standalone Oracle Management Agent

1-4 Use Cases for Upgrading Enterprise Manager System or Oracle Management Service

1-5 Use Cases for Upgrading Oracle Management Agent

2-1 Verifying Platform Information

2-2 Installation Types Offered by the Enterprise Manager Grid Control Installation Wizard

2-3 Configuration Assistant

2-4 Arguments Supported by Agent Configuration Assistant (agentca)

2-5 Actions to be Performed When Configuration Assistants Fail

2-6 Prerequisite Checks Run by Enterprise Manager Grid Control Installation Wizard for Different Installation Types

2-7 Running Prerequisite Checks in Standalone Mode

2-8 SYSDBA Privileges Required for Creating Repository Schema

3-1 Process for Installing Enterprise Manager System in Silent Mode

3-2 Prerequisites for Installing Enterprise Manager System in Silent Mode

3-3 Setting Fixed Initialization Parameters

3-4 Setting Variable Initialization Parameters

3-5 Response File Parameters for Installing Enterprise Manager System in Silent Mode

6-1 Process for Adding an Additional Oracle Management Service in Silent Mode

6-2 Prerequisites for Adding an Additional Oracle Management Service in Silent Mode

6-3 Response File Parameters for Adding an Additional Oracle Management Service

9-1 Prerequisites for Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard

10-1 Prerequisites for Installing Oracle Management Agent Using Shared Agent Deployment Wizard

11-1 Prerequisites for Cloning Oracle Management Agent Using Agent Cloning Wizard

12-1 Prerequisites for Installing Oracle Management Agent Using Response File

12-2 Modifying Parameters for Installing Additional Oracle Management Agent

13-1 Prerequisites for Installing Oracle Management Agent Using agentDownload Script

14-1 Response File Parameters for Installing Oracle Management Agent on a Cluster

14-2 Updating the Node List After Installing Oracle Management Agent

15-1 Prerequisites for Installing Oracle Management Agent Using nfsagentinstall Script

16-1 Prerequisites for Cloning Oracle Management Agent Using ZIP File

18-1 Important Directories in the Management Service Oracle Home

18-2 Important Directories in the AGENT_HOME Directory

19-1 Conventions Used

20-1 Configuration Parameters

20-2 Configuration Parameters

20-3 Tags in the RULES File

21-1 Prerequisites for Upgrading to Enterprise Manager 11g in Silent Mode

21-2 Response File Parameters for Upgrading Enterprise Manager Grid Control

21-3 Response File Parameters for Upgrading Additional Oracle Management Service

21-4 Removing Oracle Application Server Targets

24-1 Prerequisites for Upgrading Oracle Management Agent Using Agent Upgrade Wizard

24-2 Additional Parameters Supported for Agent Upgrade

25-1 Response File Parameters for Upgrading Oracle Management Agent

26-1 Arguments Supported by agentDownload Script

A-1 Required Physical Memory for Oracle Management Service and Oracle Management Agent

A-2 Recommended Physical Memory for Oracle Management Service and Oracle Management Agent

A-3 Recommended Physical Memory and Hard Disk Space for Oracle Management Repository

B-1 Package Requirements for Oracle Management Service

B-2 Package Requirements for Oracle Management Agent

B-3 Library Requirements for Oracle Management Service

E-1 Property Files Loaded from platformInfo.properties File

E-2 Other Property Files Loaded

F-1 Additional Parameters Supported by agentDownload Script

F-2 Additional Parameters Supported by Agent Deployment Wizard

J-1 Parameters Recognized by ConfigureGC.pl Script While Configuring Enterprise Manager System

J-2 Parameters Recognized by ConfigureGC.pl Script While Configuring an Additional OMS

K-1 Actions and Commands Supported by RepManager

L-1 General Configuration Logs

L-2 Connectivity Logs

L-3 Prerequisite Logs

L-4 Install Types

L-5 System Prerequisite Logs

L-6 Installation Logs Created During Agent Installation Using Agent Deployment Wizard

M-1 List of Deprecated Features

Oracle® Enterprise Manager

Grid Control Advanced Installation and Configuration Guide

11g Release 1 (11.1.0.1.0)

E16847-13

May 2012

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide, 11g Release 1 (11.1.0.1.0)

E16847-13

Copyright © 1996, 2012, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Aravind Jayaraaman

Contributing Author:  Dennis Lee, Leo Cloutier, Pushpa Raghavachar, Aparna Kamath, Jacqueline Gosselin

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide is an extension to Oracle Enterprise Manager Grid Control Basic Installation Guide.

While the Oracle Enterprise Manager Grid Control Basic Installation Guide covers basic installation procedures that help you get started with Enterprise Manager Grid Control, the Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide covers advanced installation procedures that help you install and configure Enterprise Manager Grid Control components for more complex environments.

This preface contains the following topics:

Intended Audience

Purpose of the Document

Documentation Accessibility

Related Documents

Conventions

Intended Audience

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide is meant for system administrators who want to install Enterprise Manager Grid Control components in complex environments.

Purpose of the Document

This section explains why and when you must use the Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide, and clarifies what falls outside the scope of this guide.

In particular, this section covers:

What Can This Guide Be Used For?

What Is Excluded From This Guide?

What Can This Guide Be Used For?

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide covers advanced installation and configuration procedures for the following:

Installing the following in graphical mode:

Oracle Management Agent 11g Release 1 (11.1.0.1.0) on a cluster using Agent Deployment Wizard

Oracle Management Agent 11g Release 1 (11.1.0.1.0) with a shared Oracle home from a mounted location using Shared Agent Deployment Wizard

Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) software only so that you can configure it later

Additional Oracle Management Service 11g Release 1 (11.1.0.1.0) software only so that you can configure it later

Cloning Oracle Management Agent 11g Release 1 (11.1.0.1.0) in graphical and silent mode.

Installing the following in silent mode:

Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0)

Additional Oracle Management Service 11g Release 1 (11.1.0.1.0)

Oracle Management Agent 11g Release 1 (11.1.0.1.0)

Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) software only so that you can configure it later

Additional Oracle Management Service 11g Release 1 (11.1.0.1.0) software only so that you can configure it later

Oracle Management Agent 11g Release 1 (11.1.0.1.0) on a cluster

Oracle Management Agent 11g Release 1 (11.1.0.1.0) with a shared Oracle home from a mounted location

Oracle Management Agent 11g Release 1 (11.1.0.1.0) using agentDownload script

Upgrading Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0) or higher to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) in silent mode.

Upgrading Oracle Management Agent 10g Release 4 (10.2.0.4.0) or higher to Oracle Management Agent 11g Release 1 (11.1.0.1.0) in graphical and silent mode.

Deinstalling Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) or Oracle Management Agent 11g Release 1 (11.1.0.1.0).

For information about the different operating systems for which Enterprise Manager 11g Grid Control has been released, refer to My Oracle Support note 412431.1.

What Is Excluded From This Guide?

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide does NOT cover the following. The procedures are documented in Oracle Enterprise Manager Grid Control Basic Installation Guide.

Installing Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) in graphical mode

Installing an additional Oracle Management Service 11g Release 1 (11.1.0.1.0) in graphical mode

Installing Oracle Management Agent 11g Release 1 (11.1.0.1.0) in graphical mode

Upgrading Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0) or higher to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0), in graphical mode.

Documentation Accessibility

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

Access to Oracle Support

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

Related Documents

For more information, see the following books in the Enterprise Manager Grid Control documentation library:

Oracle Enterprise Manager Grid Control Basic Installation Guide

Oracle Enterprise Manager Administration Guide

Oracle Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching

For the latest releases of these and other Oracle documentation, check the Oracle Technology Network at the following URL:

http://www.oracle.com/technology/documentation/oem.html

Grid Control also provides extensive online Help. Click Help at the top of any Grid Control page to display the online help window.

Conventions

The following table describes those conventions and provides examples of their use.

Convention
Meaning
Example

Bold
Bold typeface indicates an element in the user interface.
Click Help for more information.

Italics
Italic typeface indicates book titles or emphasis.
Oracle Database Concepts

Ensure that the recovery catalog and target database do not reside on the same disk.

lowercase monospace (fixed-width font)
Lowercase monospace typeface indicates executables, file names, directory names, commands, and sample user-supplied elements. Such elements include computer and database names, net service names, and connect identifiers, as well as user-supplied database objects and structures, column names, packages and classes, user names and roles, program units, and parameter values.
Enter sqlplus to open SQL*Plus.

The password is specified in the orapwd file.

Back up the datafiles and control files in the /<DVD>/oracle/dbs directory.

The department_id, department_name, and location_id columns are in the hr.departments table.

Set the QUERY_REWRITE_ENABLED initialization parameter to TRUE.

Connect as oe user.

The JRepUtil class implements these methods.

1 Getting Started

Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide covers advanced installation procedures that help you install and configure Enterprise Manager Grid Control components in different ways for more complex environments. The guide covers multiple use cases, including steps to install only the software binaries and steps to deinstall a component from your system, both in graphical mode and in silent mode.

Graphical mode is the Graphical User Interface (GUI) method that involves usage of a Java-based installation wizard or a browser-based application that is built into and accessed from the Enterprise Manager Grid Control console. This method is best suited for first-time installations because you are guided through the entire installation process and your installation details are captured using the interview screens.

Silent mode involves usage of Oracle-supplied response files that capture all the information required for installation. This method is simpler and faster, but requires you to have some knowledge on the installation process so that you can provide your installation details in the response files without having to see the interview screens of the installation wizard.

Consider this chapter to be a documentation map to understand what use cases are covered in this guide, and what sections within the guide you must read to understand each use case and successfully perform the described operation.

In particular, this chapter covers use cases for the following:

Installing Enterprise Manager Grid Control

Adding Additional Oracle Management Service

Installing Oracle Management Agent

Upgrading Enterprise Manager Grid Control or Oracle Management Service

Upgrading Oracle Management Agent

Note:

Oracle strongly recommends you to read Chapter 2, "Things to Know" so that you understand the key concepts of Enterprise Manager Grid Control and the important aspects of installation and upgrade.

Installing Enterprise Manager Grid Control

Table 1-1 lists the use cases described in this guide for installing a complete Enterprise Manager system.

Table 1-1 Use Cases for Installing a Complete Enterprise Manager System

Use Cases
Overview
Before You Begin
Prereqs
Install Procedure
After You Install

Installing Enterprise Manager System in Graphical Mode

Refer to Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Installing Enterprise Manager System in Silent Mode

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Installing Enterprise Manager Software Only in Graphical Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

Installing Enterprise Manager Software Only in Silent Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

Adding Additional Oracle Management Service

Table 1-2 lists the use cases described in this guide for adding an additional Oracle Management Service (OMS).

Table 1-2 Use Cases for Adding an Additional Oracle Management Service

Use Cases
Overview
Before You Begin
Prereqs
Install Procedure
After You Install

Adding Additional Oracle Management Service in Graphical Mode

Refer to Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Adding Additional Oracle Management Service in Silent Mode

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Installing Oracle Management Service Software Only in Graphical Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Install Additional OMS

After You Install OMS

Configure OMS

After You Configure OMS

Installing Oracle Management Service Software Only in Silent Mode and Configuring Later

Overview

Before You Begin

Prerequisites

Install Additional OMS

After You Install OMS

Configure OMS

After You Configure OMS

Installing Oracle Management Agent

Table 1-3 lists the use cases described in this guide for installing a standalone Oracle Management Agent.

Table 1-3 Use Cases for Installing a Standalone Oracle Management Agent

Use Cases
Overview
Before You Begin
Prereqs
Install Procedure
After You Install

Installing Oracle Management Agent Using Agent Deployment Wizard

Refer to Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Installing Oracle Management Agent Using Shared Oracle Home

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Cloning Oracle Management Agent Using Agent Cloning Wizard

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Installing Oracle Management Agent Using Response File

Overview

N/A

Prerequisites

Installation Procedure

After You Install

Installing Oracle Management Agent Using agentDownload Script

Overview

N/A

Prerequisites

Installation Procedure

After You Install

Installing Oracle Management Agent on a Cluster Using Response File or agentDownload Script

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Installing Oracle Management Agent Using Shared Oracle Home Using nfsagentinstall Script

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Cloning Oracle Management Agent Using ZIP File

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Cloning Oracle Management Agent on Clusters Using ZIP File

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Upgrading Enterprise Manager Grid Control or Oracle Management Service

Table 1-4 lists the use cases described in this guide for upgrading an Enterprise Manager system or an additional OMS.

Table 1-4 Use Cases for Upgrading Enterprise Manager System or Oracle Management Service

Use Cases
Overview
Prereqs
Upgrade Procedure
After You Upgrade

Upgrading Enterprise Manager 11g in Graphical Mode

Refer to Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Upgrading Enterprise Manager Grid Control in Silent Mode

Overview

Prerequisites

Upgrade Procedure

-

Upgrading Enterprise Manager Grid Control with Add-Ons Installed in Graphical Mode

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

Upgrading Enterprise Manager Grid Control with Add-Ons Installed in Silent Mode

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

Upgrading Oracle Management Agent

Table 1-5 lists the use cases described in this guide for upgrading Oracle Management Agent.

Table 1-5 Use Cases for Upgrading Oracle Management Agent

Use Cases
Overview
Before You Begin
Prereqs
Upgrade Procedure
After You Upgrade

Upgrading Oracle Management Agent Using Agent Upgrade Wizard

Overview

Before You Begin

Prerequisites

Upgrade Procedure

After You Upgrade

Upgrading Oracle Management Agent Using a Response File

Overview

N/A

Prerequisites

Upgrade Procedure

N/A

Upgrading Oracle Management Agent Using agentDownload Script

Overview

Before You Begin

Prerequisites

Upgrade Procedure

N/A

Upgrading Shared Oracle Management Agent

Overview

N/A

Prerequisites

Upgrade Procedure

After You Upgrade

Upgrading Oracle Management Agent with Add-Ons

Overview

Before You Begin

Prerequisites

Upgrade Management Agent

After You Upgrade

Configuration Procedure

After You Configure

2 Things to Know

This chapter introduces you to some key concepts of Enterprise Manager Grid Control, and describes some important aspects of installation and upgrade that you must know before you proceed any further.

In particular, this chapter covers the following:

Procuring Enterprise Manager Grid Control Software

Procuring Oracle Management Agent Software

Understanding Installation Basics

Understanding Oracle WebLogic Server Requirement

Understanding Installation Directories

Understanding Additional Components Installed

Understanding Configuration Assistants

Understanding Prerequisite Checks

Understanding Limitations of Enterprise Manager Grid Control

Understanding Other Miscellaneous Concepts

Note:

Besides the key concepts described in this chapter, you can also review the concepts and other relevant aspects of installation and upgrad described in My Oracle Support note 1073184.1.

Procuring Enterprise Manager Grid Control Software

You can procure the Enterprise Manager Grid Control software from either the product DVD or the Oracle Technology Network (OTN) Web site. This section describes these sources.

In particular, this section covers the following:

How Do You Access the Software from DVD?

How Do You Procure the Software from Oracle Technology Network?

How Do You Access the Software from DVD?

You can obtain the Enterprise Manager Grid Control software from the product DVD that is available through Oracle Service Delivery Managers or Oracle Sales Representatives. The software may be available either on a single DVD or on multiple DVDs depending on the operating system.

This section covers the following:

Accessing Software from DVD

Setting Mount Point for DVD

Accessing Software from DVD

If the software is available on a single DVD, then insert the DVD into the DVD drive, and manually run the Enterprise Manager Grid Control Installation Wizard (For UNIX operating systems, invoke runInstaller. For Microsoft Windows operating systems, invoke setup.exe)

Note:

. For information about the Enterprise Manager Grid Control Installation Wizard, see What Is Enterprise Manager Grid Control Installation Wizard?.

If the software is available on multiple DVDs, then follow these steps:

Insert the first DVD into the DVD drive.

Copy the ZIP file from the DVD to a location on your local disk.

Inser the second DVD into the DVD drive.

Copy the ZIP file from the DVD to the same location on your local disk.

Extract the contents of both the ZIP files in the same location.

Run the Enterprise Manager Grid Control Installation Wizard (For UNIX operating systems, invoke runInstaller. For Microsoft Windows operating systems, invoke setup.exe).

Setting Mount Point for DVD

If you want to access the DVD from a shared DVD drive, then set a mount point for the DVD drive.

On most Linux operating systems, the disk mounts automatically when you insert the DVD into the DVD drive. However, for some Linux operating systems, you might have to manually mount the disk. To verify whether the disk mounts automatically and to manually mount the disk if it does not mount itself automatically, follow these steps:

Insert the DVD into the disk drive.

To verify if the disk is automatically mounted, run the following command:

On Red Hat Enterprise Linux:

# ls /mnt/cdrom

On SUSE Linux Enterprise Server:

# ls /media/cdrom

If the command in Step (2) fails to display the contents of the disk, then run the following command:

On Red Hat Enterprise Linux:

# mount -t nfs <host name>:/mnt/<full path to the dvdrom>

On SUSE Linux Enterprise Server:

# mount -t nfs <host name>:/media/<full path to the dvdrom>

On most AIX operating systems, the disk mounts automatically when you insert the DVD into the DVD drive. However, for some AIX operating systems, you might have to manually mount the disk. To verify whether the disk mounts automatically and to manually mount the disk if it does not mount itself automatically, follow these steps:

Switch the user to root user by running the following command:

$ su -root

Insert the disk into the drive.

Note:

If required, enter the following command to eject the currently mounted disk and to remove it from the drive:

# /usr/sbin/umount /<SD_DVD>

Enter the following command:

# /usr/sbin/mount -rv cdrfs /dev/cd0 /SD_DVD

In this example command, /SD_DVD is the disk mount point directory and /dev/cd0 is the device name for the disk device.

If you are prompted to specify the disk location, then specify the disk mount point directory path. For example, /SD_DVD

How Do You Procure the Software from Oracle Technology Network?

You can procure the Enterprise Manager Grid Control software from OTN. The software available on OTN is archived using Info-ZIP's highly portable ZIP utility. The software may be available either in a single ZIP file or in multiple ZIP files depending on the operating system. After downloading the software, you will need the UNZIP utility to extract the files.

This section covers the following:

Downloading Software

Verifying File Size

Extracting Contents

Verifying Platform Information

Downloading Software

To download the Enterprise Manager Grid Control software from OTN, access the following URL:

http://www.oracle.com/technology/software/products/oem/index.html

The software may be available either in a single ZIP file or in multiple ZIP files depending on the operating system. Download the ZIP file to a common location on your local disk.

Verifying File Size

After downloading the ZIP file, run the cksum command against the file and check if the file checksum of the downloaded software is the same as the file checksum displayed on OTN.

The following is the format of the ZIP file:

GridControl_11.1.0.0_<platform>.zip (<value> bytes) (cksum - <value>)

The value (cksum - <value>) is the file checksum that you need to check.

To check the file checksum, run the following command:

$ cksum GridControl_11.1.0.1.0_<platform>.zip

Note:

If the software is available in multiple ZIP files, then the format is GridControl_11.1.0.1.0_<platform>_<n>of<n>.zip (<value> bytes) (cksum - <value>), where the first occurrence of <n> indicates the ZIP file number and the second occurrence of <n> indicates the total number of ZIP files available for download. In this case, you must verify the file checksum of every ZIP file.

Extracting Contents

You must unzip the archive on the platform for which it was intended. For example, if you download the software for the Linux x86 operating system, then you must unzip the file on a Linux x86 operating system only. If you unzip the file on a Microsoft Windows computer and then move the stage area to a Linux computer, then the staged area files will get corrupted. This is because Microsoft Windows does not preserve the case sensitivity or the permission bits of Linux file names.

If you downloaded a single ZIP file, then extract the contents of it and manually run the Enterprise Manager Grid Control Installation Wizard (For UNIX operating systems, invoke runInstaller. For Microsoft Windows operating systems, invoke setup.exe).

Note:

For information about the Enterprise Manager Grid Control Installation Wizard, see What Is Enterprise Manager Grid Control Installation Wizard?.

If you downloaded multiple ZIP files to a common location, then extract the contents of all the ZIP files in the same location, and then manually run the Enterprise Manager Grid Control Installation Wizard (For UNIX operating systems, invoke runInstaller. For Microsoft Windows operating systems, invoke setup.exe).

Tip:

If you plan to store the files on a DVD, then first extract the contents of the ZIP file, and then copy those extracted files to the DVD. Do NOT copy the ZIP file itself; you need the unzipped contents of the ZIP file to do the installation.

Verifying Platform Information

After extracting the contents of the ZIP file, access the following file to verify the platform information. Here, <Software_Location> can be either the DVD mount point or the location on your local disk where you have extracted the contents of the ZIP files.

<Software_Location>/stage/shiphomeproperties.xml

Note that a 32-bit Enterprise Manager Grid Control software (both Enterprise Manager Grid Control and Oracle Management Agent) can be installed only on a 32-bit operating system that is running on a 32-bit hardware. Similarly, a 64-bit Enterprise Manager software can be installed only on a 64-bit operating system that is running on a 64-bit hardware.

Do NOT try to try install a 32-bit software on a 64-bit platform or vice versa; the installation may proceed, but will fail eventually. Therefore, ensure that you use the right software download for the right platform.

The shiphomeproperties.xml file provides the platform information as shown here:

<?xml version="1.0" standalone="yes" ?>
<ORACLEHOME_INFO>
<ARU_PLATFORM_INFO>
<ARU_ID>46</ARU_ID>
<ARU_ID_DESCRIPTION>Linux x86</ARU_ID_DESCRIPTION>
</ARU_PLATFORM_INFO>
</ORACLEHOME_INFO>

You can see the platform information in the <ARU_ID_DESCRIPTION> syntax. Table 2-1 lists the platform names that may be enclosed in this syntax, and describes whether the names represent a 32-bit or 64-bit software.

Table 2-1 Verifying Platform Information

Platform Name
Platform Specified in ARU_ID_DESCRIPTION
32-bit / 64-bit

Linux x86

Linux x86

32-bit

Microsoft Windows (32-bit)

Win 32

32-bit

Microsoft Windows (64-bit AMD64)

win 64

64-bit

Microsoft Windows (64-bit IA)

Windows Itanium

64-bit

Solaris Operating System (SPARC 64-bit)

Solaris

64-bit

HPUX PA-RISC(64-bit)

HPUNIX

64-Bit

AIX

AIX

64-bit

HP_IA64

HPI

64-bit

Linux x86-64

Linux AMD

64-bit

linux_ia64

Linux Itanium

64-bit

IBM Power Based Linux

Linux PPC

64-bit

linux_zseries64

zLinux

64-bit

HP Tru64 UNIX

Decunix

64-bit

Solaris Operating System (x86-64)

Solaris AMD64

64-bit

Solaris Operating System (x86)

Solaris AMD32

32-bit

Procuring Oracle Management Agent Software

Oracle Management Agent (Management Agent) is one of the core components of Enterprise Manager Grid Control, and therefore, its software is part of the Enterprise Manager Grid Control software. When you install Enterprise Manager Grid Control or an additional Oracle Management Service (OMS), the installation wizard automatically installs a Management Agent.

In graphical mode, you can install additional Management Agents using the Agent Deployment Wizard, which is a GUI-rich interface within the Enterprise Manager Grid Control console. This wizard installs additional Management Agents using the Management Agent software that is already present in the Oracle home of the OMS.

Note:

In Enterprise Manager 11g, you cannot install a Management Agent using the Oracle Universal Installer (OUI), which is the Enterprise Manager installation wizard.

However, note that the Management Agent software present in the Oracle home of the OMS is always for the version and platform on which that OMS is running. For example, if the OMS is Oracle Management Service 11g Release 1 and it is running on Linux platform, then the Management Agent software available there is also for Linux platform.

If you want to install Oracle Management Agent 10g or Oracle Management Agent 11g Release 1 for a platform that is different from the one on which the Oracle Management Service 11g Release 1 is running, then ensure that you download that software either automatically using the Agent Download application available in Enterprise Manager Grid Control or manually from Oracle Technology Network (OTN).

This section describes how you can procure the Management Agent software. In particular, this section covers the following:

Automatically Downloading Management Agent Software Using Download Agent Software Application

Manually Downloading Management Agent Software from OTN

Automatically Downloading Management Agent Software Using Download Agent Software Application

This section describes how you can use the Download Agent Software application, which is available in Enterprise Manager Grid Control, to download the Management Agent software. In particular, this section covers the following:

What Is Agent Download Application?

What Prerequisites You Must Meet?

How Do You Download the Management Agent Software?

What Is Agent Download Application?

The Agent Download application can be accessed using the Enterprise Manager Grid Control console and used to download Management Agent software from My Oracle Support Web site.

The Management Agent software on My Oracle Support is available in the form of a ZIP file. You can choose to download it either in the default location, that is, the Oracle home of the OMS, or in a custom location.

What Prerequisites You Must Meet?

Before downloading the Management Agent software, meet the following prerequisites:

Set the My Oracle Support credentials. To do so, in Enterprise Manager Grid Control, click Setup. On the Overview of Setup page, from the menu bar on the left, click Patching Setup. For more information, click Help on that page.

Set the proxy settings if you have a proxy server in your environment. To do so, in Enterprise Manager Grid Control, click Setup. On the Overview of Setup page, from the menu bar on the left, click Patching Setup and then click Proxy & Connection Settings. For more information, click Help on that page.

Ensure that the download location, that is, the directory where you want to download the software, is writable.

How Do You Download the Management Agent Software?

To download the Management Agent software using the Enterprise Manager Grid Control console, follow these steps:

In Enterprise Manager Grid Control, click Deployments.

On the Deployments page, from the Agent Installation section, click Download Agent Software.

On the Download Agent Software page, in the Available Agent Software section, select the Management Agent software you want to download. The application downloads the software ZIP file, extracts its contents, and then deletes the ZIP file.

The Platform column indicates the platform for which the Management Agent is supported. For example, Linux x86, Microsoft Windows (32-Bit), and so on.

While the first part of the platform name refers to the name of the supported operating system, the second part in parenthesis refers to the type of operating system, that is, 32-bit or 64-bit.

A 32-bit software can be installed only on a 32-bit operating system that is running on a 32-bit hardware. Similarly, a 64-bit software can be installed only on a 64-bit operating system that is running on a 64-bit hardware. Do NOT try to install a 32-bit software on a 64-bit platform or vice versa; the installation may proceed, but will fail eventually. Therefore, ensure that you download the right software for the right platform.

To determine the type of your operating system, refer to My Oracle Support note 421453.1.

The Version column indicates the release/version of the Management Agent that you can download. For example, 11.1.0.1.0.

The Available on this OMS column indicates whether the Management Agent software is already available in the default location of the OMS from where Enterprise Manager Grid Control is being accessed. In case of multi-OMS environment, the OMS referred here is the OMS shown in the OMS field on top of the page.

Note:

This column indicates whether the software is already available only in the default location of the OMS. It does not indicate the presence of software downloaded to a non-default location or a shared location.

The values can be either TRUE or FALSE. TRUE indicates that the software is already available on the OMS. You do not have to download it again. FALSE indicates that the software is not available on the OMS. You may want to download it.

The Size (MB) column indicates the size (in megabytes) of the software ZIP file available for download.

Note:

Enterprise Manager Grid Control actually downloads the ZIP file to the staging location and extracts the contents in the same location. The total size of all the extracted files may be more than the size mentioned here. Therefore, the space required in the staging location is at least double the size of the what is mentioned here.

In the Staging Location section, select the location where you want to stage the Management Agent software.

Select Default Location if you want to download the Management Agent software to the default location, that is, to the Oracle home of the OMS (the one shown on top of the screen against the field Oracle Management Service). The default download location on the OMS is <OMS_HOME>/sysman/agent_download/<version>

In case of a single OMS environment, Enterprise Manager Grid Control downloads the software ZIP file to the default location, extracts the files to the same location, and then deletes the ZIP file, leaving only the extracted files. In case of a multi-OMS environment, Enterprise Manager Grid Control downloads the software ZIP file and extracts the files to the first OMS home (the OMS shown in the OMS field on top of the screen), then copies the ZIP file to the next OMS home and extracts the files there as well. Once all OMS homes have the software, Grid Control deletes the ZIP file from each of the OMS homes, leaving only the extracted files.

For a multi-OMS environment, you must provide the credentials to access the Oracle home directories of the OMSes in the environment.

Select Use Oracle Home Preferred Credentials if you want to use preferred credentials stored in the Management Repository.

Select Override Oracle Home Preferred Credentials if you want to override them with new set of credentials. If you select this option, you can specify either the same credentials or different credentials to access the OMSes in your environment, depending on how they are configured.

Select Custom Location and specify a location of your choice if you want to download the Management Agent software to a custom location. The custom location must be accessible from all the remote hosts and OMSes, and must have 'write' permission.

This is an ideal choice under the following conditions:

When you have a shared, mounted location that is visible on all OMSes. The shared location can be anywhere in the enterprise configuration.

When you do not want Enterprise Manager Grid Control to download the software and extract the files on all the OMSes automatically. This way, you can download the software to one particular location and manually copy the files to other OMSes, whenever required.

If the custom location already exists (that is, if you have manually created it), then Enterprise Manager Grid Control downloads the software ZIP file to that location. However, if the location does not exist, then Enterprise Manager Grid Control automatically creates the directories and then downloads the software there. If you already have a copy of the software in the default location, then Enterprise Manager Grid Control overwrites that with the version selected for download.

Enterprise Manager Grid Control downloads the software ZIP file to the custom location, extracts the files to the same location, and deletes the ZIP file. If you have multiple OMSes, you have to manually copy the extracted files to other OMSes.

Click Download to download the Management Agent software.

Manually Downloading Management Agent Software from OTN

To manually download the Management Agent software from OTN, access the following URL:

http://www.oracle.com/technology/software/products/oem/htdocs/agentsoft.html

Understanding Installation Basics

This section describes the fundamental aspects of the installation process. In particular, this section covers the following:

What Different Installation Modes Can You Use?

What Is Enterprise Manager Grid Control Installation Wizard?

What Installation Types Are Offered by the Installation Wizard?

What Ports Are Used for Installation?

How Can You Change the Language Used in Enterprise Manager Grid Control Console?

What Different Installation Modes Can You Use?

You can install Enterprise Manager Grid Control or any of its core components either in an interactive, graphical mode or in a silent mode.

Graphical Mode
Graphical mode is the Graphical User Interface (GUI) method that involves usage of a Java-based installation wizard or a browser-based application that is built into and accessed from the Enterprise Manager Grid Control console. This method is best suited for first-time installations because you are guided through the entire installation process and your installation details are captured using the interview screens.

Silent Mode
Silent method involves usage of Oracle-supplied response files or scripts that capture all the information required for installation. This method is simpler and faster, but requires you to have some knowledge on the installation process so that you can provide your installation details in the response files without having to see the interview screens of the installation wizard.

In both these modes, you can perform a software-only installation. A Software-Only installation is an approach that enables you to install only the software binaries of Enterprise Manager Grid Control or an OMS, that is, without any configuration to the installation. This is best suited when you want to install the software at one point and configure it later.

What Is Enterprise Manager Grid Control Installation Wizard?

Enterprise Manager Grid Control Installation Wizard is a Java-based wizard that helps you install or upgrade Enterprise Manager Grid Control or any of its core components in a graphical mode. If you are installing Enterprise Manager Grid Control or any of its core components for the first time, then Oracle strongly recommends you to use this installation wizard.

Figure 2-1 describes the key elements of the installation wizard.

Figure 2-1 Enterprise Manager Grid Control Installation Wizard

Note:

In Enterprise Manager 11g, you cannot install a Management Agent using the Oracle Universal Installer (OUI), which is the Enterprise Manager installation wizard.

What Installation Types Are Offered by the Installation Wizard?

Table 2-2 describes the installation types offered by the Enterprise Manager Grid Control installation wizard.

Note:

The procedures for the installation types offered by the Enterprise Manager Grid Control Install Wizard are documented in the Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Table 2-2 Installation Types Offered by the Enterprise Manager Grid Control Installation Wizard

Installation Type
Description
Core Components Installed and Configured, or Upgraded
Reference Links

Install a new Enterprise Manager system

Installs Enterprise Manager Grid Control using an existing, certified Oracle Database where a Management Repository does not exist.

Installs Oracle Management Service 11g Release 1 (Deployed to the existing Oracle WebLogic Server)

Installs Oracle Management Agent 11g Release 1

Installs Oracle Web Tier 11g Release 1

Configures the Management Repository (in the existing Oracle Database), Oracle Management Service, and Oracle Management Agent

Graphical Mode

Oracle Enterprise Manager Grid Control Basic Installation Guide

Silent Mode

Part I

Add an additional Management Service

Installs an additional OMS to your existing Enterprise Manager Grid Control environment.

Installs Oracle Management Service 11g Release 1 (Deployed to the existing Oracle WebLogic Server)

Installs Oracle Management Agent 11g Release 1

Installs Oracle Web Tier 11g Release 1

Graphical Mode

Oracle Enterprise Manager Grid Control Basic Installation Guide

Silent Mode

Part II

Upgrade to Enterprise Manager 11g

Upgrades the following:

Enterprise Manager 10g Grid Control Release 2 (10.2.0.4.0) or higher to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0)

(Additional) Oracle Management Service 10g Grid Control Release 2 (10.2.0.4.0) or higher to Oracle Management Service 11g Release 1 (11.1.0.1.0)

Automatically detects the Oracle homes and upgrades them to 11g Release 1 (11.1.0.1.0).

Graphical Mode

Oracle Enterprise Manager Grid Control Basic Installation Guide

Silent Mode

Part V

Note:

In Enterprise Manager 11g, you cannot install a Management Agent using the Oracle Universal Installer (OUI), which is the Enterprise Manager installation wizard.

What Ports Are Used for Installation?

This section describes the default ports that are honored while installing Enterprise Manager Grid Control. In particular, this section covers the following:

What Default Ports Are Used?

How Can You Customize Ports?

What Precautions Must You Take While Customizing Port Numbers?

What Default Ports Are Used?

The following are the default ports used for installation:

Enterprise Manager Grid Control

Upload Port
Console Port

HTTP Port
4889

If 4889 is not available, then the first available free port from the range 4889 to 4898 is selected.

The first available free port from the range 7788 - 7798 is selected.

HTTPS Port
1159

If 1159 is not available, then the first available free port from the range 4899 to 4908 is selected.

The first available free port from the range 7799 - 7809 is selected.

Oracle Management Agent

The default upload port for Management Agent is 3872. The same port is used for both HTTP and HTTPS. If 3872 is not available, then the first available free port from the range 1830 to 1849 is selected.

Admin Server

The default HTTPS port for Admin Server is 7101. If 7101 is not available, then the first available free port from the range 7101 to 7200 is selected.

Node Manager

The default HTTPS port for Node Manager is 7401. If 7401 is not available, then the first available free port from the range 7401 to 7500 is selected.

Managed Server

The default HTTP port for Managed Server is 7201. If 7201 is not available, then the first available free port from the range 7201 to 7300 is selected.

The default HTTPS port for Managed Server is 7301. If 7310 is not available, then the first available free port from the range 7301 to 7400 is selected.

How Can You Customize Ports?

Enterprise Manager Grid Control offers you the flexibility to use custom ports instead of default ports.

If you are installing Enterprise Manager Grid Control in graphical mode, that is, using the Enterprise Manager Grid Control Installation Wizard, then you can use the Customize Ports screen to specify custom ports.

If you are installing Enterprise Manager Grid Control in silent mode, that is, using the installation procedures described in Part III, "Installing Oracle Management Agent", then update the staticports.ini file with suitable custom ports.

The staticports.ini file is available at the following location on the installation DVD:

<DVD>/response/staticports.ini

While updating the staticports.ini file, you must be extremely careful because an error in the file can cause the installation wizard to use default ports without displaying any warning. Therefore, before updating the staticports.ini file, check for these points:

If a port is already being used by a component or any other application, do not specify that port (used port) in the staticports.ini file. If you specify a port that is already in use, then the related Configuration Assistant also fails.

If you have specified the same port for more that one component, then the installation displays an error after the prerequisite checks phase. You must rectify this error before proceeding with the installation.

If you have syntax errors in the staticports.ini file (for example, if you omitted the equal (=) character for a line), then the installation wizard ignores the line. For the components specified on such lines, the installer assigns the default ports. The installation wizard does not display a warning for lines with syntax errors.

If you misspell a component name, then the installation wizard assigns the default port for the component. Names of components in the file are case-sensitive. The installation wizard does not display a warning for lines with unrecognized names.

If you specify a nonnumeric value for the port number, then the installation wizard ignores the line and assigns the default port number for the component. It does this without displaying any warning.

If you misspell the parameter on the command line, then the installation wizard does not display a warning. It continues and assigns default ports to all components.

If you specify a relative path to the staticports.ini file (for example, ./staticports.ini) on the command line, then the installation wizard does not find the file. It continues without displaying a warning and it assigns default ports to all components. You must specify a full path to the staticports.ini file.

If the parameter you specify on the command line does not match the installation type that you are performing (for example, if you specify the parameter for the middle tier but you are installing the infrastructure), the installation wizard does not give a warning. It continues and assigns default ports to all components.

What Precautions Must You Take While Customizing Port Numbers?

While customizing port numbers, consider the following:

Port numbers cannot be greater than 65536.

If you use a port number less than 1024 for a component, then you must run the component as the root user.

If you use a port number less than 1024 for a component, then the component cannot be started at the end of the installation. You may need to configure the component first before you can start it up.

How Can You Change the Language Used in Enterprise Manager Grid Control Console?

By default, the Enterprise Manager Grid Control Installation Wizard installs Enterprise Manager Grid Control console with English language. If you want to view them in another language, then select the required languages in the Select Languages screen of the installation wizard.

Note:

The language you select here changes the language used in the Enterprise Manager Grid Control console screens only; it does NOT change the language used in the installation wizard screens. The language of the installation wizard screens is based on the operating system language.

When you select additional languages to install, the installation wizard also installs fonts required to display the languages.

For some components, languages are installed only if you select them during installation. In this case, if you access the application in a language that is not available, it reverts to the locale language.

For other components, available languages are installed regardless of what you select during installation. In this case, however, fonts are installed only for the languages that are explicitly selected. When you access the application, it uses text in your language because the language was installed. However, if you do not have the appropriate fonts to render the text, the text appears as square boxes. This usually applies to the Chinese, Japanese, and Korean languages.

What Data Files Are Created While Configuring Oracle Management Repository?

The following are the data files created while configuring Oracle Management Repository:

mgmt_ecm_depot1.dbf

mgmt.dbf

mgmt_ad4j.dbf

How Do You Delete Data Files?

To delete the data files, you must drop the SYSMAN/MDS schema. To do so, run the following command from the Oracle home of the OMS.

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>

Note:

For Microsoft Windows, invoke RepManager.bat.

If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments:

-mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN). However, RepManager 10.2.0.5 supports -action drop (drops only SYSMAN).

After dropping the schema, manually delete the database files mgmt.dbf and mgmt_ecm_depot1.dbf.

You can find these files by running the following command as SYS:

SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%';

Understanding Oracle WebLogic Server Requirement

To install Enterprise Manager Grid Control, as a prerequisite, you must have Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1). This section describes some important aspects related to Oracle WebLogic Server that you must know before you install Enterprise Manager Grid Control. In particular, this section covers the following:

How Do I Install Oracle WebLogic Server?

How Do I Verify Whether Oracle WebLogic Server Is Installed?

Is Oracle WebLogic Server Cluster Supported?

Is the Existing Admin Server in Oracle WebLogic Server Used?

When and Why Do You Need Oracle WebLogic Server Credentials?

When and Why Do You Need Node Manager Credentials?

How Do You Find Admin Server Port While Installing an Additional OMS

How Do You Verify Whether Admin Server Is Running?

How Do You Start Admin Server?

How Do I Install Oracle WebLogic Server?

For information on installing Oracle WebLogic Server, see My Oracle Support note 1063762.1.

For more information, downloads, demos, access the following URL:

http://www.oracle.com/technology/products/weblogic/index.html

How Do I Verify Whether Oracle WebLogic Server Is Installed?

As a prerequisite, you must have Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1) for installing Enterprise Manager Grid Control.

To verify whether Oracle WebLogic Server is installed, check the following file in the Oracle home of the Oracle WebLogic Server:

$<ORACL_HOME>/logs/log.txt

The following is the sample output of the log.txt file:

    release  10.3.2.0 [Added]
    |_____Common Infrastructure Engineering 6.8.0.0 [Added]
    |    |_____Uninstall [Added]
    |    |_____Patch Client [Added]
    |    |_____Patch Attachment Facility [Added]
    |    |_____Clone Facility [Added]
    |_____WebLogic Server 10.3.2.0 [Added]
    |    |_____Core Application Server [Added]
    |    |_____Administration Console [Added]
    |    |_____Configuration Wizard and Upgrade Framework [Added]
    .
    .
    .
    .

Is Oracle WebLogic Server Cluster Supported?

Oracle WebLogic Server cluster consists of multiple Oracle WebLogic Servers running simultaneously and working together to provide increased scalability and reliability. A cluster appears to be a single Oracle WebLogic Server instance. The server instances that constitute a cluster can run on the same host, or be located on different hosts.

You can install Enterprise Manager Grid Control on an Oracle WebLogic Server Cluster, however, you cannot take advantage of the cluster configurations.

Is the Existing Admin Server in Oracle WebLogic Server Used?

To install Enterprise Manager Grid Control, the Enterprise Manager Grid Control Installation Wizard uses the software binaries of the existing Oracle WebLogic Server, however, it does not use the existing Admin Server that is available. The Enterprise Manager Grid Control Installation Wizard create a new Admin Server and deploys the Enterprise Manager Grid Control software to it.

When and Why Do You Need Oracle WebLogic Server Credentials?

While installing or upgrading Enterprise Manager Grid Control and while upgrading an additional OMS, you are prompted to specify the Oracle WebLogic Server credentials (user name and password). The credentials are used for creating Oracle WebLogic Domain and other associated components such as the Admin Server, the managed server, and the node manager.

The WebLogic user name is the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic. And the WebLogic password is the password for this default administrative user account.

When and Why Do You Need Node Manager Credentials?

While installing or upgrading Enterprise Manager Grid Control and while upgrading an additional OMS, you are prompted to specify the Node Manager password for the default Node Manager user account, which is nodemanager. The password is used for configuring the Node Manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

How Do You Find Admin Server Port While Installing an Additional OMS

To install an additional OMS, you might need to know the port of the Admin Server that is used by the first OMS. To find the port, view the value set for the AS_HTTPS_PORT parameter in the emgc.properties file. This file is available in the Oracle Management Service Instance Base location.

For example,

/u01/app/Oracle/gc_inst/user_projects/domains/EMGC_DOMAIN/em/EMGC_OMS1/emgc.properties

How Do You Verify Whether Admin Server Is Running?

To install an additional OMS, the Admin Server that is used by the first OMS must be up and running. To verify whether the Admin Server is running, access the Admin Server console using the following URL:

http://host:port/console

Here, host and port are values specified in the EM_INSTANCE_HOST and AS_HTTPS_PORT parameters, respectively, in the emgc.properties file. This properties file is available in the following location, that is, in the Oracle home of the OMS (first OMS) that was initially installed:

<ORACLE_HOME>/gc_inst/user_projects/domains/EMGC_DOMAIN/em/EMGC_OMS1/emgc.properties

How Do You Start Admin Server?

To install an additional OMS, the Admin Server that is used by the first OMS must be up and running. If it is not running, then start the Admin Server using the instructions outlined in the Oracle Fusion Middleware Administrator's Guide 11g Release 1 (11.1.1).

Alternatively, you can start the Admin Server by running the following command. Although the command is used essentially to start the OMS, the command in turn starts the Admin Server on which that OMS is running. So run this command even if you know that the OMS is already running.

emctl start oms

Understanding Installation Directories

This section describes the installation directories that need to be specified while installing Enterprise Manager Grid Control or any of its core components. In particular, this section covers the following:

What Is Oracle Inventory Directory?

What Is Oracle Middleware Home?

What Is Oracle Management Service Instance Base Location?

What Is Oracle Home?

What Is Installation Base Directory?

What Is EMSTATE Directory?

What Is /TMP C:\Temp Directory Used For?

What Is Oracle Inventory Directory?

If Enterprise Manager Grid Control is the first Oracle product that you are installing, then the Enterprise Manager Grid Control Installation Wizard prompts you to specify an inventory directory (also called the oraInventory directory).

This inventory directory is used by the installation wizard to place all the installer files and directories on the host. The installation wizard automatically sets up subdirectories for each Oracle product to contain the inventory data.

You can specify the OraInventory directory in two ways:

While installing Enterprise Manager Grid Control using the installation wizard, you can specify the OraInventory directory in the Oracle Inventory screen. When you specify it in this screen, you must also select the appropriate operating system group name that will own the OraInventory directories. The group you select must have write permission on the OraInventory directories.

While installing Enterprise Manager Grid Control in silent mode, that is, without using the installation wizard, you can specify the OraInventory directory using the -invPtrLoc parameter. This parameter considers the path to a location where the inventory pointer file (oraInst.loc) is available. For example, ./runInstaller -invPtrLoc /scratch/OracleHomes/oraInst.loc

Note:

Ensure that the Oracle Inventory (oraInventory) is not in a shared location.

If you already have an Oracle product installed on the host, then the installer uses the existing OraInventory directory that was created while installing that Oracle product. Ensure that you have write permission on that directory. To do so, run the installer as the same operating system user as the one who installed the other Oracle product.

Note:

OraInventory directory is different from Installation Directory. For information about Installation Directory, see What Is Oracle Middleware Home?.

What Is Oracle Middleware Home?

While installing Enterprise Manager Grid Control or an additional OMS using the Enterprise Manager Grid Control Installation Wizard, you are required to specify the Oracle Middleware Home location.

Oracle Middleware Home is the parent directory that has the Oracle WebLogic Server home, the Web tier instance files, and, optionally, one or more Oracle homes. This is where the OMS and the Management Agent are deployed.

The installation wizard uses its built-in algorithm to identify this location, and displays it for you to validate. By default, the following is the Oracle Middleware Home location:

/u01/app/Oracle/Middleware

You can either accept the default location or select another location that has write permission.

Note:

Oracle Middleware Directory is different from Oracle home of OMS or Oracle Management Agent. For information about Oracle home, see What Is Oracle Home?.

What Is Oracle Management Service Instance Base Location?

While installing Enterprise Manager Grid Control or an additional OMS using the Enterprise Manager Grid Control Installation Wizard, you are required to specify the Oracle Management Service Instance Base Location.

Oracle Management Service Instance Base Location is the directory under the parent directory of the Oracle Middleware Home, where the configuration files of OMS are stored. If the parent directory of the Oracle Middleware Home does not have write permission, then the Oracle Management Service Instance Base is created in the Oracle Middleware Home itself.

The installation wizard uses its built-in algorithm to identify this location, and displays it for you to validate. If the Oracle Middleware Home was /u01/app/Oracle/Middleware/, then by default, the following is the Oracle Management Service Instance Base Location:

/u01/app/Oracle/gc_inst

You can either accept the default location or specify another location that has write permission.

Note:

For information about Oracle Middleware Home, see What Is Oracle Middleware Home?.

What Is Oracle Home?

Oracle home is the directory where OMS and Management Agent are installed. By default, the Oracle home of OMS is oms11g and the Oracle home of Management Agent is agent11g. Both these Oracle homes are created in the Oracle Middleware Home.

For example, if you specify /u01/app/Oracle/Middleware as the Oracle Middleware Home, then the Oracle home of the OMS is created as /u01/app/Oracle/Middleware/oms11g, and the Oracle home of the Management Agent is created as /u01/app/Oracle/Middleware/agent11g.

Note:

Oracle home is different from OraInventory and Oracle Management Agent Home. For information about OraInventory directory, see What Is Oracle Inventory Directory?.

What Is Installation Base Directory?

While installing a Management Agent using the Agent Deployment Wizard, you are required to specify an Installation Base Directory.

Installation Base Directory is the parent directory on the remote host where the Oracle home of the Management Agent is created.

For example, if you specify the installation base directory as /john/oracle/, then the Oracle home of the Management Agent is created as /john/oracle/agent11g.

What Is EMSTATE Directory?

While installing a Management Agent using the Shared Agent Deployment Wizard, you are required to specify an EMSTATE directory.

EMSTATE directory is the directory that is created on each of the remote hosts and is used for storing configuration files such as emd.properties, targets.xml, log files, and so on.

Every host that shares the Management Agent binaries has its own EMSTATE directory, and you can specify any name for it. For example, you can have an EMSTATE directory titled emstatedir_11_1.

The EMSTATE directory location must meet the following conditions:

The EMSTATE directories of agents on different hosts should be local to the host instead of on the mounted drive, for security reasons.

Since the EMSTATE directory contains the targets pertaining to each host, it is highly recommended to have it on a local host.

The EMSTATE directory must meet the following space requirements:

The initial space required for EMSTATE directories is 1 MB.

Since all the upload files, collection files, and log files are stored in this directory, the size of the directory will increase. Consequently, Oracle recommends that you allocate sufficient space for the EMSTATE directories after taking these factors into account.

What Is /TMP C:\Temp Directory Used For?

When you invoke the Enterprise Manager Grid Control Installation Wizard, it automatically copies some executable files and link files to a temporary directory on the host. For example, the default /tmp directory on UNIX hosts, and C:\Temp on Microsoft Windows hosts.

If the host is set to run cron jobs along with many other processes that may be running periodically, then these jobs attempt to clean up the default temporary directory, thereby deleting some files and causing the installation wizard to fail.

If there are any cron jobs or processes that are automatically run on the hosts to clean up the temporary directories, then ensure that you set the TMP or TEMP environment variable to a location that is different from the default location. Ensure that the non-default location you set is secure on the hard drive, that is, the non-default location is a location where cleanup jobs are not run. Also ensure that you have write permissions on this alternative directory.

This must be done before you run the installer to invoke the Enterprise Manager Grid Control Installation Wizard. (For UNIX operating systems, you invoke runInstaller, and for Microsoft Windows, you invoke setup.exe).

Note:

Specifying an alternative temporary directory location is not mandatory, and is required only if any cron jobs are set on the computers to clean up the /tmp directory.

Understanding Additional Components Installed

This section describes the additional components that are installed along with the core components of Enterprise Manager Grid Control. In particular, this section covers the following:

What Is Oracle Configuration Manager?

What Are Software Updates?

What Is Oracle Configuration Manager?

While installing Enterprise Manager Grid Control or any of its core components, you can choose to enable Oracle Configuration Manager. Alternatively, you can enable it after installing Enterprise Manager Grid Control.

Oracle Configuration Manager automatically collects configuration information from your environment at regular intervals and uploads it to Oracle repository. This helps Oracle maintain up-to-date information about your environment, identify security vulnerabilities, quickly diagnose support issues, and offer better solutions consistently.

However, no business or personal information is collected and uploaded, except for local contact name in the event of transmission problems. Oracle guarantees that all the information collected will be kept strictly confidential and under no circumstances will this information be shared with any other party.

Oracle recommends that the host from where you are running the installation wizard have a connection to the Internet so that the configuration information can be automatically collected and uploaded to My Oracle Support.

If the host from where you are running the installation wizard has a connection to the Internet, then on the Oracle Configuration Manager screen of the installation wizard, specify the My Oracle Support user name (or e-mail address) and password.

Otherwise, specify only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information.

If you want to enable it after installation Enterprise Manager Grid Control, then see Enabling Oracle Configuration Manager After Installing Enterprise Manager Grid Control.

Manually Collecting and Uploading Configuration Information

To manually collect the configuration information, follow these steps:

Navigate to the Oracle home of the OMS and run the following command:

$<ORACLE_HOME>/ccr/bin/emCCR collect

For Oracle Configuration Manager 10.2.7 and higher, the collected configuration information is stored in the /ccr/hosts/state/upload/ocmconfig.jar file. For lower versions of Oracle Configuration Manager, the collected configuration information is stored in the /ccr/state/upload/ocmconfig.jar file. When you run the same command next time, the ocmconfig.jar file gets overwritten with fresh data. Therefore, at any point, you will see only one ocmconfig.jar file.

Upload the ocmconfig.jar file to a Service Request on My Oracle Support.

Repeat Step (1) and Step (2) from the Oracle home of Oracle Management Agent.

Enabling Oracle Configuration Manager After Installing Enterprise Manager Grid Control

To enable Oracle Configuration Manager at a later point, do the folllowing:

Set the environment variable ORACLE_CONFIG_HOME to the Oracle Management Service Instance Base. Oracle Management Service Instance Base is the directory where the configuration files of the OMS are created.

From the Oracle home of the OMS, run the following command:

$<ORACLE_HOME>/ccr/bin/setupCCR

From the Oracle home of Oracle Management Agent, run the following command:

$<ORACLE_HOME>/ccr/bin/setupCCR

What Are Software Updates?

While installing or upgrading Enterprise Manager Grid Control or an additional OMS, you can choose to install software updates.

Software updates include interim patches, critical patch updates, prerequisite updates, install updates, and so on released by Oracle periodically.

How Can You Download the Software Updates?

You can either manually download the software updates or have the Enterprise Manager Grid Control Installation Wizard automatically download them for you.

Manual Download by User: If you choose to manually download the software updates yourself, then run the following utility and provide the required information:

<DVD>/install/utility/downloadSWUpdates -u <My_Oracle_Support_Username> -p <My_Oracle_Support_Password>

Note:

If you want to know about the different arguments that can be passed with the utility, then run the following command:

<DVD>/install/utility/downloadSWUpdates -h

Manual download option is best suited when you are installing Enterprise Manager Grid Control or an additional OMS in silent mode. Oracle recommends you to use this option even while installing in graphical mode.

For information on where the software updates get downloaded by default, and for information on how to download to a custom location, see Where Are the Software Updates Downloaded?.

Automatic Download by Installation Wizard: If you choose to have the Enterprise Manager Grid Control Installation Wizard automatically download the software updates, then on Install Software Updates screen of the installation wizard, specify the My Oracle Support account user name and password. The installation wizard will connect to My Oracle Support and automatically download the updates from there.

When Can You Apply the Software Updates?

You can apply the software updates in one of the following ways depending on the download mechanism:

Manual Download by User: If you have manually downloaded the software updates, then:

In Silent Mode: Before you invoke the installer using the response file, edit the response file to set the INSTALL_UPDATES_SELECTION parameter to "staged". Then, for the STAGE_LOCATION parameter, specify the full path, which leads to the Updates directory, where the software updates are available.

In Graphical Mode: On the Install Software Updates screen of the Enterprise Manager Grid Control Installation Wizard, specify the full path, which leads to the Updates directory, where the software updates are available.

Automatic Download by Installation Wizard: If you choose to have the Enterprise Manager Grid Control Installation Wizard automatically download and apply the software updates, then on Install Software Updates screen of the installation wizard, specify the My Oracle Support account user name and password. The installation wizard will connect to My Oracle Support and automatically download the updates from there, and then apply them during installation.

Oracle strongly recommends you to apply them while the installation is in progress for the following reasons:

Keeping track of the availability of software updates at the time of installation is difficult

Keeping track of the patch numbers, and manually downloading them and applying them after installation is a cumbersome process

Automatically downloading and applying the software updates during installation saves time and effort, and ensures that you do not miss out on important software updates. However, note that when you deinstall the product, the updates are downloaded and stored in a directory titled Updates in the scratch path location. For example, if the scratch path location is /scratch/OracleHomes/, then the software updates are downloaded and stored in /scratch/OracleHomes/Updates.

Where Are the Software Updates Downloaded?

By default, the software updates are downloaded and stored in a subdirectory titled Updates in the temporary directory location (for example, /tmp in UNIX and C:\Temp in Microsoft Windows). For example, /tmp/Updates.

If you do not want the software updates to be downloaded in the temporary directory location, then run the following command and specify a download location of your choice:

<DVD>/install/utility/downloadSWUpdates -u <My_Oracle_Support_Username> -p <My_Oracle_Support_Password> -s <Custom_Download_Location>

Understanding Configuration Assistants

This section describes the postinstallation activities that are performed by the installation wizard. In particular, this section covers the following:

What Are Configuration Assistants?

What Configuration Assistants Are Run by the Installation Wizard?

What Is Agent Configuration Assistant Used For?

What Do You Do When Configuration Assistants Fail?

What Are Configuration Assistants?

While installing or upgrading Enterprise Manager Grid Control or any of its core components using the Enterprise Manager Grid Control Installation Wizard, a set of Configuration Assistants are run at the end of the installation process to configure the installed components. Your installation process is complete only after all the installed components are configured using these Configuration Assistants.

What Configuration Assistants Are Run by the Installation Wizard?

The following are the Configuration Assistants run by the installation wizard:

Table 2-3 Configuration Assistant

Installation Type
Configuration Assistant

Install a new Enterprise Manager system

(Install type offered by the Enterprise Manager Grid Control installer)

(Optional) OMS One-Off Patch Application

Repository Configuration Assistant

(Optional) MDS Schema Configuration Assistant

(Optional) OCM EM Repository Instrumentation

OMS Configuration Assistant

Add-On OMS Side Configuration

(Optional) OCM Configuration for OMS (Runs only if My Oracle Support credentials were provided in the installation wizard)

(Optional) Agent One-Off Patch Application

Agent Configuration Assistant

(Optional) OCM Configuration (Runs only if My Oracle Support credentials were provided in the installation wizard)

(Optional) Agent Add-On Plug-In (Runs only if Oracle System Monitoring Plug-ins are detected on the host)

Add an additional Management Service

(Install type offered by the Enterprise Manager Grid Control installer)

(Optional) OMS One-Off Patch Application

OMS Configuration Assistant

Add-On OMS Side Configuration

(Optional) OCM Configuration for OMS (Runs only if My Oracle Support credentials were provided in the installation wizard)

(Optional) Agent One-Off Patch Application

Agent Configuration Assistant

(Optional) OCM Configuration (Runs only if My Oracle Support credentials were provided in the installation wizard)

(Optional) Agent Add-On Plug-In (Runs only if Oracle System Monitoring Plug-ins are detected on the host)

Upgrade to Enterprise Manager 11g

(Install type offered by the Enterprise Manager Grid Control installer)

While upgrading Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0) or higher, the Configuration Assistants run are the same as the ones run for the install type Install a new Enterprise Manager system (as described in the first row of this table), but the Repository Configuration Assistant is called Repository Upgrade Configuration Assistant, and the Agent Configuration Assistant is called Agent Upgrade Configuration Assistant.

While upgrading Oracle Management Service 10g Release 4 (10.2.0.4.0) or higher, then Configuration Assistants run are the same as the ones run for the install type Add an additional Management Service (as described in the second row of this table), but the Agent Configuration Assistant is called Agent Upgrade Configuration Assistant.

Oracle Management Agent (Using any of the Management Agent installation methods described in this guide. This is not an install type offered by the Enterprise Manager Grid Control installer)

(Optional) Agent One-Off Patch Application

Agent Configuration Assistant

(Optional) OCM Configuration (Runs only if My Oracle Support credentials were provided in the installation wizard)

(Optional) Agent Add-On Plug-In (Runs only if Oracle System Monitoring Plug-ins are detected on the host)

Note:

If an optional Configuration Assistant fails, then the installation wizard ignores the failure and runs to the next Configuration Assistant automatically. However, if a mandatory Configuration Assistant fails, then the installation wizard stops the installation process.

If you use the Installing Enterprise Manager Software Only and Configuring Later approach, then an additional Configuration Assistant called Verify Addons Installed is run.

What Is Agent Configuration Assistant Used For?

The Agent Configuration Assistant (agentca) is a Configuration Assistant that is run during the configuration phase to configure the Management Agent.

Besides configuring the Management Agent when it is first installed, you use the agentca script to discover the newly installed targets, convert a standalone Management Agent to a cluster-based Management Agent, discover the targets installed on the new nodes of a cluster, and reconfigure a cluster-based Management Agent. To understand how you can perform these operations, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

Table 2-4 shows the arguments you can pass with the agentca script.

Table 2-4 Arguments Supported by Agent Configuration Assistant (agentca)

Option
Description

-n

Specify the cluster name (CLUSTER_NAME).

-c

Specify a comma-separated cluster node list.

-t

Do not start the agent after reconfiguration or target rediscovery.

-d

Rediscover targets.

-f

Reconfigure agents.

-i

Specify the oraInst.loc (oracle inventory location). This is required when the Oracle home does not exist in the central inventory.

-h

Get information on all the available options.

What Do You Do When Configuration Assistants Fail?

Table 2-5 describes what you must do when Configuration Assistants fail.

Table 2-5 Actions to be Performed When Configuration Assistants Fail

Configuration Assistant
Log Files to Review
Actions to be Taken

OMS One-Off Patch Application

$<ORACLE_HOME>/cfgtoollogs/opatch/opatch<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Repository Configuration Assistant

Review the log files in the following locations:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

(ORACLE_HOME refers to the Oracle home of the OMS. <ACTION> refers to any of the schema actions, for example, CREATE, TRANSX, MY_ORACLE_SUPPORT, and so on. For more information about these repository log files, see Repository Configuration Logs.)

Resolve the cause of the issue.

Clean up the Management Repository by running the following command:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>

Note:

For Microsoft Windows, invoke RepManager.bat.

RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN).

RepManager 10.2.0.5 supports -action drop (drops only SYSMAN)

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

MDS Schema Configuration Assistant

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

For more information, review the following log files:

<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Drop the MDS schema by running the following command from the Oracle home of OMS:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-dropRepository -connectString=<database_connect_string> -dbUser= <database_user> -dbPassword=<database_password> -oracleHome=<OMS_oracle_home> -mwHome=<middleware_home>

Where where <database_connect_string> must be in the following format:<database_host>:<database_port>:<database_sid>

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

OCM EM Repository Instrumentation

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

OMS Configuration Assistant

If the installer fails BEFORE the OMS Configuration Assistant starts running, review the following log file:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

If the installer fails AFTER the OMS Configuration Assistant starts running, then review the following log file:

$<ORACLE_HOME>/cfgtoollogs/omsca/omsca_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Check whether any Java processes are running from the Oracle Middleware Home. To do so, run the following command from the host where the OMS is running:

ps -ef | grep java | grep <Oracle_Middleware_Home>

Kill all the running processes, except for installer-related Java processes, by the running the following command. The installer-related Java processes run from the temp directory, so you can ignore the processes from that directory.

kill -9 <process_id>

Remove the Oracle Management Service Instance Base by running the following command:

rm -rf <OMS_Instance_Home>

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Add-on OMS Side Configuration

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Oracle Configuration Manager Repeater Configuration

Review the following log file and identify the patch that failed:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/Confi ureGC.pl

OCM Configuration for OMS

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the OMS)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Agent One-Off Patch Application

$<ORACLE_HOME>/cfgtoollogs/opatch/opatch<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the Management Agent)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/OPatch/opatch apply -invPtrLoc <ORACLE_HOME>/oraInst.loc -silent -local -oh <ORACL_HOME> <one-off_patch_location>

Agent Configuration Assistant

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the Management Agent)

If secure fails, then review the following log file:

$<ORACLE_HOME>/sysman/log/secure.log

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/bin/agentca -f

OCM Configuration

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the Management Agent)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/bin/agentca -f

Agent Add-On Plug-In

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

(ORACLE_HOME refers to the Oracle home of the Management Agent)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/AddonConfig.pl <ORACLE_HOME>

Repository Upgrade Configuration Assistant

Review the log files in the following locations:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.<ACTION>/

(ORACLE_HOME refers to the Oracle home of the OMS. <ACTION> refers to any of the schema actions, for example, PREUPGRADE, UPGRADE, TRANSX, and so on. For more information about these repository log files, see Repository Configuration Logs.)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then rerun the configureGC.pl script from the Oracle home of the OMS:

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Agent Upgrade Configuration Assistant

$<ORACLE_HOME>/cfgtoollogs/cfgfw/CfmLogger_<timestamp>.log

If secure fails, then review the following log file:

$<ORACLE_HOME>/sysman/log/secure.log

(ORACLE_HOME refers to the Oracle home of the Management Agent)

Resolve the cause of the issue.

Rerun the Configuration Assistant.

If you are installing in graphical mode, then return to the Enterprise Manager Grid Control Installation Wizard and click Retry.

If you are installing in silent mode, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/bin/agentca -f -u

Understanding Prerequisite Checks

Every time you install Enterprise Manager Grid Control using the installation wizard, a set of prerequisite checks are run to verify if the environment meets the minimum requirements for a successful installation. The installation wizard checks for a variety of things including required operating system patches, operating system packages, kernel parameters, and so on.

The following sections describe these prerequisite checks. In particular, this section covers the following:

What Prerequisite Checks Are Run by Default?

How Can You Run Prerequisite Checks in Standalone Mode?

What Prerequisite Checks Are Run by Default?

Table 2-6 lists the default prerequisite checks that are run by the Enterprise Manager Grid Control Installation Wizard for different installation types.

Table 2-6 Prerequisite Checks Run by Enterprise Manager Grid Control Installation Wizard for Different Installation Types

Installation Type
Prerequisite Checks

Install a new Enterprise Manager system

Additional Oracle Management Service

Upgrading an existing, previous release of Enterprise Manager Grid Control or any additional Oracle Management Service

Checking for certified operating system as described in My Oracle Support note 412431.1.

Checking for Certified packages and libraries as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

Checking for valid host name.

Checking for tmp space.

Checking for the inventory space.

Oracle Management Agent

Upgrading an existing, previous release of Oracle Management Agent

Checking for certified operating systems as mentioned in My Oracle Support note 412431.1.

Checking for certified packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

Checking for valid host name.

Checking for /etc/host file.

Checking for tmp space.

Checking for the inventory space.

How Can You Run Prerequisite Checks in Standalone Mode?

You can run the prerequisite checks in standalone mode before invoking the installation wizard. This helps you identify and resolve issues that might otherwise cause the installation to fail.

Table 2-7 shows the commands you need to run to run the prerequisite checks in standalone mode:

Table 2-7 Running Prerequisite Checks in Standalone Mode

Installation Type
Command

Install a new Enterprise Manager system

Additional Oracle Management Service

Upgrading an existing, previous release of Enterprise Manager Grid Control or any additional Oracle Management Service

<Software_Location>/install/runInstaller -prereqchecker PREREQ_CONFIG_LOCATION=<Software_Location>/emgc/Disk1/stage/prereq -entryPoint "oracle.sysman.top.oms_Core" -prereqLogLoc <absolute_path_to_log_location> -silent -waitForCompletion

Oracle Management Agent

Upgrading an existing, previous release of Oracle Management Agent

<Software_Location>/install/runInstaller -prereqchecker PREREQ_CONFIG_LOCATION=<Software_Location>/emgc/Disk1/stage/prereq -entryPoint "oracle.sysman.top.agent_Complete" -prereqLogLoc <absolute_path_to_log_location> -silent -waitForCompletion

Note:

On Microsoft Windows, replace /runInstaller with setup.exe. Also, <Software_Location> mentioned in the commands in Table 2-7 refer to the location where the Enterprise Manager software is available. For example, DVD. If you have downloaded the software from Oracle Technology Network (OTN), then specify the full path to that downloaded location.

Understanding Limitations of Enterprise Manager Grid Control

This section describes the limitations you might face while using Enterprise Manager Grid Control. In particular, this section covers the following:

Can You Access Unlicensed Components?

What Are the Limitations with DHCP-Enabled Machines?

Can You Access Unlicensed Components?

Although the installation media in your media pack contain many Oracle components, you are permitted to use only those components for which you have purchased licenses. Oracle Support Service does not provide support for components for which licenses have not been purchased.

For more information, access the Enterprise Manager documentation library at the following URL and view the Oracle Enterprise Manager Licensing Information Guide:

http://www.oracle.com/technology/documentation/oem.html

What Are the Limitations with DHCP-Enabled Machines?

Do NOT run the OMS on a computer that is DHCP enabled. Oracle strongly suggests that you use a static host name or IP address assigned on the network for Enterprise Manager Grid Control components to function properly.

For more information, refer to My Oracle Support Note 428665.1 at:

https://metalink.oracle.com/

Understanding Other Miscellaneous Concepts

This section covers miscellaneous concepts related to the installation of Enterprise Manager Grid Control. In particular, this section covers the following:

What Is a Host List File?

What SYSDBA Privileges Are Required for Creating Repository Schema?

What Scripts Are Run During the Installation Process?

What Is a Host List File?

While using the Agent Deployment Wizard, you can specify the hosts on which you want to install Oracle Management Agent, in two ways:

Specify either the host name or the IP address. Separate multiple host names using a comma, a white space, or a new line.

Select an external file that contains a list of hosts mentioned.

If you choose to select an external file that contains a list of all required host names, then ensure that the file format is similar to /etc/hosts file. The following is the recommended format of the /etc/hosts file.

154.87.3.229 host1.foo.com host1
154.87.3.109 host2.foo.com host2
154.80.5.218 host3.foo.com host3

IPv6 entries are supported in the file for fresh installations of 11g Release 1 (11.1). However, they are not supported for upgrade from 10g Release 4 (10.2.0.4) or higher to 11g Release 1 (11.1).

Note:

According to RFC 952, the following are the assumptions: A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character.

The Agent Deployment Wizard picks up only the values in the first column of the Host List file that you select. Ensure that the host list format is appropriate because the Agent Deployment Wizard does not validate this format on the selected file.

WARNING:

Ensure that you do not specify duplicate entries of the hosts. If there are duplicate host entries in the list, then the application hangs. Also ensure that you use the same host names for which the SSH has been set.

What SYSDBA Privileges Are Required for Creating Repository Schema?

Table 2-8 lists the SYSDBA privileges required by the existing DBA to create the Management Repository schema:

Table 2-8 SYSDBA Privileges Required for Creating Repository Schema

Object Name
Privilege Required
Whether or Not the Privilege Can Be Granted
Command to Grant the Privilege

dbms_aq

execute

true

grant EXECUTE on DBMS_AQ to <username> with grant option

dbms_aqadm

execute

true

grant EXECUTE on DBMS_AQADM to <username> with grant option

dbms_rls

execute

true

grant EXECUTE on DBMS_RLS to <username> with grant option

aux_stats$

select

true

grant SELECT on AUX_STATS$ to <username> with grant option

aux_stats$

insert

true

grant INSERT on AUX_STATS$ to <username> with grant option

aux_stats$

update

true

grant UPDATE on AUX_STATS$ to <username> with grant option

aux_stats$

delete

true

grant DELETE on AUX_STATS$ to <username> with grant option

dbms_random

execute

true

grant EXECUTE on DBMS_RANDOM to <username> with grant option

dbms_redefinition

execute

true

grant EXECUTE on DBMS_REDEFINITION to <username> with grant option

dbms_lob

execute

true

grant EXECUTE on DBMS_LOB to <username> with grant option

dbms_lock

execute

true

grant EXECUTE on DBMS_LOCK to <username> with grant option

dbms_crypto

execute

true

grant EXECUTE on DBMS_CRYPTO to <username> with grant option

dbms_session

execute

true

grant EXECUTE on DBMS_SESSION to <username> with grant option

dbms_utility

execute

true

grant EXECUTE on DBMS_UTILITY to <username> with grant option

utl_file

execute

true

grant EXECUTE on UTL_FILE to <username> with grant option

Access Policy

exempt

true

grant EXEMPT ACCESS POLICY to <username>

What Scripts Are Run During the Installation Process?

At least once during or after the installation of Enterprise Manager Grid Control or Management Agent, you are prompted to log in as a root user and run oraInstRoot.sh, allroot.sh, or root.sh. You must log in as a root user because the scripts edit files in the /etc directory and create files in the local bin directory (/usr/local/bin, by default).

After every installation, a check is performed to identify the Central Inventory (oraInventory) directory. The Central Inventory directory is a directory that is automatically created by the installation wizard when an Oracle product is installed on a host for the very first time.

Note:

Ensure that the central inventory location you specify must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1

If you have NOT installed an Oracle product before on the host, then run the oraInstRoot.sh script from the Central Inventory:

$Home/oraInventory/oraInstRoot.sh

The oraInstRoot.sh script is run to create the oraInst.loc file. The oraInst.loc file contains the Central Inventory location.

However, if you already have an Oracle product on the host, then run the following:

If you are installing Enterprise Manager Grid Control or an additional OMS, then run allroot.sh script from the Oracle home of the OMS (oms11g):

<Oracle_Home>/allroot.sh

If you are installing a Management Agent, then run root.sh script from the Oracle home of the Management Agent (agent11g):

<Oracle_Home>/root.sh

Part I

Installing Enterprise Manager System

This part describes the different ways of installing Enterprise Manager Grid Control.

In particular, this part contains the following chapters:

Chapter 3, " Installing Enterprise Manager System"

Chapter 4, "Installing Enterprise Manager Software Only in Graphical Mode and Configuring Later"

Chapter 5, "Installing Enterprise Manager Software Only in Silent Mode and Configuring Later"

3 Installing Enterprise Manager System

This chapter describes how you can install Enterprise Manager Grid Control using an existing, certified Oracle Database and Oracle WebLogic Server, in silent mode. In particular, this section covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

Note:

Do NOT install the Enterprise Manager system on an OCFS file system. This file system is not supported.

Overview

The installation type, Install a new Enterprise Manager system, enables you to install a complete Enterprise Manager system while utilizing an existing, certified Oracle Database to store Oracle Management Repository (Management Repository).

The existing, certified Oracle Database must be one of the databases listed in My Oracle Support note 412431.1.

Table 3-1 describes the installation process and the software components that are installed or configured for this installation type.

Table 3-1 Process for Installing Enterprise Manager System in Silent Mode

Step 1

Installation of Oracle Management Service 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the Oracle Management Service (OMS) software binaries in the new home.

Oracle Middleware Home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for OMS is /u01/app/Oracle/Middleware/oms11g

Step 2

Installation of Oracle Management Agent 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the Oracle Management Agent (Management Agent) software binaries in the new home.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for Management Agent is /u01/app/Oracle/Middleware/agent11g

Step 3

Installation of Oracle Web Tier 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the Web tier software binaries in the new home.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for Web tier is /u01/app/Oracle/Middleware/Oracle_WT

Step 4

Installation of Oracle Common Directory

Creates a common directory in the Oracle Middleware Home location for storing configuration files.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the common directory is /u01/app/Oracle/Middleware/oracle_common.

Step 5

Configuration of Oracle Management Service Instance Base Location

Creates an instance home for Enterprise Manager Grid Control in the parent directory of the Oracle Middleware Home for storing all OMS-related configuration files. By default, the instance home is gc_inst. You can, however, edit this and specify a custom name.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware and if you choose to retain the default instance home name, then the instance home location is /u01/app/Oracle/gc_inst

If the parent directory of the Oracle Middleware Home does not have write permission, then the Oracle Management Service Instance Base is created in the Oracle Middleware Home.

Step 6

Configuration of Core Components

Runs the Configuration Assistants to perform the following:

Applying OMS-Related One-Off Patches: (Optional) Applies one-off patches to the Oracle home of the OMS (oms11g).

Configuring SYSMAN Schema and MDS Schema: In the specified existing, certified Oracle Database, configures the SYSMAN schema and Metadata (MDS) schema, and creates these data files: mgmt.dbf, mgmt_ecm_depot1.dbf, mgmt_ad4j.dbf

Configuring OMS: Configures the OMS and the independent instance where Enterprise Manager Grid Control is deployed.

Add-on OMS Side Configuration: Configures the Virtualization Add-On detected in the Oracle home of the OMS (oms11g).

Configures OCM (If required; Only if you have chosen to configure it): Configures Oracle Configuration Manager (OCM) in the Oracle home of the OMS (oms11g) and Oracle home of the Web tier (Oracle_WT).

Applying Agent-Related One-Off Patches: (Optional) Applies one-off patches to the Oracle home of the Management Agent (agent11g).

Configuring Management Agent: Configures the Management Agent to enable monitoring of targets, collection of information, and so on.

Configures OCM (If required; Only if you have chosen to configure it): Configures Oracle Configuration Manager (OCM) in the Oracle home of the Management Agent (agent11g).

Configures System Monitoring Plug-Ins: Configures the System Monitoring Plug-Ins detected in the Oracle home of the Management Agent (agent11g).

Before You Begin

Before you begin, keep these points in mind:

This installation type only supports installation of Enterprise Manager Grid Control locally on the server where the installer is invoked, and does not support installing on multiple or remote hosts.

Do NOT install the additional OMS on an OCFS file system. This file system is not supported

Install Enterprise Manager Grid Control on a dedicated Oracle WebLogic Server instance (in a separate middleware home). Do NOT install Enterprise Manager Grid Control on an Oracle WebLogic Server instance that already has an Oracle Fusion Middleware product installed. For example, if the middleware home already has Oracle SOA Suite 11.1.1.2.0 installed, then do not install Enterprise Manager Grid Control in the same middleware home. Enterprise Manager Grid Control cannot co-exist with any Oracle Fusion Middleware product in the same middleware home because the ORACLE_COMMON property is used by both the products.

By default, the upload ports and console ports as described in What Ports Are Used for Installation? are used.

However, if you want to use custom ports instead, then update the staticports.ini file as described in What Ports Are Used for Installation?, and pass the -staticPortsIniFile parameter while invoking the installer.

For example:

./runInstaller -silent -staticPortsIniFile <absolute_path_to_ini_file_location>/staticports.ini -responseFile <absolute_path_to_response_file> [-invPtrLoc <absolute_path_to_inventory_directory>]

By default, the software updates cannot be applied during installation because the INSTALL_UPDATES_SELECTION parameter in the response file is set to "skip". However, if you want to apply them during installation, then modify this parameter as described in Table 3-5.

Do NOT set the DISPLAY environment variable.

No environment variable specific to Enterprise Manager Grid Control needs to be set prior to installation. The ORACLE_HOME and ORACLE_SID variables should not be set; Oracle directories should not appear in the PATH.

Oracle offers code fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for code fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:

http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Grid Control installation, you must consider Enterprise Manager Grid Control's framework components as well as the targets monitored by Enterprise Manager Grid Control. Oracle recommends keeping your Grid Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license. For information about the certified combinations of Enterprise Manager Grid Control components and monitored targets, see My Oracle Support note.412431.1.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before installing a complete Enterprise Manager system in silent mode, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 3-2 Prerequisites for Installing Enterprise Manager System in Silent Mode

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the OMS only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - OMS.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

Operating System Groups and Users Requirements

Ensure that you create the required operating system groups and users as described in Appendix C, "Creating Operating System Groups and Users Requirements".

Unique Host Name and Static IP Address Requirements

Ensure that you check the network configuration to verify that the host on which you are installing resolves to a unique host name and a static IP address that are visible to other hosts in the network.

Note: You must use only a static IP address. If you use a dynamic IP address, the installation will fail.

File Descriptor Requirements

Ensure that you set the file descriptors to a minimum of 4096.

To verify the current value set to the file descriptors, run the following command:

/bin/sh -c "ulimit -n"

If the current value is not 4096, then as a root user, update the /etc/security/limits.conf file with the following entries:

<UID> soft nofile 4096

<UID> hard nofile 4096

System Parameter Value Requirements for AIX

Ensure that the value set for the system parameter ncarg is 1024. To verify the value of ncarg, run the following command:

-lsattr -EH -l sys0 | grep ncargs

If the value is less than 1024, then increase it to 1024 by running the following command:

chdev -l sys0 -a ncargs=1024

Temporary Directory Space Requiremens

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system.If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1

UMASK Value Requirements

Ensure that you set the default file mode creation mask (umask) to 022 in the shell startup file.

For example:

Bash Shell

$ . ./.bash_profile

Bourne or Korn Shell

$ . ./.profile

C Shell

% source ./.login

JDK Requirements

Ensure that you have the following version of JDK installed on the host where you are planning to install Enterprise Manager Grid control.

Linux Platform (64 Bit): SUN JDK 1.6_18+

(On Linux 32-bit platforms, you need not install JDK because it is packaged by default with Oracle WebLogic Server)

Solaris Platform: SUN JDK 1.6_18+

HP-UX Platform: JDK 6.0.05+

AIX Platform: JDK 1.6.0 SR6

Microsoft Windows Platform (64 Bit): SUN JDK 1.6_18

Download the JDK version for your platform from the platform vendor's Web site. For example, download SUN JDK 1.6_18+ for Linux platforms from Oracle Web site. Similarly, download the JDK for other platforms from other vendors' trusted Web sites.

You can also refer to My Oracle Support note 1063587.1 for an example on installing JDK 1.6_18+ on Linux x86_64 platform.

If you already have a JDK installed, then verify its version by navigating to the <jdk>/bin directory and running the following command. The output of this query should give you the complete version number.

java -fullversion

Note: JROCKIT is not supported.

Oracle WebLogic Server Requirements

Ensure that Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1) is already installed on the host where you plan to install Enterprise Manager Grid Control.

Ensure that the installation was a typical installation, and even if it was a custom installation, ensure that components chosen for custom installation were the same as the ones associated with a typical installation.

Ensure that the installation was under the Middleware Home directory. For example, /scratch/aime/Oracle/Middleware1/wlserver_10.3.

Ensure that no other Oracle Fusion Middleware products or components are installed in the Middleware Home directory where Oracle WebLogic Server 10.3.2 is installed.

Enterprise Manager Grid Control will create a new domain in this Oracle WebLogic Server, and not use any of the existing domains.

For information on installing Oracle WebLogic Server, see My Oracle Support note 1063762.1. For more information, downloads, demos, access the following URL:

http://www.oracle.com/technology/products/weblogic/index.html

Oracle WebLogic Server Patch Requirements

Ensure that you apply patch ID WDJ7 on Oracle WebLogic Server using the Oracle Smart Update utility. This patch fixes bugs 8990616, 9100465, and 9221722.

For information on applying this patch, see My Oracle Support note 1072763.1.

For information on Oracle Smart Update utility, see Oracle Smart Update Installing Patches and Maintenance Packs documentation available at:

http://www.oracle.com/technology/products/weblogic/index.html

Existing Database Version Requirements

Ensure that the existing, certified Oracle Database is one of the databases listed in My Oracle Support note 412431.1. The database can reside either on the host where you are installing the product or on a remote host.

Ensure that the existing, certified Oracle Database is not configured with Oracle Grid Infrastructure. This type of configuration is not supported.

If you are installing using Oracle Database 11g Release 1 (11.1.0.7.0), then ensure that you apply the patch for bug# 9066130.

If you are installing using Oracle Database 11g Release 2 (11.2.0.1.0), then ensure that you apply the patch for bug# 9002336 and 9067282.

Note: For information about these patches and their availability for different platforms, see My Oracle Support note 1073166.1

Database Partitioning Requirements

Ensure that the existing, certified Oracle Database has the Partitioning Option enabled.

Existing Database Not to Be in QUIESCE Mode

Ensure that existing, certified Oracle Database is not in QUIESCE mode. To verify this, run the following SQL in the database:

select active_state from v$instance;

Existing Database Not to Have Database Control

(If you are upgrading from Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, which uses an Oracle Database where the Management Repository is already created, that is, where the Grid Control SYSMAN schema is already created, then ignore this prerequisite. This prerequisite applies only when you install Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) using an existing, certified Oracle Database that has Database Control SYSMAN schema created, which you want to replace now with Grid Control SYSMAN schema.)

Ensure that your existing, certified Oracle Database does NOT have Database Control SYSMAN schema. If it has, that is, if your existing database is configured with Database Control, then deconfigure it.

Verify whether your database has Database Control SYSMAN schema.

To do so, log in to the database as SYS user and run the following query:

SELECT COUNT(*) FROM ALL_USERS WHERE USERNAME='SYSMAN'

If the result of this query is 1, then the database has this schema, so deconfigure it.

Before deconfiguring the Database Control, set the environment variable ORACLE_HOME to the Oracle home of the database, and ORACLE_SID to the SID of the database.

For example, in bash shell, you can set them in the following way:

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1

export ORACLE_SID=orcl

Deconfigure the Database Control.

To deconfigure Database Control for a standalone database, run the following command from the Oracle home of the database as the user who installed the database. If the command hangs, then restart the database and rerun the command.

$<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop -SYS_PWD <sys pasword> -SYSMAN_PWD <sysman password>

To deconfigure Database Control for a Real Application Cluster (RAC) database, run the following command from the Oracle home of the database as the user who installed the database. If the command hangs, then restart the database and rerun the command.

$<ORACLE_HOME>/bin/emca -deconfig dbcontrol db -repos drop -cluster -SYS_PWD <sys pasword> -SYSMAN_PWD <sysman password>

Note: If the deconfigure operation hangs, then refer to My Oracle Support note 375946.1.

Existing Database Not to Have SYSMAN and SYSMAN_MDS Schema

(If you are upgrading from Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, which uses an Oracle Database where the Management Repository is already created, that is, where the Grid Control SYSMAN schema is already created, then ignore this prerequisite. This prerequisite applies only when you install Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) using an existing, certified Oracle Database that has Database Control SYSMAN schema created, which you want to replace now with Grid Control SYSMAN schema.)

Ensure that your existing, certified Oracle Database does NOT have Enterprise Manager Grid Control SYSMAN schema and Metadata (MDS) schema.

Verify whether your database has Enterprise Manager Grid Control SYSMAN schema and MDS schema.

To do so, log in to the database as SYS user and run the following query:

SELECT COUNT(*) FROM ALL_USERS WHERE USERNAME IN ('SYSMAN','SYSMAN_MDS');

If the result of this query is 1, then the database has these schemas, so drop them.

Before dropping the schema, set the environment variable LD_LIBRARY_PATH to the ORACLE_HOME/lib directory of the OMS. Also set the ORACLE_HOME to the Oracle home of the OMS.

Drop the schema by running the following command from the Oracle home of the OMS.

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -mwHome <middleware_home> -mwOraHome <oms_oracle_home> -oracleHome <oms_oracle_home>

If you are dropping the schemas that belong to a 10g Release 2 (10.2.x.x) Management Repository, then run previous command without these arguments: -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

Note:

For Microsoft Windows, invoke RepManager.bat.

RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN).

RepManager 10.2.0.5 supports -action drop (drops only SYSMAN).

After dropping the schema, manually delete the database files mgmt.dbf and mgmt_ecm_depot1.dbf.

You can find these files by running the following command as SYS:

SELECT FILE_NAME FROM DBA_DATA_FILES WHERE UPPER (TABLESPACE_NAME) LIKE 'MGMT%';

Existing Oracle Database Initialization Parameters Requirements

Ensure that you have correctly set the database initialization parameters for the existing, certified Oracle Database so that the Management Repository can be created. For information about setting the parameters, see Setting Database Initialization Parameters.

Fine-Grained Access Control Requirements

Ensure that the fine-grained access control option is set to TRUE in the existing, certified Oracle Database so that the Management Repository can be created. To verify this, run the following command:

select value from v$option where parameter = 'Fine-grained access control';

UNDO Tablespace Size Requirements

Ensure that the UNDO tablespace has a minimum space of 200 MB. To verify this, run the following query:

SELECT SUM(DECODE(autoextensible,'YES',200*1024*1024+1,bytes)) total

FROM dba_data_files f, dba_tablespaces s

WHERE s.contents = 'UNDO'

AND s.tablespace_name = f.tablespace_name;

Note: The result of this query is in bytes.

If the minimum space is less than 200 MB, then set it to 200 MB by running the following command:

alter database datafile '<absolute_path>/<file_name>' resize 200M;

UNDO Tablespace and Temporary Tablespace Settings Requirements

Ensure that the UNDO tablespace and the TEMP tablespace are autoextensible in the existing, certified Oracle Database. To verify this, run the following command:

select count(*) from  dba_temp_files where tablespace_name='TEMP' and AUTOEXTENSIBLE  <> 'YES';

select count(*) from dba_data_files where tablespace_name='UNDOTBS' and AUTOEXTENSIBLE <> 'YES';

If the result of the query is 0, then the tablespace is autoextensible. If the result it not 0, then refer to Oracle Database Administrator's Guide available in the following location to make the tablespace autoextensible.

http://www.oracle.com/technology/documentation/database.html

Archive Logging Settings Requirements

(Recommended) Ensure that you turn on archive logging in the existing, certified Oracle Database for any environment where continuity of data is important. To verify this, run the following command:

select log_mode from v$database;

Tablespace-Related Hard Disk Space Requirements

Ensure that you allocate a minimum of 1 GB hard disk space for the following tablespaces:

Management Tablespace (mgmt.dbf)

Cofiguration Data Tablespace (mgmt_ecm_depot1.dbf)

JVM Diagnostics Data Tablespace (mgmt_ad4j.dbf)

Oracle also recommends that you keep the auto-extend feature enabled for the tablespace data files.

Note that the space requirement increases as the number of monitored targets increase, along with the input/output performance demands on the storage devices.

Installing User Requirements

Ensure that you meet the following requirements:

(For UNIX only) The installation must NOT be run by a root user.

(For Microsoft Windows only) User must be part of the ORA-DBA group and have administrator permissions.

(For Microsoft Windows only) User must belong to the DBA group, and have permissions to perform the following: Act as part of the operating system, Create a token object, Log on as a batch job, and Adjust memory quotas for a process.

To verify whether the agent user has these rights, from the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings. In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permission Requirements

Ensure that you are able to access and write in the following locations:

Oracle Middleware Home location

Oracle Management Service Instance Base location

Oracle Inventory Directory

For more information about these locations, see Understanding Installation Directories.

Ensure that you have write permission on the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

Proximity Requirements

Ensure that the host on which the OMS is being installed and the host on which the Management Repository is being configured are located in close proximity to each other. Ideally, the round trip network latency between the two should be less than 1 millisecond.

Firewall Requirements

If you have a firewall in your environment, then see Chapter 19, "Configuring Enterprise Manager for Firewalls".

Internet Connection Requirements

Oracle recommends that the host from where you are running the installer have a connection to the Internet so that the configuration information can be automatically collected and uploaded to My Oracle Support.

Setting Database Initialization Parameters

As one of the prerequisites, ensure that you set the initialization parameters as described in Table 3-3 and Table 3-4 for your existing, certified Oracle Database so that the Management Repository can be created. For information on how you can set these initialization parameters, see My Oracle Support note 1073647.1.

Important:

After you set the parameters, restart the database.

Table 3-3 Setting Fixed Initialization Parameters

Fixed Initialization Parameter
Value

cluster_database

(Only for Oracle RAC Database)

TRUE

compatible

10.2.0.1.0 or higher

max_commit_propogation_delay

(Only for Oracle RAC Database)

0

remote_login_passwordfile

SHARED or EXCLUSIVE

statistics_level

TYPICAL

timed_statistics

TRUE

undo_management

AUTO

workarea_size_policy

AUTO

Table 3-4 Setting Variable Initialization Parameters

Variable Initialization Parameter
Value

db_block_size

8192 or greater

instance_groups

As described in Oracle Database Reference Guide available at:

http://www.oracle.com/technology/documentation/database.html

job_queue_processes

(For Installation) 10 or greater

(For Upgrade) If you are upgrading Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, then ensure that you set the value to 0 before upgrading. And after upgrading, reset it to the original value that existed before upgrading the product.

log_buffer

10485760 or greater

memory_target

(Only for Oracle Database 11g Release 2 (11.2) and higher)

As described in Oracle Database Reference Guide available at:

http://www.oracle.com/technology/documentation/database.html

open_cursors

300 or greater

parallel_instance_groups

As described in Oracle Database Reference Guide available at:

http://www.oracle.com/technology/documentation/database.html

processes

500 or greater

session_cached_cursors

200 or greater

sga_target

As described in Oracle Database Reference Guide available at:

http://www.oracle.com/technology/documentation/database.html

Installation Procedure

To install a complete Enterprise Manager system in silent mode, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/em_using_existing_db.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Edit the response file and specify appropriate values for the parameters described in Table 3-5.

Invoke the installer:

If this is the first Oracle product you are installing on the host, then run the following command:

./runInstaller -silent -responseFile <location>/em_using_existing_db.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

The central inventory location you specify must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Otherwise, run the following command:

./runInstaller -silent -responseFile <location>/em_using_existing_db.rsp

Note:

For Microsoft Windows platforms, run setup.exe instead of runInstaller

If you are planning to have multiple OMSes, then Oracle strongly recommends you to configure a shared file system loader so that a common location is maintained to store all the metric data files uploaded by the Management Agents. If you configure the central directory now, then all subsequent additional OMS installations, which connect to the same Oracle Database, will automatically be mapped to this central directory.

To configure a shared file system loader, invoke the installer using the following command. Ensure that the location you specify is accessible and writable by all the OMSes.

./runInstaller -silent -responseFile <absolute_path_to_response_file>/em_using_existing_db.rsp SHARED_RECEIVE_DIRECTORY_LOCATION=<absolute_path_to_central_directory>

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command and specify a unique custom WebLogic Domain name:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?. You can also review the log files described in Appendix L, "Installation and Configuration Log Files".

Table 3-5 Response File Parameters for Installing Enterprise Manager System in Silent Mode

Parameter
Description

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Specify FALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

INSTALL_UPDATES_SELECTION

By default, this parameter is set to "skip" indicating that the software updates cannot be installed during installation.

However, if you want to install the software updates during installation, then set this parameter to "staged". Then, for the following parameter, specify the full path, which leads to the Updates directory, where the software updates are available:

STAGE_LOCATION

ORACLE_MIDDLEWARE_HOME_LOCATION

Specify the location that was specified while installing Oracle WebLogic Server. For example, u01/app/Oracle/Middleware. Ensure that the middleware location has write permission to create the Oracle home for OMS and the Oracle home for Management Agent

For example, if you accept the default location /u01/app/Oracle/Middleware, then the Oracle home for OMS is created as /u01/app/Oracle/Middleware/oms11g, and the Oracle home for Management Agent is created as /u01/app/Oracle/Middleware/agent11g.

For more information about this location, see What Is Oracle Middleware Home?.

Note: Ensure that the Middleware Home you specify here is used only for Enterprise Manager Grid Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware Home that is designated for Enterprise Manager Grid Control

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files. If you want to accept the default directory, then leave this field blank. However, if you want to have a custom directory, then specify the name of the custom directory.

Whether you accept the default directory or specify a custom one, by default, the directory is created under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the directory is is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

WLS_ADMIN_SERVER_USERNAME

Specify the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic.

WLS_ADMIN_SERVER_PASSWORD

Specify the password for the WebLogic user account.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

Confirm the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

Specify the node manager password.

NODE_MANAGER_CONFIRM_PASSWORD

Confirm the node manager password.

DATABASE_HOSTNAME

Specify the fully-qualified name of the host where the existing database resides. For example, db.host.com.

If you are connecting to an Oracle RAC Database, and if the nodes have virtual IP address, then specify the virtual IP of one of its nodes for this parameter. The connection to the database will be established with a connection string that is formed using only this virtual IP, and the installation will end successfully.

However, if you want to update the connection string with other nodes of the cluster, then perform a software-only installation as described in one of these chapters:

Chapter 4, "Installing Enterprise Manager Software Only in Graphical Mode and Configuring Later"

Chapter 5, "Installing Enterprise Manager Software Only in Silent Mode and Configuring Later"

If you follow the instructions in Chapter 5, "Installing Enterprise Manager Software Only in Silent Mode and Configuring Later" and create a response file as described in Table 3-5 (this table), then do the following:

In this response file, for this parameter, that is, DATABASE_HOSTNAME parameter, specify the virtual IP of one of its nodes.

Pass this response file while invoking the installation wizard (runInstaller or setup.exe) as described in Installation Procedure.

Then, while invoking the ConfigureGC.pl script as described in Configuration Procedure, pass an OMS-specific response file that has the CONNECT_STRING parameter updated with details of all the other nodes of the cluster.

For information about creating this OMS-specific response file, updating the CONNECT_STRING parameter, and passing the response file with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

LISTENER_PORT

Specify the listener port to connect to the existing database.

SERVICENAME_OR_SID

Specify the Service name or the System ID (SID) of the existing database.

SYS_PASSWORD

Specify the SYS user account's password.

MANAGEMENT_TABLESPACE_LOCATION

Specify the full path to the location where the data file for management tablespace (mgmt.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example:

If the database is on a file system, then the path must look like /u01/oracle/prod/oradata/mgmt.dbf

If the database is on Automatic Storage Management (ASM), then the path must look like +<disk_group1>/prod/oradata/mgmt.dbf, where disk_group1 is a diskgroup created on ASM and prod is the Service ID (SID).

If the database is on a raw device, then the path must look like </dev/raw1>/prod/oradata/mgmt.dbf, where /dev/raw1 is the raw device and prod is the SID.

Enterprise Manager Grid Control requires this data file to store information about the monitored targets, their metrics, and so on. Essentially, everything else other than configuration data, software library data, and audit data.

CONFIGURATION_DATA_TABLESPACE_LOCATION

Specify the full path to the location where the data file for configuration data tablespace (mgmt_ecm_depot1.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ecm_depot1.dbf

Enterprise Manager Grid Control requires this data file to store configuration information collected from the monitored targets.

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

Specify the full path to a location where the data file for JVM diagnostics data tablespace (mgmt_ad4j.dbf) can be stored. Ensure that the specified path leads up to the file name. Enterprise Manager Grid Control requires this data file to store JVM-related monitoring data.

For example, /home/john/oradata/mgmt_ad4j.dbf

LOCK_ORACLE_MANAGMENT_SERVICE

OMS always runs in a secure mode, and can further have a locked or an unlocked state. In an unlocked state, the Management Agents that are secure and the Management Agents that are not unsecure communicate with the OMS using HTTPS and HTTP protocols, respectively. However, in a locked state, only secure Management Agents communicate with the OMS using HTTPS protocol.

Specify TRUE if you want to lock the OMS running in a secure mode and further enhance the security of communication between the OMS and the Management Agents.

Specify FALSE if you do NOT want to further enhance the security of communication between the OMS and the Management Agent.

SYSMAN_PASSWORD

Specify a password for creating a SYSMAN user account. This password is used to create the SYSMAN user, which is the primary owner of the Management Repository schema.

SYSMAN_CONFIRM_PASSWORD

Confirm the password for creating a SYSMAN user account.

ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE

By default, you can use either HTTP or HTTPS protocol to access the Enterprise Manager Grid Control console.

Specify TRUE if you want to secure the access and allow users to access the console only using HTTPS protocol.

Specify FALSE if you do NOT want to secure the access and do NOT want to allow users to access the console only using HTTPS protocol.

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS and the Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

START_OMS

Specify TRUE if you want the OMS to start automatically after installation. Specify FALSE if you do NOT want it to start automatically.

After You Install

After you install Enterprise Manager Grid Control, do these:

Verify the installation:

Navigate to the Oracle home of the OMS (oms11g) and run the following command to see a message that confirms that OMS is up and running.

$<ORACLE_HOME>/bin/emctl status oms

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that the Management Agent is up and running.

$<ORACLE_HOME>/bin/emctl status agent

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that EMD upload completed successfully.

$<ORACLE_HOME>/bin/emctl upload

Note:

By default, you can access Enterprise Manager Grid Control only using the HTTPS protocol. If you want to use the HTTP protocol, then unlock it by running the following command from the Oracle home of the OMS:

emctl secure unlock -console

(Only for UNIX Operating Systems) Run the following scripts as a root user:

If you have not specified the inventory location while invoking the installer and if this is the first Oracle product you just installed on the host, then run the oraInstRoot.sh script from the Central Inventory:

$HOME/oraInventory/oraInstRoot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo $Home/oraInventory/oraInstRoot.sh

Run the allroot.sh script from the Oracle home of the OMS (oms11g):

<ORACLE_HOME>/allroot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/oms11g/allroot.sh

Configure your proxy server as described in Appendix H, "Setting Up Proxy Configuration for Oracle Management Service".

Configure the Oracle Database and Oracle Automatic Storage Management (Oracle ASM) target for monitoring as described in Appendix G, "Configuring Database and ASM Targets for Monitoring".

(Optional) If you had not configured a shared file system loader while installing a complete Enterprise Manager system, and if you want to configure a shared location for it now, then run the following command from the Oracle home of the OMS:

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir <Loader_Directory>

For example,

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir /share/recv

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

(Optional) If you want to connect to another Management Repository, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -store_repos_details (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor>) -repos_user <username> [-repos_pwd <pwd>] [-no_check_db]

Note:

On Linux, you need to double escape the connect descriptor using single and double quotes. However, on Microsoft Windows, you need not.

For example, on Linux:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc '"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb)))"' -repos_user sysman

For example, on Microsoft Windows:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb))) -repos_user sysman

(Optional) If you want to change the SYSMAN password, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -change_repos_pwd

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

4 Installing Enterprise Manager Software Only in Graphical Mode and Configuring Later

This chapter explains how you can install only the software binaries of Enterprise Manager Grid Control in graphical mode, and configure the installation later. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

Note:

Do NOT install the Enterprise Manager system on an OCFS file system. This file system is not supported.

Overview

Installing Enterprise Manager Software Only and Configuring Later is an approach that enables you to install only the software binaries of Enterprise Manager Grid Control at one point and configure it at a later point in time to work with an existing, certified Oracle Database. The existing, certified Oracle Database must be one of the databases listed in My Oracle Support note 412431.1. Therefore, this approach has two phases, mainly the installation phase and the configuration phase.

During the installation phase, this approach creates the following in the Oracle Middleware Home:

Oracle homes and installs the software binaries for Oracle Management Service (OMS) (Deployed to the existing, certified Oracle WebLogic Server), Oracle Management Agent (Management Agent), and Oracle Web Tier.

A common directory (oracle_common) for storing configuration files.

During the configuration phase, this approach does the following:

Creates an Oracle Management Service Instance Base (gc_inst or any other custom name you specify) in the parent directory of the Oracle Middleware Home.

Applies OMS-related and Management Agent-related one-off patches.

Configures Oracle Management Repository (Management Repository) in the existing, certified Oracle Database; OMS; Oracle Management Agent; Oracle Configuration Manager if you chose to configure it, and System Monitoring Plug-Ins if they were detected.

Before You Begin

Before you begin, keep these points in mind:

This installation type installs the components only on a single host, and only on that host from where the installer and the configuration script are invoked. Installation on multiple hosts and remote hosts is not supported.

Do NOT install the additional OMS on an OCFS file system. This file system is not supported

Install Enterprise Manager Grid Control on a dedicated Oracle WebLogic Server instance (in a separate middleware home). Do NOT install Enterprise Manager Grid Control on an Oracle WebLogic Server instance that already has an Oracle Fusion Middleware product installed. For example, if the middleware home already has Oracle SOA Suite 11.1.1.2.0 installed, then do not install Enterprise Manager Grid Control in the same middleware home. Enterprise Manager Grid Control cannot co-exist with any Oracle Fusion Middleware product in the same middleware home because the ORACLE_COMMON property is used by both the products.

For information about the default ports that are assigned and the possibility of using custom ports instead of default ports, see What Ports Are Used for Installation?.

While installing on hosts having multiple IP addresses, the host name is derived from the ORACLE_HOSTNAME variable that is passed while invoking the installer.

For example:

./runInstaller ORACLE_HOSTNAME=foo.us.oracle.com

Note:

Before passing this variable with the installer, ensure that you set the ORACLE_HOSTNAME environment variable.

Do NOT set the DISPLAY environment variable.

No environment variable specific to Enterprise Manager Grid Control needs to be set prior to installation. The ORACLE_HOME and ORACLE_SID variables should not be set; Oracle directories should not appear in the PATH.

Oracle offers code fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for code fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:

http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Grid Control installation, you must consider Enterprise Manager Grid Control's framework components as well as the targets monitored by Enterprise Manager Grid Control. Oracle recommends keeping your Grid Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license. For information about the certified combinations of Enterprise Manager Grid Control components and monitored targets, see My Oracle Support note.412431.1.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before installing the software binaries of Enterprise Manager in graphical mode, ensure that you meet the prerequisites described in Prerequisites.

Installation Procedure

To install only the software binaries of Enterprise Manager Grid Control in graphical mode, follow these steps:

Invoke the installer by running the following command:

<Software_Location>/runInstaller -noconfig

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

If you are planning to have multiple OMSes, then Oracle strongly recommends you to configure a shared file system loader so that a common location is maintained to store all the metric data files uploaded by the Management Agents. If you configure the central directory now, then all subsequent additional OMS installations, which connect to the same Oracle Database, will automatically be mapped to this central directory.

To configure a shared file system loader, invoke the installer using the following command. Ensure that the location you specify is accessible and writable by all the OMSes.

./runInstaller -noconfig SHARED_RECEIVE_DIRECTORY_LOCATION=<absolute_path_to_central_directory>

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command and specify a unique custom WebLogic Domain name:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

Enterprise Manager Grid Control Installation Wizard appears. The wizard guides you through the installation process. Select the first installation type, that is, Install a new Enterprise Manager system, and specify the information required on each of the screens. Click Next on each screen until you reach the final screen. On the final screen, click Install to install Enterprise Manager Grid Control.

For information about the values you need to specify on each screen, follow the instructions outlined for installing a complete Enterprise Manager system, in the Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Note:

If you are connecting to an existing Oracle RAC database, and if you have specified the virtual IP address of one of its nodes in the Connect to Oracle Database screen of the installation wizard, then when you click Next, the installation wizard prompts you with a Connection String dialog and requests you to update the connection string with information about the other nodes that are part of the cluster. Update the connection string and click OK. If you want to test the connection, click Test Connection.

After You Install

(For UNIX Only) After you install the software binaries of Enterprise Manager Grid Control, log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/allroot.sh

Configuration Procedure

To configure Enterprise Manager Grid Control, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure

After configuring Enterprise Manager Grid Control, follow these steps:

Verify the installation:

Navigate to the Oracle home of the OMS (oms11g) and run the following command to see a message that confirms that OMS is up and running.

$<ORACLE_HOME>/bin/emctl status oms

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that the Management Agent is up and running.

$<ORACLE_HOME>/bin/emctl status agent

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that EMD upload completed successfully.

$<ORACLE_HOME>/bin/emctl upload

Note:

By default, you can access Enterprise Manager Grid Control only using the HTTPS protocol. If you want to use the HTTP protocol, then unlock it by running the following command from the Oracle home of the OMS:

emctl secure unlock -console

Configure your proxy server as described in Appendix H, "Setting Up Proxy Configuration for Oracle Management Service".

Configure the Oracle Database and Oracle Automatic Storage Management (Oracle ASM) target for monitoring as described in Appendix G, "Configuring Database and ASM Targets for Monitoring".

(Optional) If you had not configured a shared file system loader while installing a complete Enterprise Manager system, and if you want to configure a shared location for it now, then run the following command from the Oracle home of the OMS:

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir <Loader_Directory>

For example,

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir /share/recv

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

(Optional) If you want to connect to another Management Repository, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -store_repos_details (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor>) -repos_user <username> [-repos_pwd <pwd>] [-no_check_db]

Note:

On Linux, you need to double escape the connect descriptor using single and double quotes. However, on Microsoft Windows, you need not.

For example, on Linux:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc '"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb)))"' -repos_user sysman

For example, on Microsoft Windows:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb))) -repos_user sysman

(Optional) If you want to change the SYSMAN password, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -change_repos_pwd

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

5 Installing Enterprise Manager Software Only in Silent Mode and Configuring Later

This chapter explains how you can install only the software binaries of Enterprise Manager Grid Control in silent mode, and configure the installation later. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Configuration Procedure

After You Configure

Note:

Do NOT install the Enterprise Manager system on an OCFS file system. This file system is not supported.

Overview

Installing Enterprise Manager Software Only and Configuring Later is an approach that enables you to install only the software binaries of Enterprise Manager Grid Control at one point and configure it at a later point in time to work with an existing, certified Oracle Database. Essentially, the approach has two phases, mainly the installation phase and the configuration phase.

The existing, certified Oracle Database must be one of the databases listed in My Oracle Support note 412431.1.

During the installation phase, this approach creates the following in the Oracle Middleware Home:

Oracle homes and installs the software binaries for Oracle Management Service (OMS) (Deployed to the existing, certified Oracle WebLogic Server), Oracle Management Agent (Management Agent), and Oracle Web Tier.

A common directory (oracle_common) for storing configuration files.

During the configuration phase, this approach does the following:

Creates an Oracle Management Service Instance Base (gc_inst or any other custom name you specify) in the parent directory of the Oracle Middleware Home.

Applies OMS-related and Management Agent-related one-off patches.

Configures Oracle Management Repository (Management Repository) in the existing, certified Oracle Database; OMS; Management Agent; Oracle Configuration Manager if you chose to configure it, and System Monitoring Plug-Ins if they were detected.

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before installing the software binaries of Enterprise Manager Grid Control in silent mode, ensure that you meet the prerequisites described in Prerequisites.

Installation Procedure

To install only the software binaries of Enterprise Manager Grid Control in silent mode, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/em_using_existing_db.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Edit the response file and specify appropriate values for the parameters described in Table 3-5.

Invoke the installer:

./runInstaller -noconfig -silent -responseFile <absolute_path_to_response_file>/em_using_existing_db.rsp -force

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

If you are planning to have multiple OMSes, then Oracle strongly recommends you to configure a shared file system loader so that a common location is maintained to store all the metric data files uploaded by the Management Agents. If you configure the central directory now, then all subsequent additional OMS installations, which connect to the same Oracle Database, will automatically be mapped to this central directory.

To configure a shared file system loader, invoke the installer using the following command. Ensure that the location you specify is accessible and wirtable by all the OMSes.

./runInstaller -noconfig -silent -responseFile <absolute_path_to_response_file>/em_using_existing_db.rsp -force SHARED_RECEIVE_DIRECTORY_LOCATION=<absolute_path_to_central_directory>

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command and specify a unique custom WebLogic Domain name:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

After You Install

(For UNIX Only) After you install the software binaries of Enterprise Manager Grid Control, log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS (for example, oms11g):

$<ORACLE_HOME>/allroot.sh

Configuration Procedure

To configure Enterprise Manager Grid Control, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure

After configuring Enterprise Manager Grid Control, follow the steps outlined in After You Configure.

Part II

Adding Additional Oracle Management Service

This part describes the different ways of adding an additional Oracle Management Service.

In particular, this part contains the following chapters:

Chapter 6, "Adding Additional Oracle Management Service"

Chapter 7, "Installing Oracle Management Service Software Only in Graphical Mode and Configuring Later"

Chapter 8, "Installing Oracle Management Service Software Only in Silent Mode and Configuring Later"

6 Adding Additional Oracle Management Service

This chapter describes how you can install an additional Oracle Management Service (OMS) in silent mode. In particular, this section covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

Note:

The additional OMS you are installing must be installed on the same operating system as the other OMSes. Also ensure that the operating system and the Oracle home of the OMS are patched to the same level as the other OMSes.

Do NOT install the additional OMS on an OCFS file system. This file system is not supported.

If your first OMS, which was installed as part of the complete Enterprise Manager system installation, has add-ons installed, then do NOT follow the instructions outlined in this chapter. Instead, follow the instructions outlined in Chapter 8, "Installing Oracle Management Service Software Only in Silent Mode and Configuring Later".

Overview

The installation type, Add an additional Management Service, enables you to install an additional OMS to your existing Enterprise Manager Grid Control environment. This option is appropriate when you already have Enterprise Manager Grid Control with a certified Oracle Database, and when you want to have another OMS for the following reasons:

When you want to balance the load on the existing OMS

When your existing OMS is running out of CPU or RAM resources

However, note that you can have multiple OMSes, and still connect to just one Oracle Management Repository (Management Repository).

Table 6-1 describes the installation process and the software components that are installed or configured for this installation type.

Table 6-1 Process for Adding an Additional Oracle Management Service in Silent Mode

Step 1

Installation of Oracle Management Service 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the OMS software binaries in the new home.

Oracle Middleware Home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for OMS is /u01/app/Oracle/Middleware/oms11g

Step 2

Installation of Oracle Management Agent 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the Oracle Management Agent (Management Agent) software binaries in the new home.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for Management Agent is /u01/app/Oracle/Middleware/agent11g

Step 3

Installation of Oracle Web Tier 11g Release 1

Creates an Oracle home in the Oracle Middleware Home location, and installs the Web tier software binaries in the new home.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the Oracle home for Web tier is /u01/app/Oracle/Middleware/Oracle_WT

Step 4

Installation of Oracle Common Directory

Creates a common directory in the Oracle Middleware Home location for storing configuration files.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the common directory is /u01/app/Oracle/Middleware/oracle_common.

Step 5

Configuration of Oracle Management Service Instance Base Location

Creates an instance home for Enterprise Manager Grid Control in the parent directory of the Oracle Middleware Home for storing all OMS-related configuration files. By default, the instance home is gc_inst. You can, however, edit this and specify a custom name.

If the Oracle Middleware Home is /u01/app/Oracle/Middleware and if you choose to retain the default instance home name, then the instance home location is /u01/app/Oracle/gc_inst

If the parent directory of the Oracle Middleware Home does not have write permission, then the Oracle Management Service Instance Base is created in the Oracle Middleware Home.

Step 6

Configuration of Core Components

Runs the Configuration Assistant tools to perform the following:

Applying OMS-Related One-Off Patches: (Optional) Applies one-off patches to the Oracle home of the OMS (oms11g).

Configuring OMS: Configures the OMS and the independent instance where Enterprise Manager Grid Control is deployed.

Add-on OMS Side Configuration: Configures the Virtualization Add-On detected in the Oracle home of the OMS (oms11g).

Configures OCM (If required; Only if you have chosen to configure it): Configures Oracle Configuration Manager (OCM) in the Oracle home of the OMS (oms11g) and Oracle home of the Web tier (Oracle_WT).

Applying Agent-Related One-Off Patches: (Optional) Applies one-off patches to the Oracle home of the Management Agent (agent11g).

Configuring Management Agent: Configures the Management Agent to enable monitoring of targets, collection of information, and so on.

Configures OCM (If required; Only if you have chosen to configure it): Configures Oracle Configuration Manager (OCM) in the Oracle home of the Management Agent (agent11g).

Configures System Monitoring Plug-Ins: Configures the System Monitoring Plug-Ins detected in the Oracle home of the Management Agent (agent11g).

Before You Begin

Before you begin, keep these points in mind:

Oracle Management Service 11g Release 1 is supported only with Enterprise Manager 11g Grid Control Release 1.

If you are installing an additional Oracle Management Service 11g Release 1 to an existing Enterprise Manager 11g Grid Control environment, then follow the installation steps outlined in this chapter.

If you are installing an additional Oracle Management Service 11g Release 1 to an existing Enterprise Manager 10g Grid Control Release 2 (10.2.X.X) environment, then first upgrade Enterprise Manager 10g Grid Control to Enterprise Manager 11g Grid Control, and then install the additional Oracle Management Service 11g.

You can install add-ons to this additional OMS only if the first OMS, which was installed as part of the complete Enterprise Manager system installation, has add-ons installed. And if your first OMS has add-ons installed, then do NOT follow the instructions outlined in this chapter. Instead, follow the instructions outlined in Chapter 8, "Installing Oracle Management Service Software Only in Silent Mode and Configuring Later".

This installation type only supports installation of OMS locally on the server where the installer is invoked, and does not support installing on multiple or remote hosts.

Do NOT install the additional OMS on an OCFS file system. This file system is not supported

You cannot install more than one OMS on a host.

By default, the upload ports and console ports as described in What Ports Are Used for Installation? are used.

However, if you want to use custom ports instead, then update the staticports.ini file as described in What Ports Are Used for Installation?, and pass the -staticPortsIniFile parameter while invoking setup.exe or runInstaller.

For example:

./runInstaller -silent -staticPortsIniFile <absolute_path_to_ini_file_location>/staticports.ini -responseFile <absolute_path_to_response_file> [-invPtrLoc <absolute_path_to_inventory_directory>]

By default, the software updates cannot be applied during installation because the INSTALL_UPDATES_SELECTION parameter in the response file is set to "skip". However, if you want to apply them during installation, then modify this parameter as described in Table 6-3.

Do not set the DISPLAY environment variable.

No environment variable specific to Enterprise Manager Grid Control needs to be set prior to installation. The ORACLE_HOME and ORACLE_SID variables should not be set; Oracle directories should not appear in the PATH.

Oracle offers code fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for code fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:

http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Grid Control installation, you must consider Enterprise Manager Grid Control's framework components as well as the targets monitored by Enterprise Manager Grid Control. Oracle recommends keeping your Grid Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license. For information about the certified combinations of Enterprise Manager Grid Control components and monitored targets, see My Oracle Support note.412431.1.

The presence or absence of EMKEY in the Management Repository does not matter, and the installation will proceed either way without any issues.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before adding an additional OMS in silent mode, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 6-2 Prerequisites for Adding an Additional Oracle Management Service in Silent Mode

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the OMS only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - OMS.

From the Release list, select 11.1.0.1.0, and click Search.

Ensure that you install the additional OMS on the same operating system as the other OMSes. Also ensure that the operating system and the Oracle home of the OMS arepatched to the same level as the other OMSes.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

Operating System Groups and Users Requirements

Ensure that you create the required operating system groups and users as described in Appendix C, "Creating Operating System Groups and Users Requirements".

Unique Host Name and Static IP Address Requirements

Ensure that you check the network configuration to verify that the host on which you are installing resolves to a unique host name and a static IP address that are visible to other hosts in the network.

Note: You must use only a static IP address. If you use a dynamic IP address, the installation will fail.

File Descriptor Requirements

Ensure that you set the file descriptors to a minimum of 4096.

To verify the current value set to the file descriptors, run the following command:

/bin/sh -c "ulimit -n"

If the current value is not 4096, then as a root user, update the /etc/security/limits.conf file with the following entries:

<UID> soft nofile 4096

<UID> hard nofile 4096

System Parameter Value Requirements for AIX

Ensure that the value set for the system parameter ncarg is 1024. To verify the value of ncarg, run the following command:

-lsattr -EH -l sys0 | grep ncargs

If the value is less than 1024, then increase it to 1024 by running the following command:

chdev -l sys0 -a ncargs=1024

Temporary Directory Space Requiremens

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

UMASK Value Requirements

Ensure that you set the default file mode creation mask (umask) to 022 in the shell startup file.

For example:

Bash Shell

$ . ./.bash_profile

Bourne or Korn Shell

$ . ./.profile

C Shell

% source ./.login

Shared File System Loader Location Requirements

If you have configured shared file system loader on the first OMS, ensure that the shared location is accessible and writable from the host where you are about to install an additional OMS.

If you have not configured the shared filesystem loader on the first OMS, and want to configure it now, then do the following:

Run the following command from the Oracle Home of the first OMS:

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir <Loader_Directory>

For example,

$<ORACLE_HOME>/bin/emctl config oms loader -shared yes -dir /share/recv

Note: If you already have additional OMSes, then run the same command on the hosts where those additional OMSes are running and specify the same shared location.

Ensure that the shared location is accessible and writable from the host where you are about to install an additional OMS. To verify this, run the following command:

On the first OMS, use a text editor to create a test file in the shared location, one for each additional OMS:

$ echo "test" > <oms name>.test

For example,

$ echo "test" > oms1.test

On the additional OMS host, verify that the above file is visible in the shared location and can be read and deleted:

$ cat <oms name>.test

$ rm <oms name>.test

For example,

$ cat oms1.test

$ rm oms1.test

JDK Requirements

Ensure that you have the following version of JDK installed on the host where you are planning to install Enterprise Manager Grid control.

Linux Platform (64 Bit): SUN JDK 1.6_18+

(On Linux 32-bit platforms, you need not install JDK because it is packaged by default with Oracle WebLogic Server)

Solaris Platform: SUN JDK 1.6_18+

HP-UX Platform: JDK 6.0.05+

AIX Platform: JDK 1.6.0 SR6

Microsoft Windows Platform (64 Bit): SUN JDK 1.6_18

Download the JDK version for your platform from the platform vendor's Web site. For example, download SUN JDK 1.6_18+ for Linux platforms from Oracle Web site. Similarly, download the JDK for other platforms from other vendors' trusted Web sites.

You can also refer to My Oracle Support note 1063587.1 for an example on installing JDK 1.6_18+ on Linux x86_64 platform.

If you already have a JDK installed, then verify its version by navigating to the <jdk>/bin directory and running the following command. The output of this query should give you the complete version number.

java -fullversion

Note: JROCKIT is not supported.

Oracle WebLogic Server Requirements

Ensure that Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1) is already installed on the host where you plan to install Enterprise Manager Grid Control.

Ensure that the installation was a typical installation, and even if it was a custom installation, ensure that components chosen for custom installation were the same as the ones associated with a typical installation.

Ensure that the installation was under the Middleware Home directory. For example, /scratch/aime/Oracle/Middleware1/wlserver_10.3.

Ensure that no other Oracle Fusion Middleware products or components are installed in the Middleware Home directory where Oracle WebLogic Server 10.3.2 is installed.

Enterprise Manager Grid Control will create a new domain in this Oracle WebLogic Server, and not use any of the existing domains.

For information on installing Oracle WebLogic Server, see My Oracle Support note 1063762.1. For more information, downloads, demos, access the following URL:

http://www.oracle.com/technology/products/weblogic/index.html

Oracle WebLogic Server Patch Requirements

Ensure that you apply patch ID WDJ7 on Oracle WebLogic Server using the Oracle Smart Update utility. This patch fixes bugs 8990616, 9100465, and 9221722.

For information on applying this patch, see My Oracle Support note 1072763.1.

For information on Oracle Smart Update utility, see Oracle Smart Update Installing Patches and Maintenance Packs documentation available at:

http://www.oracle.com/technology/products/weblogic/index.html

Existing Database Version Requirements

Ensure that the existing, certified Oracle Database is one of the databases listed in My Oracle Support note 412431.1. The database can reside either on the host where you are installing the product or on a remote host.

Existing Database Configuration Requirements

Ensure that Oracle Management Repository 11g Release 1 is already configured in your existing, certified Oracle Database.

Installing User Requirements

Ensure that you meet the following requirements:

(For UNIX only) The installation must NOT be run by a root user.

(For Microsoft Windows only) User must be part of the ORA-DBA group and have administrator permissions.

(For Microsoft Windows only) User must belong to the DBA group, and have permissions to perform the following: Act as part of the operating system, Create a token object, Log on as a batch job, and Adjust memory quotas for a process.

To verify whether the agent user has these rights, from the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings. In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permission Requirements

Ensure that you are able to access and write in the following locations:

Oracle Middleware Home location

Oracle Management Service Instance Base location

Oracle Inventory Directory

For more information about these locations, see Understanding Installation Directories.

Ensure that you have write permission on the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

Proximity Requirements

Ensure that the host on which the OMS is being installed and the host on which the Management Repository is being configured are located in close proximity to each other. Ideally, the round trip network latency between the two should be less than 1 millisecond.

Firewall Requirements

If you have a firewall in your environment, then see Chapter 19, "Configuring Enterprise Manager for Firewalls".

Internet Connection Requirements

Oracle recommends that the host from where you are running the installation wizard have a connection to the Internet so that the configuration information can be automatically collected and uploaded to My Oracle Support.

Installation Procedure

To add an additional OMS in silent mode, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/additional_mgmt_service.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Edit the response file and specify appropriate values for the parameters described in Table 6-3.

Invoke the installer:

If this is the first Oracle product you are installing on the host, then run the following command:

./runInstaller -silent -responseFile <absolute_path_to_response_file>/additional_mgmt_service.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

The central inventory location you specify must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Otherwise, run the following command:

./runInstaller -silent -responseFile <absolute_path_to_response_file>/additional_mgmt_service.rsp

Note:

For Microsoft Windows platforms, run setup.exe instead of runInstaller

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?. You can also review the log files described in Appendix L, "Installation and Configuration Log Files".

Table 6-3 Response File Parameters for Adding an Additional Oracle Management Service

Parameter
Description

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

SpecifyFALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

INSTALL_UPDATES_SELECTION

By default, this parameter is set to "skip" indicating that software updates cannot be installed during installation.

However, if you want to install the software updates during installation, then set this parameter to "staged". Then, for the following parameter, specify the full path, which leads to the Updates directory, where the software updates are available:

STAGE_LOCATION

ORACLE_MIDDLEWARE_HOME_LOCATION

Specify the location that was specified while installing Oracle WebLogic Server. For example, u01/app/Oracle/Middleware. Ensure that the middleware location has write permission to create the Oracle home for OMS and the Oracle home for Management Agent

For example, if you accept the default location /u01/app/Oracle/Middleware, then the Oracle home for OMS is created as /u01/app/Oracle/Middleware/oms11g, and the Oracle home for Management Agent is created as /u01/app/Oracle/Middleware/agent11g.

For more information about this location, see What Is Oracle Middleware Home?.

Note: Ensure that the Middleware Home you specify here is used only for Enterprise Manager Grid Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware Home that is designated for Enterprise Manager Grid Control.

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files. If you want to accept the default directory, then leave this field blank. However, if you want to have a custom directory, then specify the name of the custom directory.

Whether you accept the default directory or specify a custom one, by default, the directory is created under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the directory is is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

ADMIN_SERVER_HOSTNAME

Specify the name of the host where the Admin Server is running. Admin Server is the server that was created when you installed the first Oracle Management Service 11g Release 1.

ADMIN_SERVER_PORT

Specify the port on which the Admin Server is running.

WLS_ADMIN_SERVER_USERNAME

Specify the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic.

WLS_ADMIN_SERVER_PASSWORD

Specify the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

Specify the node manager password.

DATABASE_HOSTNAME

Specify the fully-qualified name of the host where the existing database resides. For example, db.host.com.

LISTENER_PORT

Specify the listener port to connect to the existing database.

SERVICENAME_OR_SID

Specify the System ID (SID) of the existing database.

SYSMAN_PASSWORD

Specify the SYSMAN user account's password.

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS and the Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

LOCK_ORACLE_MANAGMENT_SERVICE

OMS always runs in a secure mode, and can further have a locked or an unlocked state. In an unlocked state, the Management Agents that are secure and the Management Agents that are not secure communicate with the OMS using HTTPS and HTTP protocols, respectively. However, in a locked state, only secure Management Agents communicate with OMS using HTTPS protocol.

Specify TRUE if you want to lock the OMS running in a secure mode and further enhance the security of communication between the OMS and the Management Agents.

Specify FALSE if you do NOT want to further enhance the security of communication between the OMS and the Management Agent.

ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE

By default, you can use either HTTP or HTTPS protocol to access the Enterprise Manager Grid Control console.

Specify TRUE if you want to secure the access and allow users to access the console only using HTTPS protocol.

Specify FALSE if you do NOT want to secure the access and allow users to access the console only using HTTPS protocol.

START_OMS

Specify TRUE if you want the OMS to start automatically after installation. Specify FALSE if you do NOT want it to start automatically.

After You Install

After you add an additional OMS, do these:

Verify the installation:

Navigate to the Oracle home of the OMS (oms11g) and run the following command to see a message that confirms that OMS is up and running.

$<ORACLE_HOME>/bin/emctl status oms

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that the Management Agent is up and running.

$<ORACLE_HOME>/bin/emctl status agent

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that EMD upload completed successfully.

$<ORACLE_HOME>/bin/emctl upload

Note:

By default, you can access Enterprise Manager Grid Control only using the HTTPS protocol. If you want to use the HTTP protocol, then unlock it by running the following command from the Oracle home of the OMS:

emctl secure unlock -console

(Only for UNIX Operating Systems) Run the following scripts as a root user:

If you have not specified the inventory location while invoking the installer and if this is the first Oracle product you just installed on the host, then run the oraInstRoot.sh script from the Central Inventory:

$HOME/oraInventory/oraInstRoot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo $Home/oraInventory/oraInstRoot.sh

Run the allroot.sh script from the Oracle home of the OMS (oms11g):

<ORACLE_HOME>/allroot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/oms11g/allroot.sh

Refresh the Oracle WebLogic Server Domain, which hosts the Enterprise Manager application, so that the configuration changes made to the domain as a result of adding an additional OMS are reflected in the Grid Control console. To refresh the Oracle WebLogic Server Domain, follow these steps:

In Enterprise Manager Grid Control, navigate to the Home page for the Oracle WebLogic Server Domain that hosts the Enterprise Manager application. In most cases, the following is the direct URL to the Home page. If your domain name is not GCDomain, then replace that string with your domain name:

[protocol]://[host]:[port]/em/faces/as/as/domainHome?target=/secFarm_GCDomain/GCDomain&type=weblogic_domain

From the WebLogic Domain menu, click Refresh WebLogic Domain.

On the Refresh WebLogic Domain page, click Continue.

Note:

This submits a WebLogic Domain Refresh job, which captures the domain configuration changes and reflects them in the Enterprise Manager Grid Control console. The job repeats itself once a day, and therefore, if you add any more additional OMSes or remove OMSes from your Enterprise Manager system in the future, this job automatically captures the configuration changes to the Oracle WebLogic Server Domain. You do NOT have to repeat this procedure every time you add an additional OMS.

Configure your proxy server as described in Appendix H, "Setting Up Proxy Configuration for Oracle Management Service".

Configure the Oracle Database and Oracle Automatic Storage Management (Oracle ASM) target for monitoring as described in Appendix G, "Configuring Database and ASM Targets for Monitoring".

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

To view details related to the Management Repository, run the following command, as emoms.properties file is no longer supported.

emctl config oms -list_repos_details

(Optional) If you want to connect to another Management Repository, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -store_repos_details (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor>) -repos_user <username> [-repos_pwd <pwd>] [-no_check_db]

Note:

On Linux, you need to double escape the connect descriptor using single and double quotes. However, on Microsoft Windows, you need not.

For example, on Linux:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc '"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb)))"' -repos_user sysman

For example, on Microsoft Windows:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb))) -repos_user sysman

(Optional) If you want to change the SYSMAN password, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -change_repos_pwd

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

7 Installing Oracle Management Service Software Only in Graphical Mode and Configuring Later

This chapter explains how you can install only the software binaries of Oracle Management Service (OMS) in graphical mode, and configure the installation later. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Install Additional OMS

After You Install OMS

Configure OMS

After You Configure OMS

Note:

The additional OMS you are installing must be installed on the same operating system as the other OMSes. Also ensure that the operating system and the Oracle home of the OMS are patched to the same level as the other OMSes.

Also, do not install the additional OMS on an OCFS file system. This file system is not supported.

Overview

Installing Oracle Management Service Software Only and Configuring Later is an approach that enables you to install only the software binaries of the OMS at one point and configure it at a later point in time to work with an existing, certified Oracle Database that is already configured with Oracle Management Repository (Management Repository). Therefore, this approach has two phases, mainly the installation phase and the configuration phase.

During the installation phase, this approach creates the following in the Oracle Middleware Home:

Oracle homes and installs the software binaries for the OMS (Deployed to the existing, certified Oracle WebLogic Server), Oracle Management Agent (Management Agent), and Oracle Web Tier.

A common directory (oracle_common) for storing configuration files.

During the configuration phase, this approach does the following:

Creates an OMS Instance Base (gc_inst or any other custom name you specify) in the parent directory of the Oracle Middleware Home.

Applies OMS-related and Management Agent-related one-off patches.

Configures the OMS, the Management Agent, the Oracle Configuration Manager (OCM) if you chose to configure it, and the System Monitoring Plug-Ins if they were detected.

This approach is best suited for the following reasons:

If you want to install only the software binaries now and configure it later.

If your first OMS, which was installed as part of the complete Enterprise Manager system installation, has add-ons.

Before You Begin

Before you begin, keep these points in mind:

Oracle Management Service 11g Release 1 is supported only with Enterprise Manager 11g Grid Control Release 1.

If you are installing an additional Oracle Management Service 11g Release 1 to an existing Enterprise Manager 11g Grid Control environment, then follow the installation steps outlined in this chapter.

If you are installing an additional Oracle Management Service 11g Release 1 to an existing Enterprise Manager 10g Grid Control Release 2 (10.2.X.X) environment, then first upgrade Enterprise Manager 10g Grid Control to Enterprise Manager 11g Grid Control, and then install the additional Oracle Management Service 11g.

This installation type installs the components only on a single host, and only on that host from where the installer and the configuration script are invoked. Installation on multiple hosts and remote hosts is not supported.

You cannot install more than one OMS on a host.

Do NOT install the additional OMS on an OCFS file system. This file system is not supported

For information about the default ports that are assigned and the possibility of using custom ports instead of default ports, see What Ports Are Used for Installation?.

While installing on hosts having multiple IP addresses, the host name is derived from the ORACLE_HOSTNAME variable that is passed while invoking the installer.

For example:

./runInstaller ORACLE_HOSTNAME=foo.us.oracle.com

Note:

Before passing this variable with the installer, ensure that you set the ORACLE_HOSTNAME environment variable.

Do not set the DISPLAY environment variable.

No environment variable specific to Enterprise Manager Grid Control needs to be set prior to installation. The ORACLE_HOME and ORACLE_SID variables should not be set; Oracle directories should not appear in the PATH.

Oracle offers code fixes for a product based on the Oracle Lifetime Support Policy. When the license period expires for a particular product, the support for code fixes offered by Oracle also ends. For more information, see the Oracle Lifetime Support Policy available at:

http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf

When determining supportability and certification combinations for an Enterprise Manager Grid Control installation, you must consider Enterprise Manager Grid Control's framework components as well as the targets monitored by Enterprise Manager Grid Control. Oracle recommends keeping your Grid Control components and targets updated to the latest certified versions in order to receive code fixes without having to purchase an Extended Support license. For information about the certified combinations of Enterprise Manager Grid Control components and monitored targets, see My Oracle Support note.412431.1.

The presence or absence of EMKEY in Oracle Management Repository (Management Repository) does not matter, and the installation will proceed either way without any issues.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before installing the software binaries of OMS in graphical mode, ensure that you meet the prerequisites described in Prerequisites.

Install Additional OMS

To install only the software binaries of OMS in graphical mode, follow these steps:

Invoke the installer by running the following command:

<Software_Location>/runInstaller -noconfig

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

Enterprise Manager Grid Control Installation Wizard appears. The wizard guides you through the installation process. Select the second installation type, that is, Add an additional Management Service, and specify the information required on each of the screens. Click Next on each screen until you reach the final screen. On the final screen, click Install to install the OMS.

For information about the values you need to specify on each screen, follow the instructions outlined for installing an additional OMS, in the Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Install Add-Ons

Note:

Follow the steps outlined in this section only if you want to install add-ons to your additional OMS. Otherwise, skip this section and move to the next section.

After you install the software binaries of OMS, follow these steps to install the 11g Release 1 add-ons:

Install the add-ons by running the following command from the Oracle home of the OMS:

$<ORACLE_HOME>/oui/bin/runInstaller -noconfig

When the installer prompts you to specify the location of the products.xml file, specify the full path to the /Disk1/stage/ directory where the products.xml file is available. Ensure that the path leads up to the products.xml file. The /Disk1/stage/ directory is available in the add-on software you downloaded.

For example, if you downloaded an add-on to /scratch/<AddOn_Name>/, then specify the path as /scratch/<AddOn_Name>/Disk1/stage/products.xml.

Note:

When you proceed with the installation, you will be prompted to select the add-on OMS component, the Oracle home of the OMS in which you want to install the add-ons. You will also be prompted to specify the Management Repository-related details.

After You Install OMS

(For UNIX Only) Log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS:

$<ORACLE_HOME>/allroot.sh

Configure OMS

To configure the OMS, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure OMS

After you configure the additional OMS, follow these steps:

Verify the installation:

Navigate to the Oracle home of the OMS (oms11g) and run the following command to see a message that confirms that OMS is up and running.

$<ORACLE_HOME>/bin/emctl status oms

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that the Management Agent is up and running.

$<ORACLE_HOME>/bin/emctl status agent

Navigate to the Oracle home of the Management Agent (agent11g) and run the following command to see a message that confirms that EMD upload completed successfully.

$<ORACLE_HOME>/bin/emctl upload

Note:

By default, you can access Enterprise Manager Grid Control only using the HTTPS protocol. If you want to use the HTTP protocol, then unlock it by running the following command from the Oracle home of the OMS:

emctl secure unlock -console

Refresh the Oracle WebLogic Server Domain, which hosts the Enterprise Manager application, so that the configuration changes made to the domain as a result of adding an additional OMS are reflected in the Grid Control console. To refresh the Oracle WebLogic Server Domain, follow these steps:

In Enterprise Manager Grid Control, navigate to the Home page for the Oracle WebLogic Server Domain that hosts the Enterprise Manager application. In most cases, the following is the direct URL to the Home page. If your domain name is not GCDomain, then replace that string with your domain name:

[protocol]://[host]:[port]/em/faces/as/as/domainHome?target=/secFarm_GCDomain/GCDomain&type=weblogic_domain

From the WebLogic Domain menu, click Refresh WebLogic Domain.

On the Refresh WebLogic Domain page, click Continue.

Note:

This submits a WebLogic Domain Refresh job, which captures the domain configuration changes and reflects them in the Enterprise Manager Grid Control console. The job repeats itself once a day, and therefore, if you add any more additional OMSes or remove OMSes from your Enterprise Manager system in the future, this job automatically captures the configuration changes to the Oracle WebLogic Server Domain. You do NOT have to repeat this procedure every time you add an additional OMS.

Configure your proxy server as described in Appendix H, "Setting Up Proxy Configuration for Oracle Management Service".

Configure the Oracle Database and Oracle Automatic Storage Management (Oracle ASM) target for monitoring as described in Appendix G, "Configuring Database and ASM Targets for Monitoring".

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

(Optional) If you want to connect to another Management Repository, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -store_repos_details (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor>) -repos_user <username> [-repos_pwd <pwd>] [-no_check_db]

Note:

On Linux, you need to double escape the connect descriptor using single and double quotes. However, on Microsoft Windows, you need not.

For example, on Linux:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc '"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb)))"' -repos_user sysman

For example, on Microsoft Windows:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb))) -repos_user sysman

(Optional) If you want to change the SYSMAN password, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -change_repos_pwd

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

8 Installing Oracle Management Service Software Only in Silent Mode and Configuring Later

This chapter explains how you can install only the software binaries of Oracle Management Service (OMS) in silent mode, and configure the installation later. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Install Additional OMS

Install Add-Ons

After You Install OMS

Configure OMS

After You Configure OMS

Note:

The additional OMS you are installing must be installed on the same operating system as the other OMSes. Also ensure that the operating system and the Oracle home of the OMS are patched to the same level as the other OMSes.

Also, do not install the additional OMS on an OCFS file system. This file system is not supported.

Overview

Installing Oracle Management Service Software Only and Configuring Later is an approach that enables you to install only the software binaries of Oracle Management Service at one point and configure it at a later point in time to work with an existing, certified Oracle Database that is already configured with Oracle Management Repository (Management Repository). Essentially, the approach has two phases, mainly the installation phase and the configuration phase.

During the installation phase, this approach creates the following in the Oracle Middleware Home:

Oracle homes and installs the software binaries for the OMS (Deployed to the existing, certified Oracle WebLogic Server), Oracle Management Agent (Management Agent), and Oracle Web Tier.

A common directory (oracle_common) for storing configuration files.

During the configuration phase, this approach does the following:

Creates an OMS Instance Base (gc_inst or any other custom name you specify) in the parent directory of the Oracle Middleware Home.

Applies OMS-related and Management Agent-related one-off patches.

Configures the OMS, the Management Agent, the Oracle Configuration Manager (OCM) if you chose to configure it, and the System Monitoring Plug-Ins if they were detected.

This approach is best suited for the following reasons:

If you want to install only the software binaries now and configure it later.

If your first OMS, which was installed as part of the complete Enterprise Manager system installation, has add-ons.

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before installing the software binaries of OMS in silent mode, ensure that you meet the prerequisites described in Prerequisites.

Install Additional OMS

To install only the software binaries of OMS in silent mode, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/additional_mgmt_service.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Edit the response file and specify appropriate values for the parameters described in Table 6-3.

Invoke the installer:

./runInstaller -noconfig -silent -responseFile <absolute_path_to_response_file>/additional_mgmt_service.rsp

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

Install Add-Ons

Note:

Follow the steps outlined in this section only if you want to install add-ons to your additional OMS. Otherwise, skip this section and move to the next section.

After you install the software binaries of OMS, follow these steps to install the 11g Release 1 add-ons:

Create a response file titled addon_oms.rsp with the following details:

RESPONSEFILE_VERSION=2.2.1.0.0
FROM_LOCATION=<absolute_path_to_products.xml>
DEINSTALL_LIST={"<add-on oms component name>","<add-on oms component version>"}
TOPLEVEL_COMPONENT={"<add-on oms component name>","<add-on oms component version>"}
ORACLE_HOME=<OMS OracleHome>
ORACLE_HOME_NAME=<name of the Oracle Home>
b_upgrade=false
EM_REPOS_DBA_PWD="<Repository SYS password>"
DATABASE_HOSTNAME=<Repository Host name>
LISTENER_PORT=<Repository Port>
SERVICENAME_OR_SID=<Repository SID>
b_silentInstall=true
ACCEPT_LICENSE_AGREEMENT=true

Run the following command from the Oracle home of the OMS and pass the response file to install the add-ons:

$<ORACLE_HOME>/oui/bin/runInstaller -noconfig -silent -responseFile <absolute_path_to_location>

After You Install OMS

(For UNIX Only) Log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS (for example, oms11g):

$<ORACLE_HOME>/allroot.sh

Configure OMS

To configure Enterprise Manager Grid Control, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure OMS

After you configure the additional OMS, follow these steps outlined in After You Configure OMS.

Part III

Installing Oracle Management Agent

This part describes the different ways of installing Oracle Management Agent.

In particular, this part contains the following chapters:

Chapter 9, "Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard"

Chapter 10, "Installing Oracle Management Agent Using Shared Oracle Home"

Chapter 11, "Cloning Oracle Management Agent Using Agent Cloning Wizard"

Chapter 12, "Installing Oracle Management Agent Using Response File"

Chapter 13, "Installing Oracle Management Agent Using agentDownload Script"

Chapter 14, "Installing Oracle Management Agent on a Cluster Using Response File or agentDownload Script"

Chapter 15, "Installing Oracle Management Agent Using Shared Oracle Home Using nfsagentinstall Script"

Chapter 16, "Cloning Oracle Management Agent Using ZIP File"

Chapter 17, "Cloning Oracle Management Agent on Clusters Using ZIP File"

9 Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard

This chapter describes how you can install Oracle Management Agent (Management Agent) on the nodes of an Oracle Clusterware or Oracle Grid Infrastructure using the Agent Deployment Wizard. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Note:

This installation method is not supported on Solaris Express 5.11 x86-64 and Solaris SPARC Express 5.11 (64 bit). To install Oracle Management Agents on these operating systems, follow the silent method mentioned in Part III, "Installing Oracle Management Agent".

Note:

If you have a cluster-based environment, then Oracle strongly recommends you to install the Management Agent using the Agent Deployment Wizard as described in this chapter.

Overview

The Management Agents installed on the nodes of a cluster are different from the Management Agents installed on standalone hosts. While the Management Agent installed on a standalone host is called a standalone Management Agent, the Management Agent installed on a node of the cluster is called a cluster-based Management Agent.

You can install a cluster-based Management Agent on a cluster using the Agent Deployment Wizard that is built into Enterprise Manager Grid Control. The Agent Deployment Wizard offers GUI-rich, interactive screens, and can be accessed from the Enterprise Manager Grid Control console.

Using the Agent Deployment Wizard, you can do the following:

Use Case
Description
Your Requirement
Your Action

Installing a Management Agent on Each Node of a Cluster for the First Time
You might have a cluster containing many nodes, and none of the nodes might have a Management Agent installed.

For example, cr1 with three nodes n1, n2, and n3.

You want to install a Management Agent on each of the nodes.
Specify the names of all the nodes.

Installing a Management Agent Only on Some Nodes of a Cluster
You might have a cluster containing many nodes, and only a few of the nodes might have a Management Agent installed.

For example, cr1 with three nodes n1, n2, and n3. The node n1 already has a Management Agent installed, but nodes n2 and n3 do not have a Management Agent.

You want to install a Management Agent on some of the nodes, not all, though.
Specify the names of only those nodes on which you want to install a Management Agent.

Installing a Management Agent on an Additional Node that Extends the Cluster
You might have a cluster containing some nodes, and you might extend the cluster by adding another node to it.

For example, cr1 with three nodes n1, n2, and n3 having a Management Agent each, and an additional node n4 that does not have a Management Agent.

You want to install a Management Agent on the additional node that extends the cluster
Specify the names of all the nodes, including the new one, with the name of the existing cluster.

Installing a Management Agent on Two Clusters of the Same Name, but with Different Nodes
You might have two clusters with the same name, but each having different nodes.

For example, cr1 with two nodes n1 and n2, and cr2 with two nodes n3 and n4.

You want to install a Management Agent on the first cluster and then on the next cluster.
Install a Management Agent on the first cluster specifying a unique name for it. Then, install a Management Agent on the second cluster specifying another unique name for it.

Before You Begin

Before you begin, keep in mind the following points:

You CANNOT use addnode.sh script to extend Management Agents to a cluster.

If you specify only one node and the name of the existing cluster (for example, cr1), then the Agent Deployment Wizard still creates a new cluster with the same name.

If you have specify only one node and do not specify the name of a cluster, then the Agent Deployment Wizard computes a default cluster name and creates a new cluster.

You can specify an installation base directory that is either shared or not shared across the other nodes of the cluster. To understand what an installation base directory is, see What Is Installation Base Directory?.

If you specify an installation base directory that is not shared across the other nodes of the cluster, then the Management Agent is installed on each of the nodes.

If you specify an installation base directory that is shared across the other nodes of the cluster, then the Management Agent is installed only on one node where the base directory is shared, but it is configured on all other nodes.

The installation is done only on those cluster nodes that you specify, regardless of the number of hosts that make up that cluster.

For example, if you choose to perform a cluster installation on a cluster having 10 nodes, but specified only 5 nodes, then the Agent Deployment Wizard installs the Management Agent only on the 5 nodes of the cluster that you have specified.

If you are extending an existing cluster, ensure that the cluster name you specify is the same as the existing cluster. You must also specify all the nodes of the existing cluster along with the new node on which you are installing the cluster Management Agent.

If you want to view the status of an installation session that was previously run, then click Agent Installation Status on the Deployments pages. However, do not attempt to view the installation status until the installation is complete. If you do, you will see an error.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Agent Deployment Wizard expects an SSH connectivity between Oracle Management Service (OMS) and the remote hosts where you want to install the Management Agents.

If there is no SSH connectivity between the OMS and the remote hosts, then the Agent Deployment Wizard automatically sets up the connectivity by generating keys in the ~/.ssh directory . Once the deployment is complete, the Agent Deployment Wizard automatically drops the connectivity and removes keys.

If there is already an SSH connectivity between the OMS and the remote hosts, then the existing connectivity itself is used, and no keys are generated in the ~/.ssh directory. Once the deployment is complete, the Agent Deployment Wizard does not drop the connectivity because the connectivity already existed and it was not created by the Agent Deployment Wizard.

Prerequisites

Before installing the Management Agent on a cluster, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 9-1 Prerequisites for Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Installation Base Directory Requirements

Ensure that the installation base directory you specify is empty and has write permission.

Software Availability Requirements

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

Accessibility Requirements

If there are multiple OMSes in your environment and if you have staged the Management Agent software in a non-default location (not on the OMS host), then ensure that the non-default location is accessible by all the OMSes.

Path Validation Requirements

Validate the path to all command locations. For more information, see Appendix E, "Validating Command Locations".

Host List Requirements

Ensure that you identify the hosts where you want to install the Management Agent. Otherwise, maintain a host list file that contains a list of hosts as described in What Is a Host List File?.

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Preinstallation/Postinstallation Scripts Requirements

Ensure that the preinstallation and postinstallation scripts that you want to run along with the installation are available on all the destination hosts.

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using one of the following options in the Additional Parameters section of the Agent Deployment Wizard:

On the Installation Details page, if you select Default, from Management Server location, which means the software is on the OMS host, then use the -i <location> option.

On the Installation Details page, if you select Another Location, which means the software is in any other location other than the OMS host, then use the -invPtrLoc option.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). The Agent Deployment Wizard uses SUDO to run the root.sh script. You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <host>=(ALL) NOPASSWD: <Agentpath>/root.sh, /bin/sh

If you do not have SUDO privileges and if you do NOT want to run root.sh and /bin/sh yourself at the time of installation, then request your Administrator who has SUDO privileges to manually run the scripts after the installation ends. To understand how and where the scripts need to be run from, see After You Install.

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that is present in the OMS Instance Base location:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

PATH Environment Variable Requirements

On the host where OMS is running and on the host where you want to install the Management Agent, ensure the following:

(For Microsoft Windows) Ensure that the cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd) on both the hosts.

(For UNIX) Ensure that the SCP binaries (for example, /usr/local/bin/scp) are in the PATH environment variable.

SSH Setup Requirements (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that you set up the SSH connectivity between the host running OMS and the host where the Management Agent needs to be installed, as described in Appendix D, "Setting Up SSH Connectivity".

Agent User Account Permissions and Rights (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that the agent user account has permissions and rights to perform the following:

Act as part of the operating system.

Increase quotas.

Replace process level token.

Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

Launch the Local Security Settings.

From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings.

In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Installation Procedure

To install a Management Agent, follow these steps:

In Grid Control, click Deployments.

On the Deployments page, from the Agent Installation section, click Install Agent.

On the following page, click Fresh Install.

On the Installation Details page, in the Source Software section, do the following:

Select Default, from Management Server location if the Management Agent software is available in the default directory that exists within the OMS.

For example, <OMS_HOME>/sysman/agent_download/<version>/<platform>

Select Another Location if the Management Agent software is available in a non-default or custom location. Specify the full path to that location, and ensure that the path you specify leads up to the product.xml file. Also ensure that this location (shared or non-shared) is accessible from all the remote hosts and you have read permission on it.

For example, /shared/products/shiphomes/linux/agent/stage/products.xml.

In the Version section, select the version of the Management Agent that you want to install. The values available in this list depend on the software staged on the OMS host.

In the Hosts section, do the following:

From the Platform list, select the platform (operating system) on which you want to install the Management Agent.

For Provide Host List, specify the host names or IP addresses of the hosts on which you want to install the Management Agent.You can use a comma (,) or a white space as a separator when specifying multiple hosts.

Alternatively, if you already have a list maintained in a file, then click Get Host Names From File and select that file.

For information about host list file, see What Is a Host List File?.

Select Allow local hostname to override provided hostname if the host names specified in Provide Host List are virtual host names and not physical host names.

For example, if a host name is mypc.server.com but the virtual name given to it is host1, then you can specify host1 in the Provide Host List text box, but select this check box to indicate that the specified host name is a virtual host name. The application internally interprets the virtual host name specified and maps to its real, physical host name in the network.

Select Cluster Install if you want to install the Management Agent on a cluster.

For Cluster Node List, specify the cluster nodes on which you want to install the Management Agent. For more information, see Overview.

Note:

The node names that you specify here must be the host short names, not the fully-qualified names. For example, if the node is xyz.server.us.com, and the short name is xyz, then specify only xyz in the Cluster Node List field.

If you have set up the cluster over a vendor clusterware, the node names can be different from the host names. You can confirm the node names by executing olsnodes from the <Oracle Clusterware home> on one of the cluster nodes. If you are using Oracle Cluster Release 9.2, confirm the node names by executing lsnodes from the cluster Oracle home.

When virtual host names are provided in Provide Host List and when Cluster Install is selected, the same virtual host names will be populated in Cluster Node List. These virtual host names listed in the Cluster Node List textbox must be changed to match the actual cluster node names of the hosts. The correct cluster node names can be found in OraInventory/ContentsXML/inventory.xml on each remote host.

For Cluster Name, specify a unique name for the cluster. If you are extending a cluster, specify the name of the existing cluster. The cluster name that you specify here identifies that cluster in the Grid Control console.

In the OS Credentials section, do the following:

Specify the appropriate operating system user credentials. The operating system credentials you specify here must be the same for all the selected hosts.

Select Run root.sh (for UNIX) if you want the application to run this script.

The root.sh script runs after the configuration assistants are run and before the postinstallation scripts (if any) are run. If you do not select this option here, you must run root.sh on each node manually.

In the Destination section, specify the full path to the Installation Base Directory. This directory is created on all the specified hosts, and the Oracle home of the Management Agent is created as a subdirectory under this directory.

For information about installation base directory, see What Is Installation Base Directory?.

In the Port section, specify the port on which the Management Agent will communicate. The default port is 3872. Ensure that the port you specify is not busy, otherwise the prerequisite check fails.

If you are not sure, leave this field blank. The application automatically picks up the first available free port within the range of 1830 - 1849.

In the Load Balancer Host and Port section, specify the name of the host and port where the Server Load Balancer is set up so that communication between the Management Agent and the host running the Server Load Balancer can be enabled. This is required only if you are deploying the Management Agent in an environment that has multiple OMSes managed by a Server Load Balancer.

Note:

If your Server Load Balancer is not functional for some reason, then you can optionally specify the host name and port of the OMS that is being managed by the Server Load Balancer. This is however not recommended, so use this option only if your Server Load Balancer has a problem.

In the Additional Parameters section, specify any additional parameters that you want to pass during installation.

The additional parameters you specify here depend on the software source location that you have selected in Step (4).

If you selected Default, from Management Server location, then specify the additional parameters listed in Table F-1.

If you selected Another Location, then specify the additional parameters listed in Table F-2.

Oracle recommends you to specify only those parameters that you want to run in addition to the general parameters you have already provided on this page for installation. For example, in Step (8), you are specifying the installation base directory. Therefore, for Additional Parameters, try to avoid specifying the installation base directory again. If you still do so, then the value you specified in Step (8) will be ignored and the value you specified here will be used instead.

And note that if you are specifying more than one parameter, then separate them with a white space. For example, -i /etc/oraInst.loc -p /home/config/staticports.ini.

In the Management Server Security section, specify a password that can be used for authenticating new Management Agents that join the Enterprise Manager Grid Control system, and for permitting only secure Management Agents to communicate with the OMS, which is in locked state, via HTTPS protocol.

Alternatively, after the installation is complete, the super administrator can approve the addition of new Management Agents to the Enterprise Manager Grid Control system.

Note:

For security reasons, Oracle strongly recommends you to change the OMS password specified here After the installation is complete.

In the Additional Scripts section, do the following:

Specify any preinstallation and/or postinstallation scripts that you want to execute.

Select Run as Superuser if you want to run these scripts as root.

Note:

The preinstallation and/or postinstallation scripts that you specify must be available on all the hosts. These files are not copied onto the hosts from the software source location during installation.

Click Continue.

On the My Oracle Support Details page, do the following:

If the host where the Management Agent is being installed has a direct connection to the Internet, then specify an e-mail address and My Oracle Support password.

An e-mail address is required so that security updates and install updates can be sent. You can specify any e-mail address, but Oracle recommends you to specify the My Oracle Support user name. For example, john.mathew@xyz.com.

If the host where the Management Agent is being installed has an indirect connection to the Internet, that is, through a proxy server, then specify an e-mail address and My Oracle Support password, and then in the Connection Details section, specify the proxy server details.

Note:

You can change the proxy server settings any time after the installation or patching process ends. To do so, run the configCCR command from the ccr/bin directory within the Oracle home of the Management Agent.

If the host where the Management Agent is being installed does not have a direct or indirect connection to the Internet, then specify the e-mail address and leave the other fields blank.

In this case, after you complete the installation process, manually collect the configuration information and upload it to My Oracle Support.

Note:

If you see any errors on this page, then check whether you (the user installing the Management Agent) have write permissions on crontab. If you do not, then create an entry for your user account in the cron.allow file.

For information about Oracle Configuration Manager, see What Is Oracle Configuration Manager?. To understand how you can manually collect and upload configuration information, see Manually Collecting and Uploading Configuration Information.

Click Continue.

As part of this process, the Agent Deployment Wizard performs some prerequisite checks before proceeding with the installation. When all the prerequisite checks are complete, the wizard displays the results. You can choose to either retry the prerequisite check on all those failed hosts, or ignore the result and proceed to install the Agent.

Note:

If you see the following error messages on the Prerequisite Details page, ignore them and click Continue to proceed with the installation:

Some or all Agent home locations(Install base dir/agent10g or Install Base Dir/agent11g) provided are not empty directories

The Agent Oracle Home ( InstallBaseDir/agent10g or InstallBaseDir/agent11g), is already registered with the inventory

An agent home exists in the hosts

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Install

After you install the Management Agent, follow these steps:

Verify the installation:

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that the Management Agent is up and running:

$<ORACLE_HOME>/bin/emctl status agent

Note:

If the status of the Management Agent is down for some reason, then manually start the Management Agent by running the following command from its Oracle home:

$<ORACLE_HOME>/bin/emctl start agent

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that EMD upload completed successfully:

$<ORACLE_HOME>/bin/emctl upload

Note:

(For UNIX operating systems) Before running the emctl command to start the Management Agent, ensure that the environment variable NLS_LANG is set with a value that is compatible with the operating system default locale setting and the character set of the Oracle Database, which houses the Management Repository.

(Only for UNIX Operating Systems) If you had NOT selected Run Root.sh in the OS Credentials section of the Installation Details page, then manually run the following scripts as a root user from each of the hosts where the installation was done. If you do not have SUDO privileges, then request your Administrator who has the privileges to run these scripts.

If this is the first Oracle product you just installed on the host, then run the oraInstRoot.sh script from the inventory location specified in the oraInst.loc file that is available in the Oracle home of the Management Agent.

For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

If you are not a root user, then use SUDO to change to a root user. For example, run the following command:

/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

Run the root.sh script from the Oracle home of the Management Agent:

<Oracle_Home>/root.sh

If you are not a root user, then use SUDO to change to a root user. For example, run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/agent11g/root.sh

(Optional) If you have not secured the communications between the Management Agent and the OMS, then secure it by running the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/emctl secure agent

Note:

Even after securing the Management Agent, some data might still be transferred over the network without being encrypted.

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

10 Installing Oracle Management Agent Using Shared Oracle Home

This chapter describes how you can install Oracle Management Agents (Management Agent) with the help of a central, shared Oracle home location of an existing Oracle Management Agent (Management Agent).

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Note:

This installation method is not supported on Solaris Express 5.11 x86-64 and Solaris SPARC Express 5.11 (64 bit). To install Oracle Management Agents on these operating systems, follow the silent method mentioned in Part III, "Installing Oracle Management Agent".

Overview

If you want to install additional Management Agents on hosts that share a mounted drive where a Management Agent is already installed, then the best option is to use the software binaries of the shared Oracle home from that mounted drive and configure the remote hosts to be managed by that Management Agent, thus capitalizing on the network visibility and saving hard disk space on the remote hosts. You can achieve this by using the Shared Agent Deployment Wizard, which is a GUI-rich, interactive wizard built into Enterprise Manager Grid Control.

The Shared Agent Deployment Wizard uses the software binaries from the shared Oracle home, and configures an EMSTATE directory on each of the remote hosts for storing configuration files such as emd.properties, targets.xml, log files, and so on. For more information about the EMSTATE directory, see What Is EMSTATE Directory?.

The Management Agent that shares its software binaries, in this context, is called the Master Agent, and the one that is configured with an EMSTATE directory on the remote host is called the Shared Agents or NFS Agents. Technically, the Shared Agent Deployment Wizard does not install a Management Agent; it only uses the software binaries from the shared Oracle home and configures an EMSTATE directory on each of the remote hosts.

Much like the Agent Deployment Wizard, the Shared Agent Deployment Wizard also can be used for installing multiple Management Agents, as a mass deployment. The only difference here is that the Shared Agent Deployment Wizard does not actually install Management Agents on the destination hosts, but it configures those remote hosts to use the software binaries from the shared, already-installed Management Agent location, and hold only the configuration files. The configuration files can be emd.properties, targets.xml, log files, and so on. The location on a host where the configuration files are placed is called EMSTATE directory.

Before You Begin

Before you begin, keep these points in mind:

You can install only on UNIX-based platforms.

You CANNOT use a shared Oracle home of a Management Agent to install a Management Agent on a cluster. If you want to install a Management Agent on a cluster, follow the instructions outlined in Chapter 9, "Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard".

You can choose to skip the prerequisite check that is run by the Agent Deployment Wizard. To do so, follow these steps:

Navigate to the following location in the Oracle home of the OMS:

<ORACLE_HOME>/sysman/prov/agentpush directory

Access the agentpush.properties file.

Change the value of oracle.sysman.prov.agentpush.step2 to "false", that is oracle.sysman.prov.agentpush.step2=false.

If you want to view the status of an installation or upgrade session that was previously run, click Agent Installation Status in the Deployments screen. However, do not attempt to view the installation status until the installation is complete. If you do, you will see an error.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before installing the Management Agent using a shared Oracle home, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 10-1 Prerequisites for Installing Oracle Management Agent Using Shared Agent Deployment Wizard

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

EMSTATE Directory Requirements

Ensure that the EMSTATE directory you specify is empty and has write permission.

shared, mounted

Existing Management Agent Software Requirements

Ensure that you install a Management Agent (Master Agent) on the shared, mounted location.

To install a Management Agent on the shared, mounted location, you can use any of the other Management Agent Deployment methods described in this guide.

Existing Management Agent Status Requirements

Ensure that the existing Management Agent (Master Agent) on the shared, mounted location is shut down always and not used for monitoring any targets. This installation is purely for sharing the software binaries with the Shared Agents.

oraInst.loc Location Requirements

If the shared Management Agent is not the first Oracle product installation but its Oracle home is shared, then ensure that you verify the oraInst.loc location under the /etc directory.

If oraInst.loc and inventory_loc are located in the your home directory, then ensure that you change this entry point to a non-shared location. The oraInst.loc entry should look like this:

inventory_loc=/<any location other than the home directory>/oraInventory

inst_group=<group to which the user belongs>

Software Availability Requirements

Although the installation actually is done using a shared Oracle home of an installed Management Agent that might be running on a different host, the Shared Agent Deployment Wizard uses some scripts and files that are available in the Management Agent software package. Therefore, you are expected to maintain a copy of the Management Agent software for the required platform on the OMS host.

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

Shared Oracle Home Requirements

Ensure that the shared, mounted location is accessible from all destination hosts where you want to install additional Management Agents.

Path Validation Requirements

Validate the path to all command locations. For more information, see Appendix E, "Validating Command Locations".

Destination Host List Requirements

Ensure that you identify the hosts where you want to install the Management Agent. Otherwise, maintain a host list file that contains a list of hosts as described in What Is a Host List File?.

Destination Host Credentials Requirements

Ensure that the destination hosts have the same operating system credentials and file system structure, including the following:

Same User names and Group names

Same user identifiers (UID) and group identifiers (GUID)

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Preinstallation/Postinstallation Scripts Requirements

Ensure that the preinstallation and postinstallation scripts that you want to run along with the installation are available on all the destination hosts.

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). The Agent Deployment Wizard uses SUDO to run the root.sh script. You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file present in the OMS Instance Base location:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

Installation Procedure

To install a new Management Agent using a shared Oracle home of a Management Agent, follow these steps:

In Grid Control, click Deployments.

On the Deployments page, from the Agent Installation section, click Install Agent.

On the following page, select Add Hosts to Shared Agent.

In the Hosts section, do the following:

From the Platform list, select the platform (operating system) on which you want to install the Management Agent.

For Provide Host List, specify the host names or IP addresses of the hosts on which you want to install the Management Agent.You can use a comma (,) or a white space as a separator when specifying multiple hosts.

Alternatively, if you already have a list maintained in a file, then click Get Host Names From File and select that file.

For information about host list file, see What Is a Host List File?.

In the OS Credentials section, do the following:

Specify the appropriate operating system user credentials of the destination hosts. The OS credentials that you specify here must be the same for all the selected hosts

Select Run root.sh (on UNIX machines only) if you want the application to run this script.

The root.sh script runs after the configuration assistants are run and before the postinstallation scripts (if any) are run. If you do not select this option here, you must manually run root.sh on each node.

In the Destination section, do the following:

For NFS Agent Location, specify the complete path to the shared, mounted, shared directory where the Management Agent software is available. This location must be visible on all remote hosts.

For State Directory Location, specify the complete path to an appropriate EMSTATE directory for storing configuration files such as emd.properties, targets.xml, log files, and so on, on each host. Every host that shares the Management Agent has its own EMSTATE directory.

For information about EMSTATE directory, see What Is EMSTATE Directory?.

In the Port section, specify the appropriate port on which the Management Agent will communicate.

Note:

Ensure that the port you specify is not busy, otherwise the prerequisite check fails. If you do not specify a port here, then the Agent Deploy application automatically picks up a free port (3872 or in the range of 1830 - 1849).

In the Additional Parameters section, do not specify any value.

In the Management Server Security section, specify the Management Service Registration Password if you want to secure communications between the Shared Agent and the OMS. This password is mandatory if the Master Agent is secure. Alternatively, the super administrator can approve the addition of new agents to Grid Control after the installation is complete.

Note:

If the OMS is secure in a locked state, then only secure Management Agents can upload data to the OMS.

In the Additional Scripts section, do the following:

Specify any preinstallation and/or postinstallation scripts that you want to run. These scripts are optional. If you do not want to customize your installation, leave these fields blank and continue.

Select Run as Superuser if you want to run these scripts as root.

Click Continue.

As part of this process, the application performs some prerequisite checks before proceeding with the installation. When all the prerequisite checks are complete, the application displays the results. The results include the name, type, and status for all prerequisite checks designed for the installation.

Besides the successfully run prerequisite checks, the prerequisite checks can return either Warning or Failed status messages. For these status messages, you may choose to ignore and continue with the installation (though this is not recommended).

To fix the failed prerequisites, you can either click Retry. The Fixup screen displays the prerequisites that can be automatically fixed, and those that require manual fixes.

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Install

After you install the Management Agent, do these:

The targets that were already installed on the host before installing the Management Agent are automatically discovered in Enterprise Manager Grid Control. However, the new targets installed after installing the Management Agent are not automatically discovered. Therefore, if you install any new target, and if you want to discover and monitor it in Enterprise Manager Grid Control, then run the agentca script from the <NFSAGENT_STATEDIRECTORY>/bin directory:

<NFSAGENT_STATEDIRECTORY>/bin/agentca

11 Cloning Oracle Management Agent Using Agent Cloning Wizard

This chapter explains how you can clone an existing Oracle Management Agent (Management Agent). In particular, this section covers the following:

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Note:

This installation method is not supported on Solaris Express 5.11 x86-64 and Solaris SPARC Express 5.11 (64 bit). To install Oracle Management Agents on these operating systems, follow the silent method mentioned in Part III, "Installing Oracle Management Agent".

Overview

The Management Agent you install using other installation types is always a fresh installation without any customized configuration that you had done or interim one-off patches that you had applied to other running Management Agents.

If you want to install an additional Management Agent that is identical to the existing well-tested, pre-patched, and running Management Agent, then the best option is to clone the existing instance.

Agent Cloning Wizard is an application built into Enterprise Manager Grid Control that enables you to clone existing installations of a Management Agent so that the same configuration changes are carried over to the newly cloned Management Agent instance - either on a single host or multiple hosts. This saves time and effort in patching a fresh installation all over again and bringing it to the current state.

Much like the Agent Deployment Wizard and the Shared Agent Deployment Wizard, the Agent Cloning Wizard also can be used for installing multiple Management Agents, as a mass deployment. The only difference here is that the Agent Cloning Wizard uses the software binaries of an existing Management Agent that can be cloned to the destination host.

This installation type is best suited when you want to install a Management Agent on multiple hosts using an existing installation, and carry forward the same configuration settings and applied patches from the existing versions to the newer installations.

Understandably, as a prerequisite, you need to have at least one Management Agent in your environment, and its software binaries must be accessible from all the hosts where you want to install an additional Management Agent. You can either share the Oracle home of the existing Management Agent or copy the software binaries of that Management Agent to a shared, mounted location that can be accessed from other remote hosts. The shared Oracle home of the Management Agent can also reside on the host where Oracle Management Service (OMS) is running.

Therefore, note that this installation type must be used for installing only additional Management Agents in your environment.

Before You Begin

Before you begin, keep these points in mind:

Cloning on shared clusters is NOT supported.

Cloning between two UNIX platforms and cloning between two Microsoft Windows platforms is supported. However, cloning across one UNIX platform and another Microsoft Windows is NOT supported. For example, you can clone a Management Agent from a Solaris host to another Solaris host. However, you cannot clone a Management Agent from a Solaris host to a Microsoft Windows host.

Remember that Management Agent will be able to monitor only those targets that have been installed by the same users.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1.

Prerequisites

Before cloning a Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 11-1 Prerequisites for Cloning Oracle Management Agent Using Agent Cloning Wizard

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Installation Base Directory Requirements

Ensure that the installation base directory you specify is empty and has write permission.

Existing Management Agent Requirements

Ensure that you already have a Management Agent, which can be cloned, available in your environment.

The Management Agent can be available in one of the following forms:

Oracle home directory (in a shared, mounted location; can also be on the OMS host). For example, /home/john/Oraclehomes/agent11g/

Archived format (ZIP file) of the Oracle home directory (in a shared, mounted location; can also be on the OMS host). For example, /home/nfsshared/agent.zip

Existing Management Agent Version Requirements

Ensure that the version of the existing Management Agent (or its archived Oracle home) is the same as the one you want to install.

For example, if you want to install Oracle Management Agent 11g Release 1, then ensure that the existing Management Agent is 11g Release 1.

Existing Oracle Management Agent Platform

Ensure that the platform of the existing Management Agent (or its archived Oracle home) is the same as the platform of the destination hosts on which you want to clone.

For example, if you want to install Oracle Management Agent 11g Release 1 on a Linux host, then ensure that the existing, shared Oracle Management Agent 11g Release 1 is also running on a Linux host.

Existing Management Agent Accessibility Requirements

Ensure that the Management Agent or its archived Oracle home is accessible from all the destination hosts on which you want to clone.

Software Availability Requirements

Although the installation actually is done using the archived Oracle home of an existing Management Agent that might be running on a different host, the Agent Cloning Wizard uses some scripts and files that are available in the Management Agent software package. Therefore, you are expected to maintain a copy of the Management Agent software for that platform on the OMS host.

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to clone and install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

Accessibility Requirements

If there are multiple OMSes in your environment and if you have staged the Management Agent software in a non-default location (not on the OMS host), then ensure that the non-default location is accessible by all the OMSes.

Path Validation Requirements

Validate the path to all command locations. For more information, see Appendix E, "Validating Command Locations".

Host List Requirements

Identify the hosts where you want to install the Management Agent. Otherwise, maintain a host list file that contains a list of hosts. Ensure that they are accessible.

For more information about host list file, see What Is a Host List File?

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

For information about oraInventory permissions, see What Is Oracle Inventory Directory?.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). The Agent Clone Wizard uses SUDO to run the root.sh script. You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

PATH Environment Variable Requirements

On the host where OMS is running and on the host where you want to install the Management Agent, ensure the following:

(For Microsoft Windows) Ensure that the cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd) on both the hosts.

(For UNIX) Ensure that the SCP binaries (for example, /usr/local/bin/scp) are in the PATH environment variable.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that resides in the OMS Instance Base location:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

SSH Setup Requirements (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that you set up the SSH connectivity between the host running OMS and the host where the Management Agent needs to be installed, as described in Appendix D, "Setting Up SSH Connectivity".

Agent User Account Permissions and Rights (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that the agent user account has permissions and rights to perform the following:

Act as part of the operating system.

Increase quotas.

Replace process level token.

Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

Launch the Local Security Settings.

From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings.

In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Cloning Procedure

To clone a Management Agent using Grid Control console, follow these steps:

In Grid Control, click Deployments. Grid Control displays the Deployments page.

On the Deployments page, from the Agent Installation section, click Install Agent. Grid Control displays the Select Agent Deployment Type page.

On the Select Agent Deployment Type page, click Clone Agent.

On the Installation Details page, in the Source Agent section, do the following:

For Source Agent Home, specify the location where the Management Agent to be cloned is available.

The location can be one of the following:

Full path to the Oracle home of the Management Agent that you want to clone
In this case, the Oracle home can be on the host where OMS is running. For example, /home/john/Oraclehomes/agent11g/. Alternatively, it can be on a shared, mounted location. For example, /net/host/OracleHomes/agent11g.

While specifying the path, ensure that the path leads to the Oracle home directory (agent11g).

In this case, the Agent Cloning Wizard automatically excludes the directories mentioned in the following file present in the Oracle home of the OMS:

$<ORACLE_HOME>/sysman/prov/agentpush/resources/scripts/exclude.lst

Full path to the location where the archived format (ZIP file) is available, that is, if you have already archived the Oracle home of the Management Agent
The archived ZIP file can be on the host where OMS is running. For example, /home/john/Oraclehomes/agent11g.zip. Alternatively, it can be on a shared, mounted location. For example, /net/host/OracleHomes/agent11g.zip. While specifying the path, ensure that the path leads to the archived ZIP file name.

Ensure that the ZIP file contains the contents of the Oracle home. To ensure this, when you create the ZIP file, create it from the parent directory of the Oracle home. Also note that, in this case, the Agent Cloning Wizard does not automatically exclude the directories mentioned in the exclude.lst file present in the Oracle home of the OMS, and therefore, while archiving the Oracle home of the Management Agent, you must manually pass this file in the ZIP command.

For example, to ZIP the contents from /scratch/oraclehome/agent/agent11g, navigate to /scratch/oraclehome/agent directory first, and then run the following command:

# zip -r agent11g.zip agent11g -x@<ORACLE_HOME>/sysman/prov/agentpush/resources/scripts/exclude.lst

Note:

If this Oracle home of the Management Agent or the archived ZIP file is on the host where OMS is running, then ensure that the user account that was used to install that OMS has read access to that Oracle home or the archived ZIP file, respectively.

However, if this Oracle home of the Management Agent or the archived ZIP file is on a shared, mounted location, then ensure that the user account that you want to use for cloning the Management Agent has read access to that Oracle home or the archived ZIP file, respectively.

Select Source Agent Home on OMS if the location you specified for Source Agent Home (above) is available on the host where OMS is running.

In the Hosts section, do the following:

From the Platform list, select the platform of the host on which you want to clone. Ensure that the platform you select here matches with the platform of the Source Agent Home.

For Provide Host List, specify the hosts where you want to clone the Management Agent. You can specify either the name of the host or its IP address. Separate them by a comma or white space. For example, host1.example.com,host2.example.com

You can specify either physical hosts or virtual hosts, but not a combination of the two. If you are specifying virtual hosts, then select All are Virtual Hosts.

If you have a file that contains a list of all required host names, then click Get Host Names From File and select the file. Ensure that the file format is similar to /etc/hosts file.

For information about host list file, see What Is a Host List File?.

Select Allow local hostname to override provided hostname if the host names specified in Provide Host List are virtual host names and not physical host names.

For example, if a host name is mypc.server.com but the virtual name given to it is host1, then you can specify host1 in the Provide Host List text box, but select this check box to indicate that the specified host name is a virtual host name. The application internally interprets the virtual host name specified and maps to its real, physical host name in the network.

For Cluster Name, specify a name that can be used to form a cluster of the all the destination hosts you specified.

In the OS Credentials section, do the following:

Specify the user name and password to access the destination hosts where you want to clone the Management Agent. If you are cloning on multiple hosts, then ensure that the credentials are the same for all the hosts.

Select Run root.sh if you want Grid Control to run this script.

In the Destination section, specify the full path to the installation base directory on the destination hosts where you want to clone the Management Agent. For example, /home/mark/OracleHomes.

The Oracle home for the Management Agent will be created as a subdirectory in this base directory. For example, if you specify /home/mark/OracleHomes as the installation base directory here, then the Management Agent is cloned to /home/mark/OracleHomes/agent11g.

In the Port section, specify a port on which the Management Agent can communicate with the OMS.

The same port will be used for all the hosts specified across all platforms. If no port is specified here, the application uses the first free port that is available within the range of 1830 to 1849.

In the Additional Parameters section, specify any additional parameters that you want to pass during the cloning process. If you are specifying more than one parameter, then separate them with a white space.

For information about the additional parameters that are supported for Agent Cloning, see Table F-2.

Note:

If you are cloning a Management Agent that was installed along with OMS, then include the following additional parameter:

b_chainedInstall=false, oracle.sysman.top.agent:s_installType=AGENT

In the Management Server Security section, specify a password that can be used for authenticating new Management Agents that join the Enterprise Manager Grid Control system, and for permitting only secure Management Agents to communicate with the OMS, which is in locked state, via HTTPS protocol.

Alternatively, after the installation is complete, the super administrator can approve the addition of new Management Agents to the Enterprise Manager Grid Control system.

Note:

For security reasons, Oracle strongly recommends you to change the OMS password specified here After the installation is complete.

In the Additional Scripts section, do the following:

Specify the additional scripts you want to run before and/or after cloning and configuration steps. The scripts you specify here must be available on all the destination hosts.

If you want to run the scripts as SUDO, then select Run as Superuser.

Click Continue.

On the My Oracle Support Details page, do the following:

If the host where the Management Agent is being cloned has a direct connection to the Internet, then specify an e-mail address and My Oracle Support password.

An e-mail address is required so that security updates and install updates can be sent. You can specify any e-mail address, but Oracle recommends you to specify the My Oracle Support user name. For example, john.mathew@xyz.com.

If the host where the Management Agent is being cloned has an indirect connection to the Internet through a proxy server, then specify an e-mail address and My Oracle Support password, and then in the Connection Details section, specify the proxy server details.

Note:

You can change the proxy server settings any time after the installation or patching process ends. To do so, run the configCCR command from the ccr/bin directory within the Oracle home of the Management Agent.

If the host where the Management Agent is being cloned does not have a direct or indirect connection to the Internet, then specify the e-mail address and leave the other fields blank.

In this case, after you complete the installation process, manually collect the configuration information and upload it to My Oracle Support.

For information about Oracle Configuration Manager, see What Is Oracle Configuration Manager?. To understand how you can manually collect and upload configuration information, see Manually Collecting and Uploading Configuration Information.

Click Continue.

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Clone

After you install the Management Agent, follow these steps outlined in After You Install.

12 Installing Oracle Management Agent Using Response File

This chapter describes how you can install Oracle Management Agent (Management Agent) using a response file. In particular, this section covers the following:

Overview

Prerequisites

Installation Procedure

After You Install

Overview

By default, the Management Agent software comes with a response file, additional_agent.rsp, which helps you install a Management Agent silently, without having to use the GUI screens of Enterprise Manager Grid Control. The response file captures all the information required for installing a Management Agent, and it is available in the <Software_Location>/<platform>/response directory.

For example, if you have an Oracle Management Service (OMS) running on a Linux host and if you have the Management Agent software on that host, then the response file is available at oms11g/sysman/agent_download/11.1.0.1.0/linux/response/additional_agent.rsp. And, if you do not have an OMS but if you have downloaded the Management Agent software for Linux operating system to /private/temp, then the response file is available at /private/temp/linux/response/additional_agent.rsp.

This installation type is best suited when you want to install additional Management Agents on the destination hosts, from the destination hosts itself, and without having to use the Agent Deployment Wizard in the Enterprise Manager Grid Control console.

The following are the basic differences between Agent Deployment Wizard and the additional_agent.rsp file.

While the Agent Deployment Wizard is GUI-based, the additional_agent.rsp file is file -based. Therefore, using the file is a silent, non-GUI way of installing Management Agents.

If you use the Agent Deployment Wizard, then you will have to use the interview screens and provide basic source details every time you install a Management Agent. If you use the additional_agent.rsp file, then you will update a response file with the basic source details for once and use the same response file for multiple installations.

While the Agent Deployment Wizard can be run from a source or destination host, the additional_agent.rsp file must be run only from a destination host. Therefore, if you want to install only a few Management Agents, then use the additional_agent.rsp file.

While the Agent Deployment Wizard enables you to install multiple Management Agents at a time, the additional_agent.rsp file enables you to install only one Management Agent at a time.

The Agent Deployment Wizard pushes the software binaries from a central source location to the destination hosts. The additional_agent.rsp file pulls the software binaries from the source host to the destination hosts.

Prerequisites

Before installing the Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 12-1 Prerequisites for Installing Oracle Management Agent Using Response File

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Installation Base Directory Requirements

Ensure that the installation base directory you specify in the response file is empty and has write permission.

Software Availability Requirements

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. However, this Management Agent software is for the platform on which the OMS is running.

Therefore, if you have an OMS and if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you do not have an OMS or if you want to install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

Destination Host Requirements

Ensure that all the destination hosts have the same operating system credentials and file system structure.

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

For information about oraInventory permissions, see What Is Oracle Inventory Directory?.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Installation Procedure

To install a Management Agent using the response file, follow these steps:

Navigate to the location where the Management Agent software is available.

For example, oms11g/sysman/agent_download/11.1.0.1.0/linux if the Management Agent software is available in the Oracle home of the OMS.

Alternatively, /private/temp/11.1.0.1.0/linux if you have downloaded the Management Agent software to /private/temp on your local system.

Compress the files from the <platform> directory using the WinZIP utility, and transfer the compressed file to the destination host where you want to install the Management Agent. For example, linux.zip.

On the destination host, do the following:

Extract the contents of the compressed file you just transferred.

Navigate to the following location and edit the additional_agent.rsp file as described in Table 12-2.

<Software_Extracted_Location>/<platform>/response/ additional_agent.rsp

For example:

/scratch/john/linux/response/ additional_agent.rsp

Navigate to the following location and invoke the installer:

If this is the first Oracle product you are installing on the host, then run the following command:

<Software_Extracted_Location>/<platform>/agent/runInstaller -silent -responseFile <absolute_path_to_location>/additional_agent.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

For example,

/scratch/john/linux/agent/runInstaller -silent -responseFile /scratch/john/linux/response/additional_agent.rsp -invPtrLoc /scratch/OracleHomes/oraInst.loc

Otherwise, run the following command:

<Software_Extracted_Location>/<platform>/agent/runInstaller -silent -responseFile <absolute_path_to_location>/additional_agent.rsp

For example,

/scratch/john/linux/agent/runInstaller -silent -responseFile /scratch/john/linux/response/additional_agent.rsp

Note:

For Microsoft Windows platforms, run setup.exe instead of runInstaller.

After the installation ends successfully, the Management Agent starts automatically. If you do not want it to start automatically, then invoke the installer with the b_startAgent=false argument.

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

Table 12-2 Modifying Parameters for Installing Additional Oracle Management Agent

Parameter
Description

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified FALSE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Specify FALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

ORACLE_AGENT_HOME_LOCATION

Specify the full path to the installation base directory where you want to install the Management Agent. The Oracle home of the Management Agent is created inside this installation base directory.

For example, if you specify the installation base directory as /home/john/, then the Oracle home is created as /home/john/agent11g.

For information about installation base directory, see What Is Installation Base Directory?.

OMS_HOST

Specify the name of the host on which the OMS is running.

OMS_PORT

Specify the port used by the OMS.

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS and the Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

After You Install

After you install the Management Agent, do these:

Verify the installation:

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that the Management Agent is up and running:

$<ORACLE_HOME>/bin/emctl status agent

Note:

If the status of the Management Agent is down for some reason, then manually start the Management Agent by running the following command from its Oracle home:

$<ORACLE_HOME>/bin/emctl start agent

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that EMD upload completed successfully:

$<ORACLE_HOME>/bin/emctl upload

Note:

(For UNIX operating systems) Before running the emctl command to start the Management Agent, ensure that the environment variable NLS_LANG is set with a value that is compatible with the operating system default locale setting and the character set of the Oracle Database, which houses the Management Repository.

(Only for UNIX Operating Systems) Run the following scripts as a root user on each of the hosts where the installation was done:

If you have not specified the inventory location while invoking the installer and if this is the first Oracle product you just installed on the host, then run the oraInstRoot.sh script from the Central Inventory:

$HOME/oraInventory/oraInstRoot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo $Home/oraInventory/oraInstRoot.sh

Run the root.sh script from the Oracle home of the Management Agent (agent11g):

<ORACLE_HOME>/root.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/agent11g/root.sh

(Optional) If you have not secured the communications between the Management Agent and the OMS, then secure it by running the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/emctl secure agent

Note:

Even after securing the Management Agent, some data might still be transferred over the network without being encrypted.

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

13 Installing Oracle Management Agent Using agentDownload Script

This chapter explains how you can install Oracle Management Agent (Management Agent) using the agentDownload script. In particular, this section covers the following:

Overview

Prerequisites

Installation Procedure

After You Install

Overview

The agentDownload script is a script that helps you install Management Agents on destination hosts, silently without having to use the GUI screens of Enterprise Manager Grid Control. The script is available on the source host where Oracle Management Service (OMS) is installed, and it is run from the destination host where the Management Agent needs to be installed.

This installation type is best suited when you want to install additional Management Agents on the destination hosts, from the destination hosts itself without having to access the source host, and without having to use the Enterprise Manager Grid Control console.

The following are the basic differences between Agent Deployment Wizard and agentDownload Script.

While the Agent Deployment Wizard is GUI-based, the agentDownload script is script-based. Therefore, using the script is a silent, non-GUI way of installing Management Agents.

While the Agent Deployment Wizard can be run from a source or destination host, the agentDownload script must be run only from a destination host.

While the Agent Deployment Wizard enables you to install multiple Management Agents at a time, the agentDownload script enables you to install only one Management Agent at a time.

The Agent Deployment Wizard pushes the software binaries from a central source location to the destination hosts. The agentDownload script pulls the software binaries from the source host to the destination hosts.

Prerequisites

Before installing the Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 13-1 Prerequisites for Installing Oracle Management Agent Using agentDownload Script

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Software Availability Requirements

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

OMS Requirements

Ensure that you already have an OMS running in your enterprise because the agentDownload script needs to be downloaded from the OMS host.

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system.If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Installation Base Directory Requirements

Ensure that the Installation Base Directory is writable and is empty.

Destination Host Requirements

Ensure that all the destination hosts have the same operating system credentials and file system structure.

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

agentDownload Script Requirements

Ensure that the agentDownload script is for the platform of the destination host where you want to install the Management Agent.

For example, if you want to run the script on a Linux host, then ensure that the script available on the OMS host is a script for Linux operating system.

agentDownload Script File-Protection Setting Requirements

Ensure that the execute binary is set and the script file has proper file-protection settings. You can use chmod to ensure the file has the correct privileges.

Load Balancer Requirements

If the OMS is using a load balancer, you must modify the s_omsHost and s_omsPort values in the agentDownload file.

Wget Defined in the agentDownload Script

Ensure that the wget software has been defined in the agentDownload script. The script checks for the existence of wget in /usr/local/bin/wget, followed by /usr/bin/wget.

If wget is not found in these locations, then it must be included in the $PATH or the script will exit with an error.

Environment Variable Settings

Ensure that the AGENT_INSTALL_PASSWORD environment variable is set in the environment if the Management Agent is uploading to a secure and locked OMS.

Alternatively, you can secure the Management Agent by running the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/emctl secure agent <password>

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

For information about oraInventory permissions, see What Is Oracle Inventory Directory?.

Ensure that you have write permission on the Installation Base Directory, and write and execute permissions on the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Installation Procedure

To install a Management Agent using the agentDownload script, follow these steps:

Edit the SECURITY_UPDATES_VIA_MYORACLESUPPORT and DECLINE_SECURITY_UPDATES parameters in the following file that is available in the Oracle home of the OMS:

<ORACLE_HOME>/sysman/agent_download/agent_download.rsp

If you want to download and install security updates, then do the following:

Set the SECURITY_UPDATES_VIA_MYORACLESUPPORT parameter to TRUE.

Specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Set the DECLINE_SECURITY_UPDATES parameter to False.

If you do not want to download and install security updates, then do the following:

Set the SECURITY_UPDATES_VIA_MYORACLESUPPORT parameter to False.

Set the DECLINE_SECURITY_UPDATES parameter to TRUE.

On the destination host where you want to install the Management Agent, open a browser to access the OMS URL and download the agentDownload script.

UNIX Platform
Microsoft Windows Platforms

Using Browser

http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

If you are using HTTPS protocol, then run the following command:

wget https://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform> --no-check-certificate

(wget 1.10 and higher versions support the option --no-check-certificate)

Using Browser

http://<ons_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Run the agentDownload script on the destination host using the following command. For other options you can use with the command, see Table F-1.

UNIX Platform
Microsoft Windows Platforms

./agentDownload.<platform> -b <absolute_path_to_installation_base_directory> -m <OMS_Host> -r <OMS_port>

For example:

./agentDownload.linux -b /john/OracleHomes -m host1.servers.com -r 4889

cscript.exe agentDownload.vbs b <absolute_path_to_installation_base_directory> m <OMS_Host> r <OMS_port>

For example:

cscript.exe agentDownload.vbs b C:\scratch\OracleHomes m host1.servers.com r 4889

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

If the installation base directory does not exist, then it is created during the installation. If it exists, then ensure that it is empty. If the variable is not set, then the script exits with an error.

After You Install

After you install the Management Agent, follow these steps outlined in After You Install.

14 Installing Oracle Management Agent on a Cluster Using Response File or agentDownload Script

This chapter describes how you can install Oracle Management Agent (Management Agent) on a cluster using either the response file (additional_agent.rsp) or the agentDownload script. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Note:

If you have a cluster-based environment, then Oracle strongly recommends you to install the Management Agent using the Agent Deployment Wizard as described in Chapter 9, "Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard".

Overview

The Management Agents installed on the nodes of a cluster are different from the Management Agents installed on standalone hosts. While the Management Agent installed on a standalone host is called a standalone Management Agent, the Management Agent installed on a node of the cluster is called a cluster-based Management Agent.

You can install a cluster-based Management Agent on a cluster using either the response file, that is, additional_agent.rsp, or the agentDownload script.

The following are the use cases that are supported:

Use Case
Description
Your Requirement

Installing a Management Agent on All the Nodes of a Cluster
You might have a cluster containing many nodes, and none of the nodes might have a Management Agent installed.

For example, let's say you have a cluster crs1 with nodes n1, n2, n3, n4, and n5, and none of the nodes have a Management Agent installed.

You want to install a Management Agent on each of the nodes.

Installing a Management Agent Only on Some Nodes of a Cluster
You might have a cluster containing many nodes, and only a few of the nodes might have a Management Agent installed.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed only on n1 and n2.

You want to install a Management Agent on some of the nodes, not all, though.

Installing a Management Agent on Additional Nodes that Extends the Cluster
You might have a cluster containing some nodes, and you might extend the cluster by adding one or more new nodes to it.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed on each of the nodes. You now introduce two new nodes n6 and n7 to the cluster.

You want to install a Management Agent on the additional nodes that extend the cluster.

Installing a Management Agent on Two Clusters of the Same Name, but with Different Nodes
You might have two clusters with the same name, but each cluster having different nodes.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's say you have another cluster named crs2 with nodes n6, n7, n8, n9, and n10.

You want to install a Management Agent on the nodes of each of the clusters.

Before You Begin

Before you begin, keep in mind the following points:

You CANNOT use addnode.sh script to extend Management Agents to a cluster.

If the CLUSTER_NAME environment variable is not set or passed, the Management Agent uses the cluster name that was specified during the Oracle Clusterware installation.

The installation is done only on those cluster nodes that you specify, regardless of the number of hosts that make up that cluster.

Prerequisites

Before installing the Management Agent, ensure that you meet the following prerequisites:

If you are installing using the response file, then meet the prerequisites described in Prerequisites.

If you are installing using the agentDownload script, then meet the prerequisites described in Prerequisites.

Installation Procedure

This section describes the installation procedures for installing a Management Agent on a cluster using either the response file, that is, additional_agent.rsp, or the agentDownload script. In particular, this section covers the following:

Installing Using Response File

Installing Using agentDownload Script

Installing Using Response File

To install a Management Agent using the response file, follow these steps:

Navigate to the location where the Management Agent software is available.

For example, oms11g/sysman/agent_download/11.1.0.1.0/linux if the Management Agent software is available in the Oracle home of the OMS.

Alternatively, /private/temp/11.1.0.1.0/linux if you have downloaded the Management Agent software to /private/temp on your local system.

Compress the files from the <platform> directory using the WinZIP utility, and transfer the compressed file to the node where you want to install the Management Agent. For example, linux.zip.

Note:

If you are installing on one of the new nodes that are extending the cluster, then transfer the ZIP file to one of the new nodes.

On the node where you want to install the Management Agent, do the following:

Extract the contents of the compressed file you just transferred.

Navigate to the following location and edit the additional_agent.rsp file as described in Table 14-1.

<Software_Extracted_Location>/<platform>/response/ additional_agent.rsp

For example:

/scratch/john/linux/response/ additional_agent.rsp

Navigate to the following location and invoke the installer:

If this is the first Oracle product you are installing on the host, then run the following command:

<Software_Extracted_Location>/<platform>/agent/runInstaller -silent -responseFile <absolute_path_to_location>/additional_agent.rsp [-invPtrLoc <absolute_path_to_inventory_directory>]

For example,

/scratch/john/linux/agent/runInstaller -silent -responseFile /scratch/john/linux/response/additional_agent.rsp -invPtrLoc /scratch/OracleHomes/oraInst.loc

Otherwise, run the following command:

<Software_Extracted_Location>/<platform>/agent/runInstaller -silent -responseFile <absolute_path_to_Location>/additional_agent.rsp

For example,

/scratch/john/linux/agent/runInstaller -silent -responseFile /scratch/john/linux/response/additional_agent.rsp

Note:

For Microsoft Windows platforms, run setup.exe instead of runInstaller.

After the installation ends successfully, the Management Agent starts automatically. If you do not want it to start automatically, then invoke the installer with the b_startAgent=false argument.

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

Update the node list of the cluster as described in Table 14-2.

Editing Parameters for Installing Oracle Management Agent on a Cluster

Table 14-1 shows the parameters you must edit in the additional_agent.rsp file for installing Management Agent on a cluster.

Table 14-1 Response File Parameters for Installing Oracle Management Agent on a Cluster

Parameter
Description

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Specify FALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

ORACLE_AGENT_HOME_LOCATION

Specify the full path to the installation base directory where you want to install the Management Agent. The Oracle home of the Management Agent is created inside this installation base directory.

For example, if you specify the installation base directory as /home/john/, then the Oracle home is created as /home/john/agent11g.

For information about installation base directory, see What Is Installation Base Directory?.

Important: The installation base directory must be the same across the nodes of the cluster.

OMS_HOST

Specify the name of the host on which the OMS is running.

OMS_PORT

Specify the port used by the OMS.

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS andthe Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

CLUSTER_NODES

Specify the nodes of the cluster, including the node from where you are invoking the installer.

For information about what you must specify for the use cases described in Overview, see Table 14-2.

Updating the Node List After Installing the Management Agent

Table 14-2 shows the command you must run after installing the Management Agents to update the node list of the cluster based on the use cases described in Overview.

Table 14-2 Updating the Node List After Installing Oracle Management Agent

Use Case
CLUSTER_NODES Parameter Value
Command to Update the Inventory

Installing a Management Agent on All the Nodes of a Cluster

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. If you want to install a Management Agent on each of the nodes, then specify the following in the CLUSTER_NODES parameter of the response file:

CLUSTER_NODES={"n1","n2","n3","n4","n5"}

This installs a Management Agent on n1, n2, n3, n4, and n5, and updates the inventory of n1, n2, n3, n4, and n5 with details of n1, n2, n3, n4, and n5.

-

Installing a Management Agent Only on Some Nodes of a Cluster

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed only on n1 and n2. If you want to install a Management Agent on n3, n4, and n5, then specify the following in the CLUSTER_NODES parameter of the response file:

CLUSTER_NODES={"n3","n4","n5"}

This installs a Management Agent on n3, n4, and n5, and updates the inventory of n3, n4, and n5 with details of n3, n4, and n5 only.

To update the inventory of n1, n2, n3, n4, and n5 with details of all the nodes, run the following command from the Oracle home of the Management Agent from each of the nodes:

<ORACLE_HOME>/oui/bin/runInstaller ORACLE_HOME=<absolute_path_to_agent_home> -updateNodeList "CLUSTER_NODES={n1,n2,n3,n4,n5}" -local -invPtrLoc <absolute_path_to_OraInst.loc_File>

Installing a Management Agent on Additional Nodes that Extend the Cluster

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed on each of the nodes. You now introduce two new nodes n6 and n7 to the cluster. If you want to install a Management Agent on this new nodes, then specify the following in the CLUSTER_NODES parameter of the response file:

CLUSTER_NODES={"n6"}

This installs a Management Agent on n6, and updates the inventory of n6 with details of n6 only.

Run the same command on n7. Ensure that you specify only n7 in the cluster node list. This installs a Management Agent on n7, and updates the inventory of n7 with details of n7 only.

To update the inventory of n1, n2, n3, n4, n5, n6, and n7 with details of all the nodes, run the following command from the Oracle home of the Management Agent from each of the nodes:

$<ORACLE_HOME>/oui/bin/runInstaller ORACLE_HOME=<absolute_path_to_agent_home> -updateNodeList "CLUSTER_NODES={n1,n2,n3,n4,n5,n6,n7}" -local -invPtrLoc <absolute_path_to_OraInst.loc_File>

Installing a Management Agent on Two Clusters of the Same Name, but with Different Nodes

For example, let's say you have a cluster crs1 with nodes n1, n2, n3, n4, and n5. If you want to install a Management Agent on each of the nodes, then specify the following in the CLUSTER_NODES parameter of the response file:

CLUSTER_NODES={"n1","n2","n3","n4","n5"}

This installs a Management Agent on n1, n2, n3, n4, and n5, and updates the inventory of n1, n2, n3, n4, and n5 with details of n1, n2, n3, n4, and n5.

Then, run the response file on one of the nodes of the second cluster, and specify the nodes that belong to that cluster, separated by a comma.

-

Installing Using agentDownload Script

To install a Management Agent using the agentDownload script, follow these steps:

On one of the nodes of the cluster where you want to install a Management Agent, open a browser to access the OMS URL and download the agentDownload script.

UNIX Platform
Microsoft Windows Platforms

Using Browser

http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

Using Browser

http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Run the agentDownload script as outlined in this step for the use case that matches your requirement:

Use Case
Installation Procedure

Installing a Management Agent on All the Nodes of a Cluster
Invoke the agentDownload script on one of the nodes of the cluster, and specify all the nodes separated by a comma.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. If you want to install a Management Agent on each of the nodes, then run the following command on one of the nodes:

For UNIX

./agentDownload.<platform> -b <absolute_path_to_installation_base_directory> -n <cluster_name> -c "n1,n2,n3,n4,n5"

For Microsoft Windows

cscript.exe agentDownload.vbs b <absolute_path_to_installation_base_directory> n <cluster_name> c "n1,n2,n3,n4,n5"

Important: Ensure that the installation base directory is the same across the nodes of the cluster.

This installs a Management Agent on n1, n2, n3, n4, and n5, and updates the inventory of n1, n2, n3, n4, and n5 with details of n1, n2, n3, n4, and n5.

Installing a Management Agent Only on Some Nodes of a Cluster
Invoke the agentDownload script on one of the nodes on which you want to install the Management Agent, and specify all the nodes (separated by a comma) on which you want to install the Management Agent.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed only on n1 and n2. If you want to install a Management Agent on n3, n4, and n5, then run the following command on n3:

For UNIX

./agentDownload.<platform> -b <absolute_path_to_installation_base_directory> -n <cluster_name> -c "n3,n4,n5"

For Microsoft Windows

cscript.exe agentDownload.vbs b <absolute_path_to_installation_base_directory> n <cluster_name> c "n3,n4,n5"

Important: Ensure that the installation base directory is the same across the nodes of the cluster.

This installs a Management Agent on n3, n4, and n5, and updates the inventory of n3, n4, and n5 with details of n3, n4, and n5 only.

To update the inventory of n1, n2, n3, n4, and n5 with details of all the nodes, run the following command from the Oracle home of the Management Agent from each of the nodes:

<ORACLE_HOME>/oui/bin/runInstaller ORACLE_HOME=<absolute_path_to_agent_home> -updateNodeList "CLUSTER_NODES={n1,n2,n3,n4,n5}" -local -invPtrLoc <absolute_path_to_OraInst.loc_File>

Installing a Management Agent on Additional Nodes that Extend the Cluster
Invoke the agentDownload script on the new node, and specify all the nodes (separated by a comma) that are part of the cluster.

For example, let's say you have a cluster named crs1 with nodes n1, n2, n3, n4, and n5. Let's assume that a Management Agent is installed on each of the nodes. You now introduce two new nodes n6 and n7 to the cluster. If you want to install a Management Agent on this new nodes, then run the following command on n6:

For UNIX

./agentDownload.<platform> -b <absolute_path_to_installation_base_directory> -n <cluster_name> -c "n6"

For Microsoft Windows

cscript.exe agentDownload.vbs b <absolute_path_to_installation_base_directory> n <cluster_name> c "n6"

Important: Ensure that the installation base directory is the same across the nodes of the cluster.

This installs a Management Agent on n6, and updates the inventory of n6 with details of n6 only.

Run the same command on n7. Ensure that you specify only n7 in the cluster node list. This installs a Management Agent on n7, and updates the inventory of n7 with details of n7 only.

To update the inventory of n1, n2, n3, n4, n5, n6, and n7 with details of all the nodes, run the following command from the Oracle home of the Management Agent from each of the nodes:

$<ORACLE_HOME>/oui/bin/runInstaller ORACLE_HOME=<absolute_path_to_agent_home> -updateNodeList "CLUSTER_NODES={n1,n2,n3,n4,n5,n6,n7}" -local -invPtrLoc <absolute_path_to_OraInst.loc_file>

Installing a Management Agent on Two Clusters of the Same Name, but with Different Nodes
Invoke the agentDownload script on one of the nodes of the first cluster, and specify all the nodes separated by a comma.

For example, let's say you have a cluster crs1 with nodes n1, n2, n3, n4, and n5. If you want to install a Management Agent on each of the nodes, then run the following command on one of the nodes:

For UNIX

./agentDownload.<platform> -b <absolute_path_to_installation_base_directory> -n <cluster_name> -c "n1,n2,n3,n4,n5"

For Microsoft Windows

cscript.exe agentDownload.vbs b <absolute_path_to_installation_base_directory> n <cluster_name> c "n1,n2,n3,n4,n5"

Important: Ensure that the installation base directory is the same across the nodes of the cluster.

This installs a Management Agent on n1, n2, n3, n4, and n5, and updates the inventory of n1, n2, n3, n4, and n5 with details of n1, n2, n3, n4, and n5.

Then, run the same command from one of the nodes of the second cluster, and specify the nodes that belong to that cluster, separated by a comma.

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Install

After you install the Management Agent, follow these steps outlined in After You Install.

15 Installing Oracle Management Agent Using Shared Oracle Home Using nfsagentinstall Script

This chapter describes how you can use the nfsagentinstall script to install Oracle Management Agents (Management Agent) with the help of a central, shared Oracle home of an existing Management Agent. In particular, this section covers the following:

Overview

Before You Begin

Prerequisites

Installation Procedure

After You Install

Overview

If you want to install additional Management Agents on hosts that share a mounted drive where a Management Agent is already installed, then the best option is to use the software binaries of the shared Oracle home from the mounted drive and configure the remote hosts to be managed by that Management Agent, thus capitalizing on the NFS visibility and saving hard disk space on the remote hosts. You can achieve this in GUI as well as in silent mode.

While the Shared Agent Deployment Wizard helps you install such Management Agents in GUI mode, the nfsagentinstall script helps you install in silent mode.

Much like the Shared Agent Deployment Wizard, the nfsagentinstall uses the software binaries from the shared Oracle home, and configures an EMSTATE directory on each of the remote destination hosts for storing configuration files such as emd.properties, targets.xml, log files, and so on. For more information about the EMSTATE directory, see What Is EMSTATE Directory?.

The Management Agent that shares its software binaries, in this context, is called the Master Agent, and the one that is configured with an EMSTATE directory on the remote host is called the Shared Agents or NFS Agents. Technically, the nfsagentinstall script does not install a Management Agent; it only uses the software binaries from the shared Oracle home and configures an EMSTATE directory on each of the remote hosts.

However, unlike the Shared Agent Deployment Wizard, the nfsagentinstall script must be run only from a destination host, and at a given time, only one Management Agent can be installed at a given time. Therefore, if you want to install only a few Management Agents, then use The nfsagentinstall script.

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before installing the Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 15-1 Prerequisites for Installing Oracle Management Agent Using nfsagentinstall Script

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

EMSTATE Directory Requirements

Ensure that the installation base directory you specify is empty and has write permission.

Existing Management Agent Software Requirements

Ensure that you install a Management Agent (Master Agent) on the shared, mounted location.

To install a Management Agent on the shared, mounted location, you can use any of the other Management Agent Deployment methods described in this guide.

Existing Management Agent Status Requirements

Ensure that the existing Management Agent (Master Agent) on the shared, mounted location is shut down always and not used for monitoring any targets. This installation is purely for sharing the software binaries with the Shared Agents.

oraInst.loc Location Requirements

If the shared Management Agent is not the first Oracle product installation but its Oracle home is shared, then ensure that you verify the oraInst.loc location under the /etc directory.

If oraInst.loc and inventory_loc are located in the your home directory, then ensure that you change this entry point to a non-shared location. The oraInst.loc entry should look like this:

inventory_loc=/<any location other than the home directory>/oraInventory

inst_group=<group to which the user belongs>

Software Availability Requirements

Although the installation actually is done using a shared Oracle home of an installed Management Agent that might be running on a different host, the nfsagentinstall script uses some files that are available in the Management Agent software package. Therefore, you are expected to maintain a copy of the Management Agent software for the required platform on the OMS host.

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to install Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to install Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the Management Agent software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

Shared, Mounted Location Requirements

Ensure that the shared, mounted location is accessible from all destination hosts where you want to install additional Management Agents.

Destination Host Credentials Requirements

Ensure that the destination hosts have the same operating system credentials and file system structure, including the following:

Same User names and Group names

Same user identifiers (UID) and group identifiers (GUID)

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

For information about oraInventory permissions, see What Is Oracle Inventory Directory?.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file present in the OMS Instance Base:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

Installation Procedure

To install a Management Agent using the nfsagentinstall script, follow these steps:

On one of the destination hosts, navigate to the following directory (the shared Oracle home that is visible on this destination host):

<ORACLE_HOME>/sysman/install/

Run the following command:

./nfsagentinstall -s <absolute_path_to_EMSTATE_directory_location> [ -p <customized_port_number>] [ -i <invPtrLoc> inventory_pointer_location] [-t Skip discovery]

Note:

In this command, -p, -i, and -t are optional arguments.

If AGENT_INSTALL_PASSWORD parameter is not set in the nfsagentinstall script, then you are prompted to specify the agent registration password to secure the Management Agent.

(Only for UNIX Operating Systems) If this Management Agent installation is the first Oracle product installation on this host, then the nfsagentinstall script prompts you to run the following scripts manually:

If this is the first Oracle product you just installed on the host, then run the oraInstRoot.sh script from the inventory location specified in the oraInst.loc file that is available in the Oracle home of the Management Agent.

For example, if the inventory location specified in the oraInst.loc file is $HOME/oraInventory, then run the following command:

$HOME/oraInventory/oraInstRoot.sh

If you are not a root user, then use SUDO to change to a root user. For example, run the following command:

/usr/local/bin/sudo $HOME/oraInventory/oraInstRoot.sh

Run the root.sh script from the Oracle home of the Management Agent:

<Oracle_Home>/root.sh

If you are not a root user, then use SUDO to change to a root user. For example, run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/agent11g/root.sh

Repeat Step (1) to Step (3) on the remaining hosts where you want to install the Management Agent.

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Install

After you install the Management Agent, follow these steps outlined in After You Install.

16 Cloning Oracle Management Agent Using ZIP File

This chapter explains how you can clone an existing Oracle Management Agent 11g Release 1 (11.1.0.1.0) to additional hosts using a ZIP file. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Cloning Procedure

After You Clone

Overview

The Management Agent you install using other installation types is always a fresh installation without any customized configuration that you had done or interim one-off patches that you had applied to other running Management Agents.

If you want to install an additional Management Agent that is identical to the existing well-tested, pre-patched, and running Management Agent, then the best option is to clone the existing instance. You can achieve this in GUI as well as in silent mode.

While the Agent Cloning Wizard helps you install in GUI mode, the ZIP format helps you install in silent mode. Understandably, this is a much easier method because you compress the Oracle home of an existing Management Agent and transfer it to the destination host without having to specify any parameters or values in an interview screen, but still retaining all its configuration settings and applied one-off patches.

However, unlike the Agent Cloning Wizard, the ZIP format helps you install only on one destination at any given time. Once you are done with cloning of a Management Agent on a host, you must redo the procedure to clone on another host. You cannot clone on multiple hosts simultaneously. Therefore, this approach is best suited only if you want to clone only on a few destination hosts.

Before You Begin

In addition to the points described in Before You Begin, keep in mind the following:

By default, the cloned Management Agent is not in the secure mode. You must manually secure the Management Agent by running the following command from the Oracle home of the cloned Management Agent:

<Oracle_Home>/bin/emctl secure agent

However, note that even after securing the Management Agent, some data might still be transferred over the network without being encrypted.

Prerequisites

Before cloning a Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 16-1 Prerequisites for Cloning Oracle Management Agent Using ZIP File

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system.If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Existing Management Agent

Ensure that you already have a Management Agent installed in your environment, which can be cloned.

Existing Oracle Management Agent Version Requirements

Ensure that the version of the existing, shared Oracle Management Agent is the same as the one you want to install.

For example, if you want to install Oracle Management Agent 11g Release 1, then ensure that the existing, shared Oracle Management Agent is 11g Release 1.

Existing Oracle Management Agent Platform Requirements

Ensure that the platform of the existing, shared Oracle Management Agent is the same as the host on which you want to install an additional Oracle Management Agent.

For example, if you want to install Oracle Management Agent 11g Release 1 on a Linux host, then ensure that the existing, shared Oracle Management Agent 11g Release 1 is also running on a Linux host.

Existing Oracle Management Agent Status Requirements

Ensure that you shut down the existing Oracle Management Agent before creating the ZIP file of its Oracle home.

Shared Software Binaries Requirements

Ensure that the software binaries of the existing Management Agent are accessible from all the destination hosts where the additional Management Agent needs to be installed.

You can either share the Oracle home of the existing Management Agent or copy the software binaries of that Management Agent to a shared, mounted location that can be accessed from other remote hosts.

Path Validation Requirements

Validate the path to all command locations. For more information, see Appendix E, "Validating Command Locations".

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

For information about oraInventory permissions, see What Is Oracle Inventory Directory?.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). The Agent Clone Wizard uses SUDO to run the root.sh script. You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file present in the OMS Instance Base:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

Agent User Account Permissions and Rights (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that the agent user account has permissions and rights to perform the following:

Act as part of the operating system.

Increase quotas.

Replace process level token.

Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

Launch the Local Security Settings.

From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings.

In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe (For Microsoft Windows)

(For Microsoft Windows) If you are installing the Management Agent on a Microsoft Windows-based platform, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Cloning Procedure

To clone a Management Agent using a ZIP file, follow these steps:

Use the ZIP utility to zip the Oracle home of the Management Agent you want to clone. For example, agent.zip

Use a file transfer utility (for example, FTP) to transfer the ZIP file to the destination host. For example, ftp agent.zip

On the destination host, extract the contents of the ZIP file.

Navigate to $<ORACLE_HOME>/oui/bin/ directory and run the following command:

If you are cloning a Management Agent that was installed along with an OMS, then run the following command:

./runInstaller -clone -forceClone ORACLE_HOME=<Location_to_Agent's_OracleHome> ORACLE_HOME_NAME=<alphanumeric_without_special_characters> -noconfig -silent b_chainedInstall=false oracle.sysman.top.agent:s_installType=AGENT OMS_HOST=<oms_host> OMS_PORT=<oms_port>

For Microsoft Windows platforms, run the setup.exe file.

If you are cloning a Management Agent that was installed as a standalone Management Agent, then run the following command:

./runInstaller -clone -forceClone ORACLE_HOME=<Location_to_Agent's_OracleHome> ORACLE_HOME_NAME=<alphanumeric_without_special_characters> -noconfig -silent OMS_HOST=<oms_host> OMS_PORT=<oms_port>

For Microsoft Windows platforms, run the setup.exe file.

Configure the Management Agent by running the following script:

$<ORACLE_HOME>/bin/agentca -f

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Clone

After you clone, follow the steps described in After You Install.

17 Cloning Oracle Management Agent on Clusters Using ZIP File

This chapter explains how you can clone an existing Oracle Management Agent 11g Release 1 (11.1.0.1.0) to additional nodes of a cluster using a ZIP file. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Cloning Procedure

Note:

If you have a cluster-based environment, then Oracle strongly recommends you to install the Management Agent using the Agent Deployment Wizard as described in Chapter 9, "Installing Oracle Management Agent on a Cluster Using Agent Deployment Wizard".

Overview

The Management Agents installed on the nodes of a cluster are different from the Management Agents installed on standalone hosts. While the Management Agent installed on a standalone host is called a standalone Management Agent, the Management Agent installed on a node of the cluster is called a cluster-based Management Agent.

You can install a cluster-based Management Agent on a cluster using the compressed format (ZIP) of an existing Management Agent.

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before you clone a Management Agent, ensure that you meet the prerequisites described in Prerequisites.

Cloning Procedure

To clone a Management Agent on a cluster, follow these steps:

Use the ZIP utility to zip the Oracle home of the Management Agent you want to clone. For example, agent.zip

Use a file transfer utility (for example, FTP) to transfer the ZIP file to the destination host. For example, ftp agent.zip

On each of the target nodes of the cluster, extract the contents of the ZIP file. Oracle recommends that you maintain the same installation location on all the nodes of the cluster.

On each of the target nodes, navigate to $<ORACLE_HOME>/oui/bin/ directory and run the following command:

If you are cloning a Management Agent that was installed along with an OMS, then run the following command:

./runInstaller -clone -forceClone ORACLE_HOME=<full path of Oracle home> ORACLE_HOME_NAME=<Oracle home name> -noconfig -silent b_chainedInstall=false oracle.sysman.top.agent:s_installType=AGENT OMS_HOST=<oms_host> OMS_PORT=<oms_port>

For Microsoft Windows platforms, run the setup.exe file.

If you are cloning a Management Agent that was installed as a standalone Management Agent, then run the following command:

./runInstaller -clone -forceClone ORACLE_HOME=<full path of Oracle home> ORACLE_HOME_NAME=<Oracle home name> -noconfig -silent OMS_HOST=<oms_host> OMS_PORT=<oms_port>

For Microsoft Windows platforms, run the setup.exe file.

On each of the target nodes, configure the Management Agents by running the following script:

$<ORACLE_HOME>/bin/agentca -f -c "node1, node2, node3...."

Note:

If the installation fails, then review the log files described in Appendix L, "Installation and Configuration Log Files".

After You Clone

After you clone, follow the steps described in After You Install.

Part IV

Advanced Configuration

This part describes the advanced configuration tasks you can perform after you have installed Enterprise Manager Grid Control and have started using the product. These tasks are optional and provide additional functionality for specific types of Oracle Enterprise Manager customers.

In particular, this part contains the following chapters:

Chapter 18, "Introduction to Enterprise Manager Advanced Configuration"

Chapter 19, "Configuring Enterprise Manager for Firewalls"

Chapter 20, "Additional Configuration Tasks"

18 Introduction to Enterprise Manager Advanced Configuration

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

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

Specifically, this chapter includes the following topics:

Types of Advanced Configuration Tasks

Understanding the Enterprise Manager Directory Structure

Enabling Enterprise Manager Accessibility Features

Types of Advanced Configuration Tasks

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

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

Implement Enterprise Manager security and firewall features.

Enable End-User Performance Monitoring for your Web applications.

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

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

Understanding the Enterprise Manager Directory Structure

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

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

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

Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Grid Control 11g Release 1

Understanding the Enterprise Manager Directories Installed with the Management Agent

Identifying the Oracle Home When Using the emctl Command

Understanding the Enterprise Manager Directories Installed with Oracle Enterprise Manager Grid Control 11g Release 1

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

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

Oracle Management Service home directory

Middleware WebTier home directory

Middleware Common home directory

Oracle Management Service Instance home directory

Oracle Management Agent home directory

About the Oracle Management Service Home Directory

The Oracle Management Service is a J2EE application that is installed and deployed using the Oracle WebLogic Server.

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

Information about the directories that are specific to the Fusion Middleware installation can be found in the Fusion Middleware documentation.

About the Oracle Management Agent Home (AGENT_HOME) Directory

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

The Oracle Management Agent is installed in a separate Oracle home directory which is at the same level as the Fusion Middleware home directory.

Summary of the Important Directories in the Oracle Management Service Home

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

Figure 18-1 Directory Structure in the Management Service Home

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

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

Directory
Description

ORACLE_HOME/bin

The bin directory in the Management Service home contains commands used to control the components of the Grid Control installation.

ORACLE_HOME/sysman

The sysman directory in the Management Service home contains the system management files associated with this Grid Control installation.

ORACLE_HOME/config

The config directory contains Management Service configuration files.

ORACLE_HOME/log

This directory contains log files for the Oracle Management Service. The repository log files are under sysman/log/schemamanager.

ORACLE_HOME/emd

The emd directory contains information about targets discovered on hosts.

Understanding the Enterprise Manager Directories Installed with the Management Agent

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

You can install additional Oracle Management Agents using different installation methods. This enables you to install the Oracle Management Agent on the hosts throughout your enterprise. The Oracle Management Agent can then gather management data about the targets on each host so those targets can be managed from the Grid Control Console.

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

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

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

Summary of the Important Directories in the Oracle Management Agent Home

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

Table 18-2 Important Directories in the AGENT_HOME Directory

Directory
Description

AGENT_HOME

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

The default AGENT_HOME location is at the same level as the Middle Ware home.

This directory serves as the Oracle Home for the Oracle Management Agent.

AGENT_HOME/bin

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

You use the following emctl commands in this directory to start and stop the Oracle Management Agent on this host:

<agent_home>/bin/emctl start agent
<agent_home>/bin/emctl stop agent

AGENT_HOME/sysman/admin

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

AGENT_HOME/sysman/config

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

AGENT_HOME/sysman/log

This directory contains the log files for the Oracle Management Agent.

AGENT_HOME/hostname

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

Understanding the Oracle Management Agent Directory Structure on Windows

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

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

$PROMPT> E:\oracle\em11gAgent\bin

Identifying the Oracle Home When Using the emctl Command

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

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

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

$PROMPT> emctl getemhome

This command displays the path to the current Oracle home that will be affected by commands executed by this instance of the emctl command.

Enabling Enterprise Manager Accessibility Features

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

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

Enabling Enterprise Manager Accessibility Mode

Providing Textual Descriptions of Enterprise Manager Charts

Enabling Enterprise Manager Accessibility Mode

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

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

Locate the uix-config.xml configuration file.

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

./oms11g/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/uix-config.xml

Open the uix-config.xml file using a text editor and locate the following entry:

<!-- An alternate configuration that disables accessibility features  -->
<default-configuration>
  <accessibility-mode>inaccessible</accessibility-mode>
</default-configuration>

Change the value of the accessibility-mode property from inaccessible to accessible.

Save and close the file.

Restart the Oracle Management Service.

Providing Textual Descriptions of Enterprise Manager Charts

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

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

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

Figure 18-2 Icon Representing the Textual Representation of a Chart

Description of Figure 18-2 follows
Description of "Figure 18-2 Icon Representing the Textual Representation of a Chart"

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

Locate the web.xml configuration file.

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

./oms11g/sysman/archives/emgc/deployments/EMGC_DOMAIN/emgc.ear/em.war/WEB-INF/web.xml

Open the web.xml file with your favorite text editor and locate the following six lines of the file:

<!-- Uncomment this to enable textual chart descriptions
<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>
-->

Remove comments from this section by deleting the first line and the last line of this section so that the section consists of only these 4 lines:

<context-param>
<param-name>enableChartDescription</param-name>
<param-value>true</param-value>
</context-param>

Save and exit the file.

Restart the Oracle Management Service.

19 Configuring Enterprise Manager for Firewalls

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

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

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

See Also:

Refer to the Enterprise Manager Administration Guide for more information about some of the ways you can configure the Grid Control components on your network.

This chapter contains the following topics:

Considerations Before Configuring Your Firewall

Firewall Configurations for Enterprise Management Components

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

Considerations Before Configuring Your Firewall

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

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

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

See Also:

Refer to the Enterprise Manager Administration Guide for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent.

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

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

Firewall Configurations for Enterprise Management Components

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

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

Firewalls Between Your Browser and the Grid Control Console

Configuring the Management Agent on a Host Protected by a Firewall

Configuring the Management Service on a Host Protected by a Firewall

Firewalls Between the Management Service and the Management Repository

Firewalls Between the Grid Control and a Managed Database Target

Firewalls Used with Multiple Management Services

Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

Configuring Firewalls When Managing Oracle Application Server

Figure 19–1 provides a topology of an Enterprise Manager grid environment that is using a firewall, and also illustrates the default ports that can be used.

Figure 19-1 Firewall Port Requirements (Default)

Description of Figure 19-1 follows
Description of "Figure 19-1 Firewall Port Requirements (Default)"

The conventions used in the preceding illustration are as follows:

Table 19-1 Conventions Used

Convention
Description

C

Is the entity that is making the call.

*

Enterprise Manager will default to the first available port within an Enterprise Manager set range.

**

Enterprise Manager will default to the first available port.

***

Are the Database listener ports.

Note:

The direction of the arrows specify the direction of ports.

Port 1159, 4898-4989 specify that 1159 is the default. If this port is not available, the Management Service will search in the range that is specified.

To clone between two target hosts separated by a firewall, the agents will need to communicate to each other on the agent ports. The initiating agent will make the call.

Firewalls Between Your Browser and the Grid Control Console

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

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

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

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

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

See also:

Oracle Application Server 10g Security Guide

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

Figure 19-2 Firewall Between Your Browser and the Grid Control Console

Description of Figure 19-2 follows
Description of "Figure 19-2 Firewall Between Your Browser and the Grid Control Console"

Figure 19-3 Firewall Between Your Browser and the Grid Control Console

Description of Figure 19-3 follows
Description of "Figure 19-3 Firewall Between Your Browser and the Grid Control Console "

Configuring the Management Agent on a Host Protected by a Firewall

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

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

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

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

Figure 19-4 Configuration Tasks When the Management Agent Is Behind a Firewall

Description of Figure 19-4 follows
Description of "Figure 19-4 Configuration Tasks When the Management Agent Is Behind a Firewall"

Figure 19-5 Configuration Tasks When the Management Agent is Behind a Firewall

Description of Figure 19-5 follows
Description of "Figure 19-5 Configuration Tasks When the Management Agent is Behind a Firewall"

Configuring the Management Agent to Use a Proxy Server

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

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

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

Locate the following entry in the emd.properties file:

# If it is necessary to go through an http proxy server to get to the
# repository, uncomment the following lines
#REPOSITORY_PROXYHOST=
#REPOSITORY_PROXYPORT=

To enable support for authenticating the proxy server, the following additional properties need to be specified.

#REPOSITORY_PROXYREALM=
#REPOSITORY_PROXYUSER=
#REPOSITORY_PROXYPWD=

Edit the following properties by removing the pound sign (#) at the start of each line and entering a value as follows:

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

For example:

REPOSITORY_PROXYHOST=proxy42.acme.com
REPOSITORY_PROXYPORT=80
REPOSITORY_PROXYREALM=
REPOSITORY_PROXYUSER=
REPOSITORY_PROXYPWD=

Save your changes and close the emd.properties file.

Stop and start the Management Agent.

Note:

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

Configuring the Firewall to Allow Incoming Communication From the Management Service

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

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

See Also:

Refer to the Enterprise Manager Administration Guide for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent.

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

See Also:

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

Configuring the Management Service on a Host Protected by a Firewall

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

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

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

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

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

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

Description of Figure 19-6 follows
Description of "Figure 19-6 Configuration Tasks When the Management Service Is Behind a Firewall"

Figure 19-7 Configuration Tasks When the Management Service is Behind a Firewall

Description of Figure 19-7 follows
Description of "Figure 19-7 Configuration Tasks When the Management Service is Behind a Firewall"

Configuring the Management Service to Use a Proxy Server

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

To configure the Management Service to use a proxy server, do the following:

Set the properties by using the following command:

OMS_Home/bin/emctl set property -name <property name> -value <property value>

Stop and start the Management Service:

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

About the dontProxyfor Property

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

For example, suppose the following were true:

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

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

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

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

http://metalink.oracle.com

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

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

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

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

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

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

Administrators can also change the upload port after the installation.

See Also:

Refer to the Enterprise Manager Administration Guide for information about locating and changing the default ports for the Oracle Management Service and the Oracle Management Agent.

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

See Also:

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

Firewalls Between the Management Service and the Management Repository

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

See Also:

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

Figure 19-8 shows a typical configuration of a firewall between the Management Service and the Management Repository.

Figure 19-8 Firewall Between the Management Service and the Management Repository

Description of Figure 19-8 follows
Description of "Figure 19-8 Firewall Between the Management Service and the Management Repository"

Firewalls Between the Grid Control and a Managed Database Target

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

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

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

See Also:

Oracle Database Advanced Security Administrator's Guide

Figure 19-9 shows a typical configuration of a firewall between the Management Service and the Management Repository.

Figure 19-9 Firewall Between the Grid Control and a Managed Database Target

Description of Figure 19-9 follows
Description of "Figure 19-9 Firewall Between the Grid Control and a Managed Database Target"

Figure 19-10 Firewall Between Grid Control and Managed Database Target

Description of Figure 19-10 follows
Description of "Figure 19-10 Firewall Between Grid Control and Managed Database Target"

Firewalls Used with Multiple Management Services

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

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

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

See Also:

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

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

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

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

See Also:

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

Configuring Firewalls to Allow ICMP and UDP Traffic for Beacons

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

See Also:

"About Service Level Management" in the Enterprise Manager Online Help

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

Enabling ICMP Echo Requests on Firewalls

The Management Service uses the ICMP Echo Request to check the status of the machine. If the ICMP Echo Request is blocked by the firewall, the machine will be appear to be down. To determine the status of any machine in the environment, ICMP Echo Requests must be enabled on the firewall. If the ICMP Echo Request is enabled, the ping command can be issued by the Management Service to check the status of the machine.

Configuring Firewalls When Managing Oracle Application Server

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

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

See Also:

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

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

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

When you install Oracle Enterprise Manager 11g Grid Control, you can view a list of the ports assigned during the application server installation either by doing either of the following:

Running the OMS_Home/bin/emctl status oms -details [-sysman_pwd <pwd>] command

Checking the <EM_Instance_Home>/emgc.properties file.

Additional Considerations for Windows XP

For secure agent install, ensure that the firewall settings are disabled for HTTP/HTTPS communication for Windows XP by running the following commands on the Management Agent machine:

Go to Start, and then select Control Panel.

In Control Panel, click Windows Firewall.

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

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

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

20 Additional Configuration Tasks

This chapter contains the following sections:

Understanding Default and Custom Data Collections

Enabling Multi-Inventory Support for Configuration Management

Manually Configuring a Database Target for Complete Monitoring

Modifying the Default Login Timeout Value

Configuring Clusters and Cluster Databases in Grid Control

Collecting Client Configurations

Configuring Privilege Delegation Providers

Understanding Default and Custom Data Collections

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

See Also:

About Alerts in the Enterprise Manager online help

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

How Enterprise Manager Stores Default Collection Information

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

AGENT_HOME/sysman/admin/default_collection/

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

AGENT_HOME/sysman/emd/collection/

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

Enabling Multi-Inventory Support for Configuration Management

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

See Also:

Oracle Universal Installer and OPatch User's Guide

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

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

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

Caution:

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

To set up Enterprise Manager so it can read multiple inventories on a host, follow these steps:

Locate the OUIinventories.add file in the following directory:

$ORACLE_HOMEsysman/config

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

Open OUIinventories.add using a text editor.

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

Carefully review the instructions within the file.

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

Save your changes and close the file.

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

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

Note:

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

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

AGENT_HOME Versus AGENT_STATE Directories

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

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

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

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

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

Manually Configuring a Database Target for Complete Monitoring

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

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

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

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

See Also:

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

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

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

See Also:

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

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

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

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

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

For example:

$PROMPT> ./sqlplus "connect / as sysdba"

Enter the following command to run the database dbmon script:

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

The script will display the following prompt:

Enter value for dbm_password:

When prompted, enter the password for the DBSNMP account.

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

Connect as the DBSNMP user.

For example:

SQL> connect DBSNMP

Enter the following command:

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

Note:

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

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

SQL> @ORACLE_HOME/rdbms/admin/spcreate

Note:

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

Connect as the PERFSTAT user.

For example:

SQL> connect PERFSTAT;

Enter the following commands from the PERFSTAT user account:

SQL> define snap_level='6';
SQL> define cinterval='1';
SQL> define cjobno='-1';
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/spset

Connect as the SYS user and enter the following command:

SQL> grant OEM_MONITOR to dbsnmp;

If the database you are modifying is an Oracle8i database, also enter the following commands as the SYS user:

grant select on sys.ts$ to OEM_MONITOR;grant select on sys.seg$ to OEM_MONITOR;grant select on sys.user$ to OEM_MONITOR;grant select on sys.obj$ to OEM_MONITOR;grant select on sys.sys_objects to OEM_MONITOR;grant select on sys.file$ to OEM_MONITOR;grant select on sys.attrcol$ to OEM_MONITOR;grant select on sys.clu$ to OEM_MONITOR;grant select on sys.col$ to OEM_MONITOR;grant select on sys.ind$ to OEM_MONITOR;grant select on sys.indpart$ to OEM_MONITOR;grant select on sys.indsubpart$ to OEM_MONITOR;grant select on sys.lob$ to OEM_MONITOR;grant select on sys.lobfrag$ to OEM_MONITOR;grant select on sys.partobj$ to OEM_MONITOR;grant select on sys.tab$ to OEM_MONITOR;grant select on sys.tabpart$ to OEM_MONITOR;grant select on sys.tabsubpart$ to OEM_MONITOR;grant select on sys.undo$ to OEM_MONITOR;

For any supported database version, enter the following command from the SYS account:

SQL> show parameter job_queue_processes

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

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

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

Otherwise, do the following:

Enter the following command:

SQL> alter system set job_queue_processes = 2;

Exit SQL*PLUS and update the init.ora database configuration file with the following entry so the parameter will be applied whenever the database is restarted:

job_queue_processes=2

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

AGENT_HOME/bin

Reload the Management Agent by entering the following command:

$PROMPT> ./emctl agent reload

Using the Grid Control console, return to the Database home page and verify that the Bad SQL and Top SQL Report metrics are now being gathered.

Modifying the Default Login Timeout Value

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

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

Caution:

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

To increase or decrease the default timeout period:

Change directory to the following location in the Fusion Middleware home directory where the Management Service was deployed:

IAS_HOME/sysman/config/

Using your favorite text editor, open the emoms.properties file and add the following entry:

oracle.sysman.eml.maxInactiveTime=time_in_minutes

For example, if you want to change the default timeout period to one hour, add the following entry:

oracle.sysman.eml.maxInactiveTime=60

Save and close the emoms.properties file.

Restart the Management Service.

Note:

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

Configuring Clusters and Cluster Databases in Grid Control

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

Configuring Clusters

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

Click All Targets from the Targets page.

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

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

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

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

See Also:

The Enterprise Manager online help for more information about configuring clusters

Configuring Cluster Databases

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

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

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

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

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

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

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

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

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

Provide the required values for the Properties table.

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

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

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

See Also:

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

Discovering Instances Added to the Cluster Database

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

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

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

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

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

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

Click Check Connection to ensure that the connection is working.

See Also:

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

Troubleshooting

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

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

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

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

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

Collecting Client Configurations

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

Hardware for the client.

Operating system (includes information such as operating system properties, file systems, and patches) for the client.

Operating system-registered software.

Network data, which includes:

Latency to the Web server

Bandwidth to the Web server

Client-specific data items that describe the configuration of the browser used to access the client configuration collection applet, which includes:

Browser type (vendor)

Browser version

JVM vendor (of the JVM used to run the client configuration collection applet)

JVM version (of the JVM used to run the client configuration collection applet)

Proxy server (if specified)

Proxy server exceptions

Browser cache size (MB)

Browser cache update frequency

Supported HTTP version

Other client-oriented data items, including: 

Client configuration collection applet identifier (version, defined in the applet code)

Application URL (from which the client configuration collection applet was accessed)

Boot drive serial number (not available from diskless systems)

Collection timestamp (from the client configuration collection applet JSP)

Collection durations, in milliseconds

Client IP address

Effective client IP address - if a network proxy server is being used between the client and the Web server providing the client configuration collection applet, the effective client IP address will be the IP address of the proxy server.

Configuring the Client System Analyzer

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

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

Client System Analyzer in Oracle Grid Control

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

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

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

Deploying Client System Analyzer Independently

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

Download the CSA Application:

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

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

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

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

Deploy CSA to any J2EE Web server.

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

Direct users to the CSA.

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

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

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

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

Configure Enterprise Manager.

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

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

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

Test the CSA Deployment.

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

Configuration Parameters

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

Table 20-1 Configuration Parameters

Parameter
Description
Default Value

alertWhenDone

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

false

appletJAR

The name of the JAR file.

CSA.jar

application

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

none

autoRedir

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

false

bwTestFile

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

CSA.mb (included with CSA)

bwTestMsec

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

200 ms

classid

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

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

codebase

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

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

collectCookie

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

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

cookieDomain

The domain of the CSA cookie.

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

cookieMaxAge

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

1 year

cookiePath

The path of the CSA cookie

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

customClass

The name of the class used to collect custom data.

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

customKey1customKey2customKey3

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

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

descriptionFile

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

None

destURL

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

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

destURLResultsParam

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

Sun

JVM

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

Sun

maxExecInterval

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

90 days

maxFileSize

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

100

maxOutputFiles

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

100

outputDir

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

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

outputEnabled

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

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

pluginspage

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

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

receiver

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

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

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

ruleFile

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

rules.xml

script

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

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

type

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

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

viewData

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

false

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

Table 20-2 Configuration Parameters

Parameter Name
Description
Default Value

csaURL

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

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

execInterval

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

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

redirectURL

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

None.

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

UIMode

0 - synchronous (in the current browser window)

1 - asynchronous visible

2 - asynchronous invisible

synchronous

Associating the Parameters with an Application

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

Rules

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

Example 20-1 Sample RULES

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

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

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

Table 20-3 Tags in the RULES File

Tag Name
Description

RULES

This is the top-level tag for the XML file

BUNDLE

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

PRECONDITION

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

RULE

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

NAME

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

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

DESCRIPTION

This is the description of the rule.

VIOLATION

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

SEVERITY

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

PARAM

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

MOREINFO

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

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

TEXT

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

ARG

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

See Also:

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

Customization

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

CSA Deployment Examples

The following sections outline sample use cases for client configurations.

Using Multiple Collection Tags

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

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

Create two separate rule files, one for each application.

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

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

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

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

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

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

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

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

Privilege Model for Viewing Client Configurations

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

Using the Customization API Example

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

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

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

Example 20-3 Customization API

public interface CSACustomInterface {

    /**
     * requires: none
     * effects: returns a CSAResultInterface object that may contain custom
     * properties. Other effects are determined by the customActions method
     * in the implementing class
     * modifies: unknown - dependent on implementing class.
     * @param inputData contains client config data collected by default, plus
     * applet parameters, etc.None of the data in the inputData is guaranteed
     * to be there as there could have been collection errors.
     * @return a data structure that may contain custom properties
     */
    CSAResultInterface customActions(CSAInputInterface inputData);
}

public interface CSAResultInterface {

    /**
     * requires: none
     * effects: returns an array of custom properties
     * modifies:none
     * @return String[][7] where ...
     *
     * String[i][0] is a name
     * String[i][1] is a value of the i-th row. (Type and name must be unique.)
     * String[i][2] is a type/category of data (could be null),
     * String[i][3] is the displayed value of the name of the property
     * String[i][4] is the displayed value of the type of the property
     * String[i][5] indicates data item (ie "Y") whose history should be computed
     * String[i][6] indicates data item (ie "Y") should be displayed in default UI
     */
    String[][] getResultsData();
}

public interface CSAInputInterface {

    /**
    * Get data value for given name
    * requires: name is not null
    * effects: returns the data value associated with the name
    * modifies: none
    * @param name the name of the key whose value is to be returned
    * @return the value assocaited with name
    *
    */
    String getDataValue(String name);

    /**
    * Get table-formatted data.
    * requires: name is not null
    * effects: returns the table with this name
    * modifies: none
    * @param name the name of the table
    * @return the rows of the child tables
    *
    */
    CSAInputInterface[] getDataTable(String name);
}

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

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

Using the CSA Servlet Filter Example

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

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

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

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

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

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

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

<context-param>
  <param-name>csa execInterval</param-name>
  <param-value>2592000</param-value>
</context-param>

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

Sample Deployments

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

Example 1: Helpdesk

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

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

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

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

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

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

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

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

Example 2: Inventory

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

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

Example 20-4 Inventory Code

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

<context-param>
  <param-name>csa execInterval</param-name>
  <param-value>2592000</param-value>
</context-param>

<context-param>
  <param-name>csa uiMode</param-name>
  <param-value>2</param-value>
</context-param>

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

Example 3: Problem Detection

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

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

Example 20-5 Context Parameter Values for CSA Servlet Filter

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

<context-param>
  <param-name>csa execInterval</param-name>
  <param-value>2592000</param-value>
</context-param>

<context-param>
  <param-name>csa uiMode</param-name>
  <param-value>0</param-value>
</context-param>

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

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

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

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

Configuring Privilege Delegation Providers

A privilege delegation provider is defined as a program that allows a logged in user to perform an activity with the privileges of another user. Typically, the privileges that are granted to a specific user are administered centrally.

Enterprise Manager preferred credentials allow you to use two types of privilege delegation providers:

Sudo

Sudo allows a permitted user to execute a command as the super user or another user, as specified in the sudo user administration file (sudoers). If the invoking user is root or if the target user is the same as the invoking user, no password is required. Otherwise, sudo requires that users authenticate themselves with a password by default.

Note:

(In the default configuration, this is the user's password, not the root password.

Sudo determines who is an authorized user by consulting the file /etc/sudoers file. Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in the sudoers file).

PowerBroker

Symark PowerBroker enables UNIX system administrators to specify the circumstances under which other users may run certain programs such as root (or other important accounts). The result is that responsibility for such actions as adding user accounts, fixing line printer queues, and so on, can be safely assigned to the appropriate people, without disclosing the root password. The full power of root is thus protected from potential misuse or abuse. For example, modifying databases or file permissions, or erasing disks.

Symark PowerBroker can access existing programs as well as its own set of utilities that execute common system administration tasks. Utilities being developed to run on top of Symark PowerBroker can manage passwords, accounts, backups, line printers, file ownership or removal, rebooting, logging people out, killing their programs, deciding who can log in to where from where, and so on. They can also provide TCP/IP, Load Balancer, cron, NIS, NFS, FTP, rlogin, and accounting subsystem management. Users can work from within a restricted shell or editor to access certain programs or files as root.

For additional information about Sudo or PowerBroker, see their respective product documentation.

Using Enterprise Manager's command line interface (EMCLI), you can set/edit privilege delegation provider properties for a host. See the Oracle Enterprise Manager Command Line Interface guide for more information. See your privilege delegation provider documentation for detailed setup and configuration information.

Creating a Privilege Delegation Setting

A privilege delegation setting can be created using the EM CLI command line interface's create_privilege_delegation_setting verb.

You can also configure a host with a Privilege Delegation setting, apply a Privilege Delegation setting template or unconfigure the Privilege Delegation setting by clicking Setup on the Enterprise Manager home page and then choosing Manage Privilege Delegation Settings from the left menu panel.

Creating a Sudo Setting Using EMCLI

Use the create_privilege_delegation_setting EMCLI verb to create a sudo privilege delegation setting. For explicit syntax and examples, see EMCLI command line help or the Oracle Enterprise Manager Command Line Interface guide.

Variables

You can used the following variables when using EMCLI to set the privilege delegation settings. Variables are case-sensitive.

Variable | Definition
%RUNAS% | Run the command as this user.
%USERNAME% | Name of the user running the command.
%COMMAND% | Sudo Command

Syntax

emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS:<command to be used with all the options>"

The following example illustrates using EMCLI to create a sudo setting. Here, sudo is installed in /opt/sudo/bin.

Example 20-7 Using EMCLI to Create a Sudo Setting

>emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS:/opt/sudo/bin/sudo –S –u %RUNAS% %command%"

Creating a PowerBroker Setting Using EMCLI

Use the create_privilege_delegation_setting EM CLI verb to create a PowerBroker privilege delegation setting.

Variables

You can used the following variables when using EMCLI to set the privilege delegation settings. Variables are case-sensitive.

Variable | Definition
%RUNAS% | Run the command as this user.
%USERNAME% | Name of the user running the command.
%COMMAND% | Sudo Command
%PROFILE% | Use this profile to run the command

Syntax

>emcli create_privilege_delegation_setting -setting_name=powerbroker_setting_1 -setting_type=POWERBROKER -settings="SETTINGS:<command to be used with all the options>;[PASSWORD_PROMPT_STRING,<password prompt for PowerBroker>]"

Example 20-8 Using EMCLI to Create a Sudo Setting

./emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS: /opt/powerbroker/bin/pbrun –u %RUNAS% %command%"

Note:

In this example, PowerBroker is installed in /opt/powerbroker directory and its password prompt is "Password:".

Applying Privilege Delegation Settings

Once you have created a privilege delegation setting, you must apply this setting to selected targets. As with the setting creation process, you use EMCLI to apply the privilege delegation setting to specified targets. The setting can be applied to one or more hosts or to a composite (Group) target (the group must contain at least one host target).

You can also apply a Privilege Delegation setting using the Grid Control console by clicking Setup on the Enterprise Manager Home page and then choosing Manage Privilege Delegation Settings from the left menu panel.

Applying Settings to Host Targets Using EMCLI

Use the apply_privilege_delegation_setting EMCLI verb to apply privilege delegation settings to a host target.

Syntax

emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=host -target_names="host1;host2;..." -input_file="FILE:hosts.txt" -force="yes/no"

To apply privilege delegation properties to a large number of hosts, you can specify a file containing all hosts by using the -input_file option in place of the -target_names option, as shown in the following example.

Example 20-9 Using EMCLI to Apply Privilege Delegation Settings to a Host Target

./emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=host -input_file="FILE: /mydirectory/file.txt" -force=yes

Applying Settings to a Composite Target

Use the apply_privilege_delegation_setting EMCLI verb to apply privilege delegation settings to a composite (group) target.

Syntax

emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -target_names="group" -force="yes/no"

Example 20-10 Using EMCLI to Apply Privilege Delegation Settings to a Composite Target

./emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -input_file="FILE: /mydirectory/file.txt" -force=yes

Once the setting has been applied successfully to host targets, you can set their preferred credentials using EMCLI or through the Grid Control console.

Disabling Host Privilege Delegation Provider Settings Using EMCLI

To disable a privilege delegation setting, an administrator can create a new setting with disabled status and can apply it to the targets. This disabled setting can be applied to any privilege delegation provider (Sudo/PowerBroker). It will remove the setting from the host.

Create a new privilege delegation setting.

./emcli create_privilege_delegation_setting -setting_name= disabled_setting -setting_type=SUDO –disabled=yes

Apply the new setting to one or more targets.

./emcli apply_privilege_delegation_setting -setting_name= disabled_setting -target_type=host  -target_names="host1;host2;..."  -force=yes

Sudo Configuration: Sudoers File

Enterprise Manager uses a trust-based model that permits specification of responsibilities with a high degree of granularity. Administrators can set up sudo or pbrun configuration entries to assign specific Enterprise Manager functional privileges to their OS users. A new executable has been introduced in the Management Agent called nmosudo. Administrators will be able to configure sudo/pbrun such that a less privileged user can run nmosudo as a more privileged user.

In the following example, if an administrator wants user 'joe' to run any Enterprise Manager job as user 'oracle', the corresponding entry in the /etc/sudoers file would be:

(JOB_USERS) ALL : (RUNAS_USERS) AGENT_HOME /bin/nmosudo *

Where 'joe' would be in the JOB_BACKUP_USERS list and 'oracle' would be in the RUNAS_USERS list.

Enterprise Manager will guarantee that the nmosudo executable will only honor requests to run remote operation requests from the OMS via the Agent. nmosudo will not run the remote operation if it cannot validate that the request came from the Agent. Thus, as shown in the example above, it will not be possible for user 'joe' to invoke nmosudo directly from the command line and run a Perl script as user 'oracle'.

Note:

To ensure system security, the administrator must provide the full path to the nmosudo executable.

Configuring Privilege Delegation Providers Using Grid Control Console

Enterprise Manager Grid Control allows you to configure Privilege Delegation Providers through functionality provided through its user interface. Using Grid Control, you can avoid the command line interface while performing essentially the same functions.

The following sections describe the functions you can perform using the Grid Control interface.

Configuring Sudo Settings For a Host Using Enterprise Manager Grid Control Console

You can use Enterprise Manager to create a Sudo setting by using the Grid Control console. You can create privilege delegation settings either by creating the setting directly on a host target, or by creating a PDP setting template that you can apply to multiple hosts.

To create a privilege delegation Sudo setting directly on a host, follow these steps:

Navigate to the Manage Privilege Delegation Settings page. Setup-->Manage Privilege Delegation Settings

For any host target appearing in the table, click Edit. Enterprise Manager takes you to the Host Privilege Delegation Setting page

Select the Sudo privilege delegation type

Enter the privilege delegation command to be used

Click Update to apply the settings to the host

Figure 20-1 shows the Host Privilege Delegation Setting window that you can use to create a Sudo setting.

Figure 20-1 Host Privilege Delegation Setting for Sudo

Note:

If the host has been configured with either the Sudo or Powerbroker setting, choosing None on this page will remove (or disable) the setting.

Configuring PowerBroker Settings For a Host Using the Grid Control Console

You can create privilege delegation settings either by creating the setting directly on a host target, or by creating a PDP setting template that you can apply to multiple hosts.

To create a privilege delegation PowerBroker setting directly on a host, follow these steps:

Navigate to the Manage Privilege Delegation Settings page. Setup-->Manage Privilege Delegation Settings

For any host target appearing in the table, click Edit. Enterprise Manager takes you to the Host Privilege Delegation Setting page

Select the PowerBroker privilege delegation type

Enter the privilege delegation command to be used and the optional Password Prompt

Click Update to apply the settings to the host

Figure 20-2 shows the Host Privilege Delegation Setting window that you can use to create a PowerBroker setting.

Figure 20-2 Host Privilege Delegation Setting for PowerBroker

Note:

If the host has been configured with either the Sudo or Powerbroker setting, choosing None on this page will remove (or disable) the setting.

Applying Settings to Multiple Host Targets Using the Grid Control Console

You apply Privilege Delegation settings to a target using Privilege Delegation setting templates. If no template with the desired Privilege Delegation settings exists, you must first create the template on the Manage Privilege Delegation Settings Template page as seen in Figure 20-3.

To create a template, follow these steps:

Navigate to the Manage Privilege Delegation Settings page. Setup-->Manage Privilege Delegation Settings

From the Related Links section, click Manage Privilege Delegation Setting Templates

Select a privilege delegation type (Sudo or PowerBroker) and click Go

Fill in the requisite privilege delegation setting information

Click Save

If the desired privilege delegation settings template already exists, you need only apply the template to the desired host(s). To apply the template to the hosts, follow these steps:

Navigate to the Manage Privilege Delegation Settings page. Setup-->Manage Privilege Delegation Settings

Select the desired privilege delegation settings template from the Apply drop-down menu

Click Go to access the Apply Settings page

Add the targets (hosts) to which you want to apply the privilege delegation settings template

Click Apply. Enterprise Manager displays the Past Apply Operations page where you can view the queue of scheduled apply operations along with those that are scheduled/pending. From this page, you can Stop or Delete apply operations

You can also apply privilege delegation settings from the Manage Privilege Delegation Setting Templates page as seen in Figure 20-3.

Figure 20-3 Manage Privilege Delegation Settings Template Window

Disabling Host Privilege Delegation Provider Settings For One or More Hosts Using Grid Control Console

You can disable a Privilege Delegation setting using the Grid Control console. To disable a privilege delegation setting using this method, follow these steps:

Click Setup to access the Enterprise Manager Configuration page

From the left menu, click Manage Privilege Delegation Settings

Grid Control displays the Manage Privilege Delegation Settings Page seen in Figure 20-4.

Figure 20-4 Manage Privilege Delegation Settings Page

Select the host(s) from which to clear the privilege delegation settings

Click Clear. Enterprise Manager asks you whether to proceed with the privilege setting disable operation

Click Yes

Part V

Upgrading Enterprise Manager System

This part describes the different ways of upgrading Enterprise Manager Grid Control.

In particular, this part contains the following chapters:

Chapter 21, "Upgrading to Enterprise Manager 11g"

Chapter 22, "Upgrading Enterprise Manager System with Add-Ons Installed in Graphical Mode"

Chapter 23, "Upgrading Enterprise Manager System with Add-Ons Installed in Silent Mode"

21 Upgrading to Enterprise Manager 11g

This chapter describes how you can use silent mode to upgrade Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0), and how you can upgrade Oracle Management Service 10g Release 4 (10.2.0.4.0) to Oracle Management Service 11g Release 1 (11.1.0.1.0).

In particular, this chapter covers the following:

Overview

Prerequisites

Upgrade Procedure

After You Upgrade

Note:

If Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher has add-ons installed, then do NOT follow the instructions outlined in this chapter. Instead, follow the instructions outlined for upgrading Enterprise Manager Grid Control with add-ons installed in Part V, "Upgrading Enterprise Manager System".

And if you want to upgrade standalone Management Agents, then see the upgrade chapters described in Part VI, "Upgrading Oracle Management Agent".

Note:

If you have Enterprise Manager 10g Grid Control Release 1 (10.1) or Enterprise Manager 10g Grid Control Release 3 (10.2.0.3) or lower, then you must first upgrade or patch them to Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, before upgrading them directly to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0). For information about upgrading or patching them to Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, see My Oracle Support note 1076420.1.

After upgrading or patching them to Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or higher, follow the instructions outlined in this chapter to upgrade them to Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0).

Overview

You can upgrade an existing Enterprise Manager Grid Control or Oracle Management Service (OMS) in silent mode using the response file upgrade.rsp. Using the response file is only an alternative to using the GUI-rich screens offered by the installer to upgrade a previous release of Enterprise Manager Grid Control. The response file captures all the required information that the installer captures, and performs exactly the same function as the installer. This is an out-of-place upgrade where the Oracle homes of the previous release are left intact and new Oracle homes for 11g Release 1 are created.

The following are the functions performed by the response file:

Upgrades Oracle Management Service 10g Release 4 (10.2.0.4.0) or higher

Upgrades Oracle Management Agent 10g Release 4 (10.2.0.4.0) or higher that was installed by default with Oracle Management Service 10g Release 4 (10.2.0.4.0)

Installs Oracle Web Tier 11g Release 1

Note:

If you have multiple OMSes connecting to one Management Repository, stop all the OMSes and upgrade the first OMS using the installer. When you upgrade the first OMS, the installer also upgrades the Management Repository, and since the other OMSes connect to the same Management Repository, they must also be stopped.

Stopping the Management Agents is not mandatory, and as a result, there may be an increase in the number of Agent-related log files. However, this is harmless and can be ignored.

Once that OMS is upgraded, invoke the installer again, and select and upgrade all other OMSes, which connect to the same Management Repository, so that they are upgraded simultaneously. Ensure that Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1) is installed on every host where the OMS is being upgraded. For information on installing Oracle WebLogic Server, see My Oracle Support note 1063762.1.

This upgrade process does NOT do the following:

Does NOT upgrade Oracle Management Agent 10g Release 4 (10.2.0.4.0) or higher that was NOT installed by default with Oracle Management Service 10g Release 4 (10.2.0.4.0).

To upgrade such Management Agents, use the Agent Upgrade Wizard available in the Grid Control console.

Does NOT upgrade your existing Oracle Database where the Management Repository is configured.

To upgrade such databases, use the database upgrade tool. For more information, on the upgrade tool, see the Oracle Database Upgrade Guide available at:

http://www.oracle.com/technology/documentation/database.html

Before You Begin

If you are upgrading the installation type Enterprise Manager Grid Control Using a New Database or Enterprise Manager Grid Control Using an Existing Database of 10g Release 4 (10.2.0.4) or higher, then before you begin, keep in mind the points described in Before You Begin.

If you are upgrading the installation type Additional Oracle Management Service of 10g Release 4 (10.2.0.4) or higher, then meet the prerequisites described in Before You Begin.

Prerequisites

Before upgrading to Enterprise Manager 11g in silent mode, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 21-1 Prerequisites for Upgrading to Enterprise Manager 11g in Silent Mode

Requirement
Description
Yes/No

Basic Prerequisites

The basic prerequisites for upgrading Enterprise Manager Grid Control depend on the installation type that is being upgraded.

If you are upgrading the installation types Enterprise Manager Grid Control Using a New Database or Enterprise Manager Grid Control Using an Existing Database of 10g Release 4 (10.2.0.4) or higher, then meet the prerequisites described in Prerequisites. One of the most important prerequisite is to install Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1).

Important: In Prerequisites, one of the prerequisites is to ensure that the existing database does not have any Management Repository configured. However, for upgrade, ignore this prerequisite because while upgrading, the existing Management Repository will be reused.

If you are upgrading the installation type Additional Oracle Management Service of 10g Release 4 (10.2.0.4) or higher, then meet the prerequisites described in Prerequisites. One of the most important prerequisite is to install Oracle WebLogic Server 10.3.2 (Oracle Fusion Middleware 11g Release 1 Patch Set 1).

Existing Management Repository

Ensure that the existing, certified Oracle Database already has a Management Repository configured, and that the Management Repository is compatible with Oracle Management Service 11g Release 1 (11.1). For more information, refer to My Oracle Support note 412431.1.

Existing Database Backup and OMS Backup Requirements

Ensure that you back up the existing, certified Oracle Database (which houses the Management Repository), the Oracle home of the OMS, the Oracle home of the Management Agent (which was installed along with the OMS), and the Oracle Inventory directory. This helps you maintain a copy of the database, the Oracle home, and the inventory details that were existing before the environment was upgraded, and it naturally offers the scope to revert to it whenever you want.

Database Partitioning Requirements

Ensure that the existing Oracle Database, which houses the Management Repository, has the Partitioning Option enabled (therefore, ensure that you install it into Oracle Database Enterprise Edition.)

To verify this, connect to the database as SYSDBA and run the following query:

SQL> select value from v$option where parameter = 'Partitioning';

The result of this query should be VALUE=TRUE. No additional partitioning license is required for the database that houses the Management Repository.

Database Partition Maintenance Requirements

If the Enterprise Manager system that you are about to upgrade was shut down for a long period of time, then you will not have partitions created in the existing, certified Oracle Database, which houses the Management Repository, to load new data. Therefore, under such circumstances, do the following:

Log in to the database as SYSMAN and run the following command:

execute emd_maintenance.analyze_emd_schema('SYSMAN');

commit;

Restart the OMS from its Oracle home:

$<ORACLE_HOME>/bin/emctl start oms

Database and Listener Status Requirements

Ensure that the existing, certified Oracle Database and its listener are running.

Valid Objects Requirements

Ensure that you do have only valid SYSMAN and SYS objects in the existing, certified Oracle Database.

To verify whether there are only valid SYSMAN objects, log in to the database as SYS and run the following command:

select object_name, object_type from all_objects where owner='SYSMAN' and status <> 'VALID';

The command must return 0 rows. However, if it returns one or more rows, then you have some invalid objects, and to turn them valid, run the following command as SYSMAN:

@admin_recompile_invalid.sql SYSMAN

Run this command again to ensure that all SYSMAN objects are valid. If you still have invalid SYSMAN objects, then contact Oracle Support.

Note: The admin_recompile_invalid.sql script is in the following location of the Oracle home of the OMS:

<ORACLE_HOME>/sysman/admin/emdrep/sql/core/latest/admin

To verify whether there are only valid SYS objects, log in to the database as SYS and run the following command:

select object_name, object_type from all_objects where status<>'VALID' and object_name like 'DBMS%';

The command must return 0 rows. However, if it returns one or more rows, then you have some invalid objects, and to turn them valid, recompile them by running the following command:

alter <object type> <object name> compile;

For example,

If the object_type is mypackage and the object_name is foo, then run the following command:

alter mypackage foo compile;

Run this command again to ensure that all the packages are valid. If you still have invalid packages, then contact Oracle Support.

DBMS Jobs and DBMS Scheduler Status Requirements

Ensure that your stop the DBMS Jobs and the DBMS scheduler in the existing, certified Oracle Database. To do so, log in to the database as SYS:

Write down the value of job_queue_processes by running the following command:

select a.instance_name as sid, b.value as jobqueue from gv$instance a, gv$parameter b where a.inst_id = b.inst_id and b.name='job_queue_processes';

Stop the DBMS JOBS by running the following command:

execute emd_maintenance.remove_em_dbms_jobs;

alter system set job_queue_processes=0 SID='*';

commit;

Note: This will allow the currently running jobs to finish, but will not allow any new jobs to be started.

Ensure that there are no active jobs by running the following:

select l.id2 job, l.sid, to_char(last_date, 'DD-MON-YYYY:HH24.MI.SS') last_date, to_char(this_date, 'DD-MON-YYYY:HH24.MI.SS') this_date, l.inst_id instance from sys.job$ j, gv$lock l where l.type = 'JQ' and j.job (+) = l.id2 order by 5, 4;

Stop the DBMS Scheduler by running the following command:

execute dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','TRUE');

Ensure that there were no active schedulers running by waiting until the following query returns 0:

select count(*) from dba_scheduler_running_jobs where SLAVE_PROCESS_ID IS NOT NULL;

Gather Statistics Job Status Requirements

Ensure that you stop the Gather Statistics job that is running in the existing, certified Oracle Database. To do so, log in to the database as SYS and run the following commands:

For Oracle Database 10g (10.2.0.4) or higher

execute dbms_scheduler.disable('GATHER_STATS_JOB',TRUE);

execute dbms_scheduler.stop_job('GATHER_STATS_JOB',TRUE);

For Oracle Database 11g (11.1.0.7) or higher

execute dbms_auto_task_admin.disable('auto optimizer stats collection',null,null);

User Privilege Requirements

Ensure that SYSMAN and DBSNMP users have EXECUTE privileges to access the DBMS_RANDOM package in the existing, certified Oracle Database. To verify whether the users have EXECUTE privileges, run the following query. When you run this query for the SYSMAN user, the <user_account_name> must be SYSMAN, and when you run it for the DBSNMP user, the <user_account_name> must be DBSNMP.

SQL> CONNECT AS SYS;
SQL> SELECT grantee, grantor, owner, table_name
FROM DBA_TAB_PRIVS
WHERE table_name = 'DBMS_RANDOM'
AND privilege = 'EXECUTE'
AND grantee IN
(
SELECT DISTINCT granted_role
FROM DBA_ROLE_PRIVS
START WITH grantee = '<user_account_name>'
CONNECT BY PRIOR granted_role=grantee
UNION ALL
SELECT '<user_account_name>'
FROM dual
WHERE ROWNUM = 1
UNION ALL
SELECT 'PUBLIC'
FROM dual
WHERE ROWNUM = 1
)

If these users do not have EXECUTE privileges, then grant them the privileges by running the following command. When you run this command for granting the privileges for the SYSMAN user, the <user_account_name> must be SYSMAN, and when you run it for the DBSNMP user, the <user_account_name> must be DBSNMP.

SQL> GRANT EXECUTE ON DBMS_RANDOM TO <user_account_name>;

Environment Variable Setting Requirements

Ensure that the environment variable ORACLE_HOME is set to the Oracle home of the OMS.

For example, in Cshell, set it in the following way:

setenv ORACLE_HOME /home/OraHomes/oms10g

For example, in bash shell, set it in the following way:

export ORACLE_HOME= /home/OraHomes/oms10g

OMS and Grid Control Process Status Requirements

Ensure that you shut down all the running processes (OPMN, DCM, and so on) and also all the OMSes, which are connecting to the same Management Repository. To do so, follow these steps:

Run the following commands from each of the Oracle homes of the OMS:

$<ORACLE_HOME>/opmn/bin/opmnctl stopall
$<ORACLE_HOME>/bin/emctl stop oms

Run the following command from each of the Oracle homes of the Management Agent:

$<ORACLE_HOME>/bin/emctl stop agent

Customization File Requirements

If there are any middle-tier customizations files that cannot be accessed using the credentials of the user account that is used for the upgrade process, then ensure that such customizations are removed or commented out. You can reapply these customizations after the upgrade is successfully completed.

Oracle Home Path Requirements

In the following file, ensure that the Oracle home path is the same as the component you are upgrading. The path must be a hardlink.

<Oracle_Inventory>/ContentsXML/inventory.xml

SUDO Configuration Requirements

Ensure that you configure SUDO in your environment. If you are unable to do so or if you have already upgraded any of the core components (OMS or Management Agent) without configuring SUDO, then follow the workaround described in My Oracle Support note 789363.1.

User-Defined Metric Script Definition Requirement

If you have any user-defined metric scripts in the Oracle home of a Management Agent that you are upgrading, then ensure that you manually copy all those scripts to another directory outside any Oracle home, and then update the user-defined metric definitions to reflect the new script location.

This is because, after the Management Agent is upgraded, the user-defined metric scripts are not automatically copied to the new Oracle home.

Note:

Besides the prerequisites mentioned in Table 21-1, refer to My Oracle Support note 1073166.1 for information on other upgrade-related known issues, prerequisites, and additional requirements.

Upgrade Procedure

To upgrade to Enterprise Manager 11g in silent mode, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

For example,

/u01/app/response/upgrade.rsp

Edit the response file:

If you are upgrading Enterprise Manager Grid Control, then specify values for the mandatory parameters listed in Table 21-2.

If you are upgrading an additional OMS, then specify values for the mandatory parameters listed in Table 21-3.

Invoke the installer:

./runInstaller -silent -responseFile <absolute_path_location>/upgrade.rsp

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

Run the allroot.sh script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/allroot.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/oms11g/allroot.sh

Table 21-2 Response File Parameters for Upgrading Enterprise Manager Grid Control

Parameter
Description

OLD_BASE_DIR

Specify the full path to the installation base directory where the existing OMS, which has to be upgraded, is installed.

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Specify FALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

ORACLE_MIDDLEWARE_HOME_LOCATION

Specify the location that was specified while installing Oracle WebLogic Server. For example, u01/app/Oracle/Middleware. Ensure that the middleware location has write permission to create the Oracle home for OMS and the Oracle home for Management Agent

For example, if you accept the default location /u01/app/Oracle/Middleware, then the Oracle home for OMS is created as /u01/app/Oracle/Middleware/oms11g, and the Oracle home for Management Agent is created as /u01/app/Oracle/Middleware/agent11g.

For more information about this location, see What Is Oracle Middleware Home?

Note: Ensure that the Middleware Home you specify here is used only for Enterprise Manager Grid Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware Home that is designated for Enterprise Manager Grid Control.

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files. If you want to accept the default directory, then leave this field blank. However, if you want to have a custom directory, then specify the name of the custom directory.

Whether you accept the default directory or specify a custom one, by default, the directory is created under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the directory is is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

WLS_ADMIN_SERVER_USERNAME

Specify the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic.

WLS_ADMIN_SERVER_PASSWORD

Specify the password for the WebLogic user account.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

Confirm the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

Specify the node manager password.

NODE_MANAGER_CONFIRM_PASSWORD

Confirm the node manager password.

SYS_PASSWORD

Specify the password for SYS user account.

Table 21-3 Response File Parameters for Upgrading Additional Oracle Management Service

Parameter
Description

OLD_BASE_DIR

Specify the full path to the installation base directory where the existing OMS, which has to be upgraded, is installed.

SECURITY_UPDATES_VIA_MYORACLESUPPORT

Specify TRUE if you want to download and install security updates. Then, specify the credentials for the following parameters:

MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

Specify FALSE if you do not want to download and install security updates:

DECLINE_SECURITY_UPDATES

Specify TRUE if you want to decline the security updates. In this case, you should have specified False for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Specify FALSE if you do not want to decline the security updates. In this case, you should have specified TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

ORACLE_MIDDLEWARE_HOME_LOCATION

Specify the location that was specified while installing Oracle WebLogic Server. For example, u01/app/Oracle/Middleware. Ensure that the middleware location has write permission to create the Oracle home for OMS and the Oracle home for Management Agent

For example, if you accept the default location /u01/app/Oracle/Middleware, then the Oracle home for OMS is created as /u01/app/Oracle/Middleware/oms11g, and the Oracle home for Management Agent is created as /u01/app/Oracle/Middleware/agent11g.

For more information about this location, see What Is Oracle Middleware Home?.

ORACLE_INSTANCE_HOME_LOCATION

Specify the directory where the configuration files of OMS can be created. Ensure that the directory you specify has write permission.

By default, this location is under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is <$Home>/Oracle/Middleware, then the OMS Instance Base is <$Home>/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

ADMIN_SERVER_HOSTNAME

Specify the name of the host where the Admin Server is running. Admin Server is the server that was created when you installed the first Oracle Management Service 11g Release 1.

ADMIN_SERVER_PORT

Specify the port on which the Admin Server is running.

WLS_ADMIN_SERVER_USERNAME

Specify the user name that will be used as the administrative user for the WebLogic Server Domain. By default, the user name is weblogic.

WLS_ADMIN_SERVER_PASSWORD

Specify the password for the WebLogic user account that was provided during the first Oracle Management Service installation.

SYS_PASSWORD

Specify the password for SYS user account.

After You Upgrade

After you upgrade, follow these steps:

Start the DBMS Jobs and the DBMS Scheduler. To do so, log in to the database as SYS and perform the following:

Start the DBMS Jobs by setting the job_queue_processes to the value you recorded while stopping the DBMS Jobs as a prerequisite.

alter system set job_queue_processes=<original_value> scope=both;

Start DBMS Scheduler by running the following command:

execute dbms_scheduler.set_scheduler_attribute ('SCHEDULER_DISABLED','FALSE');

Submit the DBMS jobs by running the following command:

execute emd_maintenance.submit_em_dbms_jobs;

Start the Gather Statistics job in the existing database by running the following as SYS:

For Oracle Database 10g (10.2.0.4) or higher

execute dbms_scheduler.enable('GATHER_STATS_JOB');

For Oracle Database 11g (11.1.0.7) or higher

execute dbms_auto_task_admin.enable('auto optimizer stats collection',null,null);

If you upgraded an additional OMS, then refresh the Oracle WebLogic Server Domain, which hosts the Enterprise Manager application, so that the configuration changes made to the domain as a result of adding an additional OMS are reflected in the Grid Control console. To refresh the Oracle WebLogic Server Domain, follow these steps:

In Enterprise Manager Grid Control, navigate to the Home page for the Oracle WebLogic Server Domain that hosts the Enterprise Manager application. In most cases, the following is the direct URL to the Home page. If your domain name is not GCDomain, then replace that string with your domain name:

[protocol]://[host]:[port]/em/faces/as/as/domainHome?target=/secFarm_GCDomain/GCDomain&type=weblogic_domain

From the WebLogic Domain menu, click Refresh WebLogic Domain.

On the Refresh WebLogic Domain page, click Continue.

Note:

This submits a WebLogic Domain Refresh job, which captures the domain configuration changes and reflects them in the Enterprise Manager Grid Control console. The job repeats itself once a day, and therefore, if you add any more additional OMSes or remove OMSes from your Enterprise Manager system in the future, this job automatically captures the configuration changes to the Oracle WebLogic Server Domain. You do NOT have to repeat this procedure every time you add an additional OMS.

Remove Oracle Application Server-related targets such as Oracle Application Server, Oracle HTTP Server, OC4J, and Oracle Web Cache from the Management Repository.

In particular, remove <OLD_OMS_NAME>, <OLD_OMS_NAME>_home, <OLD_OMS_NAME>_OC4J_EM, <OLD_OMS_NAME>_OC4J_EMPROV, <OLD_OMS_NAME>_HTTP Server, and <OLD_OMS_NAME>Web Cache.

Table 21-4 shows how these targets might appear in Enterprise Manager Grid Control.

Table 21-4 Removing Oracle Application Server Targets

Target Name
Target Type

EnterpriseManager0.hostname.com

Oracle Application Server

EnterpriseManager0.hostname.com_home

OC4J

EnterpriseManager0.hostname.com_HTTP Server

Oracle HTTP Server

EnterpriseManager0.hostname.com_OC4J_EM

OC4J

EnterpriseManager0.hostname.com_OC4J_EMPROV

OC4J

EnterpriseManager0.hostname.com_Web Cache

Web Cache

To remove these targets, log in to Enterprise Manager Grid Control, click All Targets, select for the target, and click Remove.

Discover all new targets such as Scan Listener and so on either using the Enterprise Manager Grid Control console or by running the following command from the Oracle home of the Management Agent where the new targets are running:

$<ORACLE_HOME>/bin/agentca -d

In Enterprise Manager 11g Grid Control, the emoms.properties file is no longer supported. To view details related to the Management Repository, run the following command:

emctl config oms -list_repos_details

(Optional) If you want to connect to another Management Repository, then shut down the OMS, run the following command, and then restart the OMS.

emctl config oms -store_repos_details (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <connect descriptor>) -repos_user <username> [-repos_pwd <pwd>] [-no_check_db]

Note:

On Linux, you need to double escape the connect descriptor using single and double quotes. However, on Microsoft Windows, you need not.

For example, on Linux:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc '"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb)))"' -repos_user sysman

For example, on Microsoft Windows:

emctl config oms -store_repos_details -repos_host myreposhost.mydomain.com -repos_port 12345 -repos_sid mydb -repos_conndesc (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myreposhost.mydomain.com)(PORT=12345))(CONNECT_DATA=(SID=mydb))) -repos_user sysman

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

Delete the old Oracle homes of OMS (oms10g) and Management Agent (agent10g). Also remove their entries, oms10g and agent10g, from the /etc/oratab file. However, do NOT delete the Oracle home of the database because it contains the upgrade schemas.

22 Upgrading Enterprise Manager System with Add-Ons Installed in Graphical Mode

This chapter explains how you can upgrade Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0) or higher, or Oracle Management Service 10g Release 4 (10.2.0.4.0) or higher that has add-ons such as EBiz, PeopleSoft, JDEdwards, and so on installed. In particular, this chapter covers the following:

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

After You Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

Overview

If you have installed add-ons on Enterprise Manager Grid Control or an additional OMS, and if you want to upgrade such an Enterprise Manager Grid Control or an additional OMS, then the obvious questions are: What happens to the add-ons you installed? Will they remain intact with the upgraded Enterprise Manager Grid Control or additional OMS? Should I reinstall them after upgrading Enterprise Manager Grid Control or additional OMS?

When you upgrade Enterprise Manager Grid Control or additional OMS, the add-ons that have been installed on it are NOT carried over to the upgraded version of Enterprise Manager Grid Control or additional OMS. The upgrade process is an out-of-place upgrade, that is, it creates new Oracle homes for the upgraded versions of OMS (oms11g) and Oracle Management Agent (Management Agent) (agent11g).

Due to this reason, the add-ons that were installed on the older release of Enterprise Manager Grid Control or an additional OMS are NOT automatically reinstalled on the upgraded version of Enterprise Manager Grid Control or an additional OMS.

The add-ons are independent of Enterprise Manager Grid Control and additional OMS, and if you want to continue to use them, then you must first upgrade the software binaries of the existing Enterprise Manager Grid Control or additional OMS, then install the add-ons, and then finally configure the upgraded software binaries of Enterprise Manager Grid Control or additional OMS.

Prerequisites

Before upgrading the software binaries of Enterprise Manager Grid Control or an additional OMS that has add-ons installed, ensure that you meet the prerequisites described in Prerequisites.

In addition, meet the following prerequisites:

Download the 11g Release 1 add-on software to the host where you are upgrading the Enterprise Manager system.

(For Microsoft Windows)Unset the PERL5LIB environment variable.

Upgrade Enterprise Manager

To upgrade the software binaries of Enterprise Manager Grid Control or an additional OMS that has add-ons installed, follow these steps:

Invoke the installer on the host where Enterprise Manager Grid Control or the additional OMS needs to be upgraded:

<Software_Location>/runInstaller -noconfig

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command and specify a unique custom WebLogic Domain name:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

Enterprise Manager Grid Control Installation Wizard appears. The wizard guides you through the installation process. Select the third installation type, that is, Upgrade to Enterprise Manager 11g .

On the List of Oracle Homes screen, select the Enterprise Manager Grid Control (first OMS) or the additional OMS you want to upgrade. Specify the information required on each of the screens. Click Next on each screen until you reach the final screen. On the final screen, click Install to upgrade Enterprise Manager Grid Control.

For information about the values you need to specify on each screen, follow the instructions outlined for upgrading Enterprise Manager Grid Control, in Oracle Enterprise Manager Grid Control Basic Installation Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Install Add-Ons

After you upgrade the software binaries of Enterprise Manager Grid Control, follow these steps to install the 11g Release 1 add-ons:

Install the add-ons by running the following command from the Oracle home of the OMS:

$<ORACLE_HOME>/oui/bin/runInstaller -noconfig

When the installer prompts you to specify the location of the products.xml file, specify the full path to the /Disk1/stage/ directory where the products.xml file is available. Ensure that the path leads up to the products.xml file. The /Disk1/stage/ directory is available in the add-on software you downloaded.

For example, if you downloaded an add-on to /scratch/<AddOn_Name>/, then specify the path as /scratch/<AddOn_Name>/Disk1/stage/products.xml.

Notes:

When you proceed with the installation, you will be prompted to select the add-on OMS component, the Oracle home of the OMS in which you want to install the add-ons. You will also be prompted to specify the Management Repository-related details.

In order to ensure a successful upgrade, review the Application Management Pack for Oracle E-Business Suite Installation Guide to check for any additional steps required to complete the Add-On upgrade. The document is available at the following link:

http://download.oracle.com/docs/cd/E11857_01/em.111/e18708/toc.htm

After You Install Add-Ons

After you install the add-ons, log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS:

$<ORACLE_HOME>/allroot.sh

Configure Enterprise Manager

To configure Enterprise Manager Grid Control, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure Enterprise Manager

After you configure Enterprise Manager Grid Control or an additional OMS, follow the steps outlined in After You Upgrade.

23 Upgrading Enterprise Manager System with Add-Ons Installed in Silent Mode

This chapter explains how you can use silent mode to upgrade Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0) or higher, or Oracle Management Service 10g Release 4 (10.2.0.4.0) or higher that has add-ons such as EBiz, PeopleSoft, JDEdwards, and so on installed. In particular, this chapter covers the following:

Overview

Prerequisites

Upgrade Enterprise Manager

Install Add-Ons

After You Install Add-Ons

Configure Enterprise Manager

After You Configure Enterprise Manager

Overview

If you have installed add-ons on Enterprise Manager Grid Control or an additional OMS, and if you want to upgrade such an Enterprise Manager Grid Control or an additional OMS, then the obvious questions are: What happens to the add-ons you installed? Will they remain intact with the upgraded Enterprise Manager Grid Control or additional OMS? Should I reinstall them after upgrading Enterprise Manager Grid Control or additional OMS?

When you upgrade Enterprise Manager Grid Control or additional OMS, the add-ons that have been installed on it are NOT carried over to the upgraded version of Enterprise Manager Grid Control or additional OMS. The upgrade process is an out-of-place upgrade, that is, it creates new Oracle homes for the upgraded versions of OMS (oms11g) and Oracle Management Agent (Management Agent) (agent11g).

Due to this reason, the add-ons that were installed on the older release of Enterprise Manager Grid Control or an additional OMS are NOT automatically reinstalled on the upgraded version of Enterprise Manager Grid Control or an additional OMS.

The add-ons are independent of Enterprise Manager Grid Control and additional OMS, and if you want to continue to use them, then you must first upgrade the software binaries of the existing Enterprise Manager Grid Control or additional OMS, then install the add-ons, and then finally configure the upgraded software binaries of Enterprise Manager Grid Control or additional OMS.

Prerequisites

Before upgrading the software binaries of Enterprise Manager Grid Control or an additional OMS that has add-ons installed, ensure that you meet the prerequisites described in Prerequisites.

In addition, meet the following prerequisites:

Download the 11g Release 1 add-on software to the host where you are upgrading the Enterprise Manager system.

(For Microsoft Windows) Unset the PERL5LIB environment variable.

Upgrade Enterprise Manager

To upgrade the software binaries of Enterprise Manager Grid Control or an additional OMS that has add-ons installed, follow these steps:

Copy the following response file to an accessible location on your local host:

<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> is either <DVD> or <Software_Downloaded_Location>.

Edit the response file:

If you are upgrading Enterprise Manager Grid Control, then specify values for the mandatory parameters listed in Table 21-2.

If you are upgrading an additional OMS, then specify values for the mandatory parameters listed in Table 21-3.

Invoke the installer:

./runInstaller -noconfig -silent -responseFile <absolute_path_to_location>/upgrade.rsp

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In Microsoft Windows, if the path to the software download location contains a subdirectory name with two or more words and a space between each of the words, then ensure that the parent directory of such a subdirectory does not contain a file whose name matches with the first word of that subdirectory.

For example, if the software is downloaded to C:\Documents and Settings, then before you invoke setup.exe, ensure that there are no files titled Documents (for example, shortcut files such as C:\Documents) in the C:\ drive.

After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer using the START_OMS=false and b_startAgent=false arguments.

However, if you pass the START_OMS=false argument, the installation does not configure the EMCLI tool, and as a result, none of the EMCLI commands will work. Therefore, after the installation ends, you must manually configure the EMCLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface available at:

http://www.oracle.com/technology/documentation/oem.html

By default, GCDomain is the default name used for creating the WebLogic Domain.

To override this, invoke the installer using the following command:

./runInstaller WLS_DOMAIN_NAME=<Custom_Domain_Name>

Install Add-Ons

After you upgrade the software binaries of Enterprise Manager Grid Control, follow these steps to install the 11g Release 1 add-ons:

Create a response file titled addon_oms.rsp with the following details:

RESPONSEFILE_VERSION=2.2.1.0.0
FROM_LOCATION=<absolute_path_to_products.xml>
DEINSTALL_LIST={"<add-on oms component name>","<add-on oms component version>"}
TOPLEVEL_COMPONENT={"<add-on oms component name>","<add-on oms component version>"}
ORACLE_HOME=<OMS OracleHome>
ORACLE_HOME_NAME=<name of the Oracle Home>
b_upgrade=false
EM_REPOS_DBA_PWD="<Repository SYS password>"
DATABASE_HOSTNAME=<Repository Host name>
LISTENER_PORT=<Repository Port>
SERVICENAME_OR_SID=<Repository SID>
b_silentInstall=true
ACCEPT_LICENSE_AGREEMENT=true

Run the following command from the Oracle home of the OMS and pass the response file to install the add-ons:

$<ORACLE_HOME>/oui/bin/runInstaller -noconfig -silent -responseFile <absolute_path_to_location>

Note:

In order to ensure a successful upgrade, review the Application Management Pack for Oracle E-Business Suite Installation Guide to check for any additional steps required to complete the Add-On upgrade. The document is available at the following link:

http://download.oracle.com/docs/cd/E11857_01/em.111/e18708/toc.htm

After You Install Add-Ons

After you install the add-ons, log in as a root user in a new terminal and run the allroot.sh script from the Oracle home of the OMS:

$<ORACLE_HOME>/allroot.sh

Configure Enterprise Manager

To configure Enterprise Manager Grid Control, do the following:

If the environment variable PERL5LIB is set in your environment, then unset it.

Run the ConfigureGC.pl script from the Oracle home of the OMS (oms11g):

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl

Note:

If any of the Configuration Assistants fail, then review the relevant log files, resolve the issues, and rerun the Configuration Assistants as described in What Do You Do When Configuration Assistants Fail?.

To understand the optional arguments that can be passed with the ConfigureGC.pl script, see Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script".

After You Configure Enterprise Manager

After you configure Enterprise Manager Grid Control or an additional OMS, follow the steps outlined in After You Upgrade.

Part VI

Upgrading Oracle Management Agent

This part describes the different ways of upgrading Oracle Management Agent.

In particular, this part contains the following chapters:

Chapter 24, "Upgrading Oracle Management Agent Using Agent Upgrade Wizard"

Chapter 25, "Upgrading Oracle Management Agent Using a Response File"

Chapter 26, "Upgrading Oracle Management Agent Using agentDownload Script"

Chapter 27, "Upgrading Shared Oracle Management Agent"

Chapter 28, "Upgrading Oracle Management Agent with Add-Ons"

24 Upgrading Oracle Management Agent Using Agent Upgrade Wizard

This chapter describes how you can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) using the Agent Upgrade Wizard. In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Upgrade Procedure

After You Upgrade

Overview

You can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) using the Agent Upgrade Wizard that is built into Enterprise Manager Grid Control. The Agent Upgrade Wizard offers GUI-rich, interactive screens, and can be accessed from the Enterprise Manager Grid Control console.

IMPORTANT:

Agent Upgrade Wizard does not help you migrate from one patch release to another. For example, you cannot use this wizard to move from Oracle Management Agent 10g Release 4 (10.2.0.4.0) to Oracle Management Agent 10g Release 5 (10.2.0.5.0). This type of migration is called Patching and patching is done using patch sets that are released periodically by Oracle.

Although the Agent Upgrade Wizard can be used for upgrading one, single Oracle Management Agent, the wizard is best suited for upgrading multiple Oracle Management Agents at a time, and is particularly useful when you want to upgrade remotely.

The Agent Upgrade Wizard gives you the flexibility to select multiple hosts on which Oracle Management Agent needs to be upgraded. This helps you when you want to upgrade Oracle Management Agent on several hosts, in one attempt.

Before You Begin

Before you begin, keep these points in mind:

If you are upgrading a Management Agent whose software binaries were used for installing shared Management Agents, that is, either using the Shared Agent Deployment Wizard or the nfsagentinstall script, then before proceeding any further, read Chapter 27, "Upgrading Shared Oracle Management Agent".

If you want to view the status of an upgrade session that was previously run, click Agent Installation Status in the Deployments screen. However, do not attempt to view the installation status until the installation is complete. If you do, you will see an error.

On Microsoft Windows, do not open the agentpush.properties file using Microsoft Word software. Open it using other text editors such as VIM or Notepad.

For accessing the Enterprise Manager Grid Control console, ensure that you use only certified browsers as mentioned in My Oracle Support note 412431.1

Prerequisites

Before upgrading the Management Agent, ensure that you meet the following prerequisites.

If you want, you can print out this section and write 'Yes' or 'No' against each prerequisite. This will help you to track the prerequisites you have met and the prerequisites you have not met.

Table 24-1 Prerequisites for Upgrading Oracle Management Agent Using Agent Upgrade Wizard

Requirement
Description
Yes/No

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements as described in Appendix A, "Meeting Hardware Requirements".

Operating System Requirements

Ensure that you install the Management only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

Log in to My Oracle Support, and click the Certifications tab.

On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - Agent.

From the Release list, select 11.1.0.1.0, and click Search.

Package Requirements

Ensure that you install all the platform-specific packages as described in Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements ".

User and Operating System Group Requirement

Ensure that the destination host where you want to upgrade the Management Agent has the appropriate users and operating system groups created.

For information about creating operating system groups and users, see Appendix C, "Creating Operating System Groups and Users Requirements".

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied. For example, /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Central Inventory Requirements

Ensure that you allocate 100 MB of space for the central inventory directory.

Also ensure that the central inventory directory is not on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system by following the instructions outlined in My Oracle Support note 1092645.1.

Installation Base Directory Requirements

Ensure that the installation base directory you specify is empty and has write permission.

Software Availability Requirements

By default, the software for Oracle Management Agent 11g Release 1 is available on the host where Oracle Management Service 11g Release 1 is running. Note that this Management Agent software is for the platform on which the OMS is running.

Therefore, if you want to upgrade to Oracle Management Agent 11g Release 1 on a platform that is the same as the one on which the OMS is running, then you already meet this prerequisite; you do not have to take any action.

However, if you want to upgrade to Oracle Management Agent 11g Release 1 on a platform that is different from the one on which the OMS is running, then ensure that you download the software for that platform.

For more information about downloading the Management Agent software, see Procuring Oracle Management Agent Software.

File Deletion Requirements

If you are upgrading Oracle Management Agent 10g Release 4 (10.2.0.4.0) or higher, which was upgraded from Oracle Management Agent 10g Release 1, then ensure that you remove the following file from the Oracle home of the 10.2.0.4.0 or 10.2.0.5.0 Management Agent:

$<ORACLE_HOME>/bin/emctl.upgrade.backup

Accessibility Requirements

If there are multiple OMSes in your environment and if you have staged the Management Agent software in a non-default location (not on the OMS host), then ensure that the non-default location is accessible by all the OMSes.

Path Validation Requirements

Validate the path to all command locations. For more information, see Appendix E, "Validating Command Locations".

Host List Requirements

Ensure that you identify the hosts where you want to upgrade the Management Agent. Otherwise, maintain a host list file that contains a list of hosts as described in What Is a Host List File?.

Ensure that all hosts have the same operating system credentials and file system structure.

If you are upgrading the Management Agents of a cluster, then ensure that the nodes are part of the same cluster.

/etc/hosts File Requirements

If the destination host and the host on which OMS is running belong to different network domains, then ensure that you update the /etc/hosts file on the destination host to add a line with the IP address of that host, the fully-qualified name of that host, and the short name of the host.

For example, if the fully-qualified host name is mypc.cn.company.com and the short name is mypc, then add the following line in the /etc/hosts file:

12.123.123.12 mypc.cn.company.com mypc

Preinstallation/Postinstallation Scripts Requirements

Ensure that the preinstallation and postinstallation scripts, which you want to run along with the upgrade procedure, are available on all the destination hosts.

Installing User Requirements

If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.

For example, if the inventory owner is user1, and user installing the Management Agent is user2, then ensure that user1 and user2 belong to the same group, and they have read and write access to the inventory.

Permission Requirements

Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then you can specify the path to an alternative inventory location by using one of the following options in the Additional Parameters section of the Agent Deployment Wizard:

On the Installation Details page, if you select Default, from Management Server location, which means the software is on the OMS host, then use the -i <location> option.

On the Installation Details page, if you select Another Location, which means the software is in any other location other than the OMS host, then use the -invPtrLoc option.

Ensure that you have write permission on the Installation Base Directory and the temporary directory where the executables will be copied. For example, /tmp or c:\Temp.

Oracle Inventory Location Requirements

Ensure that the Oracle Inventory (oraInventory) is not in a shared location. When you use the oraInst.loc file, ensure that the inventory location specified there is not pointing to a shared location. If it is, change it to a non-shared location.

SUDO Privilege Requirement

Ensure that you have SUDO privileges to run root.sh and /bin/sh (UNIX platforms only). The Agent Upgrade Wizard uses SUDO to run the root.sh script. You must specify the invoking user's password here.

To verify whether you have SUDO privileges to run these files, access the /etc/sudoers file and check whether you have a similar entry as shown below. If you do not see a similar entry, then add one.

<user> <hostname>=PASSWD: /home/em/agent11010/agent11g/root.sh, /bin/sh

If you do not have SUDO privileges and if you do NOT want to run root.sh and /bin/sh yourself at the time of upgrade, then request your Administrator who has SUDO privileges to manually run the scripts after the installation ends. To understand how and where the scripts need to be run from, see After You Upgrade.

SUDOERS File Configuration Requirements

Ensure that you configure /etc/sudoers file so that while running a command using SUDO, you are always prompted for a password.

If /etc/sudoers file is configured in such a way that SUDO never prompts for a password, then a directory with the host password as the title gets created in the invoking users home directory.

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts.

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that is present in the OMS Instance Base:

<INSTANCE_HOME>/sysman/prov/resources/Paths.properties

PubkeyAuthentication Parameter Requirements

Ensure that the PubkeyAuthentication parameter is enabled in the sshd_config file.

To verify the value of this parameter, run the following command:

grep PubkeyAuthentication <SSH_Install_Location>/sshd_config

For example,

grep PubkeyAuthentication /etc/ssh/sshd_config

The result of this command must be Yes. If the result is No, then edit the sshd_config file, set the PubkeyAuthentication value to Yes, and restart the SSH daemon.

PATH Environment Variable Requirements

On the host where OMS is running and on the host where you want to install the Management Agent, ensure the following:

(For Microsoft Windows) Ensure that the cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd) on both the hosts.

(For UNIX) Ensure that the SCP binaries (for example, /usr/local/bin/scp) are in the PATH environment variable.

SSH Setup Requirements (For Microsoft Windows)

(For Microsoft Windows) If you are upgrading the Management Agent on a Microsoft Windows-based platform, then ensure that you set up the SSH connectivity between the host running OMS and the host where the Management Agent needs to be installed, as described in Appendix D, "Setting Up SSH Connectivity".

Agent User Account Permissions and Rights (For Microsoft Windows)

(For Microsoft Windows) If you are upgrading the Management Agent on a Microsoft Windows-based platform, then ensure that the agent user account has permissions and rights to perform the following:

Act as part of the operating system.

Increase quotas.

Replace process level token.

Log in as a batch job.

To verify whether the agent user has these rights, follow these steps:

Launch the Local Security Settings.

From the Start menu, click Settings and then select Control Panel. From the Control Panel window, select Administrative Tools, and from the Administrative Tools window, select Local Security Settings.

In the Local Security Settings window, from the tree structure, expand Local Policies, and then expand User Rights Assignment.

Permissions for cmd.exe (For Microsoft Windows)

(For Microsoft Windows) If you are upgrading the Management Agent on a Microsoft Windows-based platform, then ensure that you grant the Cmd.exe program Read and Execute permissions for the user account that the batch job runs under. This is a restriction from Microsoft.

For more information on this restriction and to understand how you can grant these permissions, access the following URL to Microsoft Web site:

http://support.microsoft.com/kb/867466/en-us

Upgrade Procedure

To upgrade a Management Agent, follow these steps:

In Grid Control, click Deployments.

On the Deployments page, from the Agent Installation section, click Install Agent.

On the following page, click Upgrade Agent.

On the Installation Details page, in the Version section, select the version of the Management Agent to which you want to upgrade. The values available in this list depend on the software staged on the OMS host.

For example, if you upgrading Oracle Management Agent 10g Release 5 (10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0), then select 11.1.0.1.0.

In the Hosts section, do the following:

From the Platform list, select the operating system on which you want to upgrade the Management Agent.

For Provide Host List, specify the host names or IP addresses of the hosts on which you want to upgrade the Management Agent.You can use a comma (,) or a white space as a separator when specifying multiple hosts.

Alternatively, if you already have a list maintained in a file, then click Get Host Names From File and select that file.

For information about host list file, see What Is a Host List File?.

If the hosts specified in the previous step are part of the same cluster, then select Cluster Upgrade.

In the OS Credentials section, do the following:

Specify the appropriate operating system user credentials. The operating system credentials you specify here must be the same for all the selected hosts.

Select Run root.sh (for UNIX) if you want the application to run this script.

The root.sh script runs after the configuration assistants are run and before the postinstallation scripts (if any) are run. If you do not select this option here, you must run root.sh on each node manually.

In the Existing Agent Information section, specify the full path to the Oracle home of the existing Management Agent that you want to upgrade. Ensure that the path you specify here is the same on all the hosts.

In the Destination section, specify the full path to the Installation Base Directory. This directory is created on all the specified hosts, and the Oracle home of the Management Agent is created as a subdirectory under this directory.

For information about installation base directory, see What Is Installation Base Directory?.

In the Additional Parameters section, specify any additional parameters that you want to pass during installation. To understand the possible parameters that can be passed here, see Table 24-2.

Oracle recommends you to specify only those parameters that you want to run in addition to the general parameters you have already provided on this page for installation. For example, in Step (8), you are specifying the installation base directory. Therefore, for Additional Parameters, try to avoid specifying the installation base directory again. If you still do so, then the value you specified in Step (8) will be ignored and the value you specified here will be used instead.

And note that if you are specifying more than one parameter, then separate them with a white space. For example, -i /etc/oraInst.loc -p /home/config/staticports.ini.

In the Management Server Security section, specify a password that can be used for authenticating new Management Agents that join the Enterprise Manager Grid Control system, and for permitting only secure Management Agents to communicate with the OMS, which is in locked state, via HTTPS protocol.

Alternatively, after the installation is complete, the super administrator can approve the addition of new Management Agents to the Enterprise Manager Grid Control system.

Note:

For security reasons, Oracle strongly recommends you to change the OMS password specified here After the installation is complete.

In the Additional Scripts section, do the following:

Specify any preinstallation and/or postinstallation scripts that you want to run.

Select Run as Superuser if you want to run these scripts as root.

Note:

The preinstallation and/or postinstallation scripts that you specify must be available on all the hosts. These files are not copied onto the hosts from the software source location during installation.

Click Continue.

On the My Oracle Support Details page, do the following:

If the host where the Management Agent is being upgraded has a direct connection to the Internet, then specify an e-mail address and My Oracle Support password.

An e-mail address is required so that security updates and install updates can be sent. You can specify any e-mail address, but Oracle recommends you to specify the My Oracle Support user name. For example, john.mathew@xyz.com.

If the host where the Management Agent is being upgraded has an indirect connection to the Internet, that is, through a proxy server, then specify an e-mail address and My Oracle Support password, and then in the Connection Details section, specify the proxy server details.

Note:

You can change the proxy server settings any time after the installation or patching process ends. To do so, run the configCCR command from the ccr/bin/ directory within the Oracle home of the Management Agent.

If the host where the Management Agent is being upgraded does not have a direct or indirect connection to the Internet, then specify the e-mail address and leave the other fields blank.

In this case, after you complete the upgrade process, manually collect the configuration information and upload it to My Oracle Support.

Note:

If you see any errors on this page, then check whether you (the user installing the Management Agent) have the necessary write permissions on crontab. If you do not, then create an entry for your user account in the cron.allow file.

For information about Oracle Configuration Manager, see What Is Oracle Configuration Manager?. For information about manually collecting and uploading configuration information, see Manually Collecting and Uploading Configuration Information.

Click Continue.

As part of this process, the Agent Upgrade Wizard performs some prerequisite checks before proceeding with the upgrade process. When all the prerequisite checks are complete, the application displays the results. You can choose to either retry the prerequisite check on all those failed hosts, or ignore the result and proceed to upgrade the Management Agent.

Note:

After the installation and configuration phase, the Agent Upgrade Wizard runs the root.sh script.

If the upgrade operation fails, then click Recover to recover the previous release of the Management Agent that you were trying to upgrade. On clicking Recover, you return to the Installation Details page of the Agent Upgrade Wizard. On the Installation Details page, in the OS Credentials section, specify the appropriate operating system user credentials and click Continue. Proceed and submit the operation again to recover the previous release of the Management Agent.

Additional Parameters You Can Specify for Agent Upgrade

The following are the additional parameters you can specify while using the Agent Upgrade Wizard to upgrade an existing Management Agent:

Table 24-2 Additional Parameters Supported for Agent Upgrade

Parameters
Description

-t

Do NOT start the Agent after installation/upgrade. No value required.

-b

Specify installation Base Dir location. For example, -b /home/OracleHomes/agent/

-d

Do not initiate automatic target discovery. No value required.

-i

Specify inventory pointer location file. For example, -i /etc/oraInst.loc

-o

Specify existing agent home to upgrade. For example, -o /home/OracleHomes/oldAgent/

-p

Specify file location for static port for Agent. For example, -p /home/config/staticports.ini

-z

Specify the timezone environment variable value (-z <timezone>). For example, -z PST8PDT.

Note:

If the parameters that you specify here are also specified independently through command-line options, the value of the parameters that you specify here will take precedence over the others. For example, if installation Base Dir has been specified independently, and the -b option is specified here, the value of the latter (-b) will be used during the upgrade.

After You Upgrade

After you upgrade the Management Agent, follow these steps:

Verify the installation:

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that the Management Agent is up and running:

$<ORACLE_HOME>/bin/emctl status agent

Note:

If the status of the Management Agent is down for some reason, then manually start the Management Agent by running the following command from its Oracle home:

$<ORACLE_HOME>/bin/emctl start agent

Navigate to the Oracle home of the Management Agent and run the following command to see a message that confirms that EMD upload completed successfully:

$<ORACLE_HOME>/bin/emctl upload

Note:

(For UNIX operating systems) Before running the emctl command to start the Management Agent, ensure that the environment variable NLS_LANG is set with a value that is compatible with the operating system default locale setting and the character set of the Oracle Database, which houses the Management Repository.

(Only for UNIX Operating Systems) If you had NOT selected Run Root.sh in the OS Credentials section, then manually run the root.sh script as a root user from the Oracle home of the Management Agent:

<Oracle_Home>/root.sh

For example, if you are using SUDO to change to a root user, then you will run the following command:

/usr/local/bin/sudo /scratch/OracleHomes/agent11g/root.sh

If you do not have SUDO privileges, then request your Administrator who has the privileges to run these scripts.

(Optional) If you have not secured the communications between the Management Agent and the OMS, then secure it by running the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/bin/emctl secure agent

Note:

Even after securing the Management Agent, some data might still be transferred over the network without being encrypted.

If the PATH environment variable is set to the agent10g directives, then manually updated them to agent11g path. Manually delete the agent10g files from the file system. Also, manually disable and remove the Oracle agent10g Windows Services (The agent11g services are created and started automatically, but old 10g services remain.)

(Optional) If you want to discover the newly installed targets, if you want to convert the standalone Management Agent to a cluster-based Management Agent, if you want to discover the targets on the new nodes of the cluster, or if you want to reconfigure the cluster-based Management Agent, you must run the agentca script to reconfigure and discover all new targets.

For information about the agentca script, see What Is Agent Configuration Assistant Used For?.

For information about reconfiguring the Management Agent and discovering all new targets, see Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets".

(Optional) If you want to enable the Request Monitoring feature for tracing transaction requests in WLS, you need JVM Diagnostics as well as Application Dependency and Performance (ADP) managers and agents configured against the target to be monitored.

For information about installing JVM Diagnostics and enabling the Request Monitoring feature, refer to the Oracle Enterprise Manager Administration Guide.

For information about enabling the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

25 Upgrading Oracle Management Agent Using a Response File

This chapter describes how you can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) in a silent mode using the response file.

In particular, this chapter covers the following:

Overview

Prerequisites

Upgrade Procedure

After You Upgrade

Overview

You can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) using the response file upgrade_agent.rsp. The response file collects all the information that the Agent Upgrade Wizard collects in its screens, and performs exactly the same function that the Agent Upgrade Wizards performs.

Note:

If you are upgrading a Management Agent whose software binaries were used for installing additional Management Agents, either using the Shared Agent Deployment Wizard or the nfsagentinstall script, then before proceeding any further, read Chapter 27, "Upgrading Shared Oracle Management Agent".

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before upgrading a Management Agent, ensure that you meet the prerequisites described in Prerequisites.

Upgrade Procedure

To upgrade an existing Management Agent using a response file, follow these steps:

Stop the Management Agent you want to upgrade.

On the host where you want to upgrade the Management Agent, download the Management Agent Software as described in Procuring Oracle Management Agent Software.

Navigate to the following location and edit the response file upgrade_agent.rsp as described in Table 25-1.

<Software_Location>/<platform>/response/upgrade_agent.rsp

Invoke the installer:

If you have the default name for the Oracle home of your existing Management Agent, that is, agent10g, then: run the following command:

./runInstaller -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file>

Note:

On Microsoft Windows, do the following:

If you are upgrading a non-shared RAC Agent, then run the following command on every node of the cluster:

setup.exe -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> -local

If you are upgrading a shared RAC Agent, then do the following:

(a) On one of the nodes, run the following command:

setup.exe -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> -local

(b) On each of the other nodes, run the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/agentca -u -c <comma-separated_list_of_nodes'_short_names> -r <absolute_path_to_response_file>

Here, the response file passed in the above-mentioned command contains the following parameter with the fully qualified name of the node on which you are invoking the command:

s_hostname=<fully_qualified_name_of_node>

If you have a custom name for the Oracle home of your existing Management Agent, then run the following command:

./runInstaller -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> s_oldAgentHome=<absolute_path_to_Old_Oracle_Home>

Note:

On Microsoft Windows, technical writing blogs:

If you are upgrading a non-shared RAC Agent, then run the following command on every node of the cluster:

setup.exe -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> s_oldAgentHome=<absolute_path_to_Old_Oracle_Home> -local

If you are upgrading a shared RAC Agent, then do the following:

(a) On one of the nodes, run the following command:

setup.exe -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> s_oldAgentHome=<absolute_path_to_Old_Oracle_Home> -local

(b) On each of the other nodes, run the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/agentca -u -c <comma-separated_list_of_nodes'_short_names> -r <absolute_path_to_response_file>

Here, the response file passed in the above-mentioned command contains the following parameter with the fully qualified name of the node on which you are invoking the command:

s_hostname=<fully_qualified_name_of_node>

Table 25-1 Response File Parameters for Upgrading Oracle Management Agent

Variable Name
Description

OLD_BASE_DIR

If you have the default name for the Oracle home of your existing Management Agent, that is, agent10g, then specify the path to the old installation base directory where the Management Agent to be upgraded is residing.

For example, if the Management Agent is residing in /john/OracleHomes/10.2/agent10g, then specify only /john/OracleHomes/10.2/

If you have a custom name for the Oracle home of your existing Management Agent, then pass the s_oldAgentHome argument while running the installer and specify the path to that Oracle home in the command.

ORACLE_AGENT_HOME_LOCATION

Specify the location where the Oracle home of the Management Agent (agent11g) can be created.

After You Upgrade

After upgrading the Management Agent, follow the steps outlined in After You Upgrade.

26 Upgrading Oracle Management Agent Using agentDownload Script

This chapter describes how you can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) in silent mode, using the agentDownload script. In particular, this section covers the following:

Overview

Before You Begin

Prerequisites

Upgrade Procedure

Overview

You can upgrade an existing Oracle Management Agent 10g Release 4 or 5 (10.2.0.4.0 or 10.2.0.5.0) to Oracle Management Agent 11g Release 1 (11.1.0.1.0) in silent mode using the agentDownload script. The agentDownload script is a script that helps you upgrade Management Agents, silently without having to use the GUI screens of Enterprise Manager Grid Control. The script is available on the source host where Oracle Management Service (OMS) is installed, and it is run from the node where the Management Agent needs to be upgraded. For more information about the agentDownload script, see Overview.

Before You Begin

Before you begin, keep in mind the following points:

If you are upgrading a Management Agent whose software binaries were used for installing additional Management Agents, either using the Shared Agent Deployment Wizard or the nfsagentinstall script, then before proceeding any further, read Chapter 27, "Upgrading Shared Oracle Management Agent".

Prerequisites

Before upgrading the Management Agent, ensure that you meet the prerequisites described in Prerequisites.

Upgrade Procedure

To upgrade an existing Management Agent using the agentDownload script, follow these steps:

On the destination host where you want to upgrade the Management Agent, open a browser to access the OMS URL and download the script.

UNIX Platform
Microsoft Windows Platforms

Using Browser

http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.<platform>

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/linux/agentDownload.linux

Using Browser

http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Using Command Line

wget http://<oms_host>:<oms_port>/agent_download/<version>/<platform>/agentDownload.vbs

For example:

wget http://host1.servers.com:4889/agent_download/11.1.0.0.0/win32/agentDownload.vbs

Run the agentDownload script on the destination host using the following command. For other options, you can use with the command, see Table 26-1.

UNIX Platform
Microsoft Windows Platforms

./agentDownload.<platform> -u -o <absolute_path_to_old_oracle_home> -b <absolute_path_to_new_installation_base_directory>

For example:

./agentDownload.linux -u -o /john/OracleHomes/agent10g -b /peter/OracleHomes

./agentDownload.vbs u o <absolute_path_to_old_oracle_home> b <absolute_path_to_new_installation_base_directory>

For example:

./agentDownload.vbs u o /john/OracleHomes/agent10g b /peter/OracleHomes

Note:

The -b argument can be skipped if you have specified the installation base directory for the parameter ORACLE_AGENT_HOME_LOCATION in the agent_download.rsp file. However, if you still pass the argument -b in the command, then the installation base directory specified in the command is honored and the one specified in the response file is ignored.

Note:

On Microsoft Windows, do the following:

If you are upgrading a non-shared RAC Agent, then run the following command on every node of the cluster:

./agentDownload.vbs u o <absolute_path_to_old_oracle_home> b <absolute_path_to_new_installation_base_directory> -local

If you are upgrading a shared RAC Agent, then do the following:

(a) On one of the nodes, run the following command:

./agentDownload.vbs u o <absolute_path_to_old_oracle_home> b <absolute_path_to_new_installation_base_directory> -local

(b) On each of the other nodes, run the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/agentca -u -c <comma-separated_list_of_nodes'_short_names> -r <absolute_path_to_response_file>

Here, the response file passed in the above-mentioned command contains the following parameter with the fully qualified name of the node on which you are invoking the command:

s_hostname=<fully_qualified_name_of_node>

If the Management Agent that you are upgrading was not secure, then the agentDownload script prompts you to specify the agent registration password.

Arguments You Can Pass While Running agentDownload Script

The following are the arguments you can pass while running the agentDownload script:

Note:

On Microsoft Windows, do not hyphenate the arguments. For example, the -b argument when run on Microsoft Windows is b.

Table 26-1 Arguments Supported by agentDownload Script

Options
Description

-b

Specify the installation base directory for the Management Agent.

-c

Specify the nodes of a cluster for which you want to upgrade the Management Agent. For example, - c "node1,node2,node3"

-d

Indicates that you do NOT want to initiate automatic target discovery.

-i

Specify the inventory pointer location file.

-l

Indicates that the command will work only on the local host.

-n

Specify the cluster name.

-N

Indicates that you do not want to be prompted for Agent Registration Password.

-o

Specify the full path to the Oracle home of the Management Agent you want to upgrade.

-p

Specify the staticports.ini file.

-R

To use virtual host name (ORACLE_HOSTNAME) for this installation. If this is being used along with more than one cluster node through -c option, then -l option also needs to be passed.

-s

Specify the installer stage directory.

-t

Indicates that you do NOT want to start the Management Agent.

-u

Indicates that you want to upgrade.

-v

Specify the inventory directory location.

-x

Indicates you want debug output.

-y

Indicates that you want to decline security updates.

27 Upgrading Shared Oracle Management Agent

This chapter explains how you can upgrade Oracle Management Agents (Management Agent) that were installed using the shared Oracle home of an existing Management Agent. In particular, this chapter covers the following:

Overview

Prerequisites

Upgrade Procedure

After You Upgrade

Overview

Shared Oracle Management Agent refers to Oracle Management Agents installed using either the Shared Agent Deployment Wizard or the nfsagentinstall script. Typically, when you use one of these installation methods to install a Management Agent, the software binaries from a shared Oracle home of an existing Management Agent are used, and an EMSTATE directory is configured on each of the remote hosts.

The Management Agent that shares its software binaries, in this context, is called the Master Agent, and the one that is configured with an EMSTATE directory on the remote host is called the Shared Agents or NFS Agents.

To upgrade a Shared Agent, you must first upgrade the Master Agent that shares its software binaries. Once you upgrade the Master Agent, its associated Shared Agents get automatically upgraded.

You can upgrade the Master Agent using one of the upgrade methods described in Part V, "Upgrading Enterprise Manager System" and Part VI, "Upgrading Oracle Management Agent".

The upgrade process on the Master Agent is an out-of-place upgrade, that is, a new agent11g Oracle home is created. However, the upgrade process for the Shared Agent is an in-place upgrade, that is, only the EMSTATE directory is upgraded without creating any new directories.

For information about the EMSTATE directory, see What Is EMSTATE Directory?.

Prerequisites

Before upgrading the Master Agent, ensure that you meet the following prerequisites:

Meet the prerequisites described for the upgrade methodology you choose to use for upgrading the Master Agent:

If you choose to upgrade the Master Agent using the Agent Upgrade Wizard, then meet the prerequisites described in Chapter 24, "Upgrading Oracle Management Agent Using Agent Upgrade Wizard".

If you choose to upgrade the Master Agent using a response file, then meet the prerequisites described in Chapter 25, "Upgrading Oracle Management Agent Using a Response File".

If you choose to upgrade the Master Agent using the agentDownload script, then meet the prerequisites described in Chapter 26, "Upgrading Oracle Management Agent Using agentDownload Script".

Ensure that the installation base directory of the upgraded Master Agent (agent11g) is mounted and is visible from all remote hosts. For information about installation base directory, see What Is Installation Base Directory?.

Ensure that the inventory directory of the Master Agent is maintained as the inventory directory of the Shared Agent as well. For example, if the inventory directory of the Master Agent is /scratch/oraInventory, then ensure that the inventory directory of the Shared Agent also is /scratch/oraInventory.

Ensure that the oraInst.loc is present in either the EMSTATE directory, the central inventory (/etc/oraInst.loc), or the user's home directory.

Upgrade Procedure

You can upgrade the Master Agent using the upgrade procedures described in Part V, "Upgrading Enterprise Manager System" and Part VI, "Upgrading Oracle Management Agent".

After the Master Agent is upgraded, the Oracle home of the Master Agent will be fully configured and will share its binaries to other Shared Agents.

After You Upgrade

Typically, when you upgrade a Master Agent, the associated Share Agents also get automatically upgraded. However, Oracle recommends you to verify if all the Shared Agents have been successfully upgraded. To do so, navigate to the EMSTATE directory of each of the Shared Agents and run the following command to verify each of them.

<EMSTATE>/bin/emctl status agent

If the status is UP and if it shows that the upgraded Management Agent is running, then you should see two EMSTATE directories, mainly <EMSTATE> and <EMSTATE>_<timestamp>. While the former represents the upgraded Shared Agent, the latter represents a backup of the old <EMSTATE> directory.

Navigate to the <EMSTATE> directory of the upgraded Shared Agent and review the following log files:

<EMSTATE>/nfslog/NFSAgentUpgrade_<timestamp>.log

<EMSTATE>/nfslog/NFSAgentUpgrade_API_<timestamp>.log

<EMSTATE>/nfslog/NFSAgentUpgrade_CfmLogger_<timestamp>.log

Note:

You can delete the <EMSTATE>_<timestamp> directory after verifying the upgrade.

If the status is DOWN or if it shows that the previous release of the Management Agent is up and running, then you should see two EMSTATE directories, mainly <EMSTATE> and <EMSTATE>_<timestamp>.Upgrade_Failed. While the former represents the old <EMSTATE> directory, the latter represents the new <EMSTATE> directory for which the Shared Agent upgrade failed.

Navigate to the <EMSTATE>_<timestamp>.Upgrade_Failed directory and review the following log files:

<EMSTATE>_<timestamp>.Upgrade_Failed/nfslog/NFSAgentUpgrade_<timestamp>.log

<EMSTATE>_<timestamp>.Upgrade_Failed/nfslog/NFSAgentUpgrade_API_<timestamp>.log

<EMSTATE>_<timestamp>.Upgrade_Failed/nfslog/NFSAgentUpgrade_CfmLogger_<timestamp>.log

Fix the issues identified in the log files.

Navigate to the <EMSTATE> directory and remove the following file:

<EMSTATE>/agentpatch/6867392

Navigate to the <EMSTATE> directory and stop the Shared Agent by running the following command:

<EMSTATE>/bin/emctl stop agent

Now, restart the Shared Agent by running the following command:

<EMSTATE>/bin/emctl start agent

Note:

You can delete the <EMSTATE>_<timestamp>.Upgrade_Failed directory after upgrading the Shared Agent.

28 Upgrading Oracle Management Agent with Add-Ons

This chapter describes how you can upgrade an existing Oracle Management Agent 10g Release 4 (10.2.0.4.0) or higher that has add-ons to Oracle Management Agent 11g Release 1 (11.1.0.1.0).

In particular, this chapter covers the following:

Overview

Before You Begin

Prerequisites

Upgrade Management Agent

After You Upgrade

Configuration Procedure

After You Configure

Overview

When you upgrade Oracle Management Agent (Management Agent), the add-ons that have been installed on it are NOT carried over to the upgraded version of the Management Agent. The upgrade process is an out-of-place upgrade, that is, it creates a new Oracle home for the upgraded version of the Management Agent (agent11g).

Due to this reason, the add-ons that were installed on the older release of the Management Agent are NOT automatically reinstalled on the upgraded version.

If you want to continue to use them, then you must first upgrade the software binaries of the existing Management Agent, then install the add-ons, and then finally configure the upgraded software binaries of the Management Agent.

Note:

If you are upgrading a Management Agent whose software binaries were used for installing additional Management Agents, either using the Shared Agent Deployment Wizard or the nfsagentinstall script, then before proceeding any further, read Chapter 27, "Upgrading Shared Oracle Management Agent".

Before You Begin

Before you begin, keep in mind the points described in Before You Begin.

Prerequisites

Before upgrading a Management Agent that has add-ons, ensure that you meet the prerequisites described in Prerequisites.

Upgrade Management Agent

To upgrade an existing Management Agent that has add-ons, follow these steps:

Stop the Management Agent you want to upgrade.

On the host where you want to upgrade the Management Agent, download the Management Agent Software as described in Procuring Oracle Management Agent Software.

Navigate to the following location and edit the response file upgrade_agent.rsp as described in Table 25-1.

<Software_Location>/<platform>/response/

Invoke the installer:

If you have the default name for the Oracle home of your existing Management Agent, that is, agent10g, then run the following command:

./runInstaller -noconfig -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file>

If you have a custom name for the Oracle home of your existing Management Agent, then run the following command:

./runInstaller -noconfig -silent -responseFile <absolute_path_to_upgrade_agent.rsp_file> s_oldAgentHome=<absolute_path_to_Old_Oracle_Home>

After You Upgrade

After you upgrade the software binaries of the Management Agent, follow these steps to install the add-ons in the Oracle home of the Management Agent.

Create a response file titled addon_agent.rsp, and specify the following details:

RESPONSEFILE_VERSION=2.2.1.0.0
FROM_LOCATION=<full path of products.xml>
DEINSTALL_LIST={"<add-on agent component name>","<add-on agent component version>"}
TOPLEVEL_COMPONENT={"<add-on agent component name>","<add-on agent component version>"}
ORACLE_HOME=<Agent OracleHome>
ORACLE_HOME_NAME=<name of the Oracle Home>
b_upgrade=false
b_silentInstall=true
ACCEPT_LICENSE_AGREEMENT=true

Run the following command from the Oracle home of the Management Agent and pass the response file to install the add-ons:

$<ORACLE_HOME>/oui/bin/runInstaller -noconfig -silent -responseFile <absolute_path_to_Location>

Configuration Procedure

After installing the add-ons, configure the Management Agent by running the following command:

If you are upgrading a standalone Management Agent, then run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/bin/agentca -u

If you are upgrading a cluster-based Management Agent, then on each of the nodes of the cluster, run the following command:

$<ORACLE_HOME>/bin/agentca -u -c <node1,node2,node3,...nodeN> -r <absolute_path_to_Response_File>

Note:

In this command, -c lists the nodes of the cluster separated by a comma, and the response file is a user-defined response file that contains the following entry to refer to the node on which you are invoking the agentca script.

s_hostname=<Node_Name>

You can ascertain the node name from the old Oracle home of the Management Agent by running the following command:

$<ORACLE_HOME>/bin/emctl getemhome

For example, if you have a cluster of three nodes, mainly node1, node2, node3, then create a response file called response.rsp with the entry s_hostname=node1, and on node1, run the following command:

$<ORACLE_HOME>/bin/agentca -u -c node1,node2,node3 -r /home/john/response.rsp

Now, update the response file to reflect s_hostname=node2, and on node2, run the same command. Finally, update the response file to reflect s_hostname=node3, and on node3, run the same command.

After You Configure

After configuring the Management Agent, follow the steps outlined in After You Upgrade.

Part VII

Deinstalling Enterprise Manager System

This part describes the different ways of deinstalling Enterprise Manager Grid Control.

In particular, this part contains the following chapters:

Chapter 29, "Deinstalling Enterprise Manager System in Graphical Mode"

Chapter 30, "Deinstalling Enterprise Manager System in Silent Mode"

29 Deinstalling Enterprise Manager System in Graphical Mode

This chapter describes how you can deinstall Enterprise Manager Grid Control (either the entire Enterprise Manager Grid Control system or one or more Oracle Management Services), in graphical mode. In particular, this chapter covers the following:

Prerequisites

Deinstallation Procedure

After You Deinstall

Note:

If you want to deinstall Oracle WebLogic Server, then refer to My Oracle Support note 1071392.1.

Prerequisites

Before you deinstall Enterprise Manager Grid Control, follow these steps:

Delete Oracle Management Service (OMS) by running the following command from the Oracle home of the OMS. This command automatically stops the OMS, Oracle WebLogic Server, and also Oracle WebTier.

<ORACLE_HOME>/bin/omsca delete -full

Shut down Oracle Management Agent (Management Agent) by running the following command from the Oracle home of the Management Agent:

<ORACLE_HOME>/bin/emctl stop agent

If you want to deinstall the entire Enterprise Manager Grid Control system, including Oracle Management Repository (Management Repository) that is configured in your database, then after deleting all the OMSes and the Management Agents, follow these steps:

Drop the Enterprise Manager Grid Control schema (SYSMAN schema) and the Metadata schema (MDS schema) from the Management Repository by running the following command from the Oracle home of the OMS:

<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <database_host> <repository_database_port> <repository_database_sid> -action dropall -dbUser <repository_database_user> -dbPassword <repository_database_password> -dbRole <repository_database_user_role> -reposName <repository_name> -reposPassword <repository_password> -mwHome <middleware_home> -mwOraHome <middleware_ora_home> -oracleHome <oracle_home>

Note:

For Microsoft Windows, invoke RepManager.bat.

RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN). However, RepManager 10.2.0.5 supports -action drop (drops only SYSMAN)

Manually delete the data files mgmt.dbf and mgmt_ecm_depot1.dbf from the Oracle home of the database.

WARNING:

Once the Management Repository is dropped, it CANNOT be retrieved. Therefore, drop the Management Repository ONLY IF you want to deinstall the entire Enterprise Manager Grid Control system, that is, all your OMSes, Management Agents, and also the Management Repository. If you want to deinstall only an OMS (additional OMS installation), then do not drop the Management Repository.

Deinstallation Procedure

To deinstall Enterprise Manager Grid Control, follow these steps:

Invoke the installer from the Oracle home of the OMS by running the following command:

$<ORACLE_HOME>/oui/bin/runInstaller -removeallfiles

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

In the Enterprise Manager Grid Control Installation Wizard, on the My Oracle Support Details screen, click Installed Products.

On the Inventory screen, select the following and click Remove.

Oracle home of the OMS (oms11g).

For example, /u01/app/Oracle/Middleware/oms11g

Oracle home of the Management Agent (agent11g).

For example, /u01/app/Oracle/Middleware/agent11g

Oracle home of Oracle WebTier (Oracle_WT) that is present in the Oracle Middleware Home.

For example, /u01/app/Oracle/Middleware/Oracle_WT

Common directory (oracle_common) that is present in the Oracle Middleware Home.

For example, /u01/app/Oracle/Middleware/oracle_common

Oracle Management Service Instance Base (gc_inst or any other custom name specified by you) that is present in the parent directory of the Oracle Middleware Home.

For example, /u01/app/Oracle/gc_inst

Note:

If the parent directory of the Oracle Middleware Home did not have write permission, then the Oracle Management Service Instance Base might have been created in the Oracle Middleware Home.

After You Deinstall

After you deinstall the Oracle homes, follow these steps:

Verify whether the Oracle homes and other directories were successfully deinstalled. To do so, follow these steps:

Invoke the installer from the Oracle home of the OMS by running the following command:

$<ORACLE_HOME>/oui/bin/runInstaller

Note:

For Microsoft Windows, invoke setup.exe.

In the Enterprise Manager Grid Control Installation Wizard, on the My Oracle Support Details screen, click Installed Products.

On the Inventory screen, check whether or not the Oracle homes and other directories you deinstalled appear. If the deinstallation was successful, then those Oracle homes and directories should not appear.

The Oracle homes you deinstalled are deregistered from the central inventory and the oratab file. However, some files might still remain in these Oracle homes. You might also see the OMS instance base directory and the Oracle home for Web Tier. You can manually delete these files and directories.

You must also manually delete all auto-start scripts present in the /etc/rc.d/ directory. For example, /etc/rc.d/rc3.d/S98gcstartup.

If you deinstalled on a Microsoft Windows platform, then follow these steps. Ensure that you are logged in as a user with Administrator privileges on that host.

Remove Entries from Microsoft Windows Registry

Start the registry editor by selecting Start and then Run. Type regedit and click OK.

Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\

Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\ODBC and expand all the subkeys, and remove the key Oracle in <HOME_NAME>. Check whether the Oracle ODBC Driver key contents refer to the ORACLE_HOME deinstalled. If yes, delete the key.

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Delete the keys that begin with Oracle.

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet2\Services. Delete the keys that begin with Oracle.

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\...\Application. Delete the keys that begin with Oracle and contain references to the EventMessageFile string entry for the ORACLE_HOME deinstalled or a location under it.

Navigateto HKEY_CLASSES_ROOT and search in the keys starting with Ora or ORCL (for example, Oracle..., ORADC... ..., OraPerf..and ORCL...). Delete keys which include string values with the specific ORACLE_HOME deinstalled.

Exit from the registry editor.

Clean Up Environment Settings

Open the Environment Variables window.

On Microsoft Windows NT, select Start, Settings, Control Panel, System, and then Environment.

On Microsoft Windows XP or 2000, select select Start, Settings, Control Panel, System, Advanced, and then Environment Variables.

In the System Variables section, click the variable PATH in order to modify the value.

For example, you may see a path similar to this one:

C:\ORACLE\EM10g\BIN
C:\PROGRAM FILES\ORACLE\JRE\1.1.7\BIN

If you are deleting the Oracle home C:\ORACLE\EM11g, then remove the C:\ORACLE\EM11g\BIN expression from the PATH variable.

Delete any path expression in the PATH variable that contains the ORACLE_HOME deinstalled or a location under it.

If there is a CLASSPATH variable under System Variables, then delete the path expressions in the variable that contains the ORACLE_HOME deinstalled or a location under it.

Check whether there are any other Oracle variables set in System Variables. Delete those variables that contain the ORACLE_HOME deinstalled.

For example, ORACLE_HOME, ORACLE_SID, TNS_ADMIN, inventory_loc, and so on.

Click Apply and then click OK.

Close the Control Panel window.

Delete Software and Start Menu Icons

Navigate to the Programs directory.

On Microsoft Windows NT, navigate to %SystemDrive%\WINNT\PROFILES\ALL USERS\START MENU\PROGRAMS

On Microsoft Windows 2000 and Windows XP, navigate to %SystemDrive%\DOCUMENTS AND SETTINGS\ALL USERS\START MENU\ ...\PROGRAMS

Note:

These locations depend on whether the operating system was upgraded from Microsoft Windows NT or was a new install of Microsoft Windows 2000 or Microsoft Windows XP.

Delete the folders -Oracle - <HOME_NAME> where <HOME_NAME> is the ORACLE_HOME deinstalled.

Note:

To locate your System Drive, type echo %SystemDrive% in the command prompt.

Navigate to the temp directory and delete all files and directories at the following locations:

On Microsoft Windows NT: %SystemDrive%\Temp

On Microsoft Windows 2000 and Microsoft Windows XP: %SystemDrive%\Documents and Settings\<username>\Local Settings\Temp\

Restart the host.

30 Deinstalling Enterprise Manager System in Silent Mode

This chapter describes how you can deinstall Enterprise Manager Grid Control (either the entire Enterprise Manager Grid Control system or one or more Oracle Management Services), in silent mode. In particular, this chapter covers the following:

Prerequisites

Deinstallation Procedure

After You Deinstall

Note:

If you want to deinstall Oracle WebLogic Server, then refer to My Oracle Support note 1071392.1.

Prerequisites

Before you deinstall Enterprise Manager Grid Control, meet the prerequisites described in Prerequisites.

Deinstallation Procedure

To deinstall Enterprise Manager Grid Control, run the following command from the Oracle home of the OMS:

$<ORACLE_HOME>/oui/bin/runInstaller -silent -responseFile <absolute_path_to_response_file> -deinstall "REMOVE_HOMES={absolute_path_to_oracle_homes_and_directories_to_be_deinstalled}" -removeallfiles

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

For the REMOVE_HOMES argument, specify the following to be deinstalled:

Oracle home of the OMS (oms11g).

For example, /u01/app/Oracle/Middleware/oms11g

Oracle home of the Management Agent (agent11g).

For example, /u01/app/Oracle/Middleware/agent11g

Oracle home of Oracle WebTier (Oracle_WT) that is present in the Oracle Middleware Home.

For example, /u01/app/Oracle/Middleware/Oracle_WT

Common directory (oracle_common) that is present in the Oracle Middleware Home.

For example, /u01/app/Oracle/Middleware/oracle_common

Oracle Management Service Instance Base (gc_inst or any other custom name specified by you) that is present in the Oracle Middleware Home.

For example, /u01/app/Oracle/gc_inst

Note:

If the parent directory of the Oracle Middleware Home did not have write permission, then the Oracle Management Service Instance Base might have been created in the Oracle Middleware Home.

For example:

$<ORACLE_HOME>oui/bin/runInstaller -silent -responseFile /scratch/deinstall.rsp -deinstall "REMOVE_HOMES={/u01/app/Oracle/Middleware/oms11g,/u01/app/Oracle/Middleware/agent11g, /u01/app/Oracle/Middleware/Oracle_WT, /u01/app/Oracle/Middleware/oracle_common, /u01/app/Oracle/gc_inst}" -removeallFiles

After You Deinstall

After you deinstall the Oracle homes, follow the steps described in After You Deinstall.

Part VIII

Deinstalling Oracle Management Agent

This part describes the different ways of deinstalling Oracle Management Agent.

In particular, this part contains the following chapters:

Chapter 31, "Deinstalling Oracle Management Agent in Graphical Mode"

Chapter 32, "Deinstalling Oracle Management Agent in Silent Mode"

31 Deinstalling Oracle Management Agent in Graphical Mode

This chapter describes how you can deinstall standalone Oracle Management Agent (Management Agent) or cluster-based Management Agent from all nodes of a cluster, in graphical mode. In particular, this chapter covers the following:

Prerequisites

Deinstallation Procedure

After You Deinstall

Note:

For more information about deinstalling a Management Agent only from one node of a cluster and deinstalling shared Management Agents, see Chapter 32, "Deinstalling Oracle Management Agent in Silent Mode".

Prerequisites

Before you deinstall a Management Agent, shut it down by running the following command from its Oracle home:

<ORACLE_HOME>/bin/emctl stop agent

Deinstallation Procedure

This section describes the following:

Deinstalling Standalone or Cluster-Based Oracle Management Agents

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

Deinstalling Standalone or Cluster-Based Oracle Management Agents

To deinstall standalone Management Agents or cluster-based Management Agents from all the nodes of a cluster, run the following command from the Oracle home of the Management Agent:

Invoke the installer from the Oracle home of the Management Agent by running the following command:

$<ORACLE_HOME>/oui/bin/runInstaller -removeallfiles

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

In the Enterprise Manager Grid Control Installation Wizard, on the My Oracle Support Details screen, click Installed Products.

On the Inventory screen, select the Oracle home of the Management Agent (agent11g) and click Remove.

For example, /u01/app/Oracle/Middleware/agent11g

Note:

On a cluster, this procedure deinstalls the Management Agents from all the nodes.

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

To deinstall a cluster-based Management Agent from only one node of a cluster, follow these steps:

On the node where you want to deinstall the Management Agent, after shutting down the Management Agent as described in Prerequisites, invoke the installer from the Oracle home of the Management Agent by running the following command:

$<ORACLE_HOME>/oui/bin/runInstaller -local -removeallfiles

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

In the Enterprise Manager Grid Control Installation Wizard, on the My Oracle Support Details screen, click Installed Products.

On the Inventory screen, select the Oracle home of the Management Agent (agent11g) and click Remove.

For example, /u01/app/Oracle/Middleware/agent11g

From all other nodes, run the following command:

./runInstaller -updateNodeList ORACLE_HOME=<Oracle_Home_of_Agent> "CLUSTER_NODES=<other_nodes_separate_by_a_comma>"

For example, if you have a cluster of five nodes, and if you have run Step (1) on node1, then run this command on node2, nod3, node4, and node5:

./runInstaller -updateNodeList ORACLE_HOME=<Oracle_Home_of_Agent> "CLUSTER_NODES=<node2, node3, node4, node5>"

After You Deinstall

After you deinstall the Management Agent, follow these steps:

Verify whether the Oracle homes and other directories were successfully deinstalled. To do so, follow these steps:

Invoke the installer by running the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/oui/bin/runInstaller

Note:

For Microsoft Windows, invoke setup.exe instead of runInstaller.

In the Enterprise Manager Grid Control Installation Wizard, on the My Oracle Support Details screen, click Installed Products.

On the Inventory screen, check whether or not the Oracle homes and other directories you deinstalled appear. If the deinstallation was successful, then those Oracle homes and directories should not appear.

The Oracle homes you deinstalled are deregistered from the central inventory and the oratab file. However, some files might still remain in these Oracle homes. If they do, you can manually delete them.

You must also manually delete all auto-start scripts present in the /etc/rc.d/ directory. For example, /etc/rc.d/rc3.d/S98gcstartup.

If you deinstalled on a Microsoft Windows platform, then follow these steps. Ensure that you are logged in as a user with Administrator privileges on that host.

Remove Entries from Microsoft Windows Registry

Start the registry editor by selecting Start and then Run. Type regedit and click OK.

Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Oracle and remove the Management Agent entry.

For example, if you have Management Agent 11g, then you select and remove the following:

HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\Key_agent11g

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Delete the Management Agent keys.

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet2\Services. Delete the Management Agent service.

Exit from the registry editor.

Clean Up Environment Settings

Open the Environment Variables window.

On Microsoft Windows NT, select Start, Settings, Control Panel, System, and then Environment.

On Microsoft Windows XP or 2000, select select Start, Settings, Control Panel, System, Advanced, and then Environment Variables.

In the System Variables section, click the variable PATH and modify the value.

Delete Management Agent home.

Click Apply and then click OK.

Close the Control Panel window.

Restart the host.

Note:

On a cluster, restart all the nodes.

32 Deinstalling Oracle Management Agent in Silent Mode

This chapter describes how you can deinstall Oracle Management Agent (Management Agent). In particular, this chapter covers the following:

Prerequisites

Deinstallation Procedure

After You Deinstall

Prerequisites

Before you deinstall a Management Agent, meet the prerequisites described in Prerequisites.

Deinstallation Procedure

This section describes the following:

Deinstalling Standalone or Cluster-Based Oracle Management Agents

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

Deinstalling Shared Oracle Management Agent

Deinstalling Standalone or Cluster-Based Oracle Management Agents

To deinstall standalone Management Agents or cluster-based Management Agents from all nodes of a cluster, run the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_agent_oracle_home}" -removeallfiles

For example:

$<ORACLE_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/agent11g}" -removeallfiles

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

Deinstalling Cluster-Based Oracle Management Agent from Only One Node of a Cluster

To deinstall a cluster-based Management Agent from only one node of a cluster, follow these steps:

On the node from where you want to deinstall the Management Agent, run the following commands:

Update the node list by running the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/oui/bin/runInstaller -updateNodeList ORACLE_HOME=<absolute_path_to_agent_oracle_home> "CLUSTER_NODES={<local_node_name>}" -local

For example (assuming that node1 is one of the five nodes of a cluster):

$<ORACLE_HOME>/oui/bin/runInstaller -updateNodeList ORACLE_HOME=</u01/app/Oracle/Middleware/agent11g> "CLUSTER_NODES={node1}" -local

Note:

For Microsoft Windows, invoke setup.exe.

Deinstall the Management Agent by the running the following command from the Oracle home of the Management Agent:

$<ORACLE_HOME>/oui/bin/runInstaller -silent "REMOVE_HOMES={absolute_path_to_agent_oracle_home}" -deinstall -waitForCompletion -removeallfiles -local -forceDeinstall

For example:

$<ORACLE_HOME>/oui/bin/runInstaller -silent "REMOVE_HOMES={/u01/app/Oracle/Middleware/agent11g}" -deinstall -waitForCompletion -removeallfiles -local -forceDeinstall

Note:

For Microsoft Windows, invoke setup.exe. Also, when you runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

On each of the other nodes of the cluster, run the following command from the Oracle home of the Management Agent:

./runInstaller -updateNodeList ORACLE_HOME=<absolute_path_to_agent_oracle_home> "CLUSTER_NODES={<comma-separated_list_of_other_nodes>}"

For example (node2, node3, node4, and node5 are the other nodes of a five-node cluster):

./runInstaller -updateNodeList ORACLE_HOME=</u01/app/Oracle/Middleware/agent11g> "CLUSTER_NODES=<node2, node3, node4, node5>"

Note:

For Microsoft Windows, invoke setup.exe.

Deinstalling Shared Oracle Management Agent

To deinstall a shared Management Agent (Shared Agent), that is, a Management Agent that was installed using a shared Oracle home of an existing Management Agent (Master Agent), run the following command from the Oracle home of the Management Agent (Shared Agent). In this command, -InvPtrLoc need not be specified if the inventory pointer is Central Inventory.

<ORACLE_HOME>sysman/install/nfs_agent_deinstall -EMStateDir <EMSTATE_Directory_Location> [ -InvPtrLoc <Inventory pointer location> ]

After You Deinstall

After you deinstall the Oracle homes, follow the steps described in After You Deinstall.

Part IX

Using Enterprise Manager Grid Control

This part describes how you can get started with Enterprise Manager Grid Control. Essentially, it explains how you can access the console, how you can log in, and so on.

This part contains the following chapters:

Chapter 33, "Using Enterprise Manager Grid Control"

33 Using Enterprise Manager Grid Control

This chapter describes how you can get started with using Enterprise Manager Grid Control. In particular, this chapter covers the following:

Accessing Enterprise Manager Grid Control

Logging In

Enabling or Disabling Licenses

Accessing Online Help

Accessing Enterprise Manager Grid Control

You can access Enterprise Manager Grid Control using the following URL:

http://<oms_hostname>.<domain>:<port>/em

If you have secured the communications, then use HTTPS protocol. For information about default upload and console ports, see What Ports Are Used for Installation?.

Logging In

You can log in using the default super administrator account, SYSMAN, that is created with the password you specified during the installation.

Enabling or Disabling Licenses

Before you begin using Enterprise Manager Grid Control, you must first set the access levels according to your licensing agreement with Oracle. To do this, perform the following steps using a super administrator account, such as SYSMAN.

After you log in using SYSMAN, in the Grid Control, click Setup, then Management Pack Access.

On the Management Pack Access page, from the View Options section, select Licensable Targets.

For Pack Access, select Pack Based Batch Update.

If you want to enable a pack, then in the Available Packs selection pane, do the following:

From the Type list, select All Licensable Targets.

From the selection pane, select a pack you want to enable.

Click Move.

For Access, select Enable.

Click Apply.

If you want to disable a pack, then in the Selected Packs selection pane:

Select a pack you want to disable.

Click Remove.

For Access, select Disable.

Click Apply.

Note:

Once a pack is disabled, the function associated with the selected pack is no longer available for any targets managed by Enterprise Manager Grid Control.

Accessing Online Help

Almost every page in Enterprise Manager Grid Control has an online help topic associated with it. If you need information about the page or the use cases supported by a particular functionality exposed by the page, then click Help on that screen.

Part X

Appendixes

This part contains the following appendixes:

Appendix A, "Meeting Hardware Requirements"

Appendix B, "Meeting Package, Kernel Parameter, and Library Requirements "

Appendix C, "Creating Operating System Groups and Users Requirements"

Appendix D, "Setting Up SSH Connectivity"

Appendix E, "Validating Command Locations"

Appendix F, "Passing Additional Parameters"

Appendix G, "Configuring Database and ASM Targets for Monitoring"

Appendix H, "Setting Up Proxy Configuration for Oracle Management Service"

Appendix I, "Reconfiguring Oracle Management Agent and Discovering New Targets"

Appendix J, "Understanding Optional Arguments Run with ConfigureGC.pl Script"

Appendix K, "Using RepManager Utility"

Appendix L, "Installation and Configuration Log Files"

Appendix M, "List of Deprecated Features"

The script content on this page is for navigation purposes only and does not alter the content in any way.

A Meeting Hardware Requirements

This appendix describes the hardware requirements you must meet before installing Oracle Management Service (OMS), a standalone Oracle Management Agent (Management Agent), and Oracle Management Repository.

Note:

For information about the hard disk space required and the ulimits to be set for OMS and standalone Management Agent, see My Oracle Support note 1076752.1. For information about planning and sizing your Enterprise Manager deployment, refer to the Oracle Enterprise Manager Administration Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Table A-1 shows the minimum physical memory (RAM) required for installing an OMS and a standalone Management Agent:

Table A-1 Required Physical Memory for Oracle Management Service and Oracle Management Agent

Installation Type
Physical Memory (RAM)

Oracle Management Service

3 GB

Oracle Management Service with ADP ManagerFoot 1 

6 GB

Oracle Management Agent (standalone)

512 MB

Oracle Management Agent (standalone) with ADP Manager

1 GB

Footnote 1 ADP Manager is Application Dependency and Performance Manager

Note:

For information about ADP and for instructions to enable the ADP feature in Enterprise Manager Grid Control, refer to the Oracle Enterprise Manager Getting Started with Management Pack Plus for SOA.

Both these guides are available at:

http://www.oracle.com/technology/documentation/oem.html

For Microsoft Windows 32-bit hosts, the RAM required is 4 GB.

Table A-2 shows the recommended physical memory (RAM) for installing an OMS and a standalone Management Agent:

Table A-2 Recommended Physical Memory for Oracle Management Service and Oracle Management Agent

Deployment Size
Installation Type
Physical Memory (RAM)

Small

(< 100 monitored targets)

Oracle Management Service

3 GB

Oracle Management Service with ADP ManagerFoot 1 

6 GB

Medium

(< 1000 monitored targets)

Oracle Management Service

4 GB

Oracle Management Service with ADP Manager

6 GB

Large

(< 10,00 monitored targets)

Oracle Management Service

6 GB

Oracle Management Service with ADP Manager

8 GB

Footnote 1 ADP Manager is Application Dependency and Performance Manager

Table A-3 shows the recommended physical memory (RAM) and the hard disk space required for configuring a Management Repository.

Table A-3 Recommended Physical Memory and Hard Disk Space for Oracle Management Repository

Deployment Size
Physical Memory (RAM)
Hard Disk Space

Small

(< 100 monitored targets)

2 GB

50 GB

Medium

(< 1000 monitored targets)

4 GB

100 GB

Large

(< 10,000 monitored targets)

6 GB

400 GB

B Meeting Package, Kernel Parameter, and Library Requirements

This appendix describes the packages and libraries required on different operating systems (32-bit as well as 64-bit) for installing Oracle Management Service (OMS) and Oracle Management Agent (Management Agent).

In particular, this appendix covers the following:

Package Requirements for Oracle Management Service

Package Requirements for Oracle Management Agent

Kernel Parameter Requirements for Oracle Management Service and Oracle Management Agent

Library Requirements for Oracle Management Service

Note:

The packages and libraries are NOT required for Microsoft Windows operating systems.

Package Requirements for Oracle Management Service

Table B-1 describes the packages required on different platforms for installing an OMS:

Table B-1 Package Requirements for Oracle Management Service

Operating System
Package

Red Hat Enterprise Linux 4

Oracle Linux 4

kernel-utils-2.4

make-3.80

binutils-2.15.92.0.2-13

gcc-3.4.5

libaio-0.3.105

glibc-common-2.3.4-2.9

compat-libstdc++-296 -2.96-132.7.2

libstdc++-3.4.3-22.1

libstdc++-devel-3.4.3-22.1

pdksh-5.2.14-30

setarch-1.6-1

sysstat-5.0.5-1

compat-db-4.1.25-9

Red Hat Enterprise Linux 5.x

Oracle Linux 5.x

rng-utils-2

make-3.81

binutils-2.17.50.0.6

gcc-4.1.1

libaio-0.3.106

glibc-common-2.3.4-2.9

compat-libstdc++-296 -2.96-132.7.2

libstdc++-4.1.1

libstdc++-devel-4.1.1

setarch-1.6-1

sysstat-5.0.5-1

compat-db-4.1.25-9

Asianux Linux 3

make-3.81

binutils-2.17.50.0.6

gcc-4.1.1

libaio-0.3.106

glibc-common-2.3.4

compat-libstdc++-296-2.96

libstdc++-4.1.1

libstdc++-devel-3.4.3

setarch-1.6-1

sysstat-5.0.5-1

compat-db-4.1.25

SUSE Linux Enterprise Server 10

make-3.80

binutils-2.16.91.0.5

gcc-4.1.0

Solaris Sparc 5.9

SUNWlibm

SUNWlibms

SUNWsprot

SUNWsprox

SUNWtoo

SUNWi1of

SUNWxwfnt

Solaris Sparc 5.10

SUNWbtool

HP PA-RISC 11.23

BUNDLE11i(B.11.23.0409.3)

HP PA-RISC 11.31

Base-VXFS(B.11.31)

OnlineDiag(B.11.31.01.03)

HP-UX Itanium-11.23

BUNDLE11i(B.11.23.0409.3)

HP-UX Itanium-11.31

BUNDLE(B.11.31)

IBM AIX 5.3

bos.perf.proctools

bos.adt.base.0.0

bos.adt.libm.0.0

In addition, manually enable asynchronous I/O. To do so, follow these steps:

Start smitty aio.

Run Change/Show Characteristics of Asynchronous I/O.

Set the STATE to be configured at system restart as available.

Note: This procedure does not require you to restart the system.

IBM AIX 6.1

bos.adt.base.0.0

bos.adt.lib.0.0

bos.adt.libm.0.0

bos.perf.libperfstat0.0

bos.perf.perfstat0.0

bos.perf.proctools0.0

rsct.basic.rte0.0

rsct.compat.clients.rte0.0

xlC.aix61.rte.9.0.0.0

xlC.rte.9.0.0.0

In addition, manually enable asynchronous I/O. To do so, follow these steps:

Start smitty aio.

Run Change/Show Characteristics of Asynchronous I/O.

Set the STATE to be configured at system restart as available.

Note: This procedure does not require you to restart the system.

Package Requirements for Oracle Management Agent

Table B-2 describes the packages required on different platforms for installing a Management Agent:

Table B-2 Package Requirements for Oracle Management Agent

Operating System
Package

Red Hat Enterprise Linux 4

Oracle Linux 4

make-3.80

binutils-2.15.92.0.2

gcc-3.4.5

libstdc++-3.4.5

Red Hat Enterprise Linux 5.x

Oracle Linux 5.x

make-3.81

binutils-2.17.50.0.6

gcc-4.1.1

libstdc++-4.1.1

libaio

glibc-devel (64-bit)

glibc-devel (32-bit)

Asianux Linux 1

make-3.79

binutils-2.14

gcc-3.2

Asianux Linux 2

make-3.80

binutils-2.15.92.0.2

gcc-3.4.5

libstdc++-3.4.5

Asianux Linux 3

make-3.81

binutils-2.17.50.0.6

gcc-4.1.1

libstdc++-4.1.1

United Linux 1

make-3.79

binutils-2.14

gcc VERSION-3.2

SUSE Linux Enterprise Server 10

SUSE Linux Enterprise Server 11

make-3.80

binutils-2.16.91.0.5

gcc-4.1.0

libstdc++-4.1.0

Solaris Express 5.11 x86-64

Note: The supported Kerne lID is 175.0.0.0.2.0,151.0.1.12.

To check the kernel ID, run the following command:

uname -X |grep KernelID

SUNWbtool

sunwarc

SUNWhea

SUNWlibm

SUNWlibms

SUNWsprot

SUNWtoo

SUNWlibC

SUNWcsl

Note: While installing the Management Agent, there might be prerequisite checks checking for obsolete packages on Solaris Express 5.11 x86-64 and Solaris Sparc Express 5.11 (64 bit), particularly packages such as SUNWi1of, SUNWi1cs, SUNWi15cs, and SUNWxwfnt. If such prerequisite checks fail, ignore the failure and proceed with the installation.

Solaris Sparc 5.9

SUNWlibm

SUNWlibms

SUNWsprot

SUNWsprox

SUNWtoo

SUNWi1of

SUNWxwfnt

Solaris Sparc 5.10

SUNWbtool

Solaris Sparc Express 5.11 (64 bit)

Note: The supported Kernel ID is 175.0.0.0.2.0,151.0.1.12.

To check kernel ID, run the following command:

uname -X |grep KernelID

SUNWbtool

sunwarc

SUNWhea

SUNWlibm

SUNWlibms

SUNWsprot

SUNWtoo

SUNWlibC

SUNWcsl

Note: While installing the Management Agent, there might be prerequisite checks checking for obsolete packages on Solaris Express 5.11 x86-64 and Solaris Sparc Express 5.11 (64 bit), particularly packages such as SUNWi1of, SUNWi1cs, SUNWi15cs, and SUNWxwfnt. If such prerequisite checks fail, ignore the failure and proceed with the installation.

HP PA-RISC 11.23

BUNDLE11i(B.11.23.0409.3)

HP PA-RISC 11.31

Base-VXFS(B.11.31)

OnlineDiag(B.11.31.01.03)

HP-UX Itanium-11.23

BUNDLE11i(B.11.23.0409.3)

HP-UX Itanium-11.31

BUNDLE(B.11.31)

IBM AIX 5.3

bos.perf.proctools(5.3.0.50)

IBM AIX 6.1

bos.adt.base.0.0

bos.adt.lib.0.0

bos.adt.libm.0.0

bos.perf.libperfstat0.0

bos.perf.perfstat0.0

bos.perf.proctools0.0

rsct.basic.rte0.0

rsct.compat.clients.rte0.0

xlC.aix61.rte.9.0.0.0

xlC.rte.9.0.0.0

Kernel Parameter Requirements for Oracle Management Service and Oracle Management Agent

If you are installing an OMS or a Management Agent on any Linux operating sytem (Red Hat Enterprise Linux 4 or 5, Oracle Linux 4 or 5, Asianux Linux 3, and SUSE Linux Enterprise Server 10), then set the kernel.shmmax parameter to a value that is not greater than 4 GB.

Library Requirements for Oracle Management Service

Table B-3 describes the libraries required on different platforms for installing an OMS:

Table B-3 Library Requirements for Oracle Management Service

Operating System
Library

Red Hat Enterprise Linux 4

Oracle Linux 4

GLIBC-2.3.4-2.19

Red Hat Enterprise Linux 5.x

Oracle Linux 5.x

GLIBC-2.5-12

Asianux Linux 3

GLIBC-2.3.4-2.9

SUSE Linux Enterprise Server 10

GLIBC-2.2.4-31.7

C Creating Operating System Groups and Users Requirements

The appendix explains what operating system groups and users you need to create and how to create them. In particular, this appendix covers the following:

What Operating System Groups and Users Are Required?

How To Create the Operating System Groups and Users?

What Operating System Groups and Users Are Required?

The following operating system group and user are required for all installation types:

The Oracle Inventory Group (oinstall)

You must create this group the first time you install Oracle software on the system. The default name chosen for this group is oinstall. This group owns the Oracle inventory that is a catalog of all Oracle software installed on the system.

Note:

If Oracle software is already installed on the system, then the existing Oracle Inventory group must be the primary group of the operating system user that you use to install other Oracle software.

The Oracle Software Owner User (typically, oracle)

You must create this user the first time you install Oracle software on the system. This user owns all of the software installed during the installation. This user must have the Oracle Inventory group as its primary group.

Note:

In Oracle documentation, this user is referred to as the oracle user.

A single Oracle Inventory group is required for all installations of Oracle software on the system. After the first installation of Oracle software, you must use the same Oracle Inventory group for all subsequent Oracle software installations on that system. However, you can choose to create different Oracle software owner users, OSDBA groups, and OSOPER groups (other than oracle, dba, and oper) for separate installations. By using different groups for different installations, members of these different groups have DBA privileges only on the associated databases rather than on all databases on the system.

How To Create the Operating System Groups and Users?

The following sections describe how to create the required operating system users and groups:

Creating the Oracle Inventory Group

Creating the OSDBA Group

Creating an OSOPER Group (Optional)

Creating the Oracle Software Owner User

Note:

As an alternative to creating local users and groups, you can create the appropriate users and groups in a directory service, for example, Network Information Services (NIS). For information about using directory services, contact your system administrator or refer to your operating system documentation.

Creating the Oracle Inventory Group

You must create the Oracle Inventory group if it does not already exist. The following subsections describe how to determine the Oracle Inventory group name, if it exists, and how to create it if necessary.

Determining Whether the Oracle Inventory Group Exists

When you install Oracle software on the system for the first time, the oraInst.loc file is created. This file identifies the name of the Oracle Inventory group and the path to the Oracle Inventory directory.

To determine whether the Oracle Inventory group exists, enter the following command:

# more /etc/oraInst.loc

If the output of this command shows the oinstall group name, then the group already exists.

If the oraInst.loc file exists, then the output from this command looks like:

inventory_loc=/u01/app/oracle/oraInventory
inst_group=oinstall

The inst_group parameter shows the name of the Oracle Inventory group, oinstall.

Creating the Oracle Inventory Group

If the oraInst.loc file does not exist, then create the Oracle Inventory group using the following command:

# /usr/sbin/groupadd oinstall

Creating the OSDBA Group

You must create an OSDBA group in the following cases:

An OSDBA group does not exist, for example, if you do not have Oracle Database already installed on the system.

An OSDBA group exists, but you want to give a different group of operating system users database administrative privileges in a new Oracle installation.

If the OSDBA group does not exist or if you require a new OSDBA group, then create it as follows. In the following command, use the group name dba unless a group with that name already exists.

# /usr/sbin/groupadd dba

Creating an OSOPER Group (Optional)

Create an OSOPER group only if you want to identify a group of operating system users with a limited set of database administrative privileges (SYSOPER operator privileges). For most installations, it is sufficient to create only the OSDBA group. If you want to use an OSOPER group, then you must create it in the following circumstances:

If an OSOPER group does not exist, for example, if this is the first installation of Oracle Database software on the system

If an OSOPER group exists, but you want to give a different group of operating system users database operator privileges in a new Oracle installation

If you require a new OSOPER group, then create it as follows. In the following command, use the group name oper unless a group with that name already exists.

# /usr/sbin/groupadd oper

Creating the Oracle Software Owner User

You must create an Oracle software owner user in the following circumstances:

If an Oracle software owner user does not exist, for example, if this is the first installation of Oracle software on the system

If an Oracle software owner user exists, but you want to use a different operating system user, with different group membership, to give database administrative privileges to those groups in a new Oracle Database installation

Determining Whether an Oracle Software Owner User Exists

To determine whether an Oracle software owner user named oracle exists, run the following command:

# id oracle

If the oracle user exists, then the output from this command looks like this:

uid=440(oracle) gid=200(oinstall) groups=201(dba),202(oper)

If the user exists, then determine whether you want to use the existing user or create another oracle user.

To use the existing user, ensure that the user's primary group is the Oracle Inventory group and that it is a member of the appropriate OSDBA and OSOPER groups.

To modify an existing user, refer to the Modifying an Oracle Software Owner User.

To create a user, refer to Creating an Oracle Software Owner User.

Note:

If necessary, contact your system administrator before using or modifying an existing user.

Creating an Oracle Software Owner User

If the Oracle software owner user does not exist or if you require a new Oracle software owner user, then follow these steps to create one. In the following procedure, use the user name oracle unless a user with that name already exists.

To create the oracle user, enter a command similar to the following:

# /usr/sbin/useradd -g oinstall -G dba[,oper] oracle

In this command:

The -g option specifies the primary group, which must be the Oracle Inventory group, for example oinstall

The -G option specifies the secondary groups, which must include the OSDBA group and if required, the OSOPER group. For example, dba or dba,oper

Set the password of the oracle user:

# passwd oracle

Note:

Oracle recommends you to use the same uid across all the OMSes, especially when you use shared file system loader and Oracle Software Library. If the uids are different, then the files created by one OMS cannot be modified by another OMS.

Modifying an Oracle Software Owner User

If the oracle user exists, but its primary group is not oinstall or it is not a member of the appropriate OSDBA or OSOPER groups, then enter a command similar to the following to modify it. Specify the primary group using the -g option and any required secondary group using the -G option:

# /usr/sbin/usermod -g oinstall -G dba[,oper] oracle

Verifying that the User nobody Exists

Before installing the software, follow these steps to verify that the nobody user exists on the system:

To determine whether the user exists, enter the following command:

# id nobody

If this command displays information about the nobody user, then you do not have to create that user.

If the nobody user does not exist, then enter the following command to create it:

# /usr/sbin/useradd nobody

D Setting Up SSH Connectivity

This appendix explains how you can set up SSH connectivity before installing Oracle Management Agent (Management Agent) on Microsoft Windows operating systems. In particular, this appendix covers the following:

Overview

Setting Up SSH Server (SSHD) on Microsoft Windows

Setting Up SSH on Microsoft Windows Using sshUserSetupNT.sh

Setting Up the Timezone Variable on Remote Hosts

Note:

This chapter is applicable only for the following cases:

When the destination host on which you are installing a Management Agent is running on Microsoft Windows.

When the OMS host from where you are accessing the Agent Deployment Wizard is running on Microsoft Windows.

Overview

SSH (Secure Shell) Setup is the connectivity that is established between the host running Oracle Management Service (OMS) and the host where the Management Agent needs to be installed. This is primarily required for the Agent Deployment Wizard to install Management Agents over HTTP on remote hosts.

The Agent Deployment Wizard is an application that is part of the Enterprise Manager Grid Control console. It is used for deploying Management Agents in your environment using an interactive user interface. The installation of a Management Agent from the source host to the remote destination host happens using SSH protocol, and for this communication to happen over SSH, an SSH setup is required between the two hosts. This also helps to avoid SSH authentication calls during future Agent Deploy operations.

Caution:

The SSH Setup must always be set between the destination hosts and the OMS, and never among the destination hosts.

In Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0), the Agent Deployment Wizard sets up and drops the SSH connectivity automatically, but if the Management Agent is going to be on a Microsoft Windows operating systems, then you need to manually install and configure Cygwin on that host.

Note:

The Agent Deployment Wizard is certified and supported with Cygwin 1.5.

Setting Up SSH Server (SSHD) on Microsoft Windows

Before You Begin

Before starting with the SSHD setup, ensure you are not using OpenSSH and MKSNT when using the Agent Deploy application. To do so, perform the following checks:

Ensure OpenSSH\bin and mksnt are not in your PATH environment variable. If they are, remove them by doing the following:

Right-click on My Computer and go to Properties.

In the System Properties window that appears, click Advanced.

In this tab, click Environment Variables.

Here, search for the Path system variable, select it, and if the OpenSSH\bin and mksnt are present in the PATH, click Edit.

In the Edit System Variable dialog box that appears, delete these two values from the PATH, and click OK.

Stop the SSH Daemon if it is running from OpenSSH,MKS or any other vendor. If the SSH Daemon is running, stop it by doing the following:

Right-click on My Computer, and select Manage.

In the Computer Management window, in the left pane, expand Services and Applications, and select Services.

In the right-pane, right click the SSH Daemon/MKS Secure Shell service and click Stop.

Installing Cygwin

To install Cygwin and start the SSH daemon on Microsoft Windows hosts, follow these steps:

Download the setup-legacy.exe file corresponding to Cygwin 1.5 from the following Website, and install the Cygwin software in the C:\cygwin directory:

http://cygwin.com/win-9x.html

If you go directly to http://cygwin.com and download the setup.exe file, it will install Cygwin 1.7 which is not supported on this version.

Note:

If you install Cygwin in a different directory than what has been previously mentioned, ensure you update the $OMS_INSTANCE_HOME/sysman/prov/resources/ssPaths_msplats.properties file with the proper Cygwin binary values after installing Oracle Enterprise Manager Grid Control.

Caution:

If you are installing Cygwin at a directory that is other than C:\cygwin on a remote machine, you must also ensure that Cygwin is installed on the OMS machine at the exact same location.

The Cygwin installation directory should not contain any spaces.

Invoke Cygwin setup, and click Next to proceed.

On the Choose Installation Type screen, select Install from Internet, and click Next.

On the Choose Installation Directory screen, enter C:\cygwin as the Root Directory, and click Next.

On the Select Local Package Directory screen, select a directory on your local machine where you want the Setup to store the installation files it downloads, and click Next.

On the Select Connection Type screen, select appropriate settings to connect to the internet, and click Next.

On the Choose Download Site(s) screen, select any site from the available list, and click Next.

On the select packages screen, ensure that you select the following packages, and click Next:

From the Archive category, select unzip and zip as follows:

From the Net category, select openssh as follows:

After selecting the packages, a Resolving Dependencies screen is displayed. Click Next to proceed.

On the Installation Status and Create Icons screen, do not make any changes. Click Finish to complete the installation process.

After you install Cygwin, navigate to the C:\cygwin directory, open the Cygwin.bat file in edit mode, and add the following line before invoking the bash shell.

set CYGWIN=binmode tty ntsec

To verify if Cygwin (cygrunsrv) is installed properly, run C:\cygwin\Cygwin.bat, and execute the following command:

cygrunsrv -h

If Cygwin is installed properly, then all the Cygwin help options are displayed on the screen. However, if this returns an error message, then it means you are not on the right track, and might have to reinstall Cygwin.

Note:

If you are prompted to provide a Cygwin value, enter binmode tty ntsec. If this returns an error message stating "service does not exist", you are on the right track, and can proceed to the next step.

To install SSHD service, run C:\cygwin\Cygwin.bat, and execute the following command:

ssh-host-config

Note:

Enter "no" when prompted to create sshd user account (message reads "sshd user account needs to be created").

Enter "yes" at all other prompts.

When prompted to answer the question "Which value should the environment variable CYGWIN have when sshd starts?", Oracle recommends that you set the value to at least "ntsec" as shown in the following example. This will enable you to change the user context without having to specify the password.

As an answer to the previously mentioned question, specify a value that is similar to the following and press Enter:

CYGWIN="binmode tty ntsec"

Backup the /etc/passwd file and then use a vim or vi editor to open it in edit mode. Remove only those entries of the user that you will use to connect to the destination host on which you want to install the Management Agent. Ask the user to make a backup of the /etc/passwd file before editing.

If the user that you are employing to connect to the destination host on which you want to install the Management Agent is a local user, run C:\cygwin\Cygwin.bat and execute the following:

/bin/mkpasswd -l –u <USER> >> /etc/passwd

If the user you are employing to connect to the destination host on which you want to install the Management Agent running is a domain user, run C:\cygwin\Cygwin.bat and execute the following:

/bin/mkpasswd -d -u <USER> >> /etc/passwd
/bin/mkgroup -d >> /etc/group

mkdir -p /home/<USER>  (for example, mkdir -p /home/pjohn)
chown <USER> /home/<USER> (for example, chown pjohn /home/pjohn)

(domain user only) If the user you are employing to connect to the destination host on which you want to install the Management Agent is a domain user, do the following to start the SSH daemon:

Right-click on My Computer, and select Manage.

In the Computer Management dialog box that appears, go to Services and Applications, and select CYGWIN sshd.

Right-click CYGWIN sshd and select Properties.

In the Properties dialog box, go to the Log On tab.

Here, specify the domain/username and password. Click Apply.

Run C:\cygwin\Cygwin.bat, and execute the following:

chown <USERNAME> /var/log/sshd.log
chown -R <USERNAME> /var/empty
chown <USERNAME> /etc/ssh*
chmod 755 /var/empty
chmod 644 /var/log/sshd.log

Note:

If /var/log/sshd.log does not exist, you do not have to execute the following commands:

chown <USERNAME> /var/log/sshd.log
chmod 644 /var/log/sshd.log

Perform one of the following steps to start the SSH daemon:

Run C:/cygwin/Cygwin.bat and execute the following command:

/usr/sbin/sshd

OR

Run C:/cygwin/Cygwin.bat and execute the following command:

cygrunsrv -S sshd

Note:

Use cygrunsrv -E sshd to stop the SSH daemon.

You can now test your cygwin setup.

To do this, go to a different machine (that has the ssh client running), and execute the following command:

ssh -l <USERNAME> <localhost> 'date'

OR

ssh -l <USERNAME> <this node> 'date'

For example,

ssh -l pjohn egal07.db.funds.com 'date'

This command will prompt you to specify the password. When you specify the correct password, the command should return the accurate date.

Setting Up SSH on Microsoft Windows Using sshUserSetupNT.sh

Note:

Before executing the sshUserSetupNT.sh script, execute the following commands to ensure the home directory has been correctly set:

Execute echo $HOME

Ensure this displays the home directory of the current user.

If it points to the home directory of another user, execute the following command:

export HOME=<Windows style absolute path of homedir>

Now, execute echo $HOME again, to verify the home directory. The $HOME value must be the same as that passed to -homeDir

This is the script that should be executed to set up SSH on Microsoft Windows operating systems. The usage of the script is as follows:

./sshUserSetupNT.sh -user -asUser -asUserGrp -sshLocalDir -homeDir -hosts -hostfile

Note:

After the SSHUserSetupNT.sh script has been executed, you must verify the successful SSH user setup on all the hosts, individually.

That is, if you have run the script to set up SSH on two hosts (host1, and host2), you must run the following command on each host to verify successful SSH setup:

ssh -l <username> host1 'date'

and then run:

ssh -l <username> host2 'date'

Caution:

You must execute the sshUserSetupNT.sh script on the local OMS machine from within the cygwin (BASH) shell only. The script will fail to execute if done from outside this location.

All the previously mentioned options are mandatory, and should be passed while executing the script.

Note:

It is assumed that C:\cygwin is the default installation directory for the Cygwin binaries.

If you install cygwin at a location other than c:\cygwin (default location), it can cause the SSH setup to fail, and in turn, the agent installation will fail.

To work around this issue, you must either install cygwin in the default directory (c:\cygwin), or update the ssPaths_msplats.properties file with the correct path to the cygwin binaries. The ssPaths_msplats.properties is available in <OMS_INSTANCE_HOME>/sysman/prov/resources/.

Description

This script is used on Microsoft Windows operating systems to set up SSH from the host on which it is run to the specified remote hosts. After this script is run, you can use SSH to execute commands on the remote hosts, or copy files between the local host and the remote hosts without being prompted for passwords or confirmations.

The list of remote hosts and their user names are specified as command-line parameters to the script.

-asUser

This is the user of the local machine on which the setup must be performed. For example, SYSTEM.

-asuserGrp

This is the group to which the specified asUser belongs.

-sshLocalDir

This is the full path to the directory where the keys should be generated for the asUser on the local machine.

-homeDir

This is the full path to the home directory of the current user.

If the /home key (in regedit) is seen as a subkey under the Cygnus Solutions key, then the value of the /home key must have /<username> as a suffix and then be used as -homeDirm value.

If the /home key is not found, go to the Cygwin BASH prompt and check the value of $HOME. You can now use the same value of $HOME as the value for -homeDir.

If $HOME does not have any value (is empty), then you must update the /etc/passwd file.

Identifying the Correct Entry in the /etc/passwd File

If the /etc/passwd file has only one entry for the user, you can simply modify that value. In the event that there are multiple entries in this file, you must first identify the correct entry and then modify it.

To identify the correct entry:

Execute the following command if you have specified a local user during SSH setup:

/bin/mkpasswd -l -u <username>

Execute the following command if you have specified a domain user during SSH setup:

/bin/mkpasswd -d -u <username>

Now, match the output with the corresponding entry in the /etc/passwd file. This is the entry that you must modify.

Updating the -homeDir value

All values for all users are listed as colon (:) separated entries (or fields). To update the user entry that you have identified previously, go to the penultimate value (or field) of that user entry, and modify the value of the home directory for that user.

Always specify the absolute path needed by Cygwin as value for the home directory. For example, if the path is C:\Documents and Settings\pjohn, modify it to:

/cygdrive/c/Documents and Settings/pjohn

Or, if the path reads C:\cygwin\pjohn, modify this to:

/cygdrive/c/cygwin/pjohn

Now, save the password file and reenter the BASH shell.

Note:

If you have used spaces in the $HOME value (for example, /cygdrive/c/Documents and Settings/pjohn), specify the $HOME value in Microsoft Windows style and within double quotation marks (for example, "C:\ Documents and Settings\pjohn").

Note:

Specify the full path within double quotation marks (" ").

Caution:

You must execute the sshUserSetupNT.sh script on the local OMS machine from within the cygwin (BASH) shell only. The script will fail to execute if done from outside this location.

Setting Up the Timezone Variable on Remote Hosts

This section lists the steps you must follow to set up the timezone environment variable on remote hosts.

To verify if the timezone environment variable (TZ) is accessible by the SSH server on the remote hosts, execute the following command from the OMS host:

ssh -l <user_name> -n <remote_node> 'echo $TZ'

If this command does not return the TZ environment variable value, you must set the TZ variable and ensure this is accessible by the SSH server. You can set the TZ environment variable on remote hosts in the following sections:

Set the TZ variable and Restart the SSH Daemon

If the shell being used is BASH, add the following line to the .bashrc file in the home directory of the user (being used) for ssh access:

export TZ=<your machine's timezone>

If you are using a CSH shell, then add the following line to the .cshrc file in that directory:

setenv TZ <your machine's timezone>

Depending on the shell that is present on the host, set the TZ variable by executing the following command:

For a CSH Shell, specify:
setenv TZ PST8PDT

Restart the SSH daemon by executing:

sudo /etc/init.d/sshd restart

Now, execute the following command from the OMS home to verify if the SSH server can access the TZ variable.

ssh -l <user_name> -n <node_name> 'echo $TZ'

Set the TZ Variable in the "Shell rc" File

The timezone variable must be set in the rc file of the shell that the host is using.

For example, if the host is using a BASH shell, go to the user's home directory ($HOME) and add the following to the ~/.bashrc file to set the TZ variable:

TZ=PST8PDT; export TZ

If the host is using a CSH shell, go to $HOME and add the following to the ~/.cshrc file:

setenv TZ PST8PDT

Now, execute the following command from the OMS home to verify if the SSH server can access the TZ variable.

ssh -l <user_name> -n <node_name> 'echo $TZ'

E Validating Command Locations

This appendix describes what property files and the command locations within them you need to validate before installing Oracle Management Agent (Management Agent). In particular, this appendix covers the following:

Overview of Property Files

Validating Command Locations

Overview of Property Files

Every time you install a Management Agent, the property files mentioned in the platformInfo.properties file are loaded with default locations for commands that are required for successful running of certain Application Programming Interfaces (APIs). For example, the ping executable. This section describes such property files. In particular, this section covers the following:

Property Files Loaded from platformInfo.properties File

Other Property Files Loaded

Property Files Loaded from platformInfo.properties File

Table E-1 describes the property files loaded from the platformInfo.properties file.

Table E-1 Property Files Loaded from platformInfo.properties File

Loading Order
Property File Name
Type
Description

1

Paths.properties

Generic

Contains arguments that need to be passed every time the commands listed in this file are run.

2

sPaths.properties

Generic

Contains paths for all the commands that need to be run, regardless of the platform.

3

ssPaths_<platform>.properties

Platform-Specific

Contains commands that need to be run for that platform. For example, ssPaths_linux_zseries64.properties.

On Microsoft Windows, the path to the Cygwin binaries is hardcoded in the ssPaths_msplats.properties file. If you install Cygwin in a location other than c:\cygwin (default location), it can cause the Management Agent installation to fail. To resolve this issue, you must either install Cygwin in the default directory (c:\cygwin), or update this properties file with the correct path to the Cygwin binaries.

4

userPaths.properties

Generic

Contains variables that are used to specify the command paths. You must uncomment the variables that you want to use and specify appropriate values.

Keep in mind the following points:

The property files mentioned in the platformInfo.properties file are loaded one-by-one in ascending order. This means that command locations you specify in the last file that is loaded will override the values you specified for the same key in the previously loaded property file.

For example, spaths.properties is loaded before ssPaths.properties. So if the default location for the ping executable in sPaths.properties file is usr/bin/ping, and if location for the same executable in the ssPaths.properties file as usr/sbin/ping, then the value in the latter file takes precedence over the former file.

If you want to include other command variables, then you can do one of the following:

Specify the additional command variables in sPaths.properties, ssPaths_<platform>.properties, or userPaths.properties.

Create a new property file with additional command variables. Then, mention the name of this new property file in platforminfo.properties.

Other Property Files Loaded

Table E-2 describes the other property files that are loaded.

Table E-2 Other Property Files Loaded

Property File Name
Type
Description

system.properties

Generic

Contains properties that help you control the activity and performance of the application. For example, these:

oracle.system.prov.threadpoolsize

Number of threads that get created in the application and work in parallel to run the commands on the destination hosts. The default threadpool size value that is set is 32. You can specify an appropriate value for the threadpool size in this property.

oracle.sysman.prov.threadpoolmaxsize

Number of threads that can increase dynamically depending on the workload. The default value used in the application is 256. You can specify an appropriate maximum value for the threadpool size in this property.

ignoreMessages.txt

Generic

If there are error messages displayed in the error stream that you know can be ignored in the setup, then you can update these messages in the ignoreMessages.txt file.

Generally, if the error stream contains data when you run any command, then it is assumed that the command failed, however, the data in the error stream may not always correspond to the error.

So, to ignore such error messages, you must add these messages (including the banner) to the ignoreMessages.txt file.

For example, when you run /usr/local/bin/sudo on a remote host, it writes the following messages on to the error stream. Error messages of this kind can be added to the ignoreMessages.txt file.

Administrator. It usually boils down to these two things:#1) Respect the privacy of others.#2) Think before you type.Password:
This essentially is just a warning to the user and does not constitute the failure of the executed command.

Note:

The data format for these files mandates only one property per line. You must specify the property values in the format: variable=value.

Validating Command Locations

The default command locations specified in the property files can vary between hosts and platforms. Therefore, it is important to verify the command locations before you install a Management Agent.

This section describes what property files and command locations within them you need to validate before you install a Management Agent. In particular, this section covers the following:

Validating Command Locations on the OMS Host

Validating Command Locations on the Destination Host

Validating Command Locations on the OMS Host

In the property files present in the <OMS_INSTANCE_HOME>/sysman/prov/resources/ location, validate the command locations (on the OMS host) for the following variables:

SH_PATH

SSH_ARGS

SSH_KEYGEN_PATH

SSH_PATH

SCP_ARGS

SCP_PATH

UNZIP_ARGS

UNZIP_PATH

TAR_PATH

Instead of manually reviewing each of the property files, you can run the following command from the OMS instance home to automatically list the variables that are not found in the default locations.

$<OMS_INSTANCE_HOME>/sysman/prov/resources/scripts/validatePaths -dirloc oms/sysman/prov/resources/

Note:

Before running the command, set the environment variable JARS_LOC to the following location of the OMS home where OraInstallar.jar and remoteinterfaces.jar are present:

$<ORACLE_HOME>/sysman/prov/agentpush/jlib

Validating Command Locations on the Destination Host

In the property files present in the <OMS_INSTANCE_HOME>/sysman/prov/resources/ location, validate the command locations (on the destination host) for the following variables:

SH_PATH

SH_ARGS

SCP_PATH

SCP_ARGS

SUDO_PATH

SSH_HOST_KEY_LOC

ZIP_PATH

TAR_PATH

F Passing Additional Parameters

This appendix describes the additional parameters you can pass while installing Oracle Management Agent (Management Agent) using the Agent Deployment Wizard and the agentDownload script. In particular, this appendix covers the following:

Additional Parameters Supported by agentDownload Script

Additional Parameters Supported by Agent Deployment Wizard for Custom Location

Additional Parameters Supported by agentDownload Script

If you install a Management Agent using the agentDownload script, then you can pass the following additional parameters while invoking the script.

You can also pass these additional parameters in the Additional Parameters section of the Agent Deployment Wizard if you install a Management Agent using the default source location in the Agent Deployment Wizard.

Note:

On Microsoft Windows, do not hyphenate the arguments. For example, the -b argument when run on Microsoft Windows is b.

Table F-1 Additional Parameters Supported by agentDownload Script

Option
Optional/Mandatory
Description

-b

Mandatory

Specify the full path to the installation base directory where you want to install the Management Agent.

For example, /scratch/OracleHomes/

-c

Optional

Specify the short names of the nodes of the cluster separated by a comma. Do NOT specify their fully-qualified names. Do NOT include any white spaces between the node names.

-d

Optional

Use this option only if you do not want automatic discovery of targets to be initiated after the installation ends.

-h

Optional

Use this option if you want to view an entire list of options that can be passed with the command. It essentially displays this entire table.

-i

Optional

Specify the full path to the location (leading to the file name) where the oraInst.loc file is available. For example, -i /scratch/oraInst.loc

The oraInst.loc file contains the following entries:

inventory_loc=<location_of_central inventory>

inst_group=<group_of_the_user_that_is_installing_the_agent>

-l

Optional

Use this to indicate that the installation must be done on the local host.

-m

Mandatory

(Only if OMS host is not specified in the response file)

Specify the host name where OMS is running. This is to download the Management Agent software.

For example, software.server.com

-n

Optional

Specify the name of the cluster.

-N

Optional

Use this option only if you DO NOT want to be prompted for Management Agent registration password.

-o

Optional

Specify the full path to the Oracle home of the lower version of the Management Agent that you want to upgrade.

For example, /scratch/OracleHomes/agent10g

-p

Optional

Specify the full path to the location (leading to the file name) where the staticports.ini file is available.

-r

Mandatory

Specify the port number of the OMS from where the Management Agent software needs to be downloaded.

-R

Optional

Use this option to use virtual host name (ORACLE_HOSTNAME) for the installation. If this is being used along with more than one cluster node through "-c" option, then "-l" option also needs to be passed.

-t

Optional

Use this option only when you DO NOT want to start the Management Agent after the installation ends.

-u

Optional

Use this option when you want to upgrade the Management Agent.

-v

Optional

Specify the location to the inventory directory. For example, /scratch/oraInventory

-x

Optional

Use this option to debug output.

-y

Optional

Indicates that you want to decline the security updates.

Additional Parameters Supported by Agent Deployment Wizard for Custom Location

If you install a Management Agent using a custom source location in the Agent Deployment Wizard, then you can pass the following additional parameters in the Additional Parameters section of the Agent Deployment Wizard.

Note:

On Microsoft Windows, do not hyphenate the arguments. For example, the -b argument when run on Microsoft Windows is b.

Table F-2 Additional Parameters Supported by Agent Deployment Wizard

Parameter
Description

-clusterware oracle.crs, <crs version>

Specify the version of the installed Oracle Clusterware.

-crslocation <path>

For cluster installs, specify the path to the Oracle home of the clusterware. If you specify this, then it overrides the clusterware information obtained from the central inventory.

-invPtrLoc <full path of oraInst.loc>

Specify the full path to the location (leading to the file name) where the oraInst.loc file is available. For example, -invPtrLoc /scratch/oraInst.loc

The oraInst.loc file contains the following entries:

inventory_loc=<location_of_central inventory>

inst_group=<group_of_the_user_that_is_installing_the_agent>

INVENTORY_LOCATION=<location>

Specify the inventory location. Instead of using the -invPtrLoc parameter to point to a file that has the inventory location details, you can use INVENTORY_LOCATION parameter to directly pass the inventory location. Therefore, this is an alternative to -invPtrLoc.

-jreLoc <location>

Specify the path where the Java Runtime Environment (JRE) is installed.

-logLevel <level>

Specify the filter log messages that have a lesser priority level than <level>. Valid options are: severe, warning, info, config, fine, finer, finest, basic, general, detailed, trace. The use of basic, general, detailed, and trace is deprecated.

-paramFile <location of file>

Specify the location of oraparam.ini file to be used.

-responseFile <Path>

Specify the full path to the response file. The path must lead up to the respone file name.

-sourceLoc <location of products.xml>

Specify the full path to the source location where the software is available.

-cfs

Indicates that the Oracle home specified is on the cluster file system (shared). This is mandatory when '-local' is specified so that the Oracle home can be appropriately registered in the inventory.

-debug

Indicates that you want to get debug information.

-executeSysPrereqs

Indicates that you want to run system prerequisite checks.

-force

Indicates that you want to allow silent mode installation into a non-empty directory.

-help

Indicates that you want to display the usage of all supported options.

-ignoreSysPrereqs

Indicates that you want to Ignore the results of the system prerequisite checks.

-local

Indicates that you want to perform the operation on the local node regardless of the number of cluster nodes you have specified.

-printmemory

Indicates that you want the log debug information for memory usage.

-printtime

Indicates that you want to log debug information for time usage.

-updateNodeList

Indicates that you want to update the node list for this Oracle home in the inventory.

G Configuring Database and ASM Targets for Monitoring

In the Enterprise Manager Grid Control console, when you view the Home page for an Oracle Database target for the first time, the Database Home page may not display any monitoring data, and the status of the database may indicate that there is a metric collection error. This is because the DBSNMP credentials have not been configured, or have been locked due to unsuccessful login attempts.

Similarly, when you view the Home page of an Oracle Automatic Storage Management (Oracle ASM) target for the first time, the status of the Oracle ASM instance may be unknown or unavailable, and the Home page may indicate that the Management Agent is unavailable (down). Again, this is because you have not specified the ASM SYS credentials.

To fix this problem for an Oracle Database target, follow these steps:

If your DBSNMP user account is locked, then unlock it. To do so, follow these steps:

In Grid Control, click Targets and then Databases.

On the Databases page, from the table that lists all databases, click a database name.

On the Database Home page, click the Server tab.

On the Server page, from the Security section, click Users. If you are prompted to log in to the database, make sure to use a database user account with DBA privileges such as SYSTEM.

On the Users page, find and select the DBSNMP user account. From the Actions list, select Unlock User, and click Go. If you are asked to confirm whether you want to unlock the DBSNMP user account, click Yes.

Set the monitoring credentials for a standalone Oracle Database or Oracle RAC database. To do so, follow these steps:

In Grid Control, click Targets and then Databases.

On the Databases page, find and select the database target and click Monitoring Configuration.

On the Properties page, specify the password for the DBSNMP user in the Monitor Password field. To verify the monitoring credentials, click Test Connection.

If the connection is successful, click Next, then click Submit.

Set the monitoring credentials for Oracle ASM. To do so, follow these steps:

In Grid Control, click Targets and then Databases.

On the Databases page, find and select the Oracle ASM target and click Monitoring Configuration.

On the Properties page, specify the password for the ASMSYS user in the Password field. To verify the monitoring credentials, click Test Connection.

If the connection is successful, click Next, then click Submit.

H Setting Up Proxy Configuration for Oracle Management Service

For the following reasons, set up the proxy server settings in Enterprise Manager Grid Control so that it can use those details to access My Oracle Support:

If you have a proxy server running on the host where Oracle Management Service (OMS) is installed.

If you want to use the same proxy server settings or have different settings for the OMS to communicate with its Oracle Management Agents (Management Agents).

To set up the proxy server settings, do the following:

In Enterprise Manager Grid Control, click Setup from the top-right corner of the home page.

On the Overview of Setup page, from the vertical menu to the left, click Patching Setup.

On the Patching Setup page, in the My Oracle Support and Proxy Connection tab, in the My Oracle Support Connection Setting section, select Manual Proxy Configuration and specify the proxy server host, port, realm, user name, and password.

Note: Only HTTP and HTTPS protocols are supported. Also note that NTLM proxy is not currently supported.

If you want to use the same proxy settings for communicating with the Management Agents, then go to Step (6). Otherwise, go to Step (5).

In the Agent Connection Setting section, do one of the following:

If you want to use the proxy settings given in My Oracle Support Connection Setting section, then retain the default section, that is, Use My Oracle Support connection settings.

If you want to use proxy settings different from the ones specified in My Oracle Support Connection Setting section, then select Manual proxy configuration and specify the proxy server details.

Note: Only HTTP and HTTPS protocols are supported. And NTLM proxy is not currently supported.

Click Apply.

The proxy server settings you specify are registered in the Management Repository. However, in case of multiple OMS environment, after you set up the proxy server settings for one OMS, restart other OMSes to ensure that the proxy server settings registered for communication with Management Agents are propogated across all OMSes.

I Reconfiguring Oracle Management Agent and Discovering New Targets

This appendix describes the commands you must run to reconfigure Oracle Management Agent and discover new targets that were installed after the installation of the Management Agent.

In particular, this appendix covers the following:

Discovering New Targets with Standalone Management Agents

Converting Standalone Management Agents to Cluster-Based Management Agents

Discovering New Targets with Cluster-Based Management Agents

Reconfiguring Cluster-Based Management Agents

Note:

The -t argument mentioned in the commands of this appendix indicate that you do not want the Management Agent to start after the operation (reconfiguration or discovery) ends.

Discovering New Targets with Standalone Management Agents

By default, the targets that were already installed on the host before installing the Management Agent are automatically discovered in Enterprise Manager Grid Control. However, the new targets installed after installing the Management Agent are not automatically discovered.

Therefore, if you install any new target, and if you want to discover and monitor it in Enterprise Manager Grid Control, run the following command from the Oracle home of the Management Agent that is installed on the host:

$<ORACLE_HOME>/bin/agentca -d [ -t -i <absolute_path_to_oraInst.loc_file>]

Converting Standalone Management Agents to Cluster-Based Management Agents

After installing standalone Management Agents on multiple hosts, if you create a cluster of those hosts, you must ideally convert those standalone Management Agents to cluster-compatible Management Agents. This section describes how you can convert in graphical and silent mode.

Convering in Graphical Mode

Converting in Silent Mode

Convering in Graphical Mode

To convert a standalone Management Agent to a cluster-compatible Management Agent in a graphical mode, follow these steps:

In Grid Control, click Deployments.

On the Deployments page, from the Agent Installation section, click Install Agent.

On the following page, click Fresh Install.

On the Installation Details page, do the following:

In the Source Software section, retain the default selection, that is, Default, from Management Server location.

In the Version section, select the appropriate version of the already-installed standalone Management Agents. Note that to use Deployment Procedures, the Management Agents must be at least 10g Release 2 (10.2.0.2).

In the Host section, select the required platform, provide a list of hosts that are part of the cluster, check Cluster Install, click Populate Defaults to automatically specify a list of cluster nodes, and then specify a cluster name.

In the OS Credentials section, provide the host credentials.

In the Destination section, specify the installation base directory on the nodes that form the cluster.

In the Additional Parameters section, supply any other optional parameters you want to run.

Click Continue.

Note:

If you see the following error messages on the Prerequisite Details page, ignore them and click Continue to proceed with the installation:

Some or all Agent home locations(Install base dir/agent10g or Install Base Dir/agent11g) provided are not empty directories

The Agent Oracle Home ( InstallBaseDir/agent10g or InstallBaseDir/agent11g), is already registered with the inventory

An agent home exists in the hosts

Converting in Silent Mode

To convert a standalone Management Agent to a cluster-compatible Management Agent in a silent mode, follow these steps:

$<ORACLE_HOME>/bin/agentca -f -c "{<comma_separated_cluster_node_list>}" [ -t -i <absolute_path_to_oraInst.loc_file> -n <cluster_name>]

Discovering New Targets with Cluster-Based Management Agents

By default, the targets that were already installed on the nodes of a cluster before converting a standalone Management Agent to a cluster-compatible Management Agent are automatically discovered in Enterprise Manager Grid Control. However, the new targets installed on a node after converting a standalone Management Agent to a cluster-compatible Management Agent are not automatically discovered.

Therefore, if you install any new target on a node of a cluster, and if you want to discover and monitor it in Enterprise Manager Grid Control, run the following command from the Oracle home of the Management Agent on that node:

$<ORACLE_HOME>/bin/agentca -d -c "{<comma_separated_cluster_node_list>}" [ -t -i <absolute_path_to_oraInst.loc_file> -n <cluster_name>]

Reconfiguring Cluster-Based Management Agents

If you add new nodes to an existing cluster, you must reconfigure the cluster-based Management Agent to update the centry inventory with the information of those new nodes, and discover all the targets installed on those new nodes. To do so, run the following command from the Oracle home of the Management Agent on every node of the cluster:

$<ORACLE_HOME>/bin/agentca -f -c "{<comma_separated_cluster_node_list_including_new_nodes>}" [ -t -i <absolute_path_to_oraInst.loc_file> -n <Cluster_Name>]

Note:

When the agentca script runs, it takes a backup of the EMSTATE directory on the local node, and creates a new EMSTATE directory.

J Understanding Optional Arguments Run with ConfigureGC.pl Script

When you adopt the Installing Software Only and Configuring Later approach to install Enterprise Manager Grid Control or an additional Oracle Management Service (OMS), after installing the software binaries, to configure the product, you run the ConfigureGC.pl script.

The following are the optional arguments that can be passed with the ConfigureGC.pl script:

-noaddoncheck

While invoking the ConfigureGC.pl script, by default, some optional Configuration Assistants are run, including Verify Addons Installed. If you want to avoid running this Configuration Assistant for verifying the add-ons, then invoke the ConfigureGC.pl script with the -noaddoncheck argument.

For example,

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl -noaddoncheck

ADDON_RESPONSE_FILE

If you want to specify some information about add-ons, then edit the following file, which is available in the Oracle home of the OMS, and pass it with the ConfigureGC.pl script.

<ORACLE_HOME>/sysman/addons/addon.rsp.template

For example,

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl ADDON_RESPONSE_FILE=<AbsolutePathToResponseFile>

OMS_RESPONSE_FILE

To install the software binaries, you either invoke the Enterprise Manager Grid Control Installation Wizard and specify the required details, or use a response file that captures the required details.

However, if you want to overwrite the information that you provided in the installer or in a response file, then create a new response file with the updated information and pass it with the ConfigureGC.pl script.

For example,

$<ORACLE_HOME>/perl/bin/perl <ORACLE_HOME>/sysman/install/ConfigureGC.pl OMS_RESPONSE_FILE=<absolute_path_to_response_file>

Table J-1 and Table J-2 show the parameters you can pass in this response file to overwrite the information you provided while installing a complete Enterprise Manager system and additional OMS, respectively.

Table J-1 Parameters Recognized by ConfigureGC.pl Script While Configuring Enterprise Manager System

Parameter
Description

ORACLE_INSTANCE_HOME_LOCATION

Specify the directory where the configuration files of OMS can be created.

By default, this location is under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the OMS Instance Base is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

WLS_ADMIN_SERVER_USERNAME

Specify the default user name that will be used as the administrative user for the WebLogic Domain. By default, the user name is weblogic.

WLS_ADMIN_SERVER_PASSWORD

Specify the password for the WebLogic user account.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

Confirm the password for the WebLogic user account.

NODE_MANAGER_PASSWORD

Specify the node manager password.

NODE_MANAGER_CONFIRM_PASSWORD

Confirm the node manager password.

DATABASE_HOSTNAME

Specify the fully-qualified name of the host where the existing database resides. For example, db.host.com.

LISTENER_PORT

Specify the listener port to connect to the existing database.

SERVICENAME_OR_SID

Specify the Service name or the System ID (SID) of the existing database.

SYS_PASSWORD

Specify the SYS user account's password.

CONNECT_STRING

Specify the details of the database to which you want to connect. For example, if you are connecting to an Oracle RAC Database, and if you have specified the virtual IP address of one of its nodes, then specify details of the other nodes using this parameter.

Syntax:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<HOSTNAME>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<SID>)))

Example:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=stajs11.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SID=opg44)))

MANAGEMENT_TABLESPACE_LOCATION

Specify the full path to the location where the data file for management tablespace (mgmt.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example:

If the database is on a file system, then the path must look like /u01/oracle/prod/oradata/mgmt.dbf

If the database is on Automatic Storage Management (ASM), then the path must look like +<disk_group1>/prod/oradata/mgmt.dbf, where disk_group1 is a diskgroup created on ASM and prod is the Service ID (SID).

If the database is on a raw device, then the path must look like </dev/raw1>/prod/oradata/mgmt.dbf, where /dev/raw1 is the raw device and prod is the SID.

Enterprise Manager Grid Control requires this data file to store information about the monitored targets, their metrics, and so on. Essentially, everything else other than configuration data, software library data, and audit data.

CONFIGURATION_DATA_TABLESPACE_LOCATION

Specify the full path to the location where the data file for configuration data tablespace (mgmt_ecm_depot1.dbf) can be stored. Ensure that the specified path leads up to the file name.

For example, /home/john/oradata/mgmt_ecm_depot1.dbf

Enterprise Manager Grid Control requires this data file to store configuration information collected from the monitored targets.

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

Specify the full path to a location where the data file for JVM diagnostics data tablespace (mgmt_ad4j.dbf) can be stored. Ensure that the specified path leads up to the file name. Enterprise Manager Grid Control requires this data file to store JVM-related monitoring data.

For example, /home/john/oradata/mgmt_ad4j.dbf

LOCK_ORACLE_MANAGMENT_SERVICE

OMS always runs in a secure mode, and can further have a locked or an unlocked state. In an unlocked state, the Management Agents that are secure and the Management Agents that are not unsecure communicate with the OMS using HTTPS and HTTP protocols, respectively. However, in a locked state, only secure Management Agents communicate with OMS using HTTPS protocol.

Specify TRUE if you want to lock the OMS running in a secure mode and further enhance the security of communication between the OMS and the Management Agents.

Specify FALSE if you do NOT want to further enhance the security of communication between the OMS and the Management Agent.

SYSMAN_PASSWORD

Specify a password for creating a SYSMAN user account. This password is used to create the SYSMAN user, which is the primary owner of the Management Repository schema.

SYSMAN_CONFIRM_PASSWORD

Confirm the password for creating a SYSMAN user account.

ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE

By default, you can use either HTTP or HTTPS protocol to access the Enterprise Manager Grid Control console.

Specify TRUE if you want to secure the access and allow users to access the console only using HTTPS protocol.

Specify FALSE if you do NOT want to secure the access and do NOT want to allow users to access the console only using HTTPS protocol.

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS and the Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

START_OMS

Specify TRUE if you want the OMS to start automatically after installation. Specify FALSE if you do NOT want it to start automatically.

SHARED_RECEIVE_DIRECTORY_LOCATION

Specify the full path to a location where you want to configure the shared file system loader.

A shared file system loader is typically required when you are planning to have multiple OMSes, so that a common location is maintained to store all the metric data files uploaded by the Management Agents.

If you configure the central directory now, then all subsequent additional OMS installations, which connect to the same Oracle Database, will automatically be mapped to this central directory.

Table J-2 Parameters Recognized by ConfigureGC.pl Script While Configuring an Additional OMS

Parameter
Description

ORACLE_INSTANCE_HOME_LOCATION

Specify the directory where the configuration files of OMS can be created.

By default, this location is under the parent directory of the Oracle Middleware Home. For example, if the Oracle Middleware Home is /u01/app/Oracle/Middleware, then the OMS Instance Base is /u01/app/Oracle/gc_inst.

For more information about this location, see What Is Oracle Management Service Instance Base Location?.

ADMIN_SERVER_HOSTNAME

Specify the name of the host where the Admin Server is running. Admin Server is the server that was created when you installed the first Oracle Management Service 11g Release 1.

ADMIN_SERVER_PORT

Specify the port on which the Admin Server is running.

DATABASE_HOSTNAME

Specify the fully-qualified name of the host where the existing database resides. For example, db.host.com.

LISTENER_PORT

Specify the listener port to connect to the existing database.

SERVICENAME_OR_SID

Specify the System ID (SID) of the existing database.

SYSMAN_PASSWORD

Specify the SYSMAN user account's password.

CONNECT_STRING

Specify the details of the database to which you want to connect.

Syntax:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<HOSTNAME>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<SID>)))

Example:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=stajs11.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SID=opg44)))

AGENT_REGISTRATION_PASSWORD

To secure the communication between the OMS and the Management Agents, specify a password. Note that you have to provide the same registration password for securing your Management Agents.

AGENT_REGISTRATION_CONFIRM_PASSWORD

Confirm the agent registration password.

LOCK_ORACLE_MANAGMENT_SERVICE

OMS always runs in a secure mode, and can further have a locked or an unlocked state. In an unlocked state, the Management Agents that are secure and the Management Agents that are not unsecure communicate with the OMS using HTTPS and HTTP protocols, respectively. However, in a locked state, only secure Management Agents communicate with OMS using HTTPS protocol.

Specify TRUE if you want to lock the OMS running in a secure mode and further enhance the security of communication between the OMS and the Management Agents.

Specify FALSE if you do NOT want to further enhance the security of communication between the OMS and the Management Agent.

ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE

By default, you can use either HTTP or HTTPS protocol to access the Enterprise Manager Grid Control console.

Specify TRUE if you want to secure the access and allow users to access the console only using HTTPS protocol.

Specify FALSE if you do NOT want to secure the access and allow users to access the console only using HTTPS protocol.

START_OMS

Specify TRUE if you want the OMS to start automatically after installation. Specify FALSE if you do NOT want it to start automatically.

K Using RepManager Utility

This appendix describes the RepManager utility. In particular, this appendix covers the following:

Overview

Prerequisites

Supported Actions and Commands

Overview

RepManager is a utility that enables you to create, upgrade, and drop Oracle Management Repository. This utility is available in the Oracle home of Oracle Management Service (OMS):

For UNIX operating systems:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager

For Microsoft Windows operating systems:

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager.bat

This utility is invoked by Repository Configuration Assistant while installing a complete Enterprise Manager system, and by Repository Upgrade Configuration Assistant while upgrading to Enterprise Manager 11g. For information about these Configuration Assistants, see What Are Configuration Assistants?.

Prerequisites

Before you start using the RepManager utility, ensure that you meed the following prerequisites:

Ensure that the environment variable ORACLE_HOME is explicitly set. To verify whether it is already set, run the following command:

echo $ORACLE_HOME

To connect to Oracle Management Repository (Management Repository), pass either <repository_database_host> <repository_database_port> <repository_database_sid> or -connectString <db_connect_string>.

For example, the connect string can

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dadvmi0213.foo.xyz.com)(PORT=15041)))(CONNECT_DATA=(SID=smos1)))

Supported Actions and Commands

Table K-1 shows the list of actions and their associated commands supported by the RepManager utility. The ORACL_HOME mentioned in the commands is the Oracle home of the OMS.

Table K-1 Actions and Commands Supported by RepManager

Action
Command
Example

create

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -action create -mwHome <middleware home>

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -action create -mwHome /scratch/weblogic/middleware

upgrade

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -action upgrade -mwHome <middleware home>

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -action upgrade -mwHome /scratch/weblogic/middleware

preupgrade

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -action preupgrade -mwHome <middleware home>

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -action preupgrade -mwHome /scratch/weblogic/middleware

transX

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -reposName sysman -reposPassword <password of sysman user> -action transx -mwHome <middleware home>

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -reposName sysman -reposPassword enter123 -action transx -mwHome /scratch/WLS/middleware

resume

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -resume retry -checkpointLocation <directory where schemamanager stores checkpoints> -mwHome <middleware home>

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -resume retry -checkpointLocation /scratch/weblogic/middleware/oms11g/sysman/log/schemamanager -mwHome /scratch/weblogic/middleware

drop

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -action drop -mwHome /scratch/weblogic/middleware

Note: Ensure that there are no active SYSMAN sessions, scheduler jobs and dbms_jobs running. To ensure this, restart the database.

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -action drop -mwHome /scratch/weblogic/middleware

dropall

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager <repository_database_host> <repository_database_port> <repository_database_sid> -dbUser sys -dbPassword <sys password> -dbRole sysdba -reposName sysman -reposPassword <password of sysman user> -action dropall -mwHome <middleware home> -mwOraHome <Oracle Home>

Note: Ensure that there are no active SYSMAN/SYSMAN_MDS sessions, scheduler jobs and dbms_jobs running. To ensure this, restart the database.

$<ORACLE_HOME>/sysman/admin/emdrep/bin/RepManager dadvmc0217.foo.xyz.com 1521 db3 -dbUser sys -dbPassword enter123 -dbRole sysdba -reposName sysman -reposPassword enter123 -action dropall -mwHome /scratch/weblogic/middleware -mwOraHome /scratch/weblogic/middleware/oms11g

Note:

RepManager 11.1 supports -action dropall (drops SYSMAN as well as SYSMAN_MDS) and -action drop (drops only SYSMAN). However, RepManager 10.2.0.5 supports -action drop (drops only SYSMAN).

L Installation and Configuration Log Files

This appendix lists the locations of the various log files that are created during the prerequisites check, installation, and configuration phases of Enterprise Manager Grid Control components.

In particular, this appendix covers the following:

Enterprise Manager Grid Control Installation Logs

Agent Deployment Log Files

Enterprise Manager Grid Control Installation Logs

This section describes the following log files that are created while installing Enterprise Manager Grid Control:

Installation Logs

Configuration Logs

Installation Logs

The following are the installation logs, which provide complete information on the installation status:

oraInventory/logs/installActions<timestamp>.log

<ORACLE_HOME>/cfgtoollogs/oui/installActions<timestamp>.log

Note:

The installActions log file is located in the oraInventory directory by default. This log file will be copied on to the above-mentioned Oracle home location after the installation is complete.

Configuration Logs

This section describes the following configuration logs:

General Configuration Logs

Repository Configuration Logs

Secure Logs

General Configuration Logs

The Oracle Management Service (OMS) configuration logs are located in the following location of the Oracle home of the OMS.

<ORACLE_HOME>/cfgtoollogs/omsca

Table L-1 lists the configuration logs for different installation types.

Table L-1 General Configuration Logs

Installation Type
Location

Install a new Enterprise Manager system

<ORACLE_HOME>/cfgtoollogs/cfgfw/cfmlogs

<ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the OMS.

Add an additional Management Service

<ORACLE_HOME>/cfgtoollogs/cfgfw/omsca/omsca<timestamp.log>

<ORACLE_HOME>/cfgtoollogs/cfgfw/oracle.sysman.top.oms.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the OMS.

Install Oracle Management Agent

<ORACLE_HOME>/cfgtools/cfgfw/cfmlogs

<ORACLE_HOME>/cfgtools/cfgfw/oracle.sysman.top.agent.<timestamp>.log

Note: <ORACLE_HOME> refers to the Oracle home of the Management Agent.

Repository Configuration Logs

This section describes the following repository configuration logs:

SYSMAN Schema Operation Logs

MDS Schema Operation Logs

SYSMAN Schema Operation Logs

The SYSMAN schema operation logs are available in the following location of the Oracle home of the OMS. Listed in this directory is an overall log file, emschema.log, which logs all the actions performed by all the instances of RepManager run.

$<ORACLE_HOME>/sysman/log/schemananager/

In this location, for each run of RepManager, a new subdirectory is created based on the time at which the RepManager was run.

For example, if the RepManager was run and an instance was created at 09/29/2007 12:50PM, then the following subdirectory is created.

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/

An instance of RepManager ( or equivalently RepManager) can have multiple schema actions, mainly CREATE, DROP, UPGRADE, TRANSX, and RESUME_RETRY. For each action, a subdirectory is created.

For example, if a CREATE action is performed by a RepManager instance at 09/29/2006 12:51PM, then the following subdirectory is created. Listed under this subdirectory are RCU-related log files and emschema.log.CREATE log file that logs the CREATE action-specific messages.

$<ORACLE_HOME>/sysman/log/schemananager/m_092907_1250_PM/m_092907_1251PM.CREATE/

In general, in $<ORACLE_HOME>/sysman/log/schemananager/m_<time-stamp>/m_<time-stamp>.<schema-action>, the following files are created:

RCU per component (i.e. init, common, modify, drop, config, outofbox, preupgrade log

RCU log

Schema action-specific RCU logs

TransX action-specific log (emrep_config.log)

If the any of the schema operations (CREATE/UPGRADE/PREUPGRADE/DROP) fail in SQL execution, and if you retry the operation by clicking Retry, then a separate subdirectory titled m_<time-stamp>.RESUME_RETRY is created.

The following shows the overall directory structure of repository operation logs for different schema actions:

$<ORACLE_HOME>/sysman/log/schemamanager
               emschema.log
        m_030210_0349_AM
            m_030210_0325_AM.TRANSX
                emrep_config.log
                emschema.log.TRANSX
        m_030210_0438_AM
            m_030210_0438_AM.DROP (Same structure for Drop and Dropall actions)
                rcu.log
                emschema.log.DROP
                em_repos_drop.log
        m_030210_0450_AM
            m_030210_0450_AM.CREATE
                 custom_comp_create_tbs.log
                 em_repos_common.log
                 em_repos_init.log
                 emrep_config.log.3
                 emrep_config.log.2
                 emrep_config.log.1
                 emrep_config.log
                 emschema.log
                 rcu.log
                 emschema.log.CREATE
                 em_repos_config.log
        m_030210_1006_PM
            m_030210_1006_PM.RESUME_RETRY
                emrep_config.log.3
                emrep_config.log.2
                emrep_config.log.1
                emrep_config.log
                emschema.log
                rcu.log
                emschema.log.RESUME_RETRY
                em_repos_modify.log
        m_030210_1021_PM
            m_030210_1021_PM.UPGRADE
                em_repos_init.log
                emrep_config.log.3
                emrep_config.log.2
                emrep_config.log.1
                emrep_config.log
                emschema.log
                rcu.log
                emschema.log.UPGRADE
                em_repos_modify.log
        m_030210_1100_PM
            m_030210_1100_PM.PREUPGRADE
                em_repos_preupgrade.log
                emschema.log.PREUPGRADE
                rcu.log
                em_repos_init.log
                emrep_config.log.3
                emrep_config.log.2
                emrep_config.log.1
                emrep_config.log
                em_repos_common.log
        m_030210_1125_PM
            m_030210_1125_PM.MY_ORACLE_SUPPORT
                emschema.log.MY_ORACLE_SUPPORT

MDS Schema Operation Logs

MDS Schema Creation Log

For MDS schema creation operation, the following log is available in the Oracle home of the OMS:

$<ORACLE_HOME>/cfgtoollogs/cfgfw/emmdscreate_<timestamp>.log

For more information, review the following logs from the Oracle home of the OMS:

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/mds.log

$<ORACLE_HOME>/sysman/log/schemamanager/m_<timestamp>/m_<timestamp>.CREATE/rcu.log

MDS Schema Drop Logs

For MDS schema drop operation, the following logs are available in the location you specified by using the -logDir argument while invoking the MDS schema drop command:

$<user_specified_location>/mds.log

$<user_specified_location>/emmdsdrop_<timestamp>.log

However, if you did not specify any custom location while invoking the MDS schema drop command, then the logs are created in the Oracle home of the OMS. For example, /scratch/OracleHomes/oms11g/mds.log and /scratch/OracleHomes/oms11g/emmdsdrop_<timestamp>.log.

Secure Logs

For OMS, the following secure log is available in the OMS Instance Base location. Here, <oms_name>, for example, can be EMGC_OMS1.

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/secure.log

For Management Agents, the following secure log is available in the Oracle home of the Management Agent.

<ORACLE_HOME>/sysman/log/secure.log

Oracle Management Service Logs

The following log files that provide information about the running OMS are available in the OMS Instance Base location. Here, <oms_name>, for example, can be EMGC_OMS1.

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.trc

<OMS_INSTANCE_HOME>/em/<oms_name>/sysman/log/emoms.log

Agent Deployment Log Files

This section describes the locations for the following agent deployment log files:

Connectivity Logs

Application Prerequisite Logs

System Prerequisite Logs

Other Installation Logs

Connectivity Logs

Table L-2 lists the connectivity logs for the local node and their locations. Note that<ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table L-2 Connectivity Logs

Log File
Location

prereq<time_stamp>.log

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/connectivity

prereq<time_stamp>.out

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/connectivity

prereq<time_stamp>.err

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/connectivity

Application Prerequisite Logs

Table L-3 lists the application prerequisite logs and their locations. Note that <ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS, and the <install_type> mentioned in this table refer to one of the installation types mentioned in Table L-4.

Table L-3 Prerequisite Logs

Log File
Location

prereq<time_stamp>.log

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/<install_type>/<nodename>

prereq<time_stamp>.out

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/<install_type>/<nodename>

prereq<time_stamp>.err

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/<install_type>/<nodename>

Table L-4 Install Types

Install Type
Description
Target Operating System Type

emagent_install

New Agent Installation

UNIX

emagent_cluster_install

New Cluster Agent Installation

UNIX

emagent_clone

Agent Cloning

UNIX

emagent_upgrade

Agent Upgrade

UNIX

nfs_install

Shared Agent Installation

UNIX

emagent_install_anothershiphome

New Agent Installation from Non Default Shiphome location

UNIX

emagent_cluster_install_anothershiphome

New Cluster Agent Installation from Non Default Shiphome location

UNIX

emagent_install_win

New Agent Installation

Microsoft Windows

emagent_cluster_install_win

New Cluster Agent Installation

Microsoft Windows

emagent_upgrade_win

Agent Upgrade

Microsoft Windows

emagent_clone_win

Agent Cloning

Microsoft Windows

System Prerequisite Logs

Table L-5 lists the system prerequisite logs and their locations. Note that<ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table L-5 System Prerequisite Logs

Log File
Location

prereq<time_stamp>.log

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/oracle.sysman.top.agent_Complete/<nodename>

prereq<time_stamp>.out

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/oracle.sysman.top.agent_Complete/<nodename>

prereq<time_stamp>.err

<ORACLE_HOME>/sysman/prov/agentpush/<time-stamp>/prereqs/entrypoints/oracle.sysman.top.agent_Complete/<nodename>

Other Installation Logs

Table L-6 lists all the other installation logs that are created during an agent installation using the Agent Deployment wizard. Note that<ORACLE_HOME> mentioned in this table refer to the Oracle home of the OMS.

Table L-6 Installation Logs Created During Agent Installation Using Agent Deployment Wizard

Logs
Location
Description

EMAgentPush<TIMESTAMP>.log

<ORACLE_HOME>/sysman/prov/agentpush/logs/

Agent Deploy application logs.

remoteInterfaces<TIMESTAMP>.log

<ORACLE_HOME>/sysman/prov/agentpush/logs/

Logs of the remote interfaces layer.

sshSetup<TIMESTAMP>.log

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/

SSH setup logs

install.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the new agent installation or new cluster agent installation.

upgrade.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the upgrade operation using Agent Deploy

nfsinstall.log/err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the agent installation using the Shared Agent Home option in Agent Deploy.

clusterUpgrade.log/err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the cluster upgrade operation using Agent Deploy.

sharedClusterUpgradeConfig.log/err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the config operation in case of upgrade on a shared cluster.

config.log/err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of the configuration of shared cluster in case of an agent installation on a shared cluster.

preinstallscript.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log/error of the running of preinstallation script, if specified.

rootsh.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log/error of running of root.sh.

postinstallscript.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log or error of running of postinstallation script, if specified.

installActions<timestamp>.log, oraInstall<timestamp>.err/.out

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Logs of Oracle Universal Installer.

agentStatus.log

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Status of agent after running emctl status agent from the agent home.

clone.log/err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log/error of agent cloning using Agent Deploy.

clone_config.log/.err

<ORACLE_HOME>/sysman/prov/agentpush/<TIMESTAMP>/logs/<HOSTNAME>/

Log/error of the config operation of agent cloning using Agent Deploy.

M List of Deprecated Features

The following features have been deprecated in Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0) or higher.

Table M-1 List of Deprecated Features

Feature Name
Description

Oracle Enterprise Manager SNMP Sub-agent

The Enterprise Manager SNMP subagent feature is planned for deprecation in Oracle Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0).

Enterprise Manager SNMP sub-agent functionality provides a way for Oracle databases to be monitored by third-party management applications through the SNMP protocol. The deprecation will only have impact on your Oracle database monitoring if Oracle databases in your environment are monitored by SNMP protocol-based management applications through the subagent.

If Enterprise Manager SNMP subagent is being used in your environment, Oracle will provide alternatives and workarounds to ensure continued monitoring support. Details regarding the alternatives will be published on Oracle Technology Network.

EUM Feature

The EUM feature will be included in Oracle Enterprise Manager 11g Grid Control Release 1 (11.1.0.1.0), but will be completely removed in the next major release.

The EUM feature is used to monitor performance of deployed Web applications. Going forward, you should plan to use Oracle Real User Experience (RUEI), a powerful Web-based utility that provides data on real-user usage of your Web applications.

Index

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  W 

A

accessibility

enabling accessibility mode, 18.3.1

enabling accessiblity features, 18.3

providing textual descriptions of charts, 18.3.2

Additional Management Agent installation type, 18.2.2

add-ons, 21

creating response file, 8.5

installing in GUI mode, 7.5

advanced configuration

introduction, 18

types of tasks, 18.1

agent cloning wizard, 11.1

agent deployment wizard, 9.1

differences, 12.1

skipping prerequisite checks, 10.2

AGENT_HOME

definition, 18.2.2, 18.2.2.1

AGENT_HOME/bin, 18.2.2.1

AGENT_HOME/sysman, 18.2.2.1

AGENT_HOME/sysman/admin/scripts/db/config/response.pl, 20.3

AGENT_HOME/sysman/config, 18.2.2.1

AGENT_HOME/sysman/log, 18.2.2.1

agentca, 2.7.3

agentDownload script, 13

differences, 13.1

Application Dependency and Performance, 3.5, 4.7

Application Performance Management, 19.2.7

applying, 2.6.2.2

assistive technology, 18.3

B

backup requirements, 21.3

Bad SQL

configuring the database to show Bad SQL, 20.3

Beacons

configuring firewalls to allow ICMP traffic, 19.2.7

C

charts

providing textual descriptions for accessibility, 18.3.2

cloning

agent cloning, 11

cluster

installing agent, 9

collection directory, 20.1.1

commands

connecting to another management repository, 21.5

data file commands

deleting data files, 29.1

deleting data files, 2.3.7

Enterprise Manager commands

deinstalling in GUI mode, 29.2

deinstalling in silent mode, 30.2

management agent commands

deinstalling from all nodes in GUI mode, 31.2.1

deinstalling from all nodes in silent mode, 32.2.1

deinstalling from one node in silent mode, 32.2.2, 32.2.2

deinstalling from one nodes in GUI mode, 31.2.2

deinstalling shared management agent, 32.2.3

shutting down management agent, 29.1

OMS commands

deleting OMS, 29.1

schema commands

deleting SYSMAN and MDS schemas, 29.1

starting DBMS jobs, 21.5

starting DMBS scheduler, 21.5

starting gather statistics job, 21.5

verifying file size, 2.1.2.2

viewing management repository details, 21.5

configuration assistants, 2.7

console port, 2.3.4.1

D

data collections

how Enterprise Manager stores, 20.1.1

restoring default, 20.1.1

understanding default and custom, 20.1

data files, 2.3.6

deleting, 2.3.7

mgmt_ad4j.dbf, 2.3.6

mgmt_ecm_depot1.dbf, 2.3.6

mgmt.dbf, 2.3.6

overview, 2.3.6

database

database partition maintenance, 21.3

database partitioning, 21.3

setting initialization parameters, 3.3.1

supported version, 3.3

database monitoring

manually configuring an Oracle9i database for monitoring, 20.3

dba group

creating, C.2.2, C.2.2, C.2.3

DBSNMP user, 20.3

default_collection directory, 20.1.1

deinstallation

deinstalling in GUI mode

deinstalling Enterprise Manager system, 29

deinstalling management agent, 31

deinstalling Oracle WebLogic Service, 29

deinstalling in silent mode

deinstalling Enterprise Manager system, 30

deinstalling management agent, 32

directory structure

introduction to, 18.2

dontProxyFor

description of property, 19.2.3.2

E

emctl

location in AGENT_HOME, 18.2.2.1

emctl getemhome, 18.2.3

emd.properties

location, 18.2.2.1

REPOSITORY_PROXYHOST, 19.2.2.1

REPOSITORY_PROXYPORT, 19.2.2.1

emoms.properties

maxInactiveTime, 20.4

EMSTATE Directory, 2.5.6

EMSTATE directory, 10.1

Enterprise Manager

See Oracle Enterprise Manager

Enterprise Manager Framework Security

in a firewall environment, 19.1

Enterprise Manager Grid Control

deinstallation in GUI mode

deinstallation procedure, 29.2

overview, 29

postdeinstall tasks, 29.3

prerequisites, 29.1

deinstallation in silent mode

deinstallation procedure, 30.2

overview, 30

postdeinstall tasks, 30.3

prerequisites, 30.1

installation

installation procedure, 3.4

postinstall tasks, 3.5

prerequisites, 3.3

process, 3.1

updating response file, 3.4

verifying, 3.5

installation types, 2.3.3

installation wizard, 2.3.2

language, 2.3.5

logging in, 33.2

ports

custom, 2.3.4.2

default, 2.3.4.1

overview, 2.3.4

software, 2.1

procuring from DVD, 2.1.1

procuring from OTN, 2.1.2

software-only installation

configuration procedure, 4.6, 5.6

installation procedure, 4.4, 5.4

overview, 4.1, 5.1

postconfiguration tasks, 4.7, 5.7

postinstall tasks, 4.5, 5.5

prerequisites, 4.3, 5.3

upgrade

in scope, 21.1

out of scope, 21.1

overview, 21.1

postupgrade tasks, 21.5

prerequisites, 21.3

upgrade procedure, 21.4

URL, 33.1

F

files

additional_agent.rsp, 14

oraInst.loc, C.2.1.1

Paths.properties, E.1.1

RepManager.bat, 29.1

sPaths.properties, E.1.1

staticports.ini, 3.2

upgrade.rsp, 21.1

userPaths.properties, E.1.1

firewall, 3.3

firewalls

between browser and the Grid Control, 19.2.1

between Grid Control and a managed database target, 19.2.5

between Management Service and Management Agents, 19.2.6

between Management Service and Management Repository, 19.2.4

configuring for ICMP traffic, 19.2.7

configuring for UDP traffic, 19.2.7

configuring the Management Agent for, 19.2.2

configuring the Management Service for, 19.2.3

configuring to allow incoming data from Management Service, 19.2.3.3

configuring to allow incoming traffic to Management Agent, 19.2.2.2

considerations before configuring, 19.1

considerations when using with multiple Management Services, 19.2.6

G

getemhome

emctl command, 18.2.3

graphical mode, 2.3.1, 2.3.1

groups

creating the dba group, C.2.2, C.2.3

creating the oinstall group, C.2.1

H

host list file, 2.10.1

HTTP port, 2.3.4.1

HTTPS port, 2.3.4.1

I

ICMP, 19.2.7

id command, C.2.4.4

Installation Base Directory, 2.5.5

installation using shared Oracle home

installation procedure, 15.4

overview, 15.1

postinstall tasks, 15.5

prerequisites, 15.3

Internet Control Message Protocol, 19.2.7

introduction to advanced configuration, 18

J

job_queue_processes, 20.3

JVM Diagnostics, 3.5, 4.7

L

library requirements

libraries for OMS, B.4

licenses

disabling, 33.3

enabling, 33.3

Listener port

obtaining, 19.2.5

Login Timeout Value

modifying the default, 20.4

M

Management Agent

configuring to allow incoming communication from the Management Service, 19.2.2.2

configuring to use a proxy server, 19.2.2.1

management agent

cloning

cloning procedure, 11.4

overview, 11.1

postcloning tasks, 11.5

prerequisites, 11.3

cloning on cluster

cloning procedure, 17.4

overview, 17.1

postcloning tasks, 17.5

prerequisites, 17.3

cloning using ZIP file

cloning procedure, 16.4

overview, 16.1

postcloning tasks, 16.5

prerequisites, 16.3

deinstallation in GUI mode

deinstallation procedure, 31.2

deinstalling from all nodes, 31.2.1

deinstalling from one node, 31.2.2

overview, 31

postdeinstall tasks, 31.3

prerequisites, 31.1

deinstallation in silent mode

deinstallation procedure, 32.2

deinstalling from all nodes, 32.2.1

deinstalling from one node, 32.2.2

overview, 32

postdeinstall tasks, 32.3

prerequisites, 32.1

installation on cluster

installation procedure, 9.4, 14.4

postinstall tasks, 9.5, 14.5

prerequisites, 9.3, 14.3

use cases, 9.1, 14.1

verifying, 9.5

installation using agentDownload script

installation procedure, 13.3

overview, 13.1

postinstall tasks, 13.4

prerequisites, 13.2

installation using response file

creating response file, 12.3

installation procedure, 12.3

overview, 12.1

postinstall tasks, 12.4

prerequisites, 12.2

verifying, 12.4

installation using shared Oracle home

installation procedure, 10.4

overview, 10.1

postinstall tasks, 10.5

prerequisites, 10.3

packages, B.2

securing communications, 9.5

software

automatic download, 2.2.1

manual download, 2.2.2

management repository

changing SYSMAN password, 3.5

connecting to another repository, 3.5

Management Service

See Oracle Management Service

management service

installation

installation procedure, 6.4

postinstall tasks, 6.5

prerequisites, 6.3

process, 6.1

response file, 6.4

verifying, 6.5

library requirements, B.4

packages, B.1

software-only installation

configuration procedure, 8.7

installing add-ons, 8.5

installing OMS, 8.4

overview, 8.1

postconfiguration tasks, 8.8

postinstall tasks, 8.6

prerequisites, 8.3

verifying, 7.8

maxInactiveTime

property in emoms.properties, 20.4

N

nmosudo, 20.7.4

nobody user

checking existence of, C.2.4.4

node manager, 2.4.6

O

OEM_MONITOR, 20.3

oinstall group

creating, C.2.1

description, C.1

online help, 33.4

oper group

creating, C.2.3

operating system groups

creating the dba group, C.2.3

creating the oinstall group, C.2.1

oinstall, C.1

requirements, C

operating system users

checking existence of the nobody user, C.2.4.4

creating the oracle user, C.2.4

oracle, C.1

requirements, C

Oracle Advanced Security, 19.2.4

Oracle Configuration Manager, 2.6.1

Oracle Enterprise Manager

directory structure, 18.2

Oracle Home, 2.5.4

Oracle Inventory

pointer file, C.2.1.1

Oracle Inventory Directory, 2.5.1

Oracle Inventory group

creating, C.2.1

description, C.1

Oracle Management Agent

configuring when protected by a firewall, 19.2.2

directory structure, 18.2.2

directory structure on Windows, 18.2.2.2

installing with Grid Control, 18.2.2

Oracle Management Service

bin directory, 18.2.1.3

configuring for use with a proxy server, 19.2.3.1

configuring to allow incoming data from Management Agent, 19.2.3.3

configuring when protected by a firewall, 19.2.3

home directory, 18.2.1.1

sysman directory, 18.2.1.3

Oracle Management Service Instance Base Location, 2.5.3

Oracle Middleware Home, 2.5.2

Oracle Net firewall proxy access, 19.2.4, 19.2.5

Oracle Software Owner user

creating, C.2.4.1

Oracle software owner user

creating, C.2.4

description, C.1

oracle user

creating, C.2.4, C.2.4.1, C.2.4.2

description, C.1

Oracle WebLogic Server

admin server

admin server port, 2.4.7

existing admin server, 2.4.4

starting admin server, 2.4.9

verifying admin server, 2.4.8

credentials, 2.4.5

installation, 3.3, 6.3

installing, 2.4.1

node manager, 2.4.6

patches, 3.3, 6.3

refreshing weblogic domain, 6.5, 7.8, 21.5

verifying, 2.4.2

ORACLE_HOME/bin, 18.2.1.3

ORACLE_HOME/sysman, 18.2.1.3

Oracle8i database

configuring for monitoring, 20.3

Oracle9i

configuring for monitoring, 20.3

oraInst.loc file

location, C.2.1.1

location of, C.2.1.1

oraInventory, 2.5.1

OSDBA group

creating, C.2.2, C.2.3

OUIinventories.add, 20.2

P

package requirements

packages for management agent, B.2

packages for OMS, B.1

passwd command, C.2.4.2

PERFSTAT, 20.3

ports, 2.3.4

4888, 19.2.3, 19.2.3.3

4889, 19.2.3.3

admin server port, 2.4.7

custom EM ports, 2.3.4.2

default EM ports, 2.3.4.1

viewing a summary of ports assigned during installation, 19.3

PowerBroker, 20.7

prerequisite checks, 2.8

default checks, 2.8.1

running in standalone mode, 2.8.2

Privilege Delegation Providers, 20.7

privilege delegation setting

applying, 20.7.2

creating, 20.7.1

disabling, 20.7.3

proxy server

configuring Management Agent for, 19.2.2.1

configuring the Management Service for, 19.2.3.1

R

REPOSITORY_PROXYHOST

property in emd.properties, 19.2.2.1

REPOSITORY_PROXYPORT

property in emd.properties, 19.2.2.1

Request Monitoring, 3.5, 4.7

S

screen readers, 18.3.1

scripts

agentDownload, 13

nfsagentinstall, 15

Secure Shell, D.1

session timeout

modifying, 20.4

shared file system loader

configuring after installation, 3.5

silent mode, 2.3.1, 2.3.1

software updates

downloading, 2.6.2.1

overview, 2.6.2

SSH connectivity, D

Statspack, 20.3

storing, 2.6.2.3

Sudo, 20.7

T

tasks

advanced configuration tasks, 18.1

Top SQL Report

configuring the database to show the Top SQL Report, 20.3

U

UDP, 19.2.7

uix-config.xml, 18.3.1

UNIX commands

id, C.2.4.4

passwd, C.2.4.2

useradd, C.2.4.2

UNIX groups

creating the dba group, C.2.2

UNIX users

creating the oracle user, C.2.4.1

unprivileged user

checking existence of, C.2.4.4

upload port, 2.3.4.1

User Datagram Protocol, 19.2.7

useradd command, C.2.4.2

users

checking existence of the nobody user, C.2.4.4

creating the oracle user, C.2.4, C.2.4.1

Oracle software owner user, C.1

W

web.xml, 18.3.2

agent behind firewall

firewall btw service and repos

firewall btw browser and console

firewall btw gc and db target

firewall port requirements

Configuratioin tasks when the management service is behind a firewall.

The illustration ada_icon.gif shows a screen capture of a typical Enterprise Manager chart. A callout in the lower right corner of the illustration identifies the icon you can click to display a textual representation of the data in the chart. This icon appears next to all charts when textual descriptions are enabled using the procedure documented in this section of the guide.

Oracle Legal Notices

Copyright Notice

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

Trademark Notice

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

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

License Restrictions Warranty/Consequential Damages Disclaimer

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

Warranty Disclaimer

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

Restricted Rights Notice

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

Hazardous Applications Notice

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

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in prerelease status:

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