Oracle Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching, 10g Release 5 (10.2.0.5.0)

10g Release 5 (10.2.0.5.0)

E14500-04

Contents

List of Figures

List of Tables

Title and Copyright Information

Preface

- Audience

- Structure of the Document

- Documentation Accessibility

- Related Documents

- Conventions

Part I Overview and Setup Details

1 Overview of Lifecycle Management Solutions

- Lifecycle Management Challenges

- Enterprise Manager Grid Control's Lifecycle Management Solutions

- Benefits of Using Provisioning and Patching Features

- Success Stories

2 Things to Know

- Understanding Provisioning and Patching Solutions

- Provisioning

- Patching

- Patching Versus Upgrading

- Patches

- Patch Sets

- Understanding Deployment Procedures

- Deployment Procedures

- Understanding Phases and Steps

- Activities Involved in Deployment Procedures

- Users of Deployment Procedures

- Viewing Details of Deployment Procedures

- Understanding Provisioning Deployment Procedures

- Understanding Patching Deployment Procedures

- Patching Deployment Procedures

- Understanding Patching Modes

- Understanding Patching Methodologies

- Understanding Oracle Software Library

- Oracle Software Library

- Components

- Directives

- Images, Network Templates, Hardware Templates, Disk Layouts

- Assignments

- Understanding Linux Patching

- Understanding Virtualization Management

- Terms Used in Virtualization

- Privileges Required for Administrative and Provisioning Operations

- Understanding Bare Metal Provisioning

- Overview of the Bare Metal Provisioning Environment

- Overview of the Bare Metal Provisioning Process

- Setting Up Provisioning Environment

- Provisioning Linux Using Bare Metal Provisioning Application

- Understanding Other Related Concepts

- Provisioning Archive (PAR) Files

- Oracle Patch Advisories

- Staging Area

- Support for SUDO, PAM, and Privilege Delegation

- Tracking the Status of Deployment Procedures

3 Infrastructure Requirements

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Creating Designer and Operator User Accounts

- Creating Designer User Account

- Creating Operator User Account

- Setting Up Oracle Software Library

- Configuring Oracle Software Library

- Creating a Component in Oracle Software Library

- Applying Patches

- Applying Common Patches

- Applying One-Off Patch to Introduce Analyze Mode and Reports

- Discovering and Monitoring Hosts and Targets

- Optional Infrastructure Requirements

- Setting Up SUDO, PAM, Privilege Delegation Settings

- Setting Up E-mail Notifications

- Setting Up Preferred Credentials

- Setting Up Preferred Credentials for Provisioning

- Setting Up Preferred Credentials for Patching

- Refreshing Host Configuration

- Setting Up Infrastructure for Online Patching

- Enabling Online Mode

- Setting Up My Oracle Support Credentials and Proxy Connection Settings

- Setting Up Online Settings

- Setting Up Infrastructure for Offline Patching

- Enabling Offline Mode

- Applying One-Off Patch

- Identifying Affected Targets and Required Patches

- Uploading Information Required by Oracle Patch Advisories

- Creating "Refresh From My Oracle Support" Job

- Uploading OPatch Patches to Oracle Software Library

- Identifying Patch from Oracle Patch Advisories

- Uploading Patch to Oracle Software Library

- Setting Up Infrastructure for Linux Patching

- Prerequisites for Using the Linux Patching Feature

- Setting Up the RPM Repository

- Prerequisites for Setting Up the RPM Repository

- Setting Up the RPM Repository

- Setting Up Linux Patching Group for Compliance Reporting

- Prerequisites for Setting Up Linux Patching Group

- Setting Up a Linux Patching Group

- Setting Up Infrastructure for Virtualization Systems

- Configuring Virtual Servers

- Creating Server Pools

- Registering Virtual Servers

- Setting Up Infrastructure for Bare Metal Provisioning

- Prerequisites for Using Bare Metal Provisioning

- Creating Super Administrator for Enterprise Manager

- Setting Up Boot Server

- Setting Up Stage Server

- Setting Up RPM Repository

- Setting UP RHEL 4 RPM Repository

- Setting Up OEL 4 RPM Repository

- Setting Up RHEL 5/OEL 5 RPM Repository

- Setting Up Software Library

- Checklist for Boot Server, Stage Server, RPM Repository, and Reference Host

- Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager

- Accessing the Bare Metal Provisioning Application

- Configuring Stage Server

- Configuring RPM Repository

- Configuring Boot Server

- Configuring the DHCP Server

- Configuring Software Library

Part II Database Provisioning

4 Provisioning Oracle Database

- Getting Started

- Deployment Procedure

- Supported Releases

- Cloning Existing Oracle Database Software

- Deployment Phases

- Prerequisites

- Cloning Procedure

- Provisioning Oracle Database Using Gold Image

- Deployment Phases

- Prerequisites

- Creating Gold Image

- Uploading Database Response File to Oracle Software Library

- Uploading Database Template File to Oracle Software Library

- Provisioning Procedure

- Provisioning Oracle Database from Staged Location

- Deployment Phase

- Prerequisites

- Provisioning Procedure

- Provisioning Standalone Oracle Database Using Archived Software Binaries

- Deployment Phases

- Prerequisites

- Uploading Software Binaries to Oracle Software Library

- Provisioning Procedure

- Manually Collecting and Uploading Configuration Information to My Oracle Support

- Instrumenting the Database for Configuration Collections

5 Provisioning Oracle Real Application Clusters (RAC)

- Getting Started

- Deployment Procedures

- Core Components Deployed

- Supported Releases

- Cloning a Running Oracle RAC

- Deployment Phases

- Prerequisites

- Cloning Procedure

- Provisioning Oracle RAC Using Gold Image

- Deployment Phases

- Prerequisites

- Provisioning Procedure

- Provisioning Oracle RAC Using Archived Software Binaries

- Deployment Phases

- Prerequisites

- Provisioning Procedure

- Sample Cluster Configuration File

6 Extending Oracle Real Application Clusters

- Getting Started

- Deployment Procedure

- Supported Releases

- Extending Oracle RAC

- Deployment Phases

- Prerequisites

- Procedure

7 Deleting or Scaling Down Oracle Real Application Clusters

- Getting Started

- Deployment Procedures

- Core Components Deleted

- Supported Releases

- Deleting the Entire Oracle RAC

- Deployment Phases

- Prerequisites

- Procedure

- Scaling Down Oracle RAC by Deleting Some of Its Nodes

- Deployment Phases

- Prerequisites

- Procedure

8 Provisioning Oracle Database Replay Client

- Getting Started

- Deployment Procedures

- Supported Releases

- Cloning a Running Oracle Database Replay Client

- Deployment Phases

- Prerequisites

- Cloning Procedure

- Provisioning Oracle Database Replay Client Using Gold Image

- Deployment Phases

- Prerequisites

- Provisioning Procedure

- Provisioning Oracle Database Replay Client from Staged Location

- Deployment Phases

- Prerequisites

- Provisioning Procedure

- Provisioning Oracle Database Replay Client Using Archived Software Binaries

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Part III Provisioning Linux Operating System

9 Provisioning Linux Operating System

- Getting Started

- Supported Releases

- Provisioning Bare Metal Boxes

- Prerequisites

- Creating a Default Image

- Setting Up a Default Image

- Staging the Default Image

- Ready to Go

- Provisioning Oracle VM Servers

- Prerequisites

- Provisioning Procedure

- Provisioning Single Server Images

- Prerequisites

- Creating a Network Component

- Creating Disk Layout Component

- Creating OS Component

- Creating Single Server Image

- Creating Assignments

- Provisioning Assignments

Part IV Provisioning Virtualization Systems

10 Provisioning Virtualization Systems

- Getting Started

- Deployment Procedures

- Supported Releases

- Provisioning Guest Virtual Machines

- Creating Software Library Components

- Prerequisites

- Creating a Software Component from an ISO Image

- Creating a Software Component from an Oracle VM Template

- Discovering ISO Images and Oracle VM Templates

- Creating Shared Disk

- Importing Oracle VM Templates and ISO Binaries as Server Pool Resources

- Prerequisites

- Importing Software Components from Software Components Tab

- Importing Software Components from Server Pool Resources Tab

- Creating Guest Virtual Machines

- Phases for Provisioning Guest Virtual Machines

- Prerequisites

- Provisioning Guest Virtual Machines Using Oracle VM Templates

- Provisioning Guest Virtual Machines Using ISO Images

- Provisioning Guest Virtual Machines Using PXE Boot

- Configuring the Guest Virtual Machine for Agent and Other Software

- Virtualization Central Dashboard

- Overview

- Editing Guest Virtual Machines

- Updating Preferred Virtual Server List

- Opening a VNC Console to the Guest Virtual Machine

- Deleting Server Pools, Oracle VM Servers, and Guest Virtual Machines

- Prerequisites for Deleting a Server Pool

- Deleting a Server Pool

- Prerequisites for Deleting an Oracle VM Server

- Deleting an Oracle VM Server

- Deleting a Guest Virtual Machine

- Live Migrating Guest Virtual Machines

- Prerequisites

- Live Migrating Selected Guest Virtual Machines

- Live Migrating All Guest Virtual Machines

- High Availability and Fault Tolerance

- Creating an NFS Cluster for High Availability

- Creating an OCFS2 Cluster for High Availability

- Configuring Oracle VM Servers for High Availability

- Advanced Operations

- Cloning Guest Virtual Machines

- Cloning Phases

- Prerequisites

- Cloning Procedure

- Saving Guest Virtual Machine as Template

- Bare Metal Provisioning of Oracle VM Servers

- Migrating from Oracle VM Manager to Enterprise Manager

Part V Middleware Provisioning

11 Provisioning Oracle Application Server

- Getting Started

- Deployment Procedures, Supported Releases, and Core Components Deployed

- Provisioning Oracle Application Server 10g Release 1 (10.1.3)

- Cloning a Running Oracle Application Server Instance

- Cloning from an Existing Cluster, Scaling Up the Existing Cluster, and Using the Same Internet Directory

- Provisioning from an Existing Cluster and Creating a New Cluster Without Internet Directory

- Provisioning from an Existing Cluster and Creating a New Cluster With Internet Directory

- Provisioning a New Installation or Gold Image of Oracle Application Server

- Provisioning and Creating a New Cluster Without Internet Directory

- Provisioning and Creating a New Cluster With Internet Directory

- Provisioning and Treating It as a Standalone Instance Without Internet Directory

- Provisioning and Treating It as a Standalone Instance With Internet Directory

- Provisioning Oracle Application Server 10g Release 1 (10.1.2.0.2)

- Provisioning Oracle Application Server and Creating a New Cluster Without Internet Directory

- Prerequisites

- Provisioning Procedure

- Provisioning Oracle Application Server and Creating a New Cluster With Internet Directory

- Prerequisites

- Provisioning Procedure

- Provisioning Oracle SOA Suite 10g (10.1.3.x)

12 Provisioning Oracle Service Bus Resources

- Getting Started

- Deployment Procedure

- Supported Releases

- Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain

- Deployment Phases

- Prerequisites

- Provisioning Procedure

- Understanding Export Modes

- Provisioning Oracle Service Bus Resources from Oracle Software Library

- Deployment Phases

- Prerequisites

- Provisioning Procedure

13 Provisioning Oracle BPEL Processes

- Getting Started

- Deployment Procedure

- Supported Releases

- Provisioning Oracle BPEL Processes

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Part VI Patching

14 Running Patch Prerequisite Checker Deployment Procedures

- Meeting Prerequisites

- Running Patch Prerequisite Checker for Standalone Database

- Running Patch Prerequisite Checker for Oracle RAC

- Patching Oracle RAC Nodes Individually

- Patching Oracle RAC Nodes Collectively

- Running Patch Prerequisite Checker for Oracle Clusterware

- Running Patch Prerequisite Checker for Oracle ASM

15 Patching Oracle Database

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Standalone Oracle Database in Online Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Standalone Oracle Database in Offline Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

16 Patching Oracle RAC

- Getting Started

- Deployment Procedures

- Core Components Patched

- Supported Releases

- Patching Oracle RAC in Online Mode

- Patching Oracle RAC Nodes Individually

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Oracle RAC Nodes Collectively

- Patching Oracle RAC in Offline Mode

- Patching Oracle RAC Nodes Individually

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Oracle RAC Nodes Collectively

17 Patching Oracle Clusterware

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Oracle Clusterware in Online Mode

- Patching Oracle Clusterware Nodes Individually

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Oracle Clusterware Nodes Collectively

- Patching Oracle Clusterware in Offline Mode

- Patching Oracle Clusterware Nodes Individually

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Oracle Clusterware Nodes Collectively

18 Patching Oracle Automatic Storage Management (ASM)

- Getting Started

- Deployment Procedure

- Supported Releases

- Patching a Standalone Oracle ASM in Online Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching a Standalone Oracle ASM in Offline Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

19 Patching Oracle Application Server

- Getting Started

- Deployment Procedure

- Core Components Patched

- Supported Releases

- Patching Oracle Application Server in Online Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

- Patching Oracle Application Server in Offline Mode

- Deployment Phases

- Prerequisites

- Patching Procedure

20 Patching Linux Hosts

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Linux Hosts

- Deployment Phases

- Prerequisites

- Patching Procedure

- Linux Patching Home Page

- Viewing Compliance History

- Prerequisites

- Procedure to View Compliance History

- Patching Non-Compliant Packages

- Prerequisites

- Procedure to patch Non-Compliant Packages

- Undo Patching

- Prerequisites

- Procedure to Undo Patching

- Registering a Custom Channel

- Prerequisites

- Procedure to Register a Custom Channel

- Cloning a Channel

- Prerequisites

- Procedure to Clone a Channel

- Copying Packages from One Channel to Another

- Prerequisites

- Procedure to Copy Packages from One Channel to Another

- Adding Custom Packages to a Channel

- Prerequisites

- Procedure to Add Custom Packages to a Channel

- Deleting a Channel

- Prerequisites

- Procedure to Delete a Channel

- Configuration File Management

- Prerequisites

- Creating Config File Channel

- Uploading Configuration Files

- Prerequisites

- Procedure to Upload Configuration Files

- Importing Files

- Prerequisites

- Procedure to Import Files

- Deploying Files

- Prerequisites

- Procedure to Deploy Files

- Deleting Channels

- Prerequisites

- Procedure to Delete Channels

21 Patching Solaris Hosts

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Solaris Hosts

- Deployment Phases

- Prerequisites

- Patching Procedure

22 Patching Microsoft Windows Hosts

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Microsoft Windows Hosts

- Deployment Phases

- Prerequisites

- Patching Procedure

Part VII Customization

23 Customizing Deployment Procedures

- Understanding Customization Types

- Understanding the Limitations

- Creating Copy of Deployment Procedure

- Adding Phases or Steps

- Adding Rolling or Parallel Phase

- Adding Job Step

- Adding Directive Step

- Adding Generic Component Step

- Adding Registered Component Step

- Adding Host Command Step

- Adding Manual Step

- Deleting Phases or Steps

- Enabling or Disabling Phases or Steps

- Customizing Steps to Run as Another User

- Choosing Privilege Delegation Over SUDO and PowerBroker

- Updating SUDOERS File with a List of Commands

- Creating Privilege Delegation Templates

- Using SUDO, PowerBroker, and Privilege Delegation Settings

- Making Global Settings

- Making Step-Level Settings

- Changing Error Handling Modes

- Customizing Directives

- Creating Copy of a Default Directive

- Storing the New Directive

- Customizing Deployment Procedure to Use the New Directive

- Running the Customized Deployment Procedure

- Setting Up E-Mail Notifications

- Enabling E-Mail Notifications

- Customizing PAF Status Notification Rule

- Customizing Deployment Procedures to RollBack Patches

- Downloading Rollback Perl Script

- Storing the Script as a Directive

- Customizing Deployment Procedure to Use Rollback Directive

- Running the Customized Deployment Procedure

Part VIII Enterprise Manager Command Line Interface (EMCLI)

24 Using EMCLI to Run Deployment Procedures

- EMCLI Concepts

- EMCLI Requirements

- Using EMCLI to Run Deployment Procedures

- Step 1: Finding Procedure GUID

- Step 2: Obtaining RuntimeData Template And RuntimeData XML

- Step 3: Creating Properties File

- Properties File for Out-Of-Box Procedures

- Properties File for Customized Procedures

- Properties File For Extending Procedure Execution

- Properties File For Applying Multiple Patches At Once

- Step 4: Procedure Execution

- Executing SIDB Patching for UNIX Using An Out-of-Box Procedure

- Use Cases for EMCLI-based Provisioning and Patching

- Use Cases for CRS/ASM/RAC Provisioning Procedure

- Use Cases for Extend Cluster Procedure

- Use Cases For RAC Delete/Descale Procedure

- Use Cases for Patching

- Limitations

- Setting Up Preferred Credentials for Targets

- Setting Credentials from the Oracle Enterprise Manager User Interface

- Setting Credentials through EMCLI

- Clearing Credentials through EMCLI

- Queries to Acquire Data for Patching Runtime

- EMCLI Verbs for Deployment Procedures

- get_instance_status

- get_procedure_types

- get_procedure_xml

- get_procedures

- EMCLI Verbs for Deployment Instances

- confirm_instance

- delete_instance

- get_instance_data_xml

- get_instances

- get_retry_arguments

- ignore_instance

- reschedule_instance

- resume_instance

- retry_instance

- set_instance_jobgrants

- start_paf_daemon

- status_paf_daemon

- stop_instance

- stop_paf_daemon

- submit_procedure

- suspend_instance

- update_and_retry_step

Part IX Additional Information

A Troubleshooting Issues

- Filing Bugs with Relevant Information

- Troubleshooting Provisioning and Patching Issues

- Troubleshooting Common Provisioning and Patching Issues

- Troubleshooting Virtualization Management Issues

- Troubleshooting Linux Provisioning Issues

- Troubleshooting Linux Patching Issues

- Frequently Asked Questions

- Frequently Asked Questions on Setting Up the Provisioning Environment

- Frequently Asked Questions on Directives and Components

- Frequently Asked Questions on Network Profiles and Images

B Using PARDeploy Utility

- Overview of Provisioning Archive (PAR) Files

- Overview of PARDeploy Utility

- Checking Oracle Software Library

- Exporting Deployment Procedures

- Obtaining Deployment Procedure's GUID

- Creating PAR File

- Importing PAR Files

- Importing Using Command Line Interface

- Importing Specific PAR File

- Importing All PAR Files

- Importing Using Grid Control Console

C Using Oracle Software Library

- Using the Software Library

- Exporting and Importing Entities Across Oracle Enterprise Manager Deployments

- Deleting and Purging Software Library Entities

- De-Configuring a Software Library Location

- Software Library Maintenance Tasks

- Software Library Issues

D Creating Templates for Oracle Database

- Overview

- Creating Database and Templates Using DBCA

- Creating Database and Templates Without Using DBCA

E Out-Of-Box RuntimeData Templates

- Out-Of-Box RuntimeData Templates for Oracle RAC Deployment Procedures

- Out-Of-Box RuntimeData Templates for Oracle Application Server Deployment Procedures

- Out-Of-Box RuntimeData Templates for Patching Procedures

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

G PXE Booting and Kickstart Technology

- About PXE Booting and Kickstart Technology

H About Patching Automation Reports

- About Patchability Report

- About Patching Deployment Procedure Execution Summary Report

I Converting Standalone Oracle Management Agent to Cluster Agent

- Using Graphical Mode to Convert

- Using Silent Mode to Convert

Index

List of Figures

- 1-1 Software Lifecycle Management Overview

- 2-1 User Flow for Creating Deployable Images for Hardware Servers

- 2-2 PXE Process

- 24-1 EMCLI Process to Run Deployment Procedures

List of Tables

- 2-1 Privileges for Provisioning and Administrative Operations in Virtualization Central

- 2-2 Deployment Procedure Status

- 3-1 EM CLI Options for set_credential Verb

- 3-2 Downloading Metadata XML Files

- 3-3 Jobs Submitted for Setting Up Linux Patching Group

- 3-4 Virtual Server Pool Configuration Details

- 3-5 Register Virtual Server Details

- 3-6 Checklist for Boot Server, Stage Server, RPM Repository, and Reference Host

- 4-1 Getting Started with Provisioning Oracle Database

- 4-2 Deployment Phases Involved in Cloning Existing Oracle Database Software

- 4-3 Deployment Phases Involved in Provisioning Gold Image from Software Library

- 4-4 Deployment Phases Involved in Provisioning Gold Image from Staged Location

- 4-5 Deployment Phases Involved in Provisioning Standalone Oracle Database

- 5-1 Getting Started with Provisioning Oracle RAC

- 5-2 Deployment Phases Involved in Cloning an Existing Oracle RAC

- 5-3 Deployment Phases for Provisioning Gold Image of Oracle RAC

- 5-4 Deployment Phases Involved in Provisioning Oracle RAC

- 5-5 Configuration Page - Element Description

- 6-1 Getting Started with Extending Oracle RAC

- 6-2 Deployment Phases Involved in Extending Oracle RAC

- 7-1 Getting Started with Deleting or Scaling Down an Existing Oracle RAC

- 7-2 Deployment Phases Involved in Deleting the Entire Oracle RAC

- 7-3 Deployment Phases Involved in Scaling Down an Existing Oracle RAC

- 8-1 Getting Started with Provisioning Oracle Database Replay Client

- 8-2 Deployment Phases Involved in Cloning Oracle Database Replay Client

- 8-3 Deployment Phases Involved in Provisioning Gold Image from Software Library

- 8-4 Deployment Phases Involved in Provisioning Gold Image from Staged Location

- 8-5 Deployment Phases Involved in Provisioning Oracle Database Replay Client

- 9-1 Getting Started with Provisioning Linux Operating System

- 9-2 Getting Started with Provisioning Single Server Images

- 10-1 Getting Started with Oracle VM Provisioning

- 10-2 Supported Releases

- 10-3 Phases for Provisioning Guest Virtual Machines

- 10-4 Guest Virtual Machine Configuration Details for Oracle VM Templates

- 10-5 Guest Virtual Machine Configuration Details for ISO Images and PXE Boot

- 10-6 Agent Configuration Options

- 10-7 Guest Virtual Machines: Editable Fields

- 10-8 Phases for Cloning Guest Virtual Machines

- 10-9 Clone Guest Virtual Machines

- 11-1 Getting Started with Provisioning Oracle Application Server

- 12-1 Getting Started with Provisioning Oracle Service Bus Resources

- 12-2 Deployment Phases Involved in Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain

- 12-3 Understanding Export Modes

- 12-4 Deployment Phases Involved in Provisioning Oracle Service Bus Resources from Oracle Software Library

- 13-1 Getting Started with Provisioning Oracle BPEL Processes

- 13-2 Deployment Phases Involved in Provisioning Oracle BPEL Processes

- 15-1 Getting Started with Patching Oracle Database

- 15-2 Deployment Phases Involved in Patching Oracle Database in Online Mode

- 15-3 Deployment Phases Involved in Patching Oracle Database in Offline Mode

- 16-1 Getting Started with Patching Oracle RAC

- 16-2 Deployment Phases for Patching Oracle RAC in Online Mode

- 16-3 Deployment Phases for Patching Oracle RAC in Offline Mode

- 17-1 Getting Started with Patching Oracle Clusterware

- 17-2 Deployment Phases for Patching Oracle Clusterware in Online Mode

- 17-3 Deployment Phases for Patching Oracle Clusterware in Offline Mode

- 18-1 Getting Started with Patching Oracle ASM

- 18-2 Deployment Phases for Patching Oracle ASM in Online Mode

- 18-3 Deployment Phases for Patching Oracle ASM in Online Mode

- 19-1 Getting Started with Patching Oracle Application Server

- 19-2 Deployment Phases for Patching Oracle Application Server in Online Mode

- 19-3 Deployment Phases for Patching Oracle Application Server in Offline Mode

- 20-1 Getting Started with Patching Linux Hosts

- 20-2 Supported Releases

- 20-3 Deployment Phases for Patching Linux Hosts

- 21-1 Getting Started with Patching Solaris Hosts

- 21-2 Deployment Phases for Patching Solaris Hosts

- 22-1 Getting Started with Patching Microsoft Windows Hosts

- 22-2 Deployment Phases for Patching Microsoft Windows Hosts

- 23-1 Field Description - Adding Rolling Phase

- 23-2 Field Description - Adding Steps

- 23-3 Updating SUDOERS File with a List of Commands

- 23-4 Map Properties

- 23-5 Values for Library Step Properties Page for Rolling Back Patches

- A-1 Status Values

- A-2 Maturity Levels

- B-1 PARDeploy Options

- E-1 Out-of-Box RuntimeData Templates for Oracle RAC Deployment Procedures

- E-2 Out-of-Box RuntimeData Templates for Oracle Application Server Deployment Procedures

- E-3 Out-of-Box RuntimeData Templates for Patching Procedures

- F-1 Sample Property Files for the Out-of-Box RuntimeData Templates

Oracle® Enterprise Manager

Administrator's Guide for Software and Server Provisioning and Patching

10g Release 5 (10.2.0.5.0)

E14500-04

November 2011

Oracle Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching, 10g Release 5 (10.2.0.5.0)

E14500-04

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

Primary Author:  Aravind Jayaraaman

Contributing Author:  Aparna Kamath

Contributor:  Sudip Datta, Rajat Nigam, Akanksha Sheoran, Hari Prasanna Srinivasan, Madhup Gulati, Bharat Paliwal, Dan Hynes, Kamaldeep Khanuja, Pradeepkumar Itharaju, Premjith Rayaroth, Eunhei Jang, Ryan Lemos, Ranjit Madampath, Macks Ningombam, Shamik Ganguly, Suparna Gurunaga, Amandeep Barboza, Rahul Gupta, Srivatsan Vijayaraghavan, Sudhir Ravindramohan, Vijay Sriram, Vivek Dosi, Kapil Makhija, Raman Venkateswaran, Siddharth Paradkar, Sachin Goel, Saurabh Garg.

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

The Administrator's Guide for Software and Server Provisioning and Patching introduces you to the lifecycle management solutions offered by Enterprise Manager Grid Control, and helps you understand what Deployment Procedures are and how they can be used for meeting your provisioning and patching requirements.

The guide has been created with great care and attention using multiple sources of information, including valuable notes from My Oracle Support, white papers and marketing collaterals from product management, feedback from development teams and also from customers that came in the form of bugs, services requests, and so on.

Understandably, this guide describes one of the most critical offerings of Enterprise Manager Grid Control and since some of the concepts may be difficult to describe using textual descriptions, we have considered some of the best practices in the industry and added as many examples and graphics as possible to help you understand the concepts, processes, and features better.

Audience

This guide is primarily meant for administrators who want to use the Deployment Procedures offered by Enterprise Manager Grid Control to meet their lifecycle management challenges. As an administrator, you can be either a Designer, who performs the role of a system administrator and does critical data center operations, or an Operator, who runs the out-of-box, automated procedures to maintain the enterprise configuration.

Structure of the Document

This guide covers conceptual information, facts you must know before you start using the Deployment Procedures, and a comprehensive set of instructions that help you understand how you can run the Deployment Procedures for different areas.

This section describes how the entire guide is structured. In particular, this section describes the following:

- Different Parts of the Guide

- Structure of the Chapters

Different Parts of the Guide

This guide has the following parts:

Part

Description

Part I, "Overview and Setup Details"

Introduces you to the lifecycle management solutions offered by Enterprise Manager Grid Control, describes the concepts and terms related to these solutions, and the infrastructure requirements for running the Deployment Procedures.

Part II, "Database Provisioning"

Describes the Deployment Procedures offered for provisioning Oracle Databases, Oracle RAC, and Oracle Database Replay Clients. Also describes the Deployment Procedures offered for extending, scaling down, or deleting an existing Oracle RAC instance.
Covers information about the supported releases, core components deployed, prerequisites to be met, and instructions to be followed for running the Deployment Procedures.

Part III, "Provisioning Linux Operating System"

Describes how you can provision Linux operating system on bare metal servers and virtual servers.

Part IV, "Provisioning Virtualization Systems"

Describes how you can provision Oracle Virtual Server (OVS) and Guest Virtual Machines, clone Guest Virtual Machines, and live-migrate Guest Virtual Machines.

Part V, "Middleware Provisioning"

Describes the Deployment Procedures offered for provisioning Oracle Application Server, Oracle Service Bus resources, and Oracle BPEL Processes.
Covers information about the supported releases, core components deployed, prerequisites to be met, and instructions to be followed for running the Deployment Procedures.

Part VI, "Patching"

Describes the Deployment Procedure offered for patching Oracle Database, ASM, Oracle Application Server, Oracle Clusterware, Oracle RAC, and operating system such as Linux, Microsoft Windows, and Sun Solaris.
Covers information about the supported releases, core components deployed, prerequisites to be met, and instructions to be followed for running the Deployment Procedures.

Part VII, "Customization"

Describes how you can customize Deployment Procedures. If you are already familiar with Deployment Procedures and have already used the out-of-box procedures for provisioning and patching, then this part will help you understand how you can create custom copies of those default procedures with changes specific to your environment. For example, you can enable e-mail notifications or even run the procedure as another user.

Part VIII, "Enterprise Manager Command Line Interface (EMCLI)"

Describes the EMCLI commands you can use to run Deployment Procedures.

Part IX, "Additional Information"

Provides additional information that are relevant and related to the details covered in the other chapters of this guide.

Structure of the Chapters

The chapters of part II, III, IV, and V cover multiple use cases and provide a comprehensive set of instructions. These chapters have the following structure:

- Getting Started section that helps you get started with that chapter. The section provides a high-level overview of the steps involved in performing a particular provisioning or patching task. Consider this section to be a documentation map to understand the sequence of actions you must take to successfully run a Deployment Procedure. Every step has a set of reference links that you can click to reach the relevant sections within the chapter and view more information.

- Deployment Procedure section that describes the Deployment Procedure offered by Enterprise Manager Grid Control for a particular provisioning or patching requirement. Read this section to understand the Deployment Procedure, the use cases it covers, and so on.

- Supported Releases section that lists the versions and releases of the target that are supported by the Deployment Procedure for provisioning or patching. Read this section to understand the coverage of the Deployment Procedure.

- <Use Case> sections that describe the use cases covered in the chapter. Every use case has the following structure:

- Deployment Phases section that describes the deployment phases involved in a particular provisioning or patching task. Read this section to understand the flow of interview screens involved in the Deployment Procedure.

- Prerequisites section that lists the prerequisites you must meet before running the Deployment Procedure. Read this section and meet all the prerequisites before you move on to the instructions to run the Deployment Procedure.

- Provisioning or Patching Procedure section that outlines the instructions for running the Deployment Procedure. Read this section and follow the steps to successfully run the Deployment Procedure for your provisioning or patching requirement.

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 documents in the Enterprise Manager documentation library available on Oracle Technology Network (OTN):

- Oracle Enterprise Manager Grid Control Release Notes

- Oracle Enterprise Manager Grid Control Installation Guide

You can access the Enterprise Manager documentation library using the following URL:

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

Conventions

The following conventions are used in this document:

Convention

Meaning

boldface

Indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Other Graphics

Graphics have been used extensively in addition to the textual descriptions to ensure that certain concepts and processes are illustrated better.

Part I

Overview and Setup Details

This part provides an overview of the lifecycle management challenges you may face in your environment and introduces you to the solutions offered by Enterprise Manager Grid Control that can help you manage critical data center operations more easily and efficiently.

In particular, this part covers the following chapters:

- Chapter 1, "Overview of Lifecycle Management Solutions"

- Chapter 2, "Things to Know"

- Chapter 3, "Infrastructure Requirements"

1 Overview of Lifecycle Management Solutions

This chapter provides an overview of the lifecycle management solutions offered by Enterprise Manager Grid Control. In particular, this chapter covers the following:

- Lifecycle Management Challenges

- Enterprise Manager Grid Control's Lifecycle Management Solutions

- Benefits of Using Provisioning and Patching Features

- Success Stories

Lifecycle Management Challenges

In today's world, proliferation of low cost servers in our data centers and numerous software deployments on those servers have brought in a fresh set of lifecycle management challenges.

One of the well-acknowledged problems include the difficulty in managing consistency and compatibility across operating systems and software deployments, server drifts and security vulnerabilities that lead to lack of compliance. Besides that, other problems include the difficulty in deploying new software and maintaining them, difficulty in provisioning new servers with variety of configurations and maintaining them, and difficulty in adapting to changes in workload of the environment.

These lifecycle management challenges eventually result in system administrators and database administrators spending significant amount of their time in software and server provisioning and maintenance operations.

Enterprise Manager Grid Control's Lifecycle Management Solutions

Enterprise Manager Grid Control offers lifecycle management solutions in the form of Deployment Procedures that help you manage the entire lifecycle of software, applications, and servers. Using Deployment Procedures, you can automate not only the deployment of software, applications, and servers but also the maintenance of these deployments. This makes critical data center operations easy, efficient, and scalable resulting in lower operational risk and cost of ownership.

The provisioning and patching solutions are offered across the stack for:

- Operating Systems, with Bare metal provisioning on Linux and operating system patching

- Databases, with Real Application Clusters (RAC) provisioning, extension, and deletion and flexible patching for Oracle database and Oracle Real Application Clusters

- Middleware, with application server J2EE, BPEL, and SOA provisioning and patching

The following illustrates how Enterprise Manager Grid Control manages the software lifecycle using its Deployment Procedures:

Figure 1-1 Software Lifecycle Management Overview

You can see in the illustration that Enterprise Manager Grid Control orchestrates the initial reference sandbox deployment and then the mass unattended deployment of gold images created from these reference deployments.

Besides deployment of software, Enterprise Manager Grid Control also automates the ongoing patch lifecycle management of these deployments - proactively informs you about the critical patches and vulnerabilities in the deployments, automatically downloads the required patches, applies them to the deployments, and also verifies whether the patches were applied successfully.

Benefits of Using Provisioning and Patching Features

The following are the advantages of using the provisioning and patching features offered by Enterprise Manager Grid Control:

- The provisioning and patching features provide a repeatable, reliable, and automated solution for performing mass, unattended, and schedulable deployment of

- Software and servers based on Gold Images created using reference deployment or installation media

- Software and operating system updates

- Complex and multi-tier software like Oracle Real Application Clusters (RAC) and Application Server Clusters

- Orchestrates not only provisioning of software but completely automates configuration of software and ensures zero-time for patching of mission critical systems by orchestrating rolling patching for complex multi-tier installation like Real Application Clusters (RAC) databases and Application Server clusters.

- Allows new resources to be provisioned at short notice based on compliant and tested gold images.

- Enterprise Manager Grid Control's Critical Patch Facility proactively and regularly queries Oracle Metalink for critical patches that have been released and notifies the administrators of only those patches applicable to them. It can also invoke the Patch application in context, and remedy the vulnerable installations. The Critical Patch Facility also supports an offline mode to serve the case of data centers that are not connected to the Internet.

- Completely automates the patching operations across the stack. For example, for database patching, it takes care of shutting down and starting up database instances as required by the patch.

- Allows multiple operations to be accommodated in a single change window.

- Enterprise Manager Grid Control also provides command-line interface support to all out-of-box provisioning and patching deployment procedures. These features can hence be invoked by custom scripts.

- Software provisioning and patching features support SUDO and PAM authentication.

- Single interface for multiple players. For example, component designers responsible for creating gold images based on corporate standards and the operators all use the same Enterprise Manager Grid Control console.

- Automation of repeatable installation and patching operations across the stack leads to substantial cost savings in terms of costs and man-hours.

Success Stories

NetApp Uses Automated Provisioning to Reduce Manual Effort Time from a Few Weeks to a Few Clicks

"With Oracle Enterprise Manager, we are now able to meet corporate standards 100% of the time. And, our pre-patched gold images, enabled by Oracle Enterprise Manager, save time and resources."
– Alok Arora, Director, Enterprise Integration and Architecture, NetApp, Inc.

NetApp, formerly Network Appliance, creates innovative storage and data management solutions that help its customers accelerate business breakthroughs and achieve outstanding cost efficiency. NetApp's dedication to principles of simplicity, innovation, and customer success has made it one of the fastest-growing storage and data management providers today.

The following were their lifecycle management challenges:

- Reduce two-week time frame needed for IT group to create a complex multitier service-oriented architecture (SOA) deployment with components spanning various hosts.

- Provision new deployments for a growing number of internal customers quickly, efficiently, and in a manner that complies with corporate standards.

- Improve day-to-day work life for IT staff by reducing amount of time needed to roll out patches developed during each patching cycle, a process that took between 8 and 10 weeks.

The following were the lifecycle management solutions offered by Oracle:

- Utilized the Provisioning and Patch Automation Pack for Oracle Middleware, and helped NetApp to expedite provisioning of new SOA deployments with gold images that enable administrators to provision deployments via a single management console.

- Created a standard process to provision and patch Fusion Middleware in a completely automated, and reliable manner — reducing manual effort from a few weeks to a few clicks.

- Created test benches based on production installations — allowing NetApp to apply patches on these test systems and then deploy them to multiple production systems.

- Enabled NetApp to deploy standard Fusion Middleware component images based on features licensed, and to have a standard process that leads to best-practice deployments with no configuration drifts from corporate standards.

- Enabled the IT staff to direct its attention to more strategic initiatives.

- Provided IT staff with processes and procedures that enable them to meet unpredictable demands from customers.

More Success Stories

To view more success stories and understand how Enterprise Manager Grid Control's lifecycle management solutions help organizations control IT management costs while improving the quality of their services, access the following URL:

http://www.oracle.com/customers/products/ent_manager.html

2 Things to Know

Enterprise Manager Grid Control offers lifecycle management solutions in the form of Deployment Procedures to meet your provisioning and patching requirements. This chapter describes the overall coverage of the provisioning and patching features, the coverage of Deployment Procedures, and other aspects you must know before you begin using them.

Oracle strongly recommends you to read this chapter so that you understand the fundamentals and terms used in this context.

This chapter covers the following:

- Understanding Provisioning and Patching Solutions

- Understanding Deployment Procedures

- Understanding Provisioning Deployment Procedures

- Understanding Patching Deployment Procedures

- Understanding Oracle Software Library

- Understanding Linux Patching

- Understanding Virtualization Management

- Understanding Bare Metal Provisioning

- Understanding Other Related Concepts

Understanding Provisioning and Patching Solutions

This section describes the following:

- Provisioning

- Patching

- Patching Versus Upgrading

- Patches

Provisioning

Provisioning is the first phase of the software lifecycle that deals with installation and configuration of software, applications, or servers across different platforms, environments, and locations.
Enterprise Manager Grid Control offers provisioning Deployment Procedures that help you seamlessly deploy software across your enterprise configuration.

Patching

Patching is one of the phases of the software lifecycle that helps you maintain the software over a period of time and always keep it updated with the latest features offered by the software vendor. It is a process that deals with migrating from one version of the software product to another, higher, much-improved version.
Enterprise Manager Grid Control offers patching Deployment Procedures that help you seamlessly patch Oracle software across your enterprise configuration.

Oracle releases patches periodically to help you migrate to a newer version of the software product and reap the benefits of an improved version. These patches contain critical enhancements and bug fixes that make the product better and offer more value to your organization.

For example, for the Oracle Database 10g Release 1 (10.2.0.1) base release, Oracle has released patches that help you migrate to either Oracle Database 10g Release 2 (10.2.0.2), Oracle Database 10g Release 3 (10.2.0.3), or Oracle Database 10g Release 4 (10.2.0.4); the last one being the most recent patch.

Patching Versus Upgrading

As described in the previous section, Patching refers to the process of migrating from one version to another, newer version of the software product within a particular release.
For example, if Oracle Database 10g is the release, then Patching refers to migrating from Oracle Database 10g Release 1 (10.2.0.1) to Oracle Database 10g Release 2 (10.2.0.2). Here, Release 2 (10.2.0.1), Release 2 (10.2.0.2), and so on are different versions of the 10g release.

Upgrading refers to the process of upgrading from one release to another, newer release of the software product.
For example, if Oracle Database 10g is one release and Oracle Database 11g is another release, then Upgrading refers to upgrading Oracle Database 10g to Oracle Database 11g. Here, 10g, 11g, and so on are different releases of the Oracle Database product.

Patches

Patches are periodic software updates released by Oracle. They contain bugs fixes only, and they must be applied on the software product to maintain a bug-free and improved version of the software.
Patches can be one-off patches, interim patches, or critical patch updates (CPU). Some of these may even be requirement-specific and released only to a few customers.

Patches can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library.

Patch Sets

Patch Sets are new releases of the software product released by Oracle. They contain a collection of patches, important enhancements, and bug fixes. They are much larger in size, and are released for all customers. They must be applied on the base or existing release of the software product to maintain an up-to-date version of the software.
Patch Sets can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library.

Understanding Deployment Procedures

This section describes the following:

- Deployment Procedures

- Understanding Phases and Steps

- Activities Involved in Deployment Procedures

- Users of Deployment Procedures

- Viewing Details of Deployment Procedures

Deployment Procedures

A Deployment Procedure is a procedure that contains a hierarchal sequence of provisioning or patching steps, where each step may contain a sequence of other steps. In other words, the workflow of all tasks that need to be performed for a particular lifecycle management activity is encapsulated in a Deployment Procedure.
For example, imagine a Deployment Procedure to be the "Coffee" button on the coffee vending machine. So, every time you need a cup of coffee, you press the "Coffee" button and it automatically adds the required ingredients and serves coffee through its nozzle.

You select a Deployment Procedure in the Enterprise Manager Grid Control console to perform a particular provisioning or patching task. The Deployment Procedure contains a set of predefined steps that run one by one automatically to complete the entire task.

Enterprise Manager Grid Control comes with a set of default Deployment Procedures that help you accomplish common provisioning and patching-related tasks. Each Deployment Procedure is unique, and is designed to perform a particular operation according to the source being provisioned or target being patched. For example, the Deployment Procedure to patch a single instance database differs from the one to patch an Oracle RAC environment or an application server.

Understandably, your provisioning and patching-related requirements may vary from one environment to another, or from a test installation to a production installation. You can use the default Deployment Procedures and customize them according to your needs.

Understanding Phases and Steps

Deployment Procedures comprise various phases and steps that run serially or in parallel to perform a particular provisioning or patching operation.

A phase contains steps or more phases. The different types of phases are:

- Rolling Phase
Rolling phase is a phase where steps are run serially across targets.

- Parallel Phase
Parallel phase is a phase where steps are run in parallel across targets.

A step is an abstraction of a unit of work. For example, starting the database is a step. It is either part of a phase or independent. The different types of steps are:

- Manual Step
Manual step is a task that requires user interaction and cannot be automated. Typically, Enterprise Manager Grid Control displays the instructions that need to be performed by you. After you perform those operations, you proceed to the next step. For example, logging in to a system and updating the kernel parameter, rebooting a system, providing special privileges to the user, and so on.

- Computational Step
Computational step is a task whose operations are performed within Enterprise Manager Grid Control and they do not require any user intervention. This step gathers additional information for running a procedure. This step cannot be manually inserted by you. For example, running an SQL query against a schema to gather more data for other steps to run, retrieving target properties from the repository and updating the runtime information, and so on.

- Action Step
Action step is a task that performs some operations run on one or more targets. They must be enclosed within a phase. The Deployment Procedure maps the Action Step and target pair to a job in the Enterprise Manager Job System. The Deployment Procedure can schedule, submit, and run a job per Action Step per target. For example, running a script, applying a patch, upgrading an Oracle home, and so on.

Also note that an Action Step is said to have completed successfully only when all its associated jobs have completed successfully. If a job fails, then the Action Step also fails. You may then manually restart the job in question or ignore and instruct the Deployment Procedure to proceed.

The different types of Action Steps include:

- Job
Job Step is a special type of Action Step that executes a predefined job type on a target. This is used if you want to execute a job type as a part of a Deployment Procedure. You need to pass job parameters for a step.

- Directive
Directive step is a special type of Action Step to deploy a directive alone. This is useful when users want to store their custom scripts in Oracle Software Library (Software Library) and reuse them in a Deployment Procedure.

- Component (Generic or Registered)
Generic component step is a special type of Action Step to deploy a Software Library component and the associated Directive. Deployment Procedure Manager executes the directive with respect to the component. Components used for Generic Component Step generally have one directive associated with them. This association is done by selecting both the component and directive while creating the step. All directives that you associate with the component while uploading to the Software Library are ignored while running the step.

- Host Command
Host Command Step is a special type of Action Step that encapsulates simple host commands. This step allows the user to enter a command line or a script (multiple commands) to be executed on the target host.

Activities Involved in Deployment Procedures

The activities involved in Deployment Procedures are design-time activities and run-time activities.

- Design-time activities include creating components, directives, and images, and storing them in Oracle Software Library; and sometimes even customizing the default Deployment Procedures according to the needs of the organization.

- Run-time activities include using these Deployment Procedures to actually provision or patch software, applications, or servers.

Users of Deployment Procedures

In a typical data center, the main users of Deployment Procedures are Designers (Lead Administrators) and Operators.

Designers (Lead Administrators) are users who perform design-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for setting up the infrastructure for running Deployment Procedures.

Operators are users who perform run-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for running the Deployment Procedures to provision or patch a target.

Viewing Details of Deployment Procedures

To view the default configuration settings of a Deployment Procedure and the steps involved in it, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, in the Procedures tab, from the table, select the Deployment Procedure for which you want to view details, and click View.
Enterprise Manager Grid Control displays the View Procedure page that shows the default configuration settings and steps involved in the selected Deployment Procedure.

Understanding Provisioning Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning:

Target Type

Provisioning Deployment Procedure

Chapter No.

Oracle Database (Standalone)

- Oracle Database Provisioning

- Oracle Database Replay Client Provisioning

- Chapter 4

- Chapter 8

Oracle RAC Database

- Oracle Clusterware / RAC Provisioning for Windows

- Oracle Clusterware / RAC Provisioning for UNIX

- One Click Extend Cluster Database

- Delete/Scale down Oracle Real Application Clusters

- Chapter 5

- Chapter 5

- Chapter 6

- Chapter 7

Middleware

- Application Server Deployment (myJ2EE) 10.1.2.0.2

- Application Server Deployment 10.1.3

- Application Server Deployment 10.1.3.xSOA

- Oracle BPEL Process Manager Provisioning

- Oracle Service Bus Provisioning

- Chapter 11

- Chapter 11

- Chapter 11

- Chapter 13

- Chapter 12

Virtualization

- Live Migration

- Virtual Machine Cloning

- Edit Virtual Machine

- Create Shared Disk

- Virtual Machine Provisioning Using PXE

- Virtual Machine Provisioning Using ISO

- Virtual Machine Provisioning Using Template

- Import ISO Image

- Import Template

Chapter 10

Note:

The Cloning Wizard is not supported from Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0).

Understanding Patching Deployment Procedures

This section describes the following:

- Patching Deployment Procedures

- Understanding Patching Modes

- Understanding Patching Methodologies

Patching Deployment Procedures

The following are the patching Deployment Procedures offered by Enterprise Manager Grid Control.

Target Type

Patching Deployment Procedure

Chapter No.

Operating System Patching

- Patch Windows hosts

- Patch Linux hosts

- Patch Solaris hosts

- Chapter 22

- Chapter 20

- Chapter 21

Oracle Database (Standalone)

Patch Oracle Database

Chapter 15

Oracle ASM

Patch Standalone Oracle ASM

Chapter 18

Oracle RAC

- Patch Oracle RAC Database - Rolling

- Patch Oracle RAC Database - All Nodes

Chapter 16

Oracle Clusterware

- Patch Oracle Clusterware - Rolling

- Patch Oracle Clusterware - All Nodes

Chapter 17

Oracle Application Server

Patch Application Server

Chapter 19

Note:

- The Patch Oracle Database Deployment Procedure supports 9.2.0.8 or higher database patch sets. For patch sets that are lower than 9.2.0.8, you cannot use Deployment Procedures, and therefore, you will have to manually apply them.

- By default, for the "Patch Oracle Database" Deployment Procedure, the Stop CSS Daemon and Start CSS Daemon steps are disabled. However, if you are applying a 10.1.0.5 database patch set, then before running the Deployment Procedure, enable the Stop CSS Daemon and Start CSS Daemon steps, and set the Run Privilege setting of these two steps to Normal.

Understanding Patching Modes

Using Deployment Procedures, you can apply a patch or patch set in either online mode or offline mode.

Online Patching Mode helps you if the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support.
Using Enterprise Manager Grid Control, you can schedule a job that will run periodically and connect to My Oracle Support, check for the latest patches and patch sets, and automatically download them. This relieves you of the manual effort involved in searching the latest patches and patch sets, and downloading them whenever they are available.

Offline Patching Mode helps you if the host that runs Enterprise Manager Grid Control does not have an Internet connection to connect to My Oracle Support.
In this case, you must manually download the patch and patch sets from My Oracle Support using another host that has an Internet connection. Using Enterprise Manager Grid Control, you can manually upload these patches and patch sets to the Patch Cache so that they can be applied later.

Understanding Patching Methodologies

For Oracle RAC Database and Oracle Clusterware, you can patch all instances of the cluster either in a rolling or parallel mode. The parallel manner is called All Nodes in Enterprise Manager Grid Control.

- Rolling mode refers to the patching methodology where the nodes of the cluster are patched individually, that is, one by one.
For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node until all the nodes are patched successfully.

This methodology is best suited for the following use cases:

- When you are applying one-off patches that support this methodology.

Note:

Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.

- When you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service.

Note:

You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use the All Nodes methodology.

- All Nodes (or parallel) mode refers to the patching methodology where all the nodes are patched at a time, collectively. In this methodology, all the nodes are shut down and the patch is applied on all of them at the same time.
This methodology is best suited for the following use cases:

- When you are applying patch sets, or one-off patches that support this methodology.

- When you want to patch a shared Oracle home clusterware. In case of a shared Oracle home, all the nodes are shut down, but the patch is applied only on one of the nodes.
For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, and not on all the nodes.

Note:

Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

Understanding Oracle Software Library

This section describes the following:

- Oracle Software Library

- Components

- Directives

- Images, Network Templates, Hardware Templates, Disk Layouts

- Assignments

Oracle Software Library

Oracle Software Library (Software Library) is a repository that stores certified software images (for example, Oracle Database, operating system, Oracle Real Application Clusters, third party software, and so on) and other related entities. These can then be automatically mass-deployed to provision software, software updates, and servers using Enterprise Manger Grid Control in a reliable and repeatable manner. These provisioning operations, which are unattended and can be scheduled, lead to substantial cost savings.
For example, imagine Software Library to be the container inside the coffee vending machine that has smaller compartments for storing milk, coffee powder, and sugar. So, before you press the "Coffee" button, you would ideally stock milk, coffee powder, and sugar in those smaller compartments of the container inside the vending machine.

The Software Library is part of and within Enterprise Manager Grid Control. It is not a separate, add-on product that needs to be installed separately. You can use the Enterprise Manager Grid Control console to access the Software Library and create components, images, directives, and store metadata and binary content.

For information about components, images, and directives, see Components, Directives, and Images, Network Templates, Hardware Templates, Disk Layouts, respectively.

For information about setting up the Software Library, see Setting Up Oracle Software Library. For information about using other options offered by the Software Library, see Appendix C, "Using Oracle Software Library".

Components

Components are entities in the Software Library that represent the primary building blocks for Deployment Procedures. A component can represent operating system software, Oracle software, or any third-party software and applications.
For example, imagine a Component to be an ingredient, such as milk, coffee powder, or sugar stored in the container inside a coffee vending machine. Without these, the vending machine cannot prepare a cup of coffee.

Components are individually maintained within the Software Library, and you can associate versions, states, and maturity levels with each component. They may also be combined with other components as needed, to specify the complete software configuration or image that is provisioned on target hosts.

Directives

Directives are entities in the Software Library that represent a set of instructions to be performed. These are constructs used to associate scripts with software components and images. These scripts contain directions on how to interpret and process the contents of a particular component or an image.
For example, imagine a Directive to be the program that runs inside the coffee vending machine to automate the process of preparing coffee. The program essentially instructs the vending machine to add the ingredients one by one, and then serve the drink through its nozzle.

Directives encapsulate the script, the command line used to invoke the script, and the script configuration properties. They capture everything required for invoking the script on a machine during a provisioning operation.

Directives are usually categorized based on the provisioning life cycle phases they are targeted for, or the actions they perform. Imagine Directives as set of executable instructions that run from a supported shell (for example, borne-again, Perl, Python), programming language (for example, Java), or execution framework or interpreter (such as “make” or “ant”).

Directives are contained within a file stored in the Oracle Software Library and referenced from the software components that employ them. Versions, states and maturity levels can be associated with each directive.

Images, Network Templates, Hardware Templates, Disk Layouts

Images are entities that represent a collection of components along with the necessary directives that create a deployable configuration for a single or set of target hosts.
Network Templates, Hardware Templates, and Disk Layouts are used to define the network, hardware, and disk layout configuration of the target hosts, respectively.

For example, imagine an Image to be a cappuccino flavored drink readily available in a paper carton. In this case, you do not prepare the coffee; the drink already contains milk, cappuccino coffee powder, and sugar, and it's all mixed and readily available for consumption.

Images are stored in the Oracle Software Library and versions, states, and maturity levels can be associated with them.

Assignments

Assignment is the activity to select an image and provision them on hardware servers. Assignments allow specifying properties (such as image properties, file system, root password, network profiles, port, IP address, etc.) that will be used during the provisioning of hardware servers. Assignments also allow for setting of advanced parameters like NTP, NIS, NFS and kernel parameters.

Understanding Linux Patching

Linux Host Patching is a feature in Enterprise Manager Grid Control that helps in keeping the machines in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm. This feature support in Enterprise Manager Grid Control enables you to:

- Set up Linux RPM Repository based in Unbreakable Linux Network(ULN) channels

- Download Advisories (Erratas) from ULN

- Set up Linux Patching Group to update a group of Linux hosts and collect compliance information

- Allow non-compliant packages to be patched

- Rollback/Uninstall packages from host

- Manage RPM repositories and channels (clone channels, copy packages from one channel into another, delete channels)

- Add RPMs to custom channels

- Manage Configuration file channels (create/delete channels, upload files, copy files from one channel into another)

The following are concepts related to Linux patching:

Linux Host

A host target in Enterprise Manager Grid Control that is running the Linux operating system.

Linux Patching Group

A set of managed Linux hosts that are associated with a common RPM repository. Every group is configured with an update schedule according to which, a recurring job is triggered that will update the hosts of the group with the associated RPM repositories.

Unbreakable Linux Network (ULN)

Unbreakable Linux Network (ULN) is a Web site hosted by Oracle to provide updates for Oracle Enterprise Linux.

ULN Channel

A channel is a grouping of RPM packages on the ULN network. For example, el4_latest channel contains all packages for OEL 4.

RPM Repository

RPM repository is a directory that contains RPM packages and their metadata (extracted by running yum-arch and createrepo). The RPM repository is accessible via http or ftp. An RPM repository can be organized to contain packages from multiple channels.
For example, /var/www/html/yum/Enterprise/EL4/latest might contain packages from the el4_latest channel on ULN.

Custom Channel

A channel that is created by the user to store a set of custom RPM packages. Custom channels can be added to the RPM repository.

Configuration Channel

A channel that is created by the user to store a set of Linux configuration files. Configuration channels can be used in the Linux patching application GUI to deploy configuration files on Linux hosts.

Understanding Virtualization Management

Virtualization management involves the monitoring, administration, and maintenance of virtual servers and guest virtual machines in your enterprise. Oracle provides the customer increased value by extending Enterprise Manager capabilities to monitor virtualized entities alongside the physical infrastructure and perform complete lifecycle management of virtual servers and software running on them.

This section describes the following:

- Terms Used in Virtualization

- Privileges Required for Administrative and Provisioning Operations

Terms Used in Virtualization

The following describes the terms used in virtualization:

Oracle VM

Oracle VM is server virtualization software. Installing Oracle VM on a bare metal box allows for the creation of multiple guest virtual machines on it. Just like Oracle databases and Oracle Fusion Middleware, Oracle VM is available for download on Oracle Technology Network (OTN).

Virtual Server

Virtual Server is a generic term used to describe a physical box running virtualization software (hypervisor) on it. A new virtual server can be provisioned by installing Oracle VM server software on a bare metal physical box. "Virtual Server" is a target type in Enterprise Manager that represents the Oracle VM targets.

Every Oracle VM server can perform one or more of the functions described below:

- Master Server
The Master Server is the core of the server pool operations. It acts as the contact point of the server pool to the outside world, and also as the dispatcher to other servers within the server pool. The load balancing is implemented by the Master Server. For example, when you start a guest virtual machine, the Master Server will choose a Guest VM Server with the maximum resources available to run the guest virtual machine. There can be only one Master Server in a server pool. The state of a virtual server pool is equivalent to the state of the master virtual server.

- Utility Server
The Utility Server is responsible for I/O intensive operations such as copying or moving files. Its function focuses on the creation and removal operations of guest virtual machines, virtual servers, and server pools. There can be one or more Utility Servers in a server pool. When there are several Utility Servers, Server Pool Master chooses the Utility Server with the maximum CPU resources available to conduct the task.

- Guest VM Server
The primary function of the Guest VM Server is to run guest virtual machines, thus acting as a hypervisor. There can be one or more Guest VM Servers in a server pool. When there are several Guest VM Servers, Master Server chooses the Guest VM Server with the maxhmum resources available (including memory and CPU) to start and run the virtual machine.

When the Oracle VM Server Pool is created, the user is asked to provide the details of the Master Server for that pool. By default, this Oracle VM Server also performs the functions of the Utility Server and Guest VM Server.

The user can later change the Utility Server and Guest VM Server functions using the Edit Virtual Server action.

Monitoring Server

The monitoring server monitors the virtual server remotely. Multiple virtual servers are monitored by one agent. Enterprise Manager agent must not be installed on virtual servers. The Monitoring Server agent (Enterprise Manager agent that monitors Oracle VM servers) should be upgraded to version 10.2.0.5.0.

Virtual Server Pool

A Server Pool is a logical grouping of one or more virtual servers that share common storage. A virtual server can belong to only one virtual server pool at a time. Guest virtual machines and resources are also associated with server pools. Oracle VM Server Pool is an aggregate target type in Enterprise Manager to represent the server pool of Oracle VM Servers.

Guest Virtual Machine

Guest Virtual Machine (also known as Guest VM) is the container running on top of a virtual server. Multiple guest virtual machines can run on a single virtual server. Guest virtual machines can be created from Oracle VM templates. Oracle VM templates provide pre-installed and pre-configured software images to deploy a fully configured software stack. Oracle VM templates can be downloaded from OTN at the following location:

http://www.oracle.com/technology/products/vm/templates.html

A guest virtual machine monitored by an Enterprise Manager agent is treated like any other Host target. This type of guest virtual machine is referred to as a "Managed Guest VM".

A guest virtual machine that is not monitored by any Enterprise Manager agent is referred to as an "Unmanaged Guest VM". Only limited monitoring and configuration information is available for such a guest virtual machine.

Privileges Required for Administrative and Provisioning Operations

Table 2-1 lists the privileges required to perform administrative and provisioning tasks on server pools, virtual servers, and guest virtual machines.

Table 2-1 Privileges for Provisioning and Administrative Operations in Virtualization Central

Task

Privileges

Create Virtual Server Pool

Add any Target system privilege

Remove Virtual Server Pool

Full privilege on the Server Pool Target and the member Virtual Servers

Manage Virtual Server Pool

Operator privilege on the Server Pool Target

Create Guest Virtual Machine

Operator privilege on the Server Pool Target

Discover Guest Virtual Machine

Operator privilege on the Server Pool Target

Clear Operation Error (Virtual Server Pool)

The Privilege check depends on the operation that has failed.

- If Create Virtual Server Pool action has failed:
User must be the job owner or must have Super Administrator privileges

- If Remove Virtual Server Pool has failed:
User must have Full privilege on the Server Pool Target and the member Virtual Servers as well

- If Stop Virtual Server / Reboot Virtual Server operation on the Master Virtual Server had failed:
User must have Operator privilege on the Master Virtual Server and the Server Pool Target

Register Virtual Server

Add any Target system privilege

De-register Virtual Server

Full privilege on the Virtual Server and the Server Pool Target

Edit Virtual Server

Operator privilege on the Virtual Server and the Server Pool Target

Live Migrate All Guest Virtual Machine

Operator privilege on the source Virtual Server and the Server Pool Target.

Since the destination virtual server gets selected automatically and may be any virtual server in the Server Pool, Operator privilege on all member virtual servers of the Server Pool Target is essential.

If preferred servers are set for the guest virtual machine, you will need Operator privilege on preferred virtual servers only.

Stop Virtual Server

Operator privilege on the Virtual Server and the Server Pool Target

Reboot Virtual Server

Operator privilege on the Virtual Server and the Server Pool Target

Clear Operation Error (Virtual Server)

Privilege check depends on the operation that has failed.

- If Register Virtual Server has failed:
User must be the job owner or must have Super Administrator privileges

- If De-register Virtual Server has failed:
User must have Full privilege on the Server Pool Target and the Virtual Servers as well

- If Stop Virtual Server/Reboot Virtual Server operation has failed:
User must have Operator privilege on the Master Virtual Server and the Server Pool Target

Live Migrate Guest Virtual Machine

Operator privilege on the source Virtual Server and the Server Pool Target.

Since the destination virtual server gets selected automatically and may be any virtual server in the Server Pool, Operator privilege on all member virtual servers of the Server Pool Target is needed.

If preferred servers are set for the guest virtual machine, you will need Operator privilege on preferred virtual servers only.

Clone Guest Virtual Machine

Operator privilege on the Server Pool Target

Save Guest Virtual Machine as Template

Operator privilege on the Server Pool Target

Edit Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target.

An Edit Guest VM action may be performed on a Halted guest virtual machine as well. In this case privileges will be checked only on the Server Pool Target.

Update Preferred Server List

Operator privilege on the Virtual Server and the Server Pool Target.

If the preferred server selection is set to Automatic, the guest virtual machine may come up on any virtual server within the server pool hence, you must have Operator privilege on all the members virtual servers in the server pool Target.

If the preferred server selection is set to Manual, you must have Operator privilege on the specified list of member virtual servers.

Delete Guest Virtual Machine

Full privilege on the Server Pool Target

Stop Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target

Start Guest Virtual Machine

Operator privilege on the Server Pool Target.

If the preferred server selection for that guest virtual machine is set to Automatic, the guest virtual machine may come up on any virtual server within the server pool. Hence, you must have Operator privilege on all the members virtual servers in the Server pool Target.

If the preferred servers for that guest virtual machine is set to Manual, you must have Operator privilege on the specified list of member virtual servers.

Reboot Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target.

Pause Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target

Un-pause Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target

Suspend Guest Virtual Machine

Operator privilege on the Virtual Server and the Server Pool Target

Resume Guest Virtual Machine

Operator privilege on the Server Pool Target.

If the preferred server selection for that guest virtual machine is set to Automatic, the guest virtual machine can come up on any virtual server within the server pool. Hence, you must have Operator privilege on all the members virtual servers in the Server pool Target.

If the preferred server selection for that guest virtual machine is set to Manual, you must have Operator privilege on the specified list of member virtual servers.

VNC Console

Operator privilege on the Virtual Server and the Server Pool Target

Clear Operation Error (Guest Virtual Machines)

Privilege check depends on the operation that has failed.

- If Delete Guest VM has failed:
User must have Full privilege the Server Pool Target

- If Start/Stop/Reboot/Pause/Un-pause/Suspend/Resume Guest VM has failed:
User must have Operator privilege the Server Pool Target

- If Create/Clone/Migrate/Edit/Save has failed:
User must have Operator privilege the Server Pool Target

View Virtual Server/Guest Virtual Machine

View privilege on the Virtual Server Pool.

If the User has Full/ Operator/View privilege on the Virtual Server Pool then the user gets View privileges on all the member Virtual Server targets automatically.

Understanding Bare Metal Provisioning

Proliferation of low cost servers in our data centers has brought in a fresh set of management challenges. The well-acknowledged problems include the difficulty in managing consistency and compatibility across operating system and software deployments, server drifts and security vulnerabilities that lead to lack of compliance, difficulty in deploying software, difficulty in provisioning new servers with variety of configurations and applications, high cost of operation and difficulty in adapting to changes in workload of the environment. These lead to system administrators and DBAs spending significant amount of their time in software and server provisioning operations.

Oracle's answer to the Software and Server Management challenge is its Bare Metal Provisioning Application, which is a part of Provisioning Pack (available at http://www.oracle.com/technology/products/oem/mgmt_solutions/provisioning.html) of the Enterprise Manager Grid Control and Oracle Management Pack for Linux (available at http://www.oracle.com/technology/products/oem/omp_linux.html). Bare Metal Provisioning Application addresses the data center, server farm challenge to provision software and servers quickly, efficiently, and make them operational.

Bare Metal Provisioning Application provides server lifecycle management capabilities that enable one to build manage and optimize their server infrastructure. The application provides an automated, repeatable and reliable solution that:

- Automates deployment of consistent, certified Linux operating system images along with other software on a larger number of servers.

- Leads to faster, unattended deployment of software and operating systems.

- Allows provisioning of middleware, Clusterware, Real Application cluster (RAC) etc. on top of Linux stack.

- Supports heterogeneous hardware and network configuration.

- Automatically discovers bare metal and live target servers for provisioning.

- Especially for Oracle software the application encodes best practices out-of-the-box for deployment and patching.

- Results in 10x or more reduction in manual labor that leads to substantial cost savings.

The application uses standardized PXE (Pre Boot Execution environment) booting process for provisioning both bare-metal and live servers. It provides a role based User Interface, for easily creating Gold Images and initiating automated, unattended installs.

Overview of the Bare Metal Provisioning Environment

The deployment environment in the data center needs to be setup in a certain manner in order to support the provisioning application. Besides the Oracle Management Server (OMS) which hosts Enterprise Manager and Provisioning Application, the following need to be setup and configured before using the provisioning application.

Software Library and its Entities

See Oracle Software Library for information about Software Library and its entities.

Boot Server

One of the key requirements of application is the ability of the hardware server to boot up over the network (rather than from a local boot device). A boot server must be set up so that it is able to service the requests from the designated hardware servers in order for them to boot over the network. Boot server must be an Enterprise Manager target and should be able to receive the BOOTP and TFTP (Trivial File Transfer Protocol) requests over the network from the hardware server. Refer to Setting Up Boot Server for setting up a boot server with DHCP/TFTP combination. Also refer to section Configuring Boot Server. It is also recommended that the users read about DHCP, PXE, and Redhat Kickstart technology before going through the boot server setup. Refer to Appendix G, "PXE Booting and Kickstart Technology" for a detailed discussion on PXE.

Stage Server

During provisioning of an image on hardware servers, the required binaries and files are first transferred to a stage server. This is known as Staging phase and is responsible for preparing images to be installed over the network, and exposing installable or executable software elements over the network to the target hardware server being provisioned.

The Provisioning application requires at least one stage server on which all the activities related to staging can be performed. From the networking perspective, you are advised to keep the stage server as close to the target machines as possible. It will help in bringing down the installation time drastically, by reducing the time taken to transfer image data from the stage server to the hardware servers. If you have multiple hardware server groups residing at physically different locations, it would be better to have one stage server for each of these locations. Stage server should again be an Enterprise Manager target. Refer to section Setting Up Stage Server for setting up a stage server. Also refer to section Configuring Stage Server.

Reference Host

A Reference Host (also called a gold machine) is the machine that the Provisioning application uses as a reference to create the Linux operating system component. The Provisioning application picks up the list of RPMs (along with their versions) installed on the reference host, and fetches those RPMs from a RPM repository to create an Linux OS component that represents the operating system installed on the reference host. The reference host must be an Enterprise Manager target.

RPM Repository

The Provisioning application picks up the RPMs for the operating system from the RPM repository. At least one repository needs to be setup for use by the Provisioning application. Refer to section Setting Up RPM Repository for setting up a RPM repository. Also refer to section Configuring RPM Repository.

Overview of the Bare Metal Provisioning Process

The provisioning process consists of the following two high-level tasks:

Setting Up Provisioning Environment ( Setting Up Infrastructure for Bare Metal Provisioning):

- Setting up Boot/DHCP server and Stage server, setting up RPM repository and Software Library

- Configuring above entities in Enterprise Manager

Provisioning Linux using Bare Metal Provisioning Application ( Provisioning Bare Metal Boxes):

- Creating Linux "Default Image" by creating an image and associating the image with a particular network subnet or MAC address

- Staging the image on the Stage server

- Powering up the bare metal machine on the network to begin the PXE-based OS boot and install process

Setting Up Provisioning Environment

The user needs to perform a one-time activity of setting up a Boot server, Stage server, and RPM repository that are required by the provisioning application. Once this infrastructure is set up, it can be used repeatedly for provisioning Linux on several bare metal machines. See Setting Up Infrastructure for Bare Metal Provisioning for more information.

Provisioning Linux Using Bare Metal Provisioning Application

The following sections outline the steps to provision Linux. See Chapter 9, "Provisioning Linux Operating System" for more information.

Figure 2-1 User Flow for Creating Deployable Images for Hardware Servers

Creating Linux Default Image

Enterprise Manager allows the user to create a Linux "Default Image" from Linux installation on a reference machine. The default image consists of an OS binary component along with directives required to stage and provision the image. Once an image is created, it can be associated with a subnet prefix or a set of MAC addresses. Doing this ensures that the image gets provisioned on bare metal machines in the specified subnet or having specified MAC address. See Creating a Default Image for more information.

Staging the Image on the Stage Server

The user is required to stage the contents of the image, namely the binaries associated with the components, directives and other templates, on the stage server. This caches the image in the staging area in the subnet for improved performance and prepares the image to be provisioned. See Staging the Default Image for more information.

Powering up the Bare Metal Machine on the Network to Begin the PXE-based OS Boot and Install Process

Once the image is staged, it is ready to be provisioned on bare metal machines that are powered on in the subnet. When a bare metal machine is connected to the subnet, the Bare Metal Provisioning Application discovers the machine and boots it over the network using the PXE protocol. It then installs the operating system and the Enterprise Manager management agent on the server. Installing the agent makes the server a managed target in the Enterprise Manager console. See Ready to Go for more information.

Figure 2-2 explains the sequence in the PXE process:

Figure 2-2 PXE Process

See Appendix G, "PXE Booting and Kickstart Technology" for a description of the PXE boot process.

Understanding Other Related Concepts

This section describes the following:

- Provisioning Archive (PAR) Files

- Oracle Patch Advisories

- Staging Area

- Support for SUDO, PAM, and Privilege Delegation

- Tracking the Status of Deployment Procedures

Provisioning Archive (PAR) Files

Provisioning Archive files or PAR files contain Deployment Procedures and/or components and directives from the Software Library. These are default Deployment Procedures offered by Enterprise Manager Grid Control. When you import or export Deployment Procedures using the default PARDeploy utility, you technically import or export PAR files.
For information on PARDeploy utility and how you can use it to import or export PAR files, see Appendix B, "Using PARDeploy Utility".

Oracle Patch Advisories

Oracle Patch Advisories describe critical software patches for Oracle products. To help ensure a secure and reliable configuration, all relevant and current critical Oracle patches must be applied.
To promote critical patch application, Enterprise Manager Grid Control performs an assessment of vulnerabilities by examining the host configurations collected for your enterprise to determine the Oracle homes that require one or more critical patches to be installed.

Staging Area

Staging Area is a temporary location on the target host where the generic component from the Software Library or the reference installation used for cloning will be staged for a short period, and then extracted and used for deployment.
The generic component or the reference installation may be in the form of a ZIP file. After it is placed in the staging area, once the Deployment Procedure is ready for deployment, the contents of the ZIP file are extracted and then deployed. You must always ensure that the staging area has write permission so that the Deployment Procedure can stage the ZIP file.

Support for SUDO, PAM, and Privilege Delegation

All the Deployment Procedures offered by Enterprise Manager Grid Control require administrator privileges to run. While most steps within a Deployment Procedure can be run as a normal user, there are some steps that require special permissions and privileges, and unless you provide the administrator's credentials, you cannot proceed with the deployment.

Under such circumstances, you can do one of the following:

- Customize the Deployment Procedure to disable the steps that require special privileges, run the other steps as a normal user, and have the administrator run the disabled steps later.

- Customize the Deployment Procedure to use authentication utilities for running some steps within the Deployment Procedure with the privileges of another user. The authentication utilities supported by Enterprise Manager Grid Control are SUDO, PowerBroker, and Privilege Delegation.

For information on how you can customize Deployment Procedures and how Privilege Delegation scores over other two utilities, see Chapter 23, "Choosing Privilege Delegation Over SUDO and PowerBroker".

Tracking the Status of Deployment Procedures

After you have submitted a Deployment Procedure, you can track its status from the Procedure Completion Status page. To access this page, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, from the Deployment Procedure Manager section, click Procedure Completion Status.

3. On the Deployment Procedure Manager page, click the Procedure Completion Status tab.

4. On the Procedure Completion Status page, you can view the status of the Deployment Procedures.

Table 2-2 Deployment Procedure Status

Status

Description

Scheduled

implies that the Deployment Procedure is scheduled to be executed at the date and time that you have specified.

Running

implies that the Deployment Procedure is currently being executed.

Action Required

Implies that the Deployment Procedure has stopped running as user interaction is required.

Suspended

Implies that the Deployment Procedure has been temporarily stopped from execution. You can resume from the paused step later.

Failed

Implies that the Deployment Procedure has failed and cannot execute the further steps. You can also ignore the error and proceed further.

Completed

Implies that the Deployment Procedure has successfully completed its execution.

Stopped

Implies that the Deployment Procedure has been permanently stopped from execution by the user.

Saved

Implies that the Deployment Procedure has not been given for execution, and has been saved.

Completed with Errors

Indicates that the Deployment Procedure completed, but completed with errors possibly because some of the steps within it might have failed and the steps might have the Skip target/Continue on Error flag enabled.

You can also perform the following actions:

1. Search for a particular Deployment Procedure using the Search section. Click Search to refine your search criteria.

2. View the status of all Deployment Procedures. You can also manually refresh the page and view the updated status by clicking Refresh.

3. View real-time status information based on a particular refresh period such as 30 seconds, 1 minute, or 5 minutes.

4. Stop or suspend any Deployment Procedure by selecting them and clicking Stop or Suspend, respectively. You can resume at any point by clicking Resume or Retry.

5. Delete any Deployment Procedure by selecting them and clicking Delete.

3 Infrastructure Requirements

Before you run any of the Deployment Procedures, meet the infrastructure requirements described in this chapter. This chapter is essentially for administrators or designers who create the infrastructure for provisioning and patching. The requirements described in this chapter have to be performed just once.

This chapter covers the following:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

- Setting Up Infrastructure for Offline Patching

- Setting Up Infrastructure for Linux Patching

- Setting Up Infrastructure for Virtualization Systems

- Setting Up Infrastructure for Bare Metal Provisioning

Mandatory Infrastructure Requirements for Provisioning and Patching

This section describes the mandatory setup requirements you must meet before running any Deployment Procedure. In particular, this section describes the following:

- Creating Designer and Operator User Accounts

- Setting Up Oracle Software Library

- Applying Patches

- Discovering and Monitoring Hosts and Targets

Creating Designer and Operator User Accounts

The main users of Deployment Procedures are Designers (Lead Administrators) and Operators. Designers are users who perform design-time activities and Operators are users who perform run-time activities. For more information about these user accounts, see Users of Deployment Procedures.

Before you begin using Deployment Procedures, create these user accounts in Enterprise Manager Grid Control so that Designers have super administrator privileges to perform advanced tasks, and Operators have basic privileges to run Deployment Procedures.

This section describes the following:

- Creating Designer User Account

- Creating Operator User Account

Creating Designer User Account

To create a Designer user account, follow these steps:

1. In Grid Control, click Setup.

2. On the Overview of Setup page, from the vertical menu on the left, click Administrators.

3. On the Administrators page, click Create.

4. In the Create Administrator wizard, do the following:

1. On the Properties page, specify the name Designer, provide a password, check Super Administrator, and click Next.

2. On the Review page, review the information you have provided for this user account, and click Finish.

Creating Operator User Account

To create a Operator user account, follow these steps:

1. In Grid Control, click Setup.

2. On the Overview of Setup page, from the vertical menu on the left, click Administrators.

3. On the Administrators page, click Create.

4. In the Create Administrator wizard, do the following:

1. On the Properties page, specify the name Operator and provide a password. Leave the other fields blank and click Next.

2. On the Roles page, select Public, and click Next.

3. On the System Privileges page, select the system privileges that you want to grant to this operator user account.

4. On the Target Privileges page, select the targets that the operator user account will access.

5. On the Review page, review the information you have provided for this user account, and click Finish.

Setting Up Oracle Software Library

Oracle Software Library (Software Library) can be configured using any mounted file system that is readable and writable from Oracle Management Service (OMS).

- If Enterprise Manager Grid Control is configured as a single server setup, then local directories can be used to configure the Software Library. Ensure that there is enough space available for the storage of software binaries, and associated scripts for the entities that you want to create and store.

- If Enterprise Manager Grid Control is configured as a multiple servers setup, then the directories comprising the Software Library must be accessible by all OMS instances. Ensure that there is enough space available on the shared storage to store files that hold binary data for your components and other entities.

- If Enterprise Manager Grid Control is configured as a single server setup, and then moved to multiple servers setup, you can use the Check Accessibility feature in the Software Library section in the Administration page and verify that the Software Library location is accessible to all Oracle Management Servers. For more details, see Appendix C, "Using Oracle Software Library".

This section describes the following:

- Configuring Oracle Software Library

- Creating a Component in Oracle Software Library

Configuring Oracle Software Library

To configure the Software Library, follow these steps:

1. Access the Oracle Enterprise Manager Provisioning Application by navigating to the Deployments tab.

2. Under the Deployments tab, go to the Provisioning tab.
There are a number of tabs here for creating components, directives and other entities. You can access some or all of the tabs depending on the privileges assigned to you.

3. Access the Administration tab. This requires super administrator privileges similar to SYSMAN user.
For information about creating the super administrator, see Creating Super Administrator for Enterprise Manager.

4. In the Software Library Configuration section of the Administration tab, click Add.

5. On the Add Software Library Location page, enter the directory location and then click OK.

Note:

When you add a Software Library location for the first time, the configuration will take some time. Subsequently, adding other Software Library locations will be quicker.

When the Software Library is configured, out-of-box Provisioning Archive files (PAR files) will be deployed. These files contain pre-build entities such as components, directives, and so on for various applications such as bare metal provisioning and patching.

For information about PAR files, see Provisioning Archive (PAR) Files. For more information about Software Library, see Appendix C, "Using Oracle Software Library".

Creating a Component in Oracle Software Library

To create a component in the Software Library, follow these steps:

Note:

If you want to create a component for the software binaries of Oracle Database Replay Client, then before you access the Software Library, see My Oracle Support note 815567.1. This note explains the different requirements for each OS platform prior to using the media with Grid Control Deployment Procedure.

1. In Grid Control, click Deployments, and select the Provisioning tab.

2. In the Components tab, select the folder under which you want to create the component and click Create Component. For example, Navigate to Components, Oracle Components, Host Patch, and 10.2.0.5.0.

3. In the Create Component: Describe page, select the type of component you are creating, the name, product/patch number, version and vendor details. You can create the following types of components:

- Oracle Application Server

- Oracle Enterprise Linux Operating System

- Linux Disk Layout

- Oracle Clusterware Clone

- SuSe Linux Operating System

- OVS

- Oracle Database Software Clone

- Hardware Profile

- RedHat Linux Operating System

- Generic Component

Click Next.

Follow the steps in the wizard depending on the type of component you have selected. Ensure that you associate the correct version of the component type when creating the component.

4. In the Create Component: Review page, review all the information you have provided and submit the component creation job.

Navigate to the directory in the Software Library where you saved the component and verify that it has been created.

Note:

Do NOT upload software binaries that are more than 2 GB of size. If you do so and try to run the Deployment Procedure, the procedure will fail. To resolve this issue, first install the software manually using the product DVD, and then create a gold image of that instance and store it in the Software Library for future deployments.

Applying Patches

Oracle released a few patches after the release of Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) to further enhance the provisioning and patching functionality. Oracle strongly recommends you to apply these patches so that you gain the benefits these paches offer.

This section describes the patches you must download and apply before using any of the provisioning or patching Deployment Procedures. In particular, this section covers the following:

- Applying Common Patches

- Applying One-Off Patch to Introduce Analyze Mode and Reports

Applying Common Patches

Apply the patches required for provisioning and patching as described in My Oracle Support note 427577.1.

To view this note, access My Oracle Support at the following URL. On the main page (based on the classic metalink view), from the Quick Find list, select Document ID (Knowledge Base, Forum, or Bug), and quote the note number and click Go.

http://metalink.oracle.com

Applying One-Off Patch to Introduce Analyze Mode and Reports

In July 2009, Oracle released the one-off patch 8653501 that enhances the following Deployment Procedures to act as prerequisite checkers:

- Patch Oracle Database

- Patch Oracle RAC Database - Rolling

- Patch Oracle RAC Database - All Nodes

The one-off patch introduces an Analyze Mode that helps you verify the applicability of a patch in the database environment. Oracle recommends you to run the Deployment Procedures in this mode to ensure that you meet all the necessary requirements for online and offline patching, and also resolve all operational conflicts and issues beforehand. This exercise ensures that the patching operation always runs smoothly and predictably. For information about running the patching Deployment Procedures in Analyze mode, see Chapter 14, "Running Patch Prerequisite Checker Deployment Procedures".

The one-off patch also introduces patching automation reports that help you identify the database targets suitable for a patching operation and analyze how the patching Deployment Procedures have performed in the past. For more information about the reports, see Appendix H, "About Patching Automation Reports".

The one-off patch has to be applied on Enterprise Manager 10g Grid Control Release 5 (10.2.0.5). If you have a lower version of Enterprise Manager Grid Control, then upgrade it to 10.2.0.5 before applying this one-off patch.

To apply this one-off patch, do the following:

1. Access My Oracle Support at the following URL and download the one-off patch 8653501:
http://metalink.oracle.com

2. Apply the one-off patch to all the Oracle Management Services.

3. Perform the additional steps outlined in the ReadMe file that is rolled out with the one-off patch.

Note:

After you apply the one-off patch, the version of the Deployment Procedure changes from 5.0 to 5.1. You can view this in the Version column of the Procedures table on the Deployment Procedure Manager page.

Discovering and Monitoring Hosts and Targets

Before running a provisioning-related Deployment Procedure, ensure that the target hosts are discovered and monitored in Enterprise Manager Grid Control. Similarly, before running a patching-related Deployment Procedure, ensure that the targets you want to patch are discovered and monitored in Enterprise Manager Grid Control.

For this purpose, you require Oracle Management Agent 10g Release 5 (or higher) to be installed on the target hosts where you want to run the procedure.

In the case of Oracle RAC and Oracle Clusterware, before you run the Deployment Procedures to provision them, ensure that Oracle Management Agent 10g Release 5 (or higher) is installed on every node of the cluster using the Cluster Install option available in the Agent Deploy application.

- If you do not have Oracle Management Agent (Management Agent) installed on every node of the cluster, then see the instructions outlined for installing a Management Agent using the Agent Deploy application in the Enterprise Manager Grid Control Installation Guide available at:
http://www.oracle.com/technology/documentation/oem.html

- If you already have a Management Agent installed on each node of the cluster, but if they were NOT installed using the Cluster Install option available in the Agent Deploy application, then see Appendix I, "Converting Standalone Oracle Management Agent to Cluster Agent".

Optional Infrastructure Requirements

This section describes the optional setup requirements you may meet before running any Deployment Procedure. In particular, this section describes the following:

- Setting Up SUDO, PAM, Privilege Delegation Settings

- Setting Up E-mail Notifications

- Setting Up Preferred Credentials

- Refreshing Host Configuration

Setting Up SUDO, PAM, Privilege Delegation Settings

Enterprise Manager Grid Control allows you to run Deployment Procedures using authentication utilities such as SUDO, PowerBroker, and Privilege Delegation. While SUDO and PowerBroker are third-party utilities supported in Enterprise Manager Grid Control, Privilege Delegation is proprietary to Oracle. Privilege Delegation is a framework that allows you to use either SUDO or PowerBroker to perform an activity with the privileges of another user (locked accounts).

For information on how you can customize Deployment Procedures and use SUDO, PowerBroker, or Privilege Delegation settings, see Chapter 23, "Customizing Steps to Run as Another User".

Note:

The supported version of SUDO is 1.6.9.5 P5, and the supported version of PBRUN is 4.0.8.

Setting Up E-mail Notifications

Enterprise Manager Grid Control can send e-mail notification every time you run a Deployment Procedure. However, by default, Deployment Procedures do not have this feature enabled. To configure them to send e-mail notifications, you must customize the Deployment Procedure.

For information on how you can customize Deployment Procedures and set up e-mail notifications, see Chapter 23, "Setting Up E-Mail Notifications".

Setting Up Preferred Credentials

Before you run any Deployment Procedure, Oracle recommends you to register the credentials of the host on which you want to provision or the Oracle home that you want to patch, as preferred credentials in Enterprise Manager Grid Control. This section explains how you can set up preferred credentials. In particular, this section explains the following:

- Setting Up Preferred Credentials for Provisioning

- Setting Up Preferred Credentials for Patching

Setting Up Preferred Credentials for Provisioning

To register the credentials of the host (on which you want to provision) as preferred credentials in Enterprise Manager Grid Control, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Preferences.

2. On the General page, from the vertical menu pane to the left, click Preferred Credentials.

3. On the Preferred Credentials page, from the table, for the Host target type, click the Set Credentials icon that is shown in the column Set Credentials.
For example, if you want to provision a database on a host named xyz.server.com, then for Host target type, click the Set Credentials icon.

Enterprise Manager Grid Control displays the <Target Type> Preferred Credentials page.

Note:

For setting up preferred credentials for virtual server targets, select Oracle VM Server as the target type and click the Set Credentials icon.

4. On the <Target Type> Preferred Credentials page, in the Target Credentials section, for the Host target on which you want to provision, specify the user name and password. If you want to use default credentials, then specify the default credentials in the Default Credentials section.

5. Click Apply.

Setting Up Preferred Credentials for Patching

To register the credentials of the Oracle home (that you want to patch) as preferred credentials in Enterprise Manager Grid Control, run the set_credential verb using the Enterprise Manager Command Line Interface (EM CLI).

set_credential
-target_type="ttype"
[-target_name="tname"]
-credential_set="cred_set"
[-user="user"]
-columns="col1:newval1;col2:newval2;..."
[-input_file="tag1:file_path1;tag2:file_path2;..."]
[-oracle_homes="home1;home2"]

[ ] denotes that the parameter is optional.

Example 1:

emcli set_credential
-target_type=oracle_database
-target_name=myDB
-credential_set=DBCredsNormal
-user=admin1
-column="username:joe;password:newPass;role:newRole"

Example 2:

emcli set_credential
-target_type=host
-target_name=host.foo.com
-credential_set=OHCreds
-user=admin1
-column="OHUsername:joe;OHPassword:newPass"
-oracle_homes="database1;mydb"

Note:

The preferred credentials set through EM CLI are specific to the Enterprise Manager Grid Control user with which the EM CLI is set up. Therefore, Oracle recommends you to use the central Enterprise Manager Grid Control accounts for this purpose, so the Database Administrators across board or a group can use this.
For more information about EM CLI, see Enterprise Manager Command Line Interface Guide available at:

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

The following describes the options available for this verb:

Table 3-1 EM CLI Options for set_credential Verb

Option

Description

target_type

Type of target. This must be "host" in case the -oracle_homes parameter is specified.

target_name

Name of the target. Omit this argument to set enterprise preferred credentials. This must be the host name in case the -oracle_homes parameter is specified.

credential_set

Credential set affected.

user

Enterprise Manager user whose credentials are affected. If omitted, the current user's credentials are affected.

columns

Name and new value of the column(s) to set. Every column of the credential set must be specified. Alternatively, a tag from the -input_file argument can be used so that the credential values are not seen on the command line. You can specify this argument more than once.

input_file

Path of file that has the -columns argument(s). This option is used to hide passwords. Each path must be accompanied by a tag referenced in the -columns argument. You can specify this argument more than once.

oracle_homes

Name of oracle homes on the target host. Credentials will be added/updated for all specified homes.

Refreshing Host Configuration

Before you run any Deployment Procedure, Oracle recommends you to refresh the configuration of the hosts. To do so, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Configuration section, click Refresh Host Configuration.

3. On the Refresh Host Configuration: Select Hosts page, from the Available Hosts pane, select the hosts, which the Deployment Procedure will use, and move them to the Selected Hosts pane.

4. Click Refresh Hosts.

Setting Up Infrastructure for Online Patching

This section describes the setup requirements for online patching. In particular, this section describes the following:

- Enabling Offline Mode

- Setting Up My Oracle Support Credentials and Proxy Connection Settings

- Setting Up Online Settings

Enabling Online Mode

To patch the targets in online mode, you must set the connection setting in Enterprise Manager Grid Control to Online mode.

To set the connection setting to Online mode, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

2. On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.
Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

3. On the Patching Setup page, select Online and Offline Settings tab.

4. On the Online and Offline page, in the Settings section, select Online.

5. Click Apply.

Setting Up My Oracle Support Credentials and Proxy Connection Settings

In an online patching mode, a Refresh From My Oracle Support job is run periodically to automatically download XML files that are required for generating Patch Advisories. Also, the Deployment Procedures automatically download the required patches and patch sets from My Oracle Support every time they are run. For these purposes, Enterprise Manager Grid Control requires credentials to log in to My Oracle Support.

This section provides instructions that help you set up My Oracle Support credentials and proxy server details, if there are any, in Enterprise Manager Grid Control so that it can use these settings to connect to My Oracle Support.

To set up My Oracle Support credentials and proxy connection settings, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

2. On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup. Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

3. On the My Oracle Support and Proxy Connection tab, do the following:

1. In the My Oracle Support section, provide the credentials to be used to access the My Oracle Support site. By default, Patch Search URL displays the URL where the patches will be searched.
If you want to verify the connectivity to My Oracle Support, then click Test. If the credentials are valid and if Enterprise Manager Grid Control is able to connect to My Oracle Support successfully, then a status message is displayed to this effect.

2. In the My Oracle Support Connection Setting section, do one of the following:
If the host where Enterprise Manager Grid Control is running has a direct connection to Internet, that is, without any proxy server, then select Direct Connection to the Internet.

If the host where Enterprise Manager Grid Control is running has a connection to Internet through a proxy server, then select Manual Proxy Configuration. And, depending on the protocol to be used (HTTP or HTTPS), specify the name of the proxy server, port, realm (if credentials are configured for realm), and credentials (if credentials are required for authentication).

The Connection Configuration subsection shows the default values set for Timeout and Number of Retries. Timeout indicates the time in milliseconds after which it should automatically time out if the connection takes unusually long time to connect to My Oracle Support. Number of Retries indicates the number of times it should retry connecting to My Oracle Support after timing out. Change the default values to higher values only if required.

3. In the Agent Connection Setting section, select the settings to be considered for all Management Agent-related communications.
If you want to use the settings specified in the My Oracle Support Connection String, then select Use My Oracle Support Connection Settings.

If the host where Management Agent is running has a direct connection to the Internet, that is, without any proxy server, then select Direct Connection to the Internet. The Connection Configuration subsection shows the default values set for Timeout and Number of Retries. Change the default values to higher values only if required.

If the host where Management Agent is running has a connection to Internet through a proxy server, then select Manual Proxy Configuration. And, depending on the protocol to be used (HTTP or HTTPS), specify the name of the proxy server, port, sites for which proxy must not be used, realm (if credentials are configured for realm), and credentials (if credentials are required for authentication).

4. In the Test URL section, to verify whether the Management Agent is reachable, specify a valid Management Agent URL and click Test. If the URL is valid and if Enterprise Manager Grid Control is able to reach the Management Agent successfully, then a status message is displayed to this effect.

Setting Up Online Settings

In an online patching mode, a Refresh From My Oracle Support job is run periodically to automatically download XML files that are required for Patch Advisories. Also, the Deployment Procedures automatically download the required patches and patch sets from My Oracle Support every time they are run. For these purposes, Enterprise Manager Grid Control needs to know where the XML files should be stored and the size limit of patch cache up to which it can store the downloaded patches and patch sets.

This section provides instructions that help you set up these online settings.

To set up online settings, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

2. On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.
Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

3. On the Patching Setup page, select Online and Offline Settings tab.

4. On the Online and Offline page, do the following:

1. In the Settings section, retain the default connection setting, that is, Online, and set the patch cache size.
Patch Cache is a repository where all downloaded patches are stored. By default, the maximum size or capacity of patch cache is set to 700 MB, which means it can store patches only up to the limit of 700 MB. Once the patch cache reaches this size, all older patches will be automatically deleted to free up some space.

2. In the Patch Validation for Critical Patch Advisories for Oracle Home section, retain the default validation setting, that is, No.
Patch Validation validates the patches that must be recommended to Database Administrators on the Critical Patch Advisories page. By default, No is selected and this ensures that all patches are recommended. If you select Yes, then only those patches that are validated by the Super User are recommended. However, this does not prevent the patches from getting staged or applied.

3. In the Dump Directory section, retain the default dump directory selection, that is, No.
Dump Directory is a directory where My Oracle Support metadata files can be stored. By default, the dump directory is a temporary storage location on the host where Oracle Management Service is running. The metadata files are XML files required for patch advisories and they are downloaded automatically in an online patching mode.

5. Click Apply.

Setting Up Infrastructure for Offline Patching

This section describes the setup requirements for offline patching. In particular, this section describes the following:

- Enabling Offline Mode

- Applying One-Off Patch

- Identifying Affected Targets and Required Patches

- Uploading Information Required by Oracle Patch Advisories

- Creating "Refresh From My Oracle Support" Job

- Uploading OPatch Patches to Oracle Software Library

- Identifying Patch from Oracle Patch Advisories

- Uploading Patch to Oracle Software Library

Enabling Offline Mode

To patch the targets in offline mode, you must set the connection setting in Enterprise Manager Grid Control to Offline mode.

To set the connection setting to Offline mode, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

2. On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.
Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

3. On the Patching Setup page, select Online and Offline Settings tab.

4. On the Online and Offline page, in the Settings section, select Offline.

5. Click Apply.

Applying One-Off Patch

From My Oracle Support, manually download patch 6880880 for the required platform and version of the target you are patching, and upload it to the Software Library. This is a platform-specific patch, so you will have to carefully select the platform while downloading this patch.

For example, if you are patching Oracle Database 11g Release 1 (11.1) that is running on Linux x86, then download patch 6880880 for the Linux x86 platform and for the 11.1.0.0.0 release.

To upload this patch to the Software Library, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Patching section, click View/Upload Patch.

3. On the Patch Cache page, click Upload Patch.

4. On the Create Oracle Software Update Component page, in Patch File, specify the full path to the patch file. Alternatively, click Browse to browse your system and select the patch.
And in the Patch Attributes section, specify critical information about the patch.

IMPORTANT:

Ensure that you upload it under the product family "System Management Products and Product - Universal Installer" with the appropriate release and platform details.

5. Click Upload.

Identifying Affected Targets and Required Patches

The information about the targets affected by the latest patches and the patch you have to manually download is available in metadata XML files. In an offline mode, you must use another host that has internet connection and manually download these XML files from My Oracle Support.

The following shows the metadata XML files you must download:

Table 3-2 Downloading Metadata XML Files

Metadata XML File

Location To Download From

aru_product.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_products

aru_releases.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_releases

aru_platforms.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_platforms

aru_languages.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_languages

aru_product_groups.xm

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_product_groups

aru_product_releases.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_product_releases

aru_component_releases.xml

https://updates.oracle.com/ARULink/XMLAPI/download_seed_data?table=aru_component_releases

query_advisories.xml

https://updates.oracle.com/ARULink/XMLAPI/query_advisories

Uploading Information Required by Oracle Patch Advisories

The information required by Oracle Patch Advisories are available in metadata XML To upload these files, follow these steps:

1. In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

2. On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.
Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

3. On the Patching Setup page, select Online and Offline Settings tab.

4. On the Online and Offline Settings page, in the Metadata Cache section, upload the metadata XML files to the Management Repository:

5. Click Apply.

Creating "Refresh From My Oracle Support" Job

To extract information from the metadata XML files and display them in Oracle Patch Advisories, you must schedule a job, that is, a "Refresh From My Oracle Support" job.

Although the name of the job reads "Refresh From My Oracle Support", it does not actually connect to My Oracle Support because of the offline connection setting you enabled in Enabling Offline Mode. Since it is set to Offline, the job looks for these XML files only in the Management Repository.

To create "Refresh From My Oracle Support" job, follow these steps:

1. In Grid Control, click Jobs. Enterprise Manager Grid Control displays the Job Activity page.

2. On the Job Activity page, from the Create Job list, select Refresh From My Oracle Support and click Go. Enterprise Manager Grid Control displays the Create 'Refresh From My Oracle Support' Job page.

3. On the Create 'Refresh From My Oracle Support' Job page, specify a name for this job, schedule it to run at a particular time, and grant access to roles that must have access to this job.

4. Click Submit.

Uploading OPatch Patches to Oracle Software Library

From My Oracle Support, manually download patch 6880880 for the required platform and the version of the target you are patching, and upload it to Oracle Software Library (Software Library). This is a platform-specific patch, so you will have to carefully select the platform while downloading this patch.

For example, if you are patching Oracle Database 11g Release 1 (11.1) that is running on Linux x86, then download patch 6880880 for the Linux x86 platform and for the 11.1.0.0.0 release.

To upload patches to the Software Library, follow these steps:

Ensure that you upload it under the product family "System Management Products and Product - Universal Installer" with the appropriate release and platform details.

1. In Grid Control, click Deployments. Enterprise Manager Grid Control displays the Deployments page.

2. On the Deployments page, from the Patching section, click View/Upload Patch. Enterprise Manager Grid Control displays the Patch Cache page.

3. On the Patch Cache page, for Patch File, click Browse to upload the patch. In the Patch Attributes section, specify details about the patch. Ensure that you upload it under the product family "System Management Products and Product - Universal Installer".

Identifying Patch from Oracle Patch Advisories

After the "Refresh From My Oracle Support" job completes, Oracle Patch Advisories show details about the Oracle homes that are affected by the latest patches. From here, identify the patch you have to download.

From Oracle Patch Advisories, to identify the patch you must download and apply to your targets, follow these steps:

1. In Grid Control, click Deployments. Enterprise Manager Grid Control displays the Deployments page.

2. On the Deployments page, from the Critical Patch Advisories for Oracle Homes section, view the critical patch advisories and the affected Oracle homes.

3. Click the number of the Patch Advisories. Enterprise Manager Grid Control displays the Critical Patch Advisories for Oracle Homes page.

4. On the Critical Patch Advisories for Oracle Homes page, identify the patch you have to download.

Uploading Patch to Oracle Software Library

For patching targets in offline mode, you must have already stored the patch in Software Library so that the Deployment Procedure can retrieve it from there and apply it to the affected targets. For this purpose, you must upload the patch to Software Library.

To upload the patch to Software Library:

1. In Grid Control, click Deployments. Enterprise Manager Grid Control displays the Deployments page.

2. On the Deployments page, from the Patching section, click View/Upload Patch. Enterprise Manager Grid Control displays the Patch Cache page.

3. On the Patch Cache page, click Upload Patch. Enterprise Manager Grid Control displays the Create Oracle Software Update Component page.

4. On the Create Oracle Software Update Component page, do the following:

1. For Patch File, click Browse and select the patch you had manually downloaded from My Oracle Support.

Note:

If you are uploading an opatch patch using Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then ensure that you upload opatch patch number 6880880 that is specific to the platform on which you want to apply the patch. For example, if you want to upload Opatch 11.1 for the Linux x86 platform, then ensure that you upload p6880880_111000_LINUX.zip.

2. In the Patch Attributes section, specify the attributes of the patch. You can find these details in the ReadMe file of the patch.

3. Click Upload.

Setting Up Infrastructure for Linux Patching

This section describes the setup requirements for Linux patching. In particular, this section describes the following:

- Prerequisites for Using the Linux Patching Feature

- Setting Up the RPM Repository

- Setting Up Linux Patching Group for Compliance Reporting

Prerequisites for Using the Linux Patching Feature

To use the Linux Patching feature, perform these setup activities:

1. Configure the Software Library as described in Setting Up Oracle Software Library.

2. Deploy the PAR files from the Oracle Management Service (OMS) host:

${OMS_ORACLE_HOME}/bin/PARDeploy -action deploy -parDir

3. The patch user credentials to be used for patching must have write access under Oracle home directory of the Management Agent.

4. Operating system credentials used to create groups and set up repository must have SUDO as root privilege.

5. Following commands must be enabled through SUDO:

- /bin/cp

- /bin/rm

- /bin/chmod

- /sbin/chkconfig

- yum

- up2date

- sed

- rpm

Setting Up the RPM Repository

This section describes how you can set up the RPM repository. In particular, this section describes the following:

- Prerequisites for Setting Up the RPM Repository

- Setting Up the RPM Repository

Prerequisites for Setting Up the RPM Repository

Before setting up the RPM repository, meet the following prerequisites:

1. Identify a Redhat or OEL host, install a Management Agent and point to the OMS. This host must have "sudo" package installed.

2. Obtain a valid CSI number.

3. Download the up2date packages corresponding to the host version and release from https://linux.oracle.com/switch.html.

4. Upload the up2date packages to the Software Library.

- First compress up2date and up2date-gname into a zip file and name it as up2date_comp.zip.

- Upload the zip file to Deployments > Provisioning > Components > Oracle Components > Stage Server Up2date Component > 10.2.0.4.0 > Linux > UP2DATE_RPM. The Software Library by default has packages for Red Hat Enterprise Linux 4, i386 uploaded.

5. Ensure that ULN staging host is able to communicate with the ULN network. If proxy is required, up2date from the host needs to be configured as well. The connectivity with ULN will be detrimental for up2date –register –nox command.

6. Patch user (OS credentials used to setup the Staging server) must have write permission under the agent home. Patch user must also have SUDO privilege.

Setting Up the RPM Repository

To set up an RPM Repository that downloads latest RPM packages and Advisories from ULN, follow these steps.

1. In Grid Control, from the top-right corner of the page, click Setup and select Patching Setup.

2. In the Linux Patching Setup tab, click the Setup RPM Repository link.

3. In the Setup Linux RPM Repository section, select the RPM Repository server by clicking the search icon. Select the machine assigned for subscribing to ULN.

4. In the Credentials section, specify the user name and password to use. Click Apply.

5. In the Deployment Procedure submission confirmation, click the link "Linux RPM Repository Server Setup." The deployment procedure starts a job to download latest RPM packages and Advisories from the subscribed ULN channels.

6. (Optional) Set the refresh mode to "30 seconds refresh".

7. Wait till the step "Installing Up2date" is completed or skipped.

8. In the Phase Status page, click the link "Register with ULN"and do the following:

1. Log in to the RPM Repository server machine.

2. Configure up2date to use a proxy server, if any, by following the instructions at:

https://linux.oracle.com/uln_faq.html - 9

3. Register the machine to ULN by following the steps at:

https://linux.oracle.com/uln_faq.html - 2

Note:

While registering, you can choose the user name and password. This credential will be used to log in to http://linux.oracle.com

9. After registering the host, select the target and click Confirm, and then click Done to go to the main flow.

10. Click the link "Subscribe to ULN channels". Do the following:

1. When you register a server, it will be subscribed to a channel that has the latest Enterprise Linux packages for the appropriate architecture. To subscribe to additional channels, log in to http://linux.oracle.com after you register your system. Click on the Systems tab to manage subscriptions for each subscribed server.

2. Subscribe either to el*_addon channel (this channel contains createrepo) or manually install the createrepo package.

11. Type the command up2date –nox –show-channels to verify the list of subscribed channels.

12. Once the deployment procedure completes successfully, go to Setup, select Patching Setup, and then select Manage RPM Repository to verify if the ULN channels are displayed in the Enterprise Manager Console.

13. In the Manage Repository Home page, check if all the subscribed channels are listed and if all the packages are downloaded.

Setting Up Linux Patching Group for Compliance Reporting

This section describes how you can set up a Linux Patching group for compliance reporting by associating the group with the RPM Repository (each subscribed ULN channel is a repository) created in Setting Up the RPM Repository.

In particular, this section describes the following:

- Prerequisites for Setting Up Linux Patching Group

- Setting Up a Linux Patching Group

Prerequisites for Setting Up Linux Patching Group

Before setting up the Linux Patching Group, meet the following prerequisites:

- RPM Repository server must be set up or a custom RPM Repository must be set as a channel in Enterprise Manager.

- Yum or up2date should be installed in the target machines.

- Sudo must be installed on the target machines.

- You must have Operator privileges on the hosts that you want to add to the Linux host patching group.

- Patch user must have write access under the agent home. Patch user must have sudo privilege.

Setting Up a Linux Patching Group

To set up a Linux patching group, do the following:

1. In Grid Control, from the top-right corner of the page, click Setup and select Patching Setup.

2. In the Linux Patching Setup tab, click the Setup Groups link.

3. In the Setup Groups page, click Create.

4. In the Create Group: Properties page, specify a unique name for the group. Select the maturity level, Linux distribution, and Linux hosts to be added to the group. Click Next.

5. In the Create Group: Package Repositories page, select the RPM Repositories to be associated with the group (click the search icon to select repository).
Select Automatically Update Hosts if you want to auto-update the host, that is, to schedule an update job (schedule specified as one of the subsequent step) to update all non-compliant packages from the select package repository.

Under the "Package Compliance" section, choose whether to include "Rogue" packages in compliance reporting or not.

Click Next.

6. In the Create Group: Credentials page, specify the host credentials or choose to use preferred credentials. Click Next.

7. If Automatically Update Hosts is not selected, the steps, "Patching Scripts" and "Schedule" pages will be skipped.

8. In the Patching script page, you can specify any pre/post patching operations to be done. This is not a mandatory step.

9. In the Schedule Page, select the schedule for the "Update Job". Click Next.

10. Validate all the parameters in the Review page. Click Finish.

11. On clicking Finish, three jobs will be submitted if you have not selected the Automatically Update Hosts option. If the option is selected, then four jobs will be submitted. Table 3-3 explains the jobs submitted. Follow the jobs submitted by clicking the job's link.

12. Go to Deployments > Linux Patching page. Verify the compliance report generated. The group created will have at least one out-of-date package.

Table 3-3 Jobs Submitted for Setting Up Linux Patching Group

Job

Description

Patching Configuration

This job configures all the hosts for patching. It creates configuration files to be used by yum and up2date tool.

Compliance Collection

Compares the packages already installed in the machine with the packages versions in the selected RPM Repositories and generates Compliance Reports.

Package Information

Collects metadata information from the selected RPM Repositories.

Packages Update

Updates non-compliant packages.

Setting Up Infrastructure for Virtualization Systems

To start using guest virtual machines, you will need to perform the following setup activities:

- Configuring Virtual Servers

- Creating Server Pools

- Registering Virtual Servers

Configuring Virtual Servers

The virtual server will need to be configured before it can be registered with the server pool to enable Enterprise Manager to perform monitoring, administration, and provisioning.

1. Create /OVS mount points for shared storage on the Oracle VM server.

2. No more than 24 Oracle VM servers must be registered and managed with one Oracle Management Agent.

3. Enterprise Manager supports only Oracle VM server version 2.1.2 or above. All Oracle VM servers version 2.1.2 or above managed by Enterprise Manager should be updated to have OVS agent of version 2.2-70 or higher.

4. The following ports must be open:

8002,8003,7777,8899,5900-5950,5353,631

To verify which ports are open, use the following command:

service iptables status

5. If you are migrating from Oracle VM Manager to Enterprise Manager, see Migrating from Oracle VM Manager to Enterprise Manager.

6. If you want to enable High Availability mode, see Configuring Oracle VM Servers for High Availability.

7. If a user other than root is used to connect to the virtual server, /etc/sudoers file must be updated to give "sudo all" privilege to this user. To provide sudo privilege for non-root user, add the following entry:

<non-root user> ALL=(ALL) ALL

In addition, comment out the following line:

Defaults    requiretty

Creating Server Pools

It is essential that you create a server pool to manage all Oracle VM servers. Server pools can be created with the high-availability option enabled or not. A server pool must have a minimum of one virtual server registered with it.

To create a Virtual Server Pool, do the following:

1. In Grid Control, click Targets, then click Virtual Servers.

2. In the Virtualization Central page, select Action as Virtual Server Pool Create Virtual Server Pool and click Go.

3. In the Create Virtual Server Pool page, provide the values specified in Table 3-4. Click OK to submit the server pool creation job.

Navigate to Virtualization Central and verify that the status of the server pool you created is Registering.. After the job is completed, the Server Pool must appear in Virtualization Central.

After the job is completed, the server pool must appear in Virtualization Central and status will be Up.

Table 3-4 Virtual Server Pool Configuration Details

Element

Description

Virtual Server Pool Name

Specifies the name of the virtual server pool that you are creating.

Shared Directory

Specifies the directory mounted as the shared directory. This shared directory is the same for all virtual servers within a virtual server pool.

For example, /OVS. All guest virtual machine templates and running guest virtual machines are maintained in this location.

High Availability Mode

Select Enable if you want the virtual server to participate in high availability.

For more information about high availability, see High Availability and Fault Tolerance.

Virtual Server Host

Specifies either FQDN name or IP address of the master virtual server for the server pool.

Monitoring Server Agent

Specifies the Management Agent that will monitor the virtual server.

Monitoring Server User

Specifies the operating system user that owns the Management Agent home/Management Agent install, and has read and write permission on the Management Agent home directory.

Monitoring Server Password

Specifies the password credentials for the monitoring server user.

SSH Username

Specifies the user on the virtual server who has sudo privileges.

SSH Password

Specifies the password credentials for the SSH user.

Oracle VM Agent Password

Specifies the password of the Oracle VM Agent running on the virtual server.

OVS Proxy Location

Specifies a directory on the virtual server where the scripts required for monitoring and administration are stored when the virtual server is registered with Enterprise Manager Grid Control.

Registering Virtual Servers

For Enterprise Manager Grid Control to monitor and manage a virtual server, you must register it with a server pool. Once you create a master virtual server, you can also register other virtual servers to the server pool.

To register virtual servers, follow these steps:

1. In the Virtualization Central page, select a Server Pool, select Action as Virtual Server - Register Virtual Server and click Go.

2. In the Register Virtual Server page, specify details of the virtual servers to be registered as shown in Table 3-5. Click Add Another Row to specify multiple virtual servers details.
You can batch assign details to different virtual servers and click Assign to specify common details for multiple virtual servers.

You can add a virtual server from file by clicking Add From File. Select the file from a local machine or a host machine in Enterprise Manager. The file should contain details of the virtual servers in the following format:

<virtualServerName>;<Monitoring Server Name>;<Monitoring Server User>;<SSH User>;<Proxy Location>;<ServerPoolName>

For example:

vs1.xyz.com;abc.xyz.com:4889;oracle;orauser;/tmp;ServerPool1.xyz.com

3. Click OK.

After registering the virtual server, navigate to Virtualization Central and verify that that the virtual server appears under the specific server pool.

Table 3-5 Register Virtual Server Details

Element

Description

Virtual Server Host

Specifies the name of the master virtual server for the server pool.

Monitoring Server Agent

Specifies the monitoring agent.

Monitoring Server User

Specifies the Operating system user that owns the Management Agent home/Management Agent install, and has read and write permission on agent home directory.

Monitoring Server Password

Specifies the password credentials for the monitoring server user.

SSH Username

Specifies the user on the virtual server who has sudo privileges.

SSH Password

Specifies the password credentials for the SSH user.

Oracle VM Agent Password

Specifies the password of the Oracle VM Agent running on the virtual server.

OVS Proxy Location

Specifies a directory on the virtual server where the scripts required for monitoring and administration are stored when the virtual server is registered with Enterprise Manager.

Virtual Server Pool

Specifies the virtual server pool to which the virtual server will belong.

Setting Up Infrastructure for Bare Metal Provisioning

This section describes how to set up the infrastructure required to provision bare metal machine. In particular, this section describes the following:

- Prerequisites for Using Bare Metal Provisioning

- Creating Super Administrator for Enterprise Manager

- Setting Up Boot Server

- Setting Up Stage Server

- Setting Up RPM Repository

- Setting Up Software Library

- Checklist for Boot Server, Stage Server, RPM Repository, and Reference Host

- Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager

- Accessing the Bare Metal Provisioning Application

- Configuring Stage Server

- Configuring RPM Repository

- Configuring Boot Server

- Configuring the DHCP Server

- Configuring Software Library

Prerequisites for Using Bare Metal Provisioning

The following steps should be followed for evaluating or using the Bare Metal Provisioning application:

Install or upgrade to the latest Enterprise Manager 10g Grid Control Release 5 (10.2.0.5).

- If you are using Enterprise Manager 10g Grid Control version 10.2.0.4 or earlier, then first upgrade it to version 10.2.0.5. Refer to the Enterprise Manager Grid Control Release 5(10.2.0.5) notes available at http://www.oracle.com/technology/documentation/oem.html

Download the agent rpm kit from the following location:

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

Creating Super Administrator for Enterprise Manager

Only a user who is a Super Administrator for Enterprise Manager can configure various elements like stage server, boot server etc. for use with the Provisioning Application. Not only that, it is only these users who can actually create assignments for actually provisioning target machines with any image. For more information about assignments, see Assignments.

Follow the steps below to create a user who is a super administrator.

1. Log into the Enterprise Manager and click on the Setup link on top right hand corner as shown in the picture below.

2. On the Setup page, click on the Administrators link on the left hand side column.

3. On the Administrators page, click Create as shown below.

4. On the Create step that comes up fill up the necessary details as shown and select the Super Administrator check box as shown below. Click Next.

5. On the Review page, click Finish to complete the user creation.

Setting Up Boot Server

This section explains how to set up the boot server. Following are the prerequisites:

- 2 GB RAM for boot server, stage server, and RPM repository server.

- Boot server and stage server must be on the same physical machine.

- If boot server and stage server reside on different machines, then the boot install directory (/tftpboot/linux-install) should be mounted on the stage server.

If you have the required boot server, stage server, and RPM repository already created, then set up the preferred credentials. For more information on setting up preferred credentials, see Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager.

Complete the following steps to setup a machine as the boot server:

1. Install DHCP and TFTP Servers if not already installed.
The two servers could be running either on the same machine, or on different machines. Oracle recommends running the TFTP server on the same host machine as the DHCP server. In case the two servers are installed and configured on different machines, the machine running the TFTP server will be referred to as the boot server.

2. Configure the TFTP server:

- Ensure that the pxelinux boot loader (pxelinux.0) exists in the directory that is configured for your TFTP server (/tftpboot/linux-install in the given examples).

3. Configure DHCP Server:
Edit the dhcpd.conf (/etc/dhcpd.conf) file. A sample dhcpd.conf file for PXE setup is shown below:

allow booting;
allow bootp;

option domain-name  <domain_name>;
option domain-name-servers dns_servers;
option routers <default_router>;

subnet <subnet-number> netmask <netmask> {
[ parameters ]
[ declarations ]
}
# Group the PXE bootable hosts together

group {

# PXE-specific configuration directives...

next-server  <TFTP_server_IP_address>;

filename "linux-install/pxelinux.0";

host <hostname> {
hardware ethernet <MAC address>;
fixed-address <IP address>;
}
}

The next-server option in the DHCP configuration file specifies the host name or IP Address of the machine hosting the TFTP server. Oracle recommends running the TFTP Server on the same host machine as the DHCP Server. Therefore, this address should be the IP Address or hostname for the local machine.

The filename option specifies the boot loader location on the TFTP server. The location of the file is relative to the main TFTP directory.

Any standard DHCP configuration file is supported.The sample file format above shows one entry (line 12-15) for each target host. The DHCP service must be restarted every time you modify the configuration file.

4. Enable the tftp service. Edit the /etc/xinetd.d/tftp file to change the disable flag as no (default=no).

5. Restart the following services:

service dhcpd restart
service xinetd restart
service portmap restart

6. Install Oracle Management Agent.

Note:

Refer to the "Installing Management Agent" chapter in Oracle Enterprise Manager Grid Control Installation Guide to install a 10.2.0.3 or higher version of Management agent on the boot server.

Setting Up Stage Server

Stage server must meet the following requirements:

- Large Storage
The files related to components and directives of an image are first copied to the stage server in preparation for the network installation, and are kept there for future use. The stage server thus acts as a huge cache of files, which requires a large storage.

The stage server can also host the staging storage on Network Attached Storage(NAS). Multiple stage servers can use the same NAS.

- High Memory
The stage directives associated with the components and images are directives that are executed during staging phase of a component or Image. They contain commands to unpack and layout the files in order to facilitate the network installation. Depending on the size of the components and images, these commands place high memory requirements on part of the stage server.

- Sufficient Bandwidth
Staging process could be very time consuming if the network between the Stage server and software library (on Oracle Management Service or OMS Server) does not have sufficient bandwidth to enable fast transfer of files. Similarly, the link between the stage server and hardware servers should have high bandwidth to make the installation process faster.

- NFS or HTTP Support
During the installation, hardware servers mount the stage directory so that all the files required for installation appear as local files. In such a scenario, the stage server functions as the NFS server and the hardware servers as its clients. If the stage server uses NAS for staging storage, the NAS server should have the NFS support.

If the stage server cannot have NFS support, it must be accessible by HTTP.

Follow the instructions listed below to set up a Linux machine as the stage server:

1. Create a top-level directory

- Create a top-level directory on the stage server where all the files will be stored. In the following steps, STAGE_TOP_LEVEL_DIRECTORY refers to the absolute path of this top-level directory. For provisioning 32-bit and 64-bit targets, separate STAGE_TOP_LEVEL_DIRECTORY is required.

- You can specify the HTTP or NFS location of agent rpms when you set up a default image in the Provisioning application. Alternatively, you can copy agent rpms to STAGE_TOP_LEVEL_DIRECTORY so that they are picked up automatically.
To copy agent RPMs to STAGE_TOP_LEVEL_DIRECTORY, do the following:

1. Download Agent RPMs zip file from the following location:

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

2. Unzip the agent RPMs zip file into a temporary directory and then copy the agent RPMs from the emagent directory to STAGE_TOP_LEVEL_DIRECTORY.

2. Configure NFS services.

Perform the following steps on the stage server.

Note:

If the stage server uses NAS for staging storage, the following steps need to be performed on the NAS server as well.

1. Ensure the NFS service is running. One can check this by running service nfs status.
Modify the "/etc/exports" file to have the following entry:

{Directory path} {host_name_or_ip_prefix}* (ro,sync)

For example, /STAGE_TOP_LEVEL_DIRECTORY 10.152.* (ro,sync), if the hardware servers to be provisioned have the IP prefix 10.152.

Or, /STAGE_TOP_LEVEL_DIRECTORY provision-host* (ro,sync), if the hardware servers to be provisioned have names starting with provision-host.

2. After the modification is made, run the service nfs restart command to make the changes visible to nfs daemons.

3. Install Enterprise Manager Agent.
Refer to the "Installing Management Agent" chapter in Oracle Enterprise Manager Grid Control Installation Guide to install a 10.2.0.3 or higher version of Management agent on the Stage Server.

Note:

Ensure that the preferred credentials set for the staging server host has "write" access to the staging storage.

4. From Grid Control Console, set the privileged preferred credentials for the stage server. For information about setting preferred credentials in Enterprise Manager, see Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager.
Oracle recommends that the stage server must have very limited access due to the criticality and sensitivity of the data it hosts. The super administrator can enforce this by creating one account on the stage server, and setting it as the preferred credential, to be used by all the provisioning users in Enterprise Manager. This preferred credential should also be a valid ORACLE_HOME credential (belonging to ORACLE_HOME owner's group).

Setting Up RPM Repository

Note:

It is recommended that you use RAM of 2 GB.

Setting UP RHEL 4 RPM Repository

RPM Repository is used as the source of Linux and application packages that need to be installed on the newly provisioned bare metal box. For example, an RPM Repository may be created to contain all the 32-bit Linux rpms and another repository may be created to contain Linux x86-64 bit rpms. Two separate Linux images can then be created each based on one of the repositories.

RHEL RPM repository to be used should have the following Red Hat Install tree structure:

There are multiple ways to create a RPM repository. If Red Hat Enterprise Linux CDs are available, do the following:

1. Copy all the contents of the first CD to a directory say RPM_REPOS.

2. Copy all rpms from other CDs to <RPM_REPOS>/Redhat/RPMS. Change directory to the RPMS directory:

cd <RPM_REPOS>/Redhat/RPMS

3. Add custom RPMs to the repository.

1. If there are custom RPMs installed on the reference host that need to be provisioned on the bare metal machine, make sure to copy them to the following repository location:

<RPM_REPOS>/Redhat/RPMS

2. Install anaconda-runtime RPM on the machine hosting the RPM repository. This might require other dependent packages to be installed.

3. Run the following commands:

cd /usr/lib/anaconda-runtime
./genhdlist --productpath=RedHat --withnumbers --hdlist <RPM_REPOS>/RedHat/base/hdlist <RPM_REPOS>

4. Run yum-arch :
This should create a headers directory. Make sure this directory contains a header.info file.

If yum is not installed then download it from the Linux Vendor's Web site.

5. Create a symbolic link in /var/www/html to <RPM_REPOS> directory.
The repository should now be available through http if an apache server is running.

Note:

If the Apache server that comes with Enterprise Manger Grid Control 10g is used, enable the Apache directory index page using the "Options Indexes" directive in the Apache configuration (httpd.conf) file.

Setting Up OEL 4 RPM Repository

Oracle Enterprise Linux (OEL) RPM repository should have the Install tree structure shown below:

You can set up Oracle Enterprise Linux (OEL) Repository by using the OEL installation media as follows:

1. Download Oracle Enterprise Linux from http://edelivery.oracle.com/linux.

2. Copy all the contents of the first CD to a directory say RPM_REPOS.

3. Copy all rpms from other CDs to <RPM_REPOS>/Enterprise/RPMS. Change directory to the RPMS directory:

cd <RPM_REPOS>/Enterprise /RPMS

4. Add custom RPMs to the repository.

1. If there are custom RPMs installed on the reference host that need to be provisioned on the bare metal machine, make sure to copy them to the following repository location:

<RPM_REPOS>/Enterprise/RPMS

2. Install anaconda-runtime RPM on the machine hosting the RPM repository. This might require other dependent packages to be installed.

3. Run the following commands:

cd /usr/lib/anaconda-runtime
./genhdlist --productpath=Enterprise --withnumbers --hdlist <RPM_REPOS>/Enterprise/base/hdlist <RPM_REPOS>

5. Run yum-arch :
This should create a headers directory. Make sure this directory contains a header.info file.

6. Create a symbolic link in /var/www/html to <RPM_REPOS> directory.

The repository should now be available through http if an apache server is running.

Setting Up RHEL 5/OEL 5 RPM Repository

Oracle Enterprise Linux (OEL) RPM repository should have the Install tree structure shown below:

You can set up Oracle Enterprise Linux (OEL) Repository by using the OEL installation media as follows:

1. Download Oracle Enterprise Linux from http://edelivery.oracle.com/linux.

2. Copy all the contents of the first CD to a directory say Root Directory.

3. Copy all contents from the Cluster, ClusterStorage, Server, and VT directories in the other CD to the respective directories.
For setting up RPM repository for OVS provisioning, copy RPMs from Oracle, Server, and VT directories to the respective directories.

4. Run createrepo for all four directories. For example:

createrepo <Root Directory>/cluster

5. Add custom RPMs to the repository as follows:

1. If there are custom RPMs installed on the reference host that need to be provisioned on the bare metal machine, make sure to copy them to the directory containing the RPMS, such as Cluster, VT, ClusterStorage, and Server.

2. Run the createrepo command on this directory. For example:

createrepo ClusterStorage

6. Create a symbolic link in /var/www/html to <Root Directory> directory.

The repository should now be available through http if an apache server is running.

Setting Up Software Library

Software Library should be located in a directory accessible by all OMSes. If there is one OMS the directory can be local. For multiple OMS environments, the directory can be on a Network File Server or a Netapp filer that is accessible from all the OMSes. One has to ensure that there is enough space available on the shared storage to store files that hold the binary data for one's components.

Software components that are generated as part of the default or single-server image creation during the bare metal provisioning process are stored in the Software Library. They are accessible under the Components tab in the Provisioning Application user interface.

Ensure that the shared storage is accessible through NFS mount points to all OMS servers in the environment.

Checklist for Boot Server, Stage Server, RPM Repository, and Reference Host

Ensure that the following criteria are met before provisioning:

Table 3-6 Checklist for Boot Server, Stage Server, RPM Repository, and Reference Host

Resource Name

Checklist

Boot Server

DHCP server is up and running.

The next_server entry in /etc/dhcpd.conf file points to this boot server.

TFTP is up and running.

Boot Server is co located on the same machine as Stage Server. If not then Network Install Directory (/tftpboot/linux-install) is exposed to the Staging server for mounting.

Boot Server is present in the same subnet where the target machines to be provisioned are present or will be added.

Enterprise Manager agent is installed.

Boot server machine is visible as a managed target in Enterprise Manager.

A brand new PXE box actually detects the boot server and starts to boot it (even if no image is installed yet)

Stage Server

Stage server is as close as possible to the target servers.

Large storage, High Memory and Sufficient Memory.

If NAS server is used for storage then it should have NFS support.

Enterprise Manager agent is installed.

Boot server machine is visible as a managed target in Enterprise Manager.

The required agent rpm is staged for installing agents on targets.

Preferred Credentials are set.

Stage server is reachable from the box to be populated (or the same subnet)

RPM Repository

Install tree structure is as indicated in Configure RPM repository section.

RPM repository is available via HTTP.

Provide the exact URL and test the RPM repository access over HTTP

Reference Host

Agent is installed on local disk and not on NFS mounted directory.

Preferred Credentials are set.

Software Library

Shared storage used for the software library is accessible through NFS mount points to all OMS servers.

Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager

Preferred credentials simplify access to managed targets by storing target login credentials in the Management Repository. With preferred credentials set, users can access an Enterprise Manager target that recognizes those credentials without being prompted to log into the target. Preferred credentials are set on a per user basis, thus ensuring the security of the managed enterprise environment.

Enterprise Manager supports two types of preferred credentials:

- Normal Credentials: Are used by Enterprise Manager functions that need operating system access, but do not require administrator privileges.

- Privileged Credentials: Are used by functions that need administrator privileges. Credentials for users that have sudo access on the target machine can be used as privileged credentials.

The Provisioning application requires preferred credentials to be setup for machines, which are part of the application.The preferred credentials need to be set for the following machines:

- Referenced Installation Host: Privileged credentials are needed to execute the command to get all the available RPMs form this machine. The credentials should also be valid ORACLE_HOME credentials (belonging to ORACLE_HOME owner's group)

- Stage Server: You must set the privileged preferred credentials for the stage server. Oracle recommends the stage server to have very limited access due to the criticality and sensitivity of the data it hosts. The super administrator can enforce this by creating one account on the stage server, and setting it as the preferred credential, to be used by all the provisioning users in Enterprise Manager. This preferred credential should also be a valid ORACLE_HOME credential (belonging to ORACLE_HOME owner's group).

- Provisioning Targets: In case you are planning to provision existing target machines, ensure the privileged credentials are setup. These credentials are required to clear the boot-sector and reboot the machine.

For details of how to set preferred credentials in Enterprise Manager, see Setting Up Preferred Credentials.

Caution:

It is recommended that you do not use root as the preferred credentials.

Accessing the Bare Metal Provisioning Application

To access the Bare Metal Provisioning Application, do the following:

1. Log in to Oracle Enterprise Manager.

2. The Provisioning application can be accessed by going to the Deployments Tab and then to Provisioning sub tab, as shown below.

The graphical user interface of the provisioning application shows various tabs for Components, Directives, and Images etc. A user can access all or some tabs shown above depending upon the privileges assigned to him. For example, in the figure below, the Administration and Assignments tabs are disabled for the user. Refer to Creating Super Administrator for Enterprise Manager for creating users that can access the Administration tab.

In this section, we will assume that the user has super user privileges and can thus access the administration tab. This tab contains different sections for configuring different elements in the environments.

Configuring Stage Server

In this section, it is assumed that the stage server has been created and the necessary setup has been done.

Click Add Server in the Staging Server Configuration section. The following page comes up.

In the above step, enter the following details:

Staging Server Hostname refers to the host name of the stage server. It is recommended that you specify the IP address of the stage server, to avoid DNS resolution problems.

Full Directory Path refers to the top-level directory on the stage server which contains the agent rpm. All the staged files will be stored in this location.

Base URL is used to expose the top-level stage directory to hardware servers being provisioned via NFS.

NOTE: If Stage Server uses NAS then the Base URL should be of the form:

<file>://<NAS_Hostname>/< NAS_DIRECTORY>

Provide the necessary values for all the parameters and click OK to add the stage server.

Configuring RPM Repository

To configure the RPM repository, the RPM repository must have been created.

Click Add in the RPM Repository Configuration section. The following page is displayed:

Repository Name Assign a name to the RPM repository that is going to be added.

Complete URL refers to the URL pointing to the directory where the required RPMs are located. For example, http://sample.oracle.com/yum/EnterpriseLinux/EL4/oracle/i386

Provide the necessary values for all the parameters shown in the picture above and click OK to add the RPM repository.

Configuring Boot Server

To configure the Boot Server, the Boot Server must have been created.

Click Add in the Boot Server Configuration section. The following page is displayed:

Boot Server Hostname refers to the host on which the boot server is setup.

Network Install Directory refers to the directory on the boot server where the pxelinux.cfg file is located. It is generally /tftpboot/linux-install directory on linux systems.

Provide the necessary values for all the parameters shown in the picture above and click OK to add the Boot Server.

Configuring the DHCP Server

To configure the DHCP server, ensure that the DHCP server is set up as mentioned in Setting Up Boot Server.

To configure the DHCP server, do the following:

1. In the Administration tab, in the DHCP Server Configuration section, click Add.

2. In the Add DHCP Server page, select the host on which the DHCP server resides and select the DHCP configuration path as /etc/dhcpd.conf. Click OK.

The DHCP Server is configured and will appear in the Administration page.

Configuring Software Library

To set up and configure the Software Library, see Setting Up Oracle Software Library.

Part II

Database Provisioning

This part describes the Deployment Procedures you can run for provisioning database targets. In particular, this part describes the Deployment Procedures for:

- Chapter 4, "Provisioning Oracle Database"

- Chapter 5, "Provisioning Oracle Real Application Clusters (RAC)"

- Chapter 6, "Extending Oracle Real Application Clusters"

- Chapter 7, "Deleting or Scaling Down Oracle Real Application Clusters"

- Chapter 8, "Provisioning Oracle Database Replay Client"

Note:

The Cloning Wizard is not supported from Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0).

Note:

The Oracle Home provisioning deployment procedures in Enterprise Manager 10.2.0.5 cannot be used to provision database versions 11.2 and higher. To provision database versions 11.2 using Enterprise Manager 10.2.0.5, use Oracle Database Cloning wizard. However, you can use database deployment procedures in Enterprise Manager 11g to provision database versions 11.2 and higher.

4 Provisioning Oracle Database

This chapter explains how you can mass-deploy Oracle Database in an unattended, repeatable, and reliable manner. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Supported Releases

- Cloning Existing Oracle Database Software

- Provisioning Oracle Database Using Gold Image

- Provisioning Oracle Database from Staged Location

- Provisioning Standalone Oracle Database Using Archived Software Binaries

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle Database. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Oracle Database. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 4-1 Getting Started with Provisioning Oracle Database

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle Database. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

Knowing About the Supported Releases

Know what releases of Oracle Database can be provisioned by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Oracle Database. Select the use case that best matches your requirement.

- To learn about cloning an existing Oracle Database, see Cloning Existing Oracle Database Software.

- To learn about provisioning Oracle Database using a gold image, see Provisioning Oracle Database Using Gold Image.

- To learn about provisioning Oracle Database from a staged location, see Provisioning Oracle Database from Staged Location.

- To learn about provisioning a standalone Oracle Database using its software binaries from an installation medium, see Provisioning Standalone Oracle Database Using Archived Software Binaries.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in cloning an existing Oracle Database, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle Database using a gold image, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle Database from a staged location, see Deployment Phase.

- To learn about the deployment phases involved in provisioning Oracle Database using its software binaries from an installation medium, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about the prerequisites for cloning an existing Oracle Database, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle Database using a gold image, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle Database from a staged location, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle Database using its software binaries from an installation medium, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle Database.

- To clone an existing Oracle Database, follow the steps explained in Cloning Procedure.

- To provision Oracle Database using a gold image, follow the steps explained in Provisioning Procedure.

- To provision Oracle Database from a staged location, follow the steps explained in Provisioning Procedure.

- To provision Oracle Database using its software binaries from an installation medium, follow the steps explained in Provisioning Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedure for provisioning Oracle Database:

- Oracle Database Provisioning

Using this Deployment Procedure, you can perform the following operations across releases and platforms:

- Deploy Oracle Database software using certified gold images, live reference installations, and installation media

- Optionally create and configure multiple databases in parallel

- Use staging location for fast file transfer

For example, if you want to have a fresh installation of Oracle Database, the recommended option is to store the software binaries of the database from an installation medium onto Oracle Software Library (Software Library), and then provision it from the Software Library. However, if you want to have a copy of a running instance that is stable and has all the latest patches applied, the recommended option is to clone that existing instance so that you retain the same configuration settings.

IMPORTANT:

This Deployment Procedure creates Oracle homes and databases, but does not clone data files. Therefore, when you use this Deployment Procedure to clone an existing, running instance of Oracle Database, you essentially create a new database that has only the structure and format copied from the existing one, but not the data.
If you want to clone data files and maintain a copy that is identical to the existing, running instance, then use the Clone Database Wizard. To access this wizard, on the Deployments pages, from the Cloning section, select Clone Database.

Supported Releases

Using these Deployment Procedures, you can provision the following releases of Oracle Database across multiple hosts:

- Oracle Database 10g Release 1 (10.1.x.x)

- Oracle Database 10g Release 2 (10.2.x.x)

- Oracle Database 11g Release 1 (11.1.x.x)

Note:

For provisioning Oracle Databases lower than 10g Release 1, use the Clone Oracle Home wizard in Enterprise Manager Grid Control. To access this wizard, in Grid Control, click Deployments. In the Cloning section, click Clone Oracle Home.

Cloning Existing Oracle Database Software

This section describes how you can clone an existing standalone Oracle Database that is running on a host monitored by Enterprise Manager Grid Control.

This option is best suited when you have a running instance of Oracle Database that is stable and has all the latest patches applied, and you want to make identical copies of that database and its template on multiple hosts.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Cloning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 4-2 Deployment Phases Involved in Cloning Existing Oracle Database Software

Phase

Description

Select Source and Destination

Allows you to select an existing database installation that you want to clone, specify target hosts on which you want to clone, specify any additional parameters to be run, create a new database, and schedule the Deployment Procedure to run immediately or later.

Database Configuration

If you choose to create and configure a database, then phase allows you to specify any additional parameters, custom response file, or DBCA template to be used for configuring the database.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning a standalone Oracle Database.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it as a generic component in the Software Library. Alternatively, you can also maintain this file on any host.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

- Ensure that the operating system user oracle is available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Cloning Procedure

To clone an existing instance of Oracle Database, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page the Oracle Database Provisioning Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Existing Database Installation. Then click the torch icon for Source Host and select the host on which the existing Oracle Database is running.

In the Source Host Details section, by default, Oracle Home, Working Directory, and Files to exclude are prefilled.

Oracle Home shows where the existing instance is installed, but this is a non-editable field. For Working Directory, specify the full path to a directory on source host where the files related to cloning can be staged temporarily. For Files to exclude, specify file names that must not be cloned to the source host. Use a comma to separate the file name, and use the wildcard (*) to indicate all files with the same extension. For example, *.trc. Note that any file or folder corresponding to the regular expressions provided here will be excluded from the clone archive that is created

In the Source Host Credentials section, select Use Preferred Credentials to use the credentials stored in the Management Repository.

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to clone the existing instance of Oracle Database.
By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the Advanced section, specify any additional parameters you want to run while installing the sing;le-instance Oracle Database. For example, -debug.
You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

While installing software binaries from an existing Oracle Database location, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. (Optional) In the Create Database section, select Create and Configure Database if you want to create a new database and configure it after installing the standalone Oracle Database.

IMPORTANT:

If you do not select Create and Configure Database, only the software binaries of Oracle Database are copied to the target host. You will have to manually configure the provisioned Oracle Database using Database Configuration Assistant (DBCA).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Next.
Enterprise Manager Grid Control displays either the Database Configuration page or the Configure Oracle Home page depending on the selection made in Step 4 (d).

In Step 4(d), if you had selected Create and Configure Database, then follow the instructions outlined in Step 5. Otherwise, go to Step 6.

5. On the Database Configuration page, do the following:

1. In the Database Configuration Details section, specify basic configuration details such as the data file location, SID, domain, and password.

You can choose to append %HOST_NAME% or %SHORT_HOST_NAME"% to the data file location so that the path is unique when shared location is used. Also ensure that the SID and domain are unique for each host.

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path to the dat file location across hosts, or select Different for each host if you want to use different paths for each host.

Also, from the Database Password list, select Same for all hosts if you want to use the same set of passwords, or select Different for each host if you want to use different passwords for each host.

2. (Optional) In the Database Parameters section, specify any additional DBCA parameters that you want to pass while configuring the database. For example, -characterSet AL32UTF8.

3. (Optional) In the Oracle Database Template File section, select Use Custom Database Template File and use the template file that is being used in the existing instance of Oracle Database that you are cloning. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.
If you have stored the template file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

IMPORTANT:

If you do not select Use Custom Database Template File, the provisioned Oracle Database will be configured but will not have the same structure as the source. You will have to manually structure the provisioned Oracle Database.

6. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Review page, review the details you have provided for provisioning a standalone Oracle Database, and click Submit.

8. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Provisioning Oracle Database Using Gold Image

This section describes how you can provision a gold image of Oracle Database from the Software Library.

This option is best suited when you have a copy of a stable, well-tested, and patched Oracle Database instance in the Software Library. This option scores over a fresh installation because you save time in patching and testing a fresh instance.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 4-3 Deployment Phases Involved in Provisioning Gold Image from Software Library

Phase

Description

Select Source and Destination

Allows you to select the gold image from the Software Library, specify target hosts on which you want to deploy the gold image, specify any additional parameters to be run, create a new database, and schedule the Deployment Procedure to run immediately or later.

Database Configuration

If you choose to create and configure a database, then phase allows you to specify any additional parameters, custom response file, or DBCA template to be used for configuring the database.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning a standalone Oracle Database.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that you create a gold image of an existing Oracle Database.
To understand how you can create a gold image, see Creating Gold Image.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it as a generic component in the Software Library. Alternatively, you can also maintain this file on any host.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

To understand how you can upload the response file to the Software Library, see Uploading Database Response File to Oracle Software Library.

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

To understand how you can upload the template to the Software Library, see Uploading Database Template File to Oracle Software Library.

- Ensure that the operating system user oracle is available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Creating Gold Image

To create a gold image of an existing Oracle Database (standalone), Oracle RAC Database, Oracle Clusterware, or Oracle Database Replay Client, follow these steps:

1. In Grid Control, click Deployments, and then Provisioning.

2. On the Components page, from the table, select Components and click Create Component. Enterprise Manager Grid Control displays the Create Component Wizard.

3. On the Create Component: Describe page, from the Type list, select Oracle Database Software Clone. Specify a unique name, description, the product/patch number, the version, and the vendor details.

4. Click Next.

5. On the Create Component: Configure page, from the configuration details such as the host name, the location of the Oracle home you want to clone, the credentials of the host, the privilege type you want to set, the working directory, and a list of file you want to exclude during this provisioning process. For more information, click Help on the page.

6. Click Next.

7. On the Review page, review all the information you have provided and click Finish to submit the component creation job. Enterprise Manager Grid Control creates the gold image and returns to the Components page.

8. On the Components page, in the table, ensure that the gold image you just created is appearing under Oracle Components.

Uploading Database Response File to Oracle Software Library

To upload a database response file, follow these steps:

1. In Grid Control, click Deployments, and then Provisioning.

2. On the Components page, from the table, expand Oracle Components, and then RAC Provisioning.

3. Under RAC Provisioning, expand Database Response File.

4. Under Database Template File, select Oracle Database Response File and click Edit.

5. On the Edit Component page, click the Upload File tab.

6. On the Upload File page, select one of the following options and upload the database response file:

1. Upload from Agent Machine, if the template file is available on the host where the Management Agent is running.

2. Upload from Local Machine, if the template file is available on the local host, that is, the host from where you are accessing the Grid Control console.

7. Click Finish. Enterprise Manager Grid Control uploads the template and returns to the Component page.

8. On the Components page, from the table, expand Oracle Components, and then RAC Provisioning.

9. Under RAC Provisioning, expand Database Template File. You should see Oracle Database Template File under it. Ensure that status of this component is Ready.

Uploading Database Template File to Oracle Software Library

To upload a database template file, follow these steps:

1. In Grid Control, click Deployments, and then Provisioning.

2. On the Components page, from the table, expand Oracle Components, and then RAC Provisioning.

3. Under RAC Provisioning, expand Database Template File.

4. Under Database Template File, select Oracle Database Template File and click Edit.

5. On the Edit Component page, click the Upload File tab.

6. On the Upload File page, select one of the following options and upload the database response file:

1. Upload from Agent Machine, if the template file is available on the host where the Management Agent is running.

2. Upload from Local Machine, if the template file is available on the local host, that is, the host from where you are accessing the Grid Control console.

7. Click Finish. Enterprise Manager Grid Control uploads the template and returns to the Component page.

8. On the Components page, from the table, expand Oracle Components, and then RAC Provisioning.

9. Under RAC Provisioning, expand Database Template File. You should see Oracle Database Template File under it. Ensure that status of this component is Ready.

Provisioning Procedure

To provision a gold image of Oracle Database from the software library, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page the Oracle Database Provisioning Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Software Library. Then click the torch icon for Component and select the generic component that has the gold image. Ensure that you select only components that are in "Ready" status.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the gold image of Oracle Database.
By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the Advanced section, specify any additional parameters you want to run while installing the sing;le-instance Oracle Database. For example, -debug.
You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

While installing software binaries from an existing Oracle Database location, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. (Optional) In the Create Database section, select Create and Configure Database if you want to create a new database and configure it after installing the standalone Oracle Database.

IMPORTANT:

If you do not select Create and Configure Database, only the software binaries of Oracle Database are copied to the target host. You will have to manually configure the provisioned Oracle Database using Database Configuration Assistant (DBCA).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Next.
Enterprise Manager Grid Control displays either the Database Configuration page or the Configure Oracle Home page depending on the selection made in Step 4 (d).

In Step 4(d), if you had selected Create and Configure Database, then follow the instructions outlined in Step 5. Otherwise, go to Step 6.

5. On the Database Configuration page, do the following:

1. In the Database Configuration Details section, specify basic configuration details such as the data file location, SID, domain, and password.

You can choose to append %HOST_NAME% or %SHORT_HOST_NAME"% to the data file location so that the path is unique when shared location is used. Also ensure that the SID and domain are unique for each host.

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path to the data file location across hosts, or select Different for each host if you want to use different paths for each host.

Also, from the Database Password list, select Same for all hosts if you want to use the same set of passwords, or select Different for each host if you want to use different passwords for each host.

2. (Optional) In the Database Parameters section, specify any additional DBCA parameters that you want to pass while configuring the database. For example, -characterSet AL32UTF8.

3. (Gold Image of Fresh Installation) (Optional) In the Oracle Database Response File section, select Use Custom Database Response File if you want to use a custom response file that has options enabled. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.

Note:

While creating the database, the values specified in the wizard (UI) for mandatory parameters, such as SID and so on, will take precedence over the values specified for the same parameters in the response file.

The options can be SYSDBA user name and password for OS authentication, wallet password if a wallet is being used, security configuration, backup and recovery settings for scheduling a backup and recovery operation, and so on.

If you have stored the response file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

4. (Optional) In the Oracle Database Template File section, select Use Custom Database Template File and use the template file that is being used in the existing instance of Oracle Database that you are cloning. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.
If you have stored the template file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

IMPORTANT:

If you do not select Use Custom Database Template File, the provisioned Oracle Database will be configured but will not have the same structure as the source. You will have to manually structure the provisioned Oracle Database.

6. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Review page, review the details you have provided for provisioning a standalone Oracle Database, and click Submit.

8. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Provisioning Oracle Database from Staged Location

This section describes how you can provision Oracle Database from a staged location. Staged location refers to a shared, NFS-mounted location in your network that is accessible from the target hosts. As a prerequisite, the Oracle Database to be provisioned must already be available in the shared location. For more information, see Prerequisites.

In particular, this section covers the following:

- Deployment Phase

- Prerequisites

- Provisioning Procedure

Deployment Phase

The following describes the different phases involved in this Deployment Procedure:

Table 4-4 Deployment Phases Involved in Provisioning Gold Image from Staged Location

Phase

Description

Select Source and Destination

Allows you to select the gold image from a staged location, specify target hosts on which you want to deploy the gold image, specify any additional parameters to be run, create a new database, and schedule the Deployment Procedure to run immediately or later.

Database Configuration

If you choose to create and configure a database, then phase allows you to specify any additional parameters, custom response file, or DBCA template to be used for configuring the database.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning a standalone Oracle Database.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that the Oracle Database to be provisioned is available in this staged location, in a format required by this Deployment Procedure.
You cannot manually stage the software binaries to the shared location; they must be staged using the Deployment Procedure in one of the following ways:

- You can run the Deployment Procedure as described in other sections of this chapter to deploy the software on a target host, and while providing details for this operation, on the Select Source and Destination page of the wizard, in the Advanced section, select Stage to Shared Location and specify the full path to the shared, NFS-mounted location where it can be staged.
This will ensure that you deploy the software on a target host and also stage a copy to the shared location. However, note that deployment is performed on a target host and this full-fledged operation requires your time, space on the target host, and so on.

- You can customize the Deployment Procedure as described in Chapter 23, "Enabling or Disabling Phases or Steps"to disable all the steps involved in the Deployment Procedure, except for the step that stages the software to a shared location, and then run the customized Deployment Procedure to only stage the software to a shared location, and not deploy it on any target host.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it as a generic component in the Software Library. Alternatively, you can also maintain this file on any host.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

- Ensure that the operating system user oracle is available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a gold image of Oracle Database from the software library, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page the Oracle Database Provisioning Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Staging Location, and then select Gold Image. Click the torch icon for Select Host and select the host on which the gold image is staged. Then click the torch icon for Stage Location and select the location where the gold image is staged.

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the gold image of Oracle Database.
By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the Advanced section, specify any additional parameters you want to run while installing the sing;le-instance Oracle Database. For example, -debug.
You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

While installing software binaries from an existing Oracle Database location, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. (Optional) In the Create Database section, select Create and Configure Database if you want to create a new database and configure it after installing the standalone Oracle Database.

IMPORTANT:

If you do not select Create and Configure Database, only the software binaries of Oracle Database are copied to the target host. You will have to manually configure the provisioned Oracle Database using Database Configuration Assistant (DBCA).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Next.
Enterprise Manager Grid Control displays either the Database Configuration page or the Configure Oracle Home page depending on the selection made in Step 4 (d).

In Step 4(d), if you had selected Create and Configure Database, then follow the instructions outlined in Step 5. Otherwise, go to Step 6.

5. On the Database Configuration page, do the following:

1. In the Database Configuration Details section, specify basic configuration details such as the data file location, SID, domain, and password.

You can choose to append %HOST_NAME% or %SHORT_HOST_NAME"% to the data file location so that the path is unique when shared location is used. Also ensure that the SID and domain are unique for each host.

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path to the data file location across hosts, or select Different for each host if you want to use different paths for each host.

Also, from the Database Password list, select Same for all hosts if you want to use the same set of passwords, or select Different for each host if you want to use different passwords for each host.

2. (Optional) In the Database Parameters section, specify any additional DBCA parameters that you want to pass while configuring the database. For example, -characterSet AL32UTF8.

3. (Optional) In the Oracle Database Response File section, select Use Custom Database Response File if you want to use a custom response file that has options enabled. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.

Note:

While creating the database, the values specified in the wizard (UI) for mandatory parameters, such as SID and so on, will take precedence over the values specified for the same parameters in the response file.

The options can be SYSDBA user name and password for OS authentication, wallet password if a wallet is being used, security configuration, backup and recovery settings for scheduling a backup and recovery operation, and so on.

If you have stored the response file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

4. (Optional) In the Oracle Database Template File section, select Use Custom Database Template File and use the template file that is being used in the existing instance of Oracle Database that you are cloning. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.
If you have stored the template file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

IMPORTANT:

If you do not select Use Custom Database Template File, the provisioned Oracle Database will be configured but will not have the same structure as the source. You will have to manually structure the provisioned Oracle Database.

6. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Review page, review the details you have provided for provisioning a standalone Oracle Database, and click Submit.

8. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Provisioning Standalone Oracle Database Using Archived Software Binaries

This section describes how you can provision one or more standalone Oracle Database using the software binaries available in the installation medium.

This option is best suited when you want a completely new installation to be provisioned across multiple hosts. Of course, understandably, this is a fresh installation and you will have to update it with all the latest patches that have been released so far.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 4-5 Deployment Phases Involved in Provisioning Standalone Oracle Database

Phase

Description

Select Source and Destination

Allows you to select a generic component (which contains the archive of the installation medium) from the Software Library, specify target hosts on which you want to deploy the database, specify any additional parameters to be run, optionally create a new database, and schedule the Deployment Procedure to run immediately or later.

Database Configuration

If you choose to create and configure a database, then phase allows you to specify any additional parameters, custom response file, or DBCA template to be used for configuring the database.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning a standalone Oracle Database.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that you upload the software binaries of Oracle Database to the Software Library.
To understand how you can upload the software binaries to the Software library, see Uploading Software Binaries to Oracle Software Library.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it as a generic component in the Software Library. Alternatively, you can also maintain this file on any host.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

To understand how you can upload the response file to the Software Library, see Uploading Database Response File to Oracle Software Library.

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

To understand how you can upload the template to the Software Library, see Uploading Database Template File to Oracle Software Library.

- Ensure that the operating system user oracle is available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Uploading Software Binaries to Oracle Software Library

To upload the software binaries of Oracle Database (standalone), Oracle RAC Database, Oracle Clusterware, or Oracle Database Replay Client to the Software Library, follow these steps:

1. In Grid Control, click Deployments, then Provisioning.

2. On the Components page, from the table, expand Oracle Components, and then RAC Provisioning.

3. Under RAC Provisioning, expand the release of the database. For example, 10.2.0.1.0.

4. Under the release of the database, expand the operating system.

5. Under the operating system, select one of the following and click Edit.

- For 11.1.0.6.0 or lower:

- For Oracle Clusterware software binaries, select Oracle Clusterware shiphome.

- For Oracle Database software binaries, select Oracle Database shiphome.'

- For Oracle Database Replay Client software binaries, select Oracle Database Replay Client Install Media.

- For 11.2.0.1.0 or higher:

- For Oracle Grid Infrastructure software binaries, select Oracle Grid Infrastructure shiphome.

- For Oracle Database software binaries, select Oracle Database shiphome.

- For Oracle Database Replay Client software binaries, select Oracle Database Replay Client Install Media.

6. On the Edit Component page, click the Upload File tab.

7. On the Upload File page, select one of the following options and upload the software binaries:

1. Upload from Agent Machine, if the software binaries are available on the host where the Management Agent is running.

2. Upload from Local Machine, if the software binaries are available on the local host, that is, the host from where you are accessing the Grid Control console.

8. Click Finish.

Provisioning Procedure

To provision a fresh standalone Oracle Database, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Software Library. Then click the torch icon for Component and select the generic component that has the software binaries of Oracle Database. Ensure that you select only components that are in "Ready" status.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the standalone Oracle Database.

By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the Advanced section, specify any additional parameters you want to run while installing the database. For example, -debug.
You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

While installing software binaries from the Software Library, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. (Optional) In the Create Database section, select Create and Configure Database if you want to create a new database and configure it after installing the standalone Oracle Database.

IMPORTANT:

If you do not select Create and Configure Database, only the software binaries of Oracle Database are copied to the target host. You will have to manually configure the provisioned Oracle Database using Database Configuration Assistant (DBCA).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Next.
Enterprise Manager Grid Control displays either the Database Configuration page or the Configure Oracle Home page depending on the selection made in Step 4 (d).

In Step 4(d), if you had selected Create and Configure Database, then follow the instructions outlined in Step 5. Otherwise, go to Step 6.

5. On the Database Configuration page, do the following:

1. In the Database Configuration Details section, specify basic configuration details such as the data file location, SID, domain, and password.

You can choose to use %HOST_NAME% or %SHORT_HOST_NAME"% to the data file location so that the path is unique when a shared location is used. Also ensure that the SID and domain are unique for each host.

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path to the data files across hosts, or select Different for each host if you want to use different paths for each host.

Also, from the Database Password list, select Same for all hosts if you want to use the same set of passwords, or select Different for each host if you want to use different passwords for each host.

2. (Optional) In the Database Parameters section, specify any additional DBCA parameters that you want to pass while configuring the database. For example, -characterSet AL32UTF8.

3. (Optional) In the Oracle Database Response File section, select Use Custom Database Response File if you want to use a custom response file that has options enabled. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.

Note:

While creating the database, the values specified in the wizard (UI) for mandatory parameters, such as SID and so on, will take precedence over the values specified for the same parameters in the response file.

The options can be SYSDBA user name and password for OS authentication, wallet password if a wallet is being used, security configuration, backup and recovery settings for scheduling a backup and recovery operation, and so on.

If you have stored the response file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

4. (Optional) In the Oracle Database Template File section, select Use Custom Database Template File if you want to use a custom template to structure the database. Ensure that the file is available either on the target hosts or in a shared location accessible by the target hosts.
If you have stored the template file as a generic component in the Software Library, then select Software Library and click the torch icon for Component to select the component. Otherwise, select Destination Host and click the torch icon to select the host where the file resides.

IMPORTANT:

If you do not select Use Custom Database Template File, the provisioned Oracle Database will be configured but will not have the same structure as the source. You will have to manually structure the provisioned Oracle Database.

6. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Review page, review the details you have provided for provisioning a standalone Oracle Database, and click Submit.

8. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Manually Collecting and Uploading Configuration Information to My Oracle Support

To manually collect the configuration information, follow these steps:

1. On the host where the Oracle home was deployed or patched, navigate to the following location. Here, <OracleHome> is the Oracle home directory of the Oracle home you deployed or patched.
<OracleHome>/ccr/bin

2. Collect configuration information by running the following command:
<OracleHome>/ccr/bin/emCCR collect

For Oracle Configuration Manager 10.2.7 and higher, the collected configuration information is stored in the <OracleHome>/ccr/hosts/<hostname>/state/upload/ocmconfig.jar file. For lower versions of Oracle Configuration Manager, the collected configuration information is stored in the <OracleHome>/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.

3. Upload the ocmconfig.jar file to a Service Request on My Oracle Support at the following URL:
http://metalink.oracle.com

Instrumenting the Database for Configuration Collections

After the Deployment Procedure ends, once the Oracle Configuration Manager is installed and configured either in connected or disconnected mode, you must instrument the database to collect configuration information.

Oracle Configuration Manager Installed in Connected Mode

If you had installed and configured Oracle Configuration Manager in a connected mode, then to instrument the database, see the steps outlined in the Instrumenting the Database for Configuration Collections chapter of the Oracle Configuration Manager Quick Start Guide available at the following URL. The steps provided in this guide must be repeated for every database instance being patched or deployed.

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

Oracle Configuration Manager Installed in Disconnected Mode

If you had installed and configured Oracle Configuration Manager in a disconnected mode, then to instrument the database, see the steps (except for the last step) outlined in the Instrumenting the Database for Configuration Collections chapter of the Oracle Configuration Manager Quick Start Guide available at the following URL:

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

As a final step, after you run the emCCR collect command and collect the configuration information, manually upload the ocmconfig.jar file to a Service Request on My Oracle Support at the following URL. The steps provided in this guide must be repeated for every database instance being patched or deployed.

http://metalink.oracle.com/

5 Provisioning Oracle Real Application Clusters (RAC)

This chapter explains how you can provision Oracle RAC. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Core Components Deployed

- Cloning a Running Oracle RAC

- Provisioning Oracle RAC Using Gold Image

- Provisioning Oracle RAC Using Archived Software Binaries

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle RAC. Consider this section to be a documentation map to understand the sequence of actions you mOracle Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patchingust perform to successfully provision Oracle RAC. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 5-1 Getting Started with Provisioning Oracle RAC

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle RAC. Know how the Deployment Procedure functions, what use cases it covers, what core components it deletes or scales down, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

To learn about the core components that are provisioned, see Core Components Deployed.

Knowing About The Supported Releases

Know what releases of Oracle RAC can be provisioned by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Oracle RAC. Select the use case that best matches your requirement.

- To learn about cloning an existing Oracle RAC, see Cloning a Running Oracle RAC.

- To learn about provisioning Oracle RAC using a gold image, see Provisioning Oracle RAC Using Gold Image.

- To learn about provisioning Oracle RAC using the software binaries from an installation medium, see Provisioning Oracle RAC Using Archived Software Binaries.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in cloning an existing Oracle RAC, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle RAC using a gold image, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle RAC using the software binaries from an installation medium, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about prerequisites for cloning an existing Oracle RAC, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle RAC using a gold image, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle RAC using the software binaries from an installation medium, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle RAC.

- To clone an existing Oracle RAC, follow the steps explained in Cloning Procedure.

- To provision Oracle RAC using a gold image, follow the steps explained in Provisioning Procedure.

- To provision Oracle RAC using the software binaries from an installation medium, follow the steps explained in Provisioning Procedure.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning Oracle RAC:

- Oracle Clusterware / RAC Provisioning For UNIX

- Oracle Clusterware / RAC Provisioning For Windows

Note:

When you run the Deployment Procedures to provisioning Oracle RAC on a shared file system, the software binaries are installed in the shared location, but the configuration happens only on one node and not on all nodes. This is an expected behavior. To configure other nodes, run the One Click Extend Cluster Database procedure to extend the Oracle RAC stack to other nodes.

Core Components Deployed

When you provision Oracle RAC, essentially, the Deployment Procedures deploy the following core components:

- Oracle Clusterware

- Oracle RAC Database

- Optionally, Automatic Storage Management (ASM)
You can deploy ASM either in the same Oracle home as the one for Oracle RAC Database, or in a completely different Oracle home (recommended).

Supported Releases

Using these Deployment Procedures, you can provision the following releases of Oracle RAC:

- Oracle RAC Database 10g Release 2 (10.2.x.x)

- Oracle RAC Database 11g Release 1 (11.1.x.x)

Cloning a Running Oracle RAC

This section describes how you can clone an existing Oracle RAC installation that is running on a host monitored by Enterprise Manager Grid Control.

This section covers the following:

- Deployment Phases

- Prerequisites

- Cloning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 5-2 Deployment Phases Involved in Cloning an Existing Oracle RAC

Phase

Description

Select Source

Allows you to select an existing Oracle RAC installation that you want to clone.

Select Hosts

Allows you to select the target hosts, which should form the cluster, and the network interfaces (public and private).

Credentials and Schedule

Allows you to specify host credentials required for accessing the hosts where the existing Oracle RAC needs to be cloned, and schedule the Deployment Procedure to run immediately or later.

Configure Cluster

Allows you to specify configuration values for the cluster, create new starter database, and enable backup and recovery options.

Storage

Allows you to specify a partition name and mount location, and select a mount format and storage device for storing data.

Configuration

Allows you to provide additional parameters for configuring the clusterware.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning Oracle RAC.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites.

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- If you want to clone Oracle RAC 11g Release 1 (11.1.0.6) on Solaris platforms, then apply patch# 6486988 on the Oracle home that needs to be cloned.

- Ensure that the target hosts have the necessary hardware and software required for Oracle RAC. The hardware requirements include setting up of the following:

- Private Network: The network interface cards must be installed on each node and connected to each other.

- Shared Storage Between Nodes: The shared storage is required for OCR, Voting disks and the data files.

- Ensure that the Virtual IPs are set up in the DNS. If you choose to set up the Virtual IPs locally, then the IP addresses can be specified using the Deployment Procedure, and the procedure will set them up for you.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.
For more information, see Oracle Clusterware Installation Guide available at:

http://www.oracle.com/pls/db111/homepage

- Ensure that the User IDs for operating system users and the Group IDs for operating system groups are identical on all nodes of the cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle RAC database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- While selecting the source, remember to remove sqlnet.ora from the list of files mentioned in Files to Exclude.

- Ensure that the umask value on the target host is 022.

Cloning Procedure

To clone an existing Oracle RAC installation, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedure subtab, from the table, select one of the following, and click Schedule Deployment.

1. To run the Deployment Procedure on UNIX platforms, Select Oracle Clusterware / RAC Provisioning For UNIX.

2. To run the Deployment Procedure on Microsoft Windows platforms, select Oracle Clusterware / RAC Provisioning For Windows.

Enterprise Manager Grid Control displays the Select Source page of the Deployment Procedure.

4. On the Select Source page, do the following:

1. In the Select Source section, select Select from Existing Installations. Then click the torch icon for Reference Host and select the host on which the existing Oracle RAC installation is running. Once you select the reference host, the application automatically displays the working directory and the details of the selected Oracle Clusterware and Oracle Database.

If you want to save the selected Oracle Clusterware and Oracle Database as gold images in the Software Library, then click Save to Software Library. Oracle Clusterware is saved as a Clusterware Clone component type and Oracle Database is stored as a Database Clone component type, respectively.

Note:

- Maintain different locations as working directories in case a shared disk is used between the source host and the destination host.

- Remove sqlnet.ora from the list of files mentioned in Files to Exclude. If you do not remove it, the Oracle RAC database configuration will fail.

2. Click Next.

5. On the Select Hosts page, do the following:

1. In the Hosts to Include in Cluster section, click Add and select the target hosts that should form the cluster. To see more details about the selected hosts, click Show Options.

Note:

When you click Add, the Select Target pop-up window appears. On this page, by default, the Show Suitable Hosts option is selected and the table lists only those hosts that are best suited for provisioning. If you do not find the host you want to add, then select Show All Hosts to view a complete list of hosts.

By default, Private Host Name and Virtual Host Name are automatically prefilled with values. Edit them and specify values that match with your environment. Optionally, you can also specify their IP addresses.

Note:

If the prefilled, default values of Private Host Name and Virtual Host Name are incorrect, then see the workaround described in Appendix A, "Troubleshooting Issues".

If you already have these details stored in cluster configuration file, then click Import From File to select that cluster configuration file. This file typically contains information about the new hosts to be added. To understand how a cluster configuration file looks, see the sample file shown in Sample Cluster Configuration File.

To configure the private and public network interfaces, click Select Interfaces. By default, the interfaces that have the same name and subnet for the selected target hosts are displayed. However, you can also choose to view all the interfaces for the selected target hosts. You can either select one of the existing interfaces or specify a completely new one if the interface you want to use does not exist.

2. In the Network Interface Configuration section, review the details of the private and public interfaces.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Reference Host Credentials section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

2. In the Target Host(s) Credentials section, provide the credentials as described in Step 6 (a).

Note:

If you are using vendor clusterware, then ensure that root and the operating system users, such as oracle and crsuser, owning the clusterware and various Oracle homes are a part of the operating system groups required by the vendor clusterware.
For example, if your system uses High Availability Cluster Multiprocessing (HACMP) clusterware, then create or check for the existence of the group hagsuser. Ensure that the relevant operating system users and root user are members of this group.

For more information, refer to the Oracle Clusterware and Oracle Real Application Clusters Installation and Configuration Guide.

3. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

4. Click Next.

7. On the Configure Cluster page, do the following:

1. In the Cluster Name and Location section, review the default name and location details provided for Oracle Clusterware and Oracle RAC Database. While Oracle recommends you to retain the default values, you can always edit them to provide custom values.
For security purposes, the clusterware configuration sets the ownership of Oracle Clusterware home and all its parent directories to be owned by root. Hence, Oracle recommends you to install Oracle Clusterware outside the Oracle base of the Oracle RAC home.

The default cluster name you see here is based on the host cluster name you provided in the Agent Deploy application in Enterprise Manager Grid Control, while deploying Management Agents on a cluster. The scratch location you see here is a temporary location on the target host where temporary files are placed before provisioning and configuring Oracle RAC.

For Additional Parameters, specify any additional parameters you want to run while installing Oracle Clusterware. For example, -debug.

You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

Note:

- If you do not see a default cluster name in the Cluster Name field, then you might have selected nodes that are not master nodes of the cluster. In this case, manually specify a cluster name, but ensure that the name you specify is the same host cluster name you provided in the Agent Deploy application in Enterprise Manager Grid Control, while deploying Management Agents on that cluster.

- If this entire section (Cluster Name and Location section) is disabled, then it is clear that each node has a Management Agent, but they were NOT installed using the Cluster Install option available in the Agent Deploy application. To resolve this issue, ensure that you convert the standalone Management Agents to a cluster agent. For more information, see Appendix I, "Converting Standalone Oracle Management Agent to Cluster Agent".

2. In the Database Details section, retain the default selection for creating a starter database.

Note:

If the database creation steps are disabled in the Deployment Procedure, then you will not see this section.

If you want to create a general-purpose database, then leave all the fields in this section blank. Otherwise, provide the required details as described in this step.

If you have a custom response file that already has the options enabled, then select Use response file to create database, and specify the full path to a location where the file is available. The file may be available on the target host, in a shared location accessible from the target host, in the Software Library, or in a location where an existing database is running.

Note:

From the Software Library or from the location where an existing database is running, only a .dbt template file can be used. However, from the target host or a shared location, any template file can be used.

If you do not have a custom response file, then select Do not use response file, and provide the global database name, the credentials, and the additional parameters you want to run while creating the starter database.

Note:

Ensure that the database name you specify is in the format database_name.database_domain. It must have 1 to 8 alphanumeric characters. For example, orcl.mydomain.com. Also note that the credentials you provide are used for SYS, SYSTEM, SYSMAN, and DBSNMP accounts.

If you want to use the structure of an existing database and have a custom template to structure the new database, then in Template File for Database, specify the full path to a location where the template file is available. The file may be available on the target host or on a shared location accessible from the target host.

Note:

If you do not store the response files and templates in a central location, you can always customize the Deployment Procedure to add another step that copies the response file or template to the target host before invoking the configuration tools to create the database.

3. In the Backup and Recovery Details section, retain the default selection, that is, Do not Enable Automated Backups if you do not want to have backups taken.

Alternatively, if you want to enable automated backups, select Enable Automated Backups, specify the full path to a directory location from where the backed-up files can be recovered, and provide the operating system credentials for running the backup job. Note that recovery location is the same location as the backup location because this where the files are backed up and also recovered from.

4. In the ASM Instance Details section (appears only if you had selected to deploy ASM), retain the default selection, that is, Create ASM Instance, and specify the credentials, additional ASM parameters to be used, and the ASM disk string to be used.

Important:

If you are provisioning Oracle Database 10g and Oracle ASM 10g, then ensure that you specify the same password for database as well as ASM.

If you have a custom response file that already has the options enabled, then select Use response file to create ASM database, and specify the full path to a location where the file is available. The file may be availableon the target host or on a shared location accessible fromt he target hosts.

If you do not want to use a response file, then select Do not use response file.

5. Click Next.

8. On the Storage page, do the following:

1. In the Shared Storage Configuration section, provide details about the storage devices and click Next. Specify the partition name and the mount location, and select the mount format and a storage device for storing data. While partition name is the path to the location where the device is installed, mount location is the mount point that represents the partition location.

While configuring the storage device, at a minimum, you must have a partition for at least OCR, Voting Disk, and data files. You cannot designate the same storage device to multiple partitions.

Oracle recommends designating the OCR and the OCR Mirror devices to different partitions. Similarly, Oracle recommends designating the Voting Disk, Voting Disk1, and Voting Disk2 to different partitions.

Before clicking Next, do the following:

- If you want to clear the data on selected raw devices before creating and configuring the cluster, then select Clear raw devices.

- If you have configured only for a few storage devices, then select Do not provision storage for others that you do not want to provision.

- Specify the ASM disk string to be used.

2. In the Options section, select the ASM redundancy mode. The default is None, which requires 7 GB of space. While Normal requires 16 GB of space, High requires 32 GB.

9. (Optional) On the Advanced Configuration page, do the following:

Note:

If the configuration steps are disabled in the Deployment Procedure, then you will not see this page.

1. In the Bonding Interface (Private Interconnect) section, select Configure Bonding Interface if you want to configure the bonding interface. To bind the interfaces, specify details as described in Table 5-5.

2. In the Sysctl File Configuration section, select Configure Sysctl file if you want to configure the sysctl.conf file. Specify the mode of editing the system configuration file and the location of the reference system configuration file used for modifying the kernel parameters.
The default mode is append. You can however select edit to modify, and replace to replace the current sysctl.conf file.

Ensure that the reference file you specify is available in a shared location accessible by the Oracle Management Service.

10. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

11. On the Review page, review the details you have provided for provisioning Oracle RAC, and click Submit. If the details you provided seem to be missing on this page, then see the workaround described in Appendix A, "Troubleshooting Issues".

12. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Provisioning Oracle RAC Using Gold Image

This section describes how you can provision a gold image of Oracle RAC.

Note:

Ensure that you use a gold image that was created using the Oracle home directory of a RAC database. You cannot use a gold image that was created using the Oracle home directory of a standalone database.

This section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 5-3 Deployment Phases for Provisioning Gold Image of Oracle RAC

Phase

Description

Select Source

Allows you to select the gold image of Oracle Clusterware, Oracle RAC, and ASM (optional).

Select Hosts

Allows you to select the target hosts, which should form the cluster, and the network interfaces (public and private).

Credentials and Schedule

Allows you to specify host credentials required for accessing the hosts where the gold image needs to be provisioned, and schedule the Deployment Procedure to run immediately or later.

Configure Cluster

Allows you to specify configuration values for the cluster, create new starter database, and enable backup and recovery options.

Storage

Allows you to specify a partition name and mount location, and select a mount format and storage device for storing data.

Configuration

Allows you to provide additional parameters for configuring the clusterware.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning Oracle RAC.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites.

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that you create gold images of existing Oracle RAC database and Oracle Clusterware.
To understand how you can create a gold image, see Creating Gold Image.

- Ensure that the target hosts have the necessary hardware and software required for Oracle RAC. The hardware requirements include setting up of the following:

- Private Network: The network interface cards must be installed on each node and connected to each other.

- Shared Storage Between Nodes: The shared storage is required for OCR, Voting disks and the data files.

- Ensure that the Virtual IPs are set up in the DNS. If you choose to set up the Virtual IPs locally, then the IP addresses can be specified using the Deployment Procedure, and the procedure will set them up for you.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it in the Software Library.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

To understand how you can upload the response file to the Software Library, see Uploading Database Response File to Oracle Software Library.

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in the Software Library.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

To understand how you can upload the template to the Software Library, see Uploading Database Template File to Oracle Software Library.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.
For more information, see Oracle Clusterware Installation Guide available at:

http://www.oracle.com/pls/db111/homepage

- Ensure that the User IDs for operating system users and the Group IDs for operating system groups are identical on all nodes of the cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle RAC database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- While selecting the source, remember to remove sqlnet.ora from the list of files mentioned in Files to Exclude.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a gold image of an Oracle RAC installation, follow these steps:

1. In Grid Control, click theDeployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedure subtab, from the table, select one of the following, and click Schedule Deployment.

1. To run the Deployment Procedure on UNIX platforms, Select Oracle Clusterware / RAC Provisioning For UNIX.

2. To run the Deployment Procedure on Microsoft Windows platforms, select Oracle Clusterware / RAC Provisioning For Windows.

Enterprise Manager Grid Control displays the Select Source page of the Deployment Procedure.

4. On the Select Source page, do the following:

1. In the Select Source section, select Select from Software Library.

2. In the Source for Clusterware section, click the torch icon and select the generic component that has the gold image of Oracle Clusterware. Ensure that you select only components that are in "Ready" status. Once you select the component name, the application automatically displays the component location.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

3. In the Source for RAC section, click the torch icon and select the generic component that has the gold image of Oracle Database. Ensure that you select only components that are in "Ready" status. Once you select the component name, the application automatically displays the component location.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

4. (Optional) In the Source for ASM section, do one of the following:
If you do not want to deploy ASM, then retain the default selection, that is, Do not Provision ASM.

If you want to deploy ASM in the same Oracle home as the Oracle RAC, then select Use the same source as the RAC home. Alternatively, if you can select Choose a component and upload an ASM component from the Software Library.

5. Click Next.

5. On the Select Hosts page, do the following:

1. In the Hosts to Include in Cluster section, click Add and select the target hosts that should form the cluster. To see more details about the selected hosts, click Show Options.

Note:

When you click Add, the Select Target pop-up window appears. On this page, by default, the Show Suitable Hosts option is selected and the table lists only those hosts that are best suited for provisioning. If you do not find the host you want to add, then select Show All Hosts to view a complete list of hosts.

By default, Private Host Name and Virtual Host Name are automatically prefilled with values. Edit them and specify values that match with your environment. Optionally, you can also specify their IP addresses.

Note:

If the prefilled, default values of Private Host Name and Virtual Host Name are incorrect, then see the workaround described in Appendix A, "Troubleshooting Issues".

If you already have these details stored in cluster configuration file, then click Import From File to select that cluster configuration file. This file typically contains information about the new hosts to be added. To understand how a cluster configuration file looks, see the sample file shown in Sample Cluster Configuration File.

To configure the private and public network interfaces, click Select Interfaces. By default, the interfaces that have the same name and subnet for the selected target hosts are displayed. However, you can also choose to view all the interfaces for the selected target hosts. You can either select one of the existing interfaces or specify a completely new one if the interface you want to use does not exist.

2. In the Network Interface Configuration section, review the details of the private and public interfaces.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host(s) Credentials section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

Note:

If you are using vendor clusterware, then ensure that root and the operating system users, such as oracle and crsuser, owning the clusterware and various Oracle homes are a part of the operating system groups required by the vendor clusterware.
For example, if your system uses High Availability Cluster Multiprocessing (HACMP) clusterware, then create or check for the existence of the group hagsuser. Ensure that the relevant operating system users and root user are members of this group.

For more information, refer to the Oracle Clusterware and Oracle Real Application Clusters Installation and Configuration Guide.

2. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

3. Click Next.

7. On the Configure Cluster page, do the following:

1. In the Cluster Name and Location section, review the default name and location details provided for Oracle Clusterware and Oracle RAC Database. While Oracle recommends you to retain the default values, you can always edit them to provide custom values.
For security purposes, the clusterware configuration sets the ownership of Oracle Clusterware home and all its parent directories to be owned by root. Hence, Oracle recommends you to install Oracle Clusterware outside the Oracle base of the Oracle RAC home.

The default cluster name you see here is based on the host cluster name you provided in the Agent Deploy application in Enterprise Manager Grid Control, while deploying Management Agents on a cluster. The scratch location you see here is a temporary location on the target host where temporary files are placed before provisioning and configuring Oracle RAC.

For Additional Parameters, specify any additional parameters you want to run while installing Oracle Clusterware. For example, -debug.

You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

Note:

If this entire section (Cluster Name and Location section) is disabled, then it is clear that each node has a Management Agent, but they were NOT installed using the Cluster Install option available in the Agent Deploy application. To resolve this issue, ensure that you convert the standalone Management Agents to a cluster agent. For more information, see Appendix I, "Converting Standalone Oracle Management Agent to Cluster Agent".

2. In the Database Details section, retain the default selection for creating a starter database.

Note:

If the database creation steps are disabled in the Deployment Procedure, then you will not see this section.

If you want to create a general-purpose database, then leave all the fields in this section blank. Otherwise, provide the required details as described in this step.

If you have a custom response file that already has the options enabled, then select Use response file to create database, and specify the full path to a location where the file is available. The file may be available on the target host, in a shared location accessible from the target host, in the Software Library, or in a location where an existing database is running.

Note:

From the Software Library or from the location where an existing database is running, only a .dbt template file can be used. However, from the target host or a shared location, any template file can be used.

If you do not have a custom response file, then select Do not use response file, and provide the global database name, the credentials, and the additional parameters you want to run while creating the starter database.

Note:

Ensure that the database name you specify is in the format database_name.database_domain. It must have 1 to 8 alphanumeric characters. For example, orcl.mydomain.com. Also note that the credentials you provide are used for SYS, SYSTEM, SYSMAN, and DBSNMP accounts.

If you want to use the structure of an existing database and have a custom template to structure the new database, then in Template File for Database, specify the full path to a location where the template file is available. The file may be available on the target host or on a shared location accessible from the target host.

Note:

If you do not store the response files and templates in a central location, you can always customize the Deployment Procedure to add another step that copies the response file or template to the target host before invoking the configuration tools to create the database.

3. In the Backup and Recovery Details section, retain the default selection, that is, Do not Enable Automated Backups if you do not want to have backups taken.

Alternatively, if you want to enable automated backups, select Enable Automated Backups, specify the full path to a directory location from where the backed-up files can be recovered, and provide the operating system credentials for running the backup job. Note that recovery location is the same location as the backup location because this where the files are backed up and also recovered from.

4. In the ASM Instance Details section (appears only if you had selected to deploy ASM), retain the default selection, that is, Create ASM Instance, and specify the credentials, additional ASM parameters to be used, and the ASM disk string to be used.

Important:

If you are provisioning Oracle Database 10g and Oracle ASM 10g, then ensure that you specify the same password for database as well as ASM.

If you have a custom response file that already has the options enabled, then select Use response file to create ASM database, and specify the full path to a location where the file is available. The file may be availableon the target host or on a shared location accessible fromt he target hosts.

If you do not want to use a response file, then select Do not use response file.

5. Click Next.

8. On the Storage page, do the following:

1. In the Shared Storage Configuration section, provide details about the storage devices and click Next. Specify the partition name and the mount location, and select the mount format and a storage device for storing data. While partition name is the path to the location where the device is installed, mount location is the mount point that represents the partition location.

While configuring the storage device, at a minimum, you must have a partition for at least OCR, Voting Disk, and data files. You cannot designate the same storage device to multiple partitions.

Oracle recommends designating the OCR and the OCR Mirror devices to different partitions. Similarly, Oracle recommends designating the Voting Disk, Voting Disk1, and Voting Disk2 to different partitions.

Before clicking Next, do the following:

- If you want to clear the data on selected raw devices before creating and configuring the cluster, then select Clear raw devices.

- If you have configured only for a few storage devices, then select Do not provision storage for others that you do not want to provision.

- Specify the ASM disk string to be used.

2. In the Options section, select the ASM redundancy mode. The default is None, which requires 7 GB of space. While Normal requires 16 GB of space, High requires 32 GB.

9. (Optional) On the Configuration page, do the following:

Note:

If the configuration steps are disabled in the Deployment Procedure, then you will not see this page.

1. In the Bonding Interface (Private Interconnect) section, select Configure Bonding Interface if you want to configure the bonding interface. To bind the interfaces, specify details as described in Table 5-5.

2. In the Sysctl File Configuration section, select Configure Sysctl file if you want to configure the sysctl.conf file. Specify the mode of editing the system configuration file and the location of the reference system configuration file used for modifying the kernel parameters.
The default mode is append. You can however select edit to modify, and replace to replace the current sysctl.conf file.

Ensure that the reference file you specify is available in a shared location accessible by the Oracle Management Service.

10. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

11. On the Review page, review the details you have provided for provisioning Oracle RAC, and click Submit. If the details you provided seem to be missing on this page, then see the workaround described in Appendix A, "Troubleshooting Issues".

12. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Provisioning Oracle RAC Using Archived Software Binaries

This section describes how you can provision Oracle RAC that is identical to the one available on the installation medium.

This section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 5-4 Deployment Phases Involved in Provisioning Oracle RAC

Phase

Description

Select Source

Allows you to select the generic components for Oracle Clusterware, Oracle RAC, and ASM (optional).

Select Hosts

Allows you to select the target hosts, which should form the cluster, and the network interfaces (public and private).

Credentials and Schedule

Allows you to specify host credentials required for accessing the hosts where Oracle RAC needs to be provisioned, and schedule the Deployment Procedure to run immediately or later.

Configure Cluster

Allows you to specify configuration values for the cluster, create new starter database, and enable backup and recovery options.

Storage

Allows you to specify a partition name and mount location, and select a mount format and storage device for storing data.

Configuration

Allows you to provide additional parameters for configuring the clusterware.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Review

Allows you to review the details you have provided for provisioning Oracle RAC.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites.

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that you upload the software binaries of Oracle RAC database and Oracle Clusterware to the Software Library.
To understand how you can upload the software binaries to the Software library, see Uploading Software Binaries to Oracle Software Library.

- Ensure that the target hosts have the necessary hardware and software required for Oracle RAC. The hardware requirements include setting up of the following:

- Private Network: The network interface cards must be installed on each node and connected to each other.

- Shared Storage Between Nodes: The shared storage is required for OCR, Voting disks and the data files.

- Ensure that the Virtual IPs are set up in the DNS. If you choose to set up the Virtual IPs locally, then the IP addresses can be specified using the Deployment Procedure, and the procedure will set them up for you.

- If you want to use standard response files while provisioning the database, then edit the dbca.rsp file available on the installation medium, and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how response files work, see the Oracle Database Installation Guide for Linux available at one of these URLs:

http://www.oracle.com/pls/db111/homepage

http://www.oracle.com/pls/db102/homepage

http://www.oracle.com/pls/db10g/portal.portal_demo3

To understand how you can upload the response file to the Software Library, see Uploading Database Response File to Oracle Software Library.

- If you want to use a custom template to create a structure for the database, then create a template (a .dbt file), and store it in a location accessible from the target hosts. The file may be on the target host or on a shared location.
To understand how a template can be created and used for creating databases, see Appendix D, "Creating Templates for Oracle Database".

To understand how you can upload the template to the Software Library, see Uploading Database Template File to Oracle Software Library.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.
For more information, see Oracle Clusterware Installation Guide available at:

http://www.oracle.com/pls/db111/homepage

- Ensure that the User IDs for operating system users and the Group IDs for operating system groups are identical on all nodes of the cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle RAC database.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a fresh Oracle RAC installation, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedure subtab, from the table, select one of the following, and click Schedule Deployment.

1. To run the Deployment Procedure on UNIX platforms, Select Oracle Clusterware / RAC Provisioning For UNIX.

2. To run the Deployment Procedure on Microsoft Windows platforms, select Oracle Clusterware / RAC Provisioning For Windows.

Enterprise Manager Grid Control displays the Select Source page of the Deployment Procedure.

4. On the Select Source page, do the following:

1. In the Select Source section, select Select from Software Library.

2. In the Source for Clusterware section, click the torch icon and select the generic component that has the software binaries of Oracle Clusterware. Ensure that you select only components that are in "Ready" status. Once you select the component name, the application automatically displays the component location.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

3. In the Source for RAC section, click the torch icon and select the generic component that has the software binaries of Oracle Database. Ensure that you select only components that are in "Ready" status. Once you select the component name, the application automatically displays the component location.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

4. (Optional) In the Source for ASM section, do one of the following:
If you do not want to deploy ASM, then retain the default selection, that is, Do not Provision ASM.

If you want to deploy ASM in the same Oracle home as the Oracle RAC, then select Use the same source as the RAC home. Alternatively, if you can select Choose a component and upload an ASM component from the Software Library.

5. Click Next.

5. On the Select Hosts page, do the following:

1. In the Hosts to Include in Cluster section, click Add and select the target hosts that should form the cluster. To see more details about the selected hosts, click Show Options.

Note:

When you click Add, the Select Target pop-up window appears. On this page, by default, the Show Suitable Hosts option is selected and the table lists only those hosts that are best suited for provisioning. If you do not find the host you want to add, then select Show All Hosts to view a complete list of hosts.

By default, Private Host Name and Virtual Host Name are automatically prefilled with values. Edit them and specify values that match with your environment. Optionally, you can also specify their IP addresses.

Note:

If the prefilled, default values of Private Host Name and Virtual Host Name are incorrect, then see the workaround described in Appendix A, "Troubleshooting Issues".

If you already have these details stored in a cluster configuration file, then click Import From File to select that cluster configuration file. This file typically contains information about the new hosts to be added. To understand how a cluster configuration file looks, see the sample file shown in Sample Cluster Configuration File.

To configure the private and public network interfaces, click Select Interfaces. By default, the interfaces that have the same name and subnet for the selected target hosts are displayed. However, you can also choose to view all the interfaces for the selected target hosts. You can either select one of the existing interfaces or specify a completely new one if the interface you want to use does not exist.

2. In the Network Interface Configuration section, review the details of the private and public interfaces.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host(s) Credentials section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

Note:

If you are using vendor clusterware, then ensure that root and the operating system users, such as oracle and crsuser, owning the clusterware and various Oracle homes are a part of the operating system groups required by the vendor clusterware.
For example, if your system uses High Availability Cluster Multiprocessing (HACMP) clusterware, then create or check for the existence of the group hagsuser. Ensure that the relevant operating system users and root user are members of this group.

For more information, refer to the Oracle Clusterware and Oracle Real Application Clusters Installation and Configuration Guide.

2. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

3. Click Next.

7. On the Configure Cluster page, do the following:

1. In the Cluster Name and Location section, review the default name and location details provided for Oracle Clusterware and Oracle RAC Database. While Oracle recommends you to retain the default values, you can always edit them to provide custom values.
For security purposes, the clusterware configuration sets the ownership of Oracle Clusterware home and all its parent directories to be owned by root. Hence, Oracle recommends you to install Oracle Clusterware outside the Oracle base of the Oracle RAC home.

The default cluster name you see here is based on the host cluster name you provided in the Agent Deploy application in Enterprise Manager Grid Control, while deploying Management Agents on a cluster. The scratch location you see here is a temporary location on the target host where temporary files are placed before provisioning and configuring Oracle RAC.

For Additional Parameters, specify any additional parameters you want to run while installing Oracle Clusterware. For example, -debug.

You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation. Using these parameters, you can even change the installation type of the database. For example, INSTALL_TYPE=SE. Ensure that the parameters are separated by white space.

Note:

If this entire section (Cluster Name and Location section) is disabled, then it is clear that each node has a Management Agent, but they were NOT installed using the Cluster Install option available in the Agent Deploy application. To resolve this issue, ensure that you convert the standalone Management Agents to a cluster agent. For more information, see Appendix I, "Converting Standalone Oracle Management Agent to Cluster Agent".

2. In the Database Details section, retain the default selection for creating a starter database.

Note:

If the database creation steps are disabled in the Deployment Procedure, then you will not see this section.

If you want to create a general-purpose database, then leave all the fields in this section blank. Otherwise, provide the required details as described in this step.

If you have a custom response file that already has the options enabled, then select Use response file to create database, and specify the full path to a location where the file is available. The file may be available on the target host, in a shared location accessible from the target host, in the Software Library, or in a location where an existing database is running.

Note:

From the Software Library or from the location where an existing database is running, only a .dbt template file can be used. However, from the target host or a shared location, any template file can be used.

If you do not have a custom response file, then select Do not use response file, and provide the global database name, the credentials, and the additional parameters you want to run while creating the starter database.

Note:

Ensure that the database name you specify is in the format database_name.database_domain. It must have 1 to 8 alphanumeric characters. For example, orcl.mydomain.com. Also note that the credentials you provide are used for SYS, SYSTEM, SYSMAN, and DBSNMP accounts.

If you want to use the structure of an existing database and have a custom template to structure the new database, then in Template File for Database, specify the full path to a location where the template file is available. The file may be available on the target host or on a shared location accessible from the target host.

Note:

If you do not store the response files and templates in a central location, you can always customize the Deployment Procedure to add another step that copies the response file or template to the target host before invoking the configuration tools to create the database.

3. In the Backup and Recovery Details section, retain the default selection, that is, Do not Enable Automated Backups if you do not want to have backups taken.

Alternatively, if you want to enable automated backups, select Enable Automated Backups, specify the full path to a directory location from where the backed-up files can be recovered, and provide the operating system credentials for running the backup job. Note that recovery location is the same location as the backup location because this where the files are backed up and also recovered from.

4. In the ASM Instance Details section (appears only if you had selected to deploy ASM), retain the default selection, that is, Create ASM Instance, and specify the credentials, additional ASM parameters to be used, and the ASM disk string to be used.

Important:

If you are provisioning Oracle Database 10g and Oracle ASM 10g, then ensure that you specify the same password for database as well as ASM.

If you have a custom response file that already has the options enabled, then select Use response file to create ASM database, and specify the full path to a location where the file is available. The file may be available on the target host or on a shared location accessible from the target hosts.

If you do not want to use a response file, then select Do not use response file.

5. Click Next.

8. On the Storage page, do the following:

1. In the Shared Storage Configuration section, provide details about the storage devices and click Next. Specify the partition name and the mount location, and select the mount format and a storage device for storing data. While partition name is the path to the location where the device is installed, mount location is the mount point that represents the partition location.

While configuring the storage device, at a minimum, you must have a partition for at least OCR, Voting Disk, and data files. You cannot designate the same storage device to multiple partitions.

Oracle recommends designating the OCR and the OCR Mirror devices to different partitions. Similarly, Oracle recommends designating the Voting Disk, Voting Disk1, and Voting Disk2 to different partitions.

Before clicking Next, do the following:

- If you want to clear the data on selected raw devices before creating and configuring the cluster, then select Clear raw devices.

- If you have configured only for a few storage devices, then select Do not provision storage for others that you do not want to provision.

- Specify the ASM disk string to be used.

2. In the Options section, select the ASM redundancy mode. The default is None, which requires 7 GB of space. While Normal requires 16 GB of space, High requires 32 GB.

9. (Optional) On the Configuration page, do the following:

Note:

If the configuration steps are disabled in the Deployment Procedure, then you will not see this page.

1. In the Bonding Interface (Private Interconnect) section, select Configure Bonding Interface if you want to configure the bonding interface. To bind the interfaces, specify details as described in Table 5-5.

2. In the Sysctl File Configuration section, select Configure Sysctl file if you want to configure the sysctl.conf file. Specify the mode of editing the system configuration file and the location of the reference system configuration file used for modifying the kernel parameters.
The default mode is append. You can however select edit to modify, and replace to replace the current sysctl.conf file.

Ensure that the reference file you specify is available in a shared location accessible by the Oracle Management Service.

10. On the Configure Oracle Home page, do the following:

1. If the host where the database is being provisioned 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being provisioned 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being provisioned 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

11. On the Review page, review the details you have provided for provisioning Oracle RAC, and click Submit. If the details you provided seem to be missing on this page, then see the workaround described in Appendix A, "Troubleshooting Issues".

12. After the Deployment Procedure ends successfully, instrument the database to collect configuration information. For information about instrumenting the database, see Instrumenting the Database for Configuration Collections.

Table 5-5 Configuration Page - Element Description

Element

Description

Bonding Device Name

Specify the name of the bond to be created. For example, bond0

Subnet Mask

Specify the subnet mask for the IP address. For example, 255.255.255.0

Default Gateway

Specify the default gateway for the bonding device. For example, 10.1.2.3

DNS Servers

Specify the Domain Name Server (DNS) list for the bonding device. For multiple DNS servers, the values should be comma- separated. Default values are picked up from the /etc/resolv.conf file. Entries provided here will be appended.

Slave Devices List

Specify the list of slave devices for the bonding device. For multiple slave devices, the values should be comma-separated. For example, eth1,eth2,eth3.

Bonding Mode

Specifies one of four policies allowed for the bonding module. Acceptable values for this parameter are:

- 0 (Balance-rr)— Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available.

- 1 (Active-backup)— Sets an active-backup policy for fault tolerance. Transmissions are received and sent out through the first available bonded slave interface. Another bonded slave interface is only used if the active bonded slave interface fails.

- 2 (Balance-xor)— Sets an XOR (exclusive-or) policy for fault tolerance and load balancing. Using this method, the interface matches up the incoming request's MAC address with the MAC address for one of the slave NICs. Once this link is established, transmissions are sent out sequentially beginning with the first available interface.

- 3 (Broadcast)— Sets a round-robin policy for fault tolerance and load balancing. Transmissions are send out sequentially on each bonded slave interface beginning with the first one available.

Domain Name

Specify the domain name for the assigned host name. For example, foo.com

Primary Slave Device

Specify the interface name, such as eth0, of the primary device. The primary device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load. This setting is only valid when the bonding interface is in active-backup mode.

ARP Interval

Specify (in milliseconds) how often ARP monitoring occurs. If using this setting while in mode 0 or 2 (the two load-balancing modes) the network switch must be configured to distribute packets evenly across the NICs. The value is set to 0 by default, which disables it.

MII Interval

Specify (in milliseconds) how often MII link monitoring occurs. This is useful if high availability is required because MII is used to verify that the NIC is active to verify that the driver for a particular NIC supports the MII tool. If using a bonded interface for high availability, the module for each NIC must support MII. Setting the value to 0 (the default), turns this feature off. When configuring this setting, a good starting point for this parameter is 100.

MII Interval Down Delay

Specify (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the miimon parameter. The value is set to 0 by default, which disables it.

MII Interval Up Delay

Specify (in milliseconds) how long to wait before enabling a link. The value must be a multiple of the value specified in the miimon parameter. The value is set to 0 by default, which disables it.

NTP Server

Specify the NTP server for the assigned host name. For example, 1.2.3.4.

Sample Cluster Configuration File

The following shows the contents of a typical cluster configuration file:

# Cluster Configuration file

# Node information

# Public Node Name

Private Node Name

Private IP (Optional)

Virtual Host Name

Virtual IP (Optional)

node1.domain.com

node1-priv.domain.com

-

node1-vip.domain.com

-

node2.domain.com

node2-priv.domain.com

10.2.109.103

node2-vip.domain.com

134.2.109.103

6 Extending Oracle Real Application Clusters

This chapter explains how you can extend and scale up an existing Oracle RAC stack (Oracle Clusterware, Oracle ASM, Oracle RAC database), in a single click. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Supported Releases

- Extending Oracle RAC

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in extending an existing Oracle RAC stack. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully extend an existing Oracle RAC. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 6-1 Getting Started with Extending Oracle RAC

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for extending Oracle RAC. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

Knowing About The Supported Releases

Know what releases of Oracle RAC can be extended by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

To learn about the deployment phases involved in extending Oracle RAC, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for extending Oracle RAC, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully extend an existing Oracle RAC.

To extend Oracle RAC, follow the steps explained in Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedure for extending Oracle RAC:

- One Click Extend Cluster Database

Supported Releases

Using this Deployment Procedure, you can extend the following releases of Oracle RAC:

- Oracle Database 10g Release 2 (10.2.x.x)

- Oracle Database 11g Release 1 (11.1.x.x)

Extending Oracle RAC

This section describes how you can extend an existing Oracle RAC to include as many additional nodes as you need, in just one click.

This section covers the following:

- Deployment Phases

- Prerequisites

- Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 6-2 Deployment Phases Involved in Extending Oracle RAC

Phase

Description

Extend RAC

Allows you to select an existing Oracle RAC you want to extend, add new nodes you want to include to it, specify credentials, and schedule the Deployment Procedure to run immediately or later. Also allows you to run prerequisite checks and fix-ups on the selected nodes.

Review

Allows you to review the details you have provided for extending the Oracle RAC instance.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that oinstall and dba groups are available.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that the credentials being used to run this operation along with the group ID are the same on all nodes of the selected cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that the shared storage used for existing cluster nodes are accessible to the nodes you want to add.

- Ensure that the umask value on the target host is 022.

Procedure

To extend an existing Oracle RAC, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select One Click Extend Cluster Database. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Extend Real Application Clusters page.

4. On the Extend Real Application Clusters page, do the following:

1. In the Select Real Application Clusters (RAC) section, select the Oracle RAC you want to extend. The associated clusterware and Automatic Storage Management (ASM) also get extended if they are not already existing.

You can use the Search section to search for a particular Oracle RAC. From the Search list, select the target type based on which you want to search, and click Go. You can use wildcards such as % and *.

Note:

If the cluster database you want to extend does not appear on this page, then:

- Specify the clusterware home location for the cluster target in Enterprise Manager Grid Control. In Grid Control, click the Targets tab, and then click the All Targets subtab. On the All Targets page, from the Search list, select Cluster and click Go. From the results table, select the cluster for which you want to specify the clusterware home location. On the Cluster Home page, in the Related Links section, click Monitoring Configuration. On the Configure Target page, specify the clusterware home location and click Update.

- Configure Enterprise Manager Grid Control settings to display them. In Grid Control, click the Deployments tab, and on the Deployments page, in the Configuration section, click Refresh Host Configuration. On the following page, from the Available Hosts pane, select the hosts and add them to the Selected Hosts pane. Then, click Refresh Hosts and wait for the job to succeed. Return to this Deployment Procedure page and run the search query again to view the hosts in the search results.

2. In the Reference Host Options section, from the Reference Host list, select a host that you want to use as the primary host for performing this operation. Reference Host is the host that is selected for creation of clone archives and then transferred to the new target nodes being added.

For Working directory, specify the full path to an existing directory on the selected host that can be used for staging files for cloning. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure. Ensure that the working directory is NOT shared on the nodes.

For Files To Exclude, for each Oracle home, specify the files you want to exclude while performing this operation. Note that any file or folder corresponding to the regular expressions provided here will be excluded.

3. In the Oracle Home Shared Storage Options section, select the Oracle home locations that are on shared storage.

4. In the Select New Nodes section, click Add to add new nodes that you want to include to the selected Oracle RAC. After adding the node, specify the virtual node name for each new node and verify the values displayed by default.

Note:

Ensure that you select nodes that are monitored by Oracle Management Agents 10g Release 5 (10.2.0.5) or higher.

Optionally, you can click Show Options to specify Private Node Name, Private IP, Virtual IP, and Working Directory. Private Node Name and Private IP are required only if you want to set up a private network as part of the procedure.Virtual Node Name and Virtual IP are required only if they are fixed and not DHCP-based. If the node is already part of the Oracle Real Application Clusters (RAC) system, it will be ignored. If the node is part of the Oracle Clusterware, the private network and virtual host information will be ignored. For Working Directory, ensure that the location you specify is NOT shared on the nodes.

If you already have these details stored in cluster configuration file, then click Import From File to select that cluster configuration file. This file typically contains information about the new nodes to be added. It may also include information about the private node name, private IP address, virtual host name, and virtual IP address to which the Oracle RAC should be extended.

5. In the User Credentials (Override Preferred Credentials) section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

Note:

If you are using vendor clusterware, then ensure that root and the operating system users, such as oracle and crsuser, owning the clusterware and various Oracle homes are a part of the operating system groups required by the vendor clusterware.
For example, if your system uses High Availability Cluster Multiprocessing (HACMP) clusterware, then create or check for the existence of the group hagsuser. Ensure that the relevant operating system users and root user are members of this group.

For more information, refer to the Oracle Clusterware and Oracle Real Application Clusters Installation and Configuration Guide.

6. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

7. In the Prerequisites (Run Prerequisites and Fix-Ups) section, by default, Skip prerequisites and fix-ups is not selected and therefore, the deployment procedure runs the prerequisite checks and fix-ups on the selected nodes.

The prerequisite checks are required to ensure that the nodes meet all the requirements of this operation and are ready to be added to the cluster. The option is not selected assuming that you have not already run the prerequisite checks on the selected nodes beforehand.

If you have already run the prerequisite checks on the selected nodes and want the deployment procedure to skip running them all over again, then select Skip prerequisites and fix-ups.

If you have never run prerequisite checks on the selected nodes and if you want the deployment procedure to run them, then deselect Skip prerequisites and fix-ups. The deployment procedure runs the prerequisite checks, fixes issues if there are any, and then proceeds with the extend cluster operation.

If you want to check the prerequisites only but not proceed with the operation at this point, then click Run Prerequisites Only.

8. Click Review.

5. On the Review page, review the details you have provided for extending Oracle RAC, and click Submit.

Note:

When you run the Deployment Procedure on Linux Itanium x64, if the CVU Run to verify shared locations step fails, then manually fix it before proceeding to the next step. No automated fix-ups are available for this platform.

7 Deleting or Scaling Down Oracle Real Application Clusters

This chapter describes how you can delete or scale down Oracle RAC. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Core Components Deleted

- Supported Releases

- Deleting the Entire Oracle RAC

- Scaling Down Oracle RAC by Deleting Some of Its Nodes

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in deleting or scaling down an existing Oracle RAC stack. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully delete or scale down an existing Oracle RAC stack. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 7-1 Getting Started with Deleting or Scaling Down an Existing Oracle RAC

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for deleting or scaling down an existing Oracle RAC. Know how the Deployment Procedure functions, what use cases it covers, what core components it deletes or scales down, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

To learn about the core components that are deleted or scaled down, see Core Components Deleted.

Knowing About The Supported Releases

Know what releases of Oracle RAC can be deleted or scaled down by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for deleting and scaling down an existing Oracle RAC. Select the use case that best matches your requirement.

- To learn about deleting the entire Oracle RAC stack, see Deleting the Entire Oracle RAC.

- To learn about scaling down an existing Oracle RAC stack by deleting one or more of its own nodes, see Scaling Down Oracle RAC by Deleting Some of Its Nodes.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in deleting an entire Oracle RAC stack, see Deployment Phases.

- To learn about the deployment phases involved in scaling down an existing Oracle RAC stack by deleting one or more of its own nodes, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about the prerequisites for deleting an entire Oracle RAC stack, see Prerequisites.

- To learn about the prerequisites for scaling down an existing Oracle RAC stack by deleting one or more of its own nodes, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully delete or scale down an existing Oracle RAC.

- To delete an entire Oracle RAC stack, follow the steps explained in Procedure.

- To scale down an existing Oracle RAC stack by deleting one or more of its own nodes, follow the steps explained in Procedure.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning Oracle RAC:

- Delete/Scale down Oracle Real Application Clusters

This Deployment Procedure enables you to desacle an entire cluster database stack (Oracle Clusterware, Oracle ASM, and Oracle RAC database) or one or more nodes of an Oracle RAC cluster, in a single click. This includes cluster databases of various releases as described in Supported Releases, and across different platforms.

The procedure can descale or delete clusters that have:

- Oracle CRS, Oracle ASM, and Oracle Database homes owned by the same or different users.

- Separate Oracle CRS, Oracle ASM, and Oracle Database homes present on a shared storage, which is shared by all member nodes.

- Partially provisioned or failed installations of Oracle RAC clusters (may include one or more tiers of the stack installed. For example, cleanup after the clusterware installation failed or cleanup when the clusterware was only partially provisioned).

- Nodes that were reimaged or shut down, and the existing configuration has to be resolved to remove all references to this node in Enterprise Manager Grid Control.

Core Components Deleted

Using this Deployment Procedure, you can delete either a node of an existing Oracle RAC or the entire Oracle RAC. As a result, the Deployment Procedure deinstalls the Oracle Clusterware, listeners, and Oracle RAC and ASM homes associated with the nodes selected for deletion.

Supported Releases

Using this Deployment Procedure, you can delete or scale down the following releases of Oracle RAC:

- Oracle Database 10g Release 2 (10.2.x.x)

- Oracle Database 11g Release 1 (11.1.x.x)

Deleting the Entire Oracle RAC

This section describes how you can delete the entire Oracle RAC. In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 7-2 Deployment Phases Involved in Deleting the Entire Oracle RAC

Phase

Description

Delete/Scale Down Oracle RAC

Allows you to select an existing Oracle RAC and all the nodes you want to delete from it, specify Oracle home credentials, schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for deleting the entire Oracle RAC instance.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that oinstall and dba groups are available.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that the credentials being used to run this operation along with the group ID are the same on all nodes of the selected cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Procedure

To delete the entire Oracle RAC, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Delete/Scale down Oracle Real Application Clusters. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Delete/Scale down Oracle Real Application Clusters page.

4. On the Delete/Scale down Oracle Real Application Clusters page, do the following:

1. In the Select Cluster section, click the torch icon for Select Cluster and select an Oracle Clusterware instance that you want to delete. Along with the selected Oracle Clusterware, the associated Oracle RAC and ASM instances will also be deleted. The table displays details about the member nodes that are part of the selected Oracle Clusterware.

Note:

When you use the torch icon to search for Oracle Clusterware, if you do not find the Oracle Clusterware that you are looking for, then from the tip mentioned below the table, click here to manually provide details about that clusterware and search for it.

This is particularly useful when you want to delete partially-provisioned or configured Oracle Clusterware instances because, by default, when you click the torch icon, only the fully-provisioned clusterware instances appear for selection. In this case, to search, select, and delete the partially-provisioned instances, click here, and in the Enter Cluster Details window, manually provide details about the cluster node that contains the partially-provisioned instance and click OK. You can then select the host that appears in the Select Nodes to Delete section and mark for deletion.

2. In the Reference Host Options section, from the Cluster Node list, select a node that you want to use as the primary node for all cleanup operations.

For Working directory, specify the full path to an existing directory on the selected node that can be used for staging files temporarily.

3. In the Select Nodes to Delete section, click Mark all to select all the nodes for deletion. On clicking Mark all, you should see a cross icon against all the nodes in the Deletion column. These cross icons indicate that the nodes have been selected for deletion.

4. In the User Credentials (Override Preferred Credentials) section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Review.

5. On the Review page, review the details you have provided for deleting Oracle RAC, and click Submit.

Scaling Down Oracle RAC by Deleting Some of Its Nodes

This section describes how you can scale down Oracle RAC by deleting one or more nodes that are part of it, and also other nodes that are part of it but do not appear as targets in Enterprise Manager Grid Control. In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 7-3 Deployment Phases Involved in Scaling Down an Existing Oracle RAC

Phase

Description

Delete/Scale Down Oracle RAC

Allows you to select an existing Oracle RAC and the nodes you want to delete from it, specify credentials, and schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for scaling down the Oracle RAC instance.

Prerequisites

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that oinstall and dba groups are available.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that the credentials being used to run this operation along with the group ID are the same on all nodes of the selected cluster.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Procedure

To scale down Oracle RAC by deleting one or more nodes that are part of it, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click RAC Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Delete/Scale down Oracle Real Application Clusters. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Delete/Scale down Oracle Real Application Clusters page.

4. On the Delete/Scale down Oracle Real Application Clusters page, do the following:

1. In the Select Cluster section, click the torch icon for Select Cluster and select an Oracle Clusterware instance that you want to scale down. Along with the selected Oracle Clusterware, the associated Oracle RAC and ASM instances will also be deleted. The table displays details about the member nodes that are part of the selected Oracle Clusterware.

Note:

When you use the torch icon to search for Oracle Clusterware, if you do not find the Oracle Clusterware that you are looking for, then you can manually provide details about that clusterware and search for it. To do so, from the tip mentioned below the table, click here.

2. In the Reference Host Options section, from the Cluster Node list, select a node that you want to use as the primary node for all cleanup operations.

For Working directory, specify the full path to an existing directory on the selected node that can be used for staging files.

3. In the Select Nodes to Delete section, select the nodes you want to delete, and click Mark for delete. On clicking Mark for delete, you should see a cross icon against the selected nodes in the Deletion column. These cross icons indicate that the nodes have been selected for deletion.
If you do not see the nodes that are part of the cluster, then click Add more nodes to add those nodes so that nodes that do not appear as targets in Enterprise Manager Grid Control also are selected for deletion.

If you want to deselect a node, click Unmark. If you want to select all nodes at a time, click Mark all, and if you want to deselect all nodes, click Unmark all.

4. In the User Credentials (Override Preferred Credentials) section, retain the default selection, that is, Use Preferred Credentials.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Different for each Oracle Home if you want to use different operating system credentials for each Oracle home, or Same for all Oracle Homes if you want to use the same set of credentials for all Oracle homes. Depending on the selection you make, specify the credentials. Ensure that the users belong to the same group (dba/oinstall).

5. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

6. Click Review.

5. On the Review page, review the details you have provided for deleting or scaling down Oracle RAC, and click Submit.

8 Provisioning Oracle Database Replay Client

This chapter explains how you can provision Oracle Database Replay Client. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Cloning a Running Oracle Database Replay Client

- Provisioning Oracle Database Replay Client Using Gold Image

- Provisioning Oracle Database Replay Client from Staged Location

- Provisioning Oracle Database Replay Client Using Archived Software Binaries

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle Database Replay Client. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Oracle Database Replay Client. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 8-1 Getting Started with Provisioning Oracle Database Replay Client

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle Database Replay Client. Know how the Deployment Procedure functions, what use cases it covers, what core components it deletes or scales down, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases of Oracle Database Replay Client can be provisioned by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Oracle Database Replay Client. Select the use case that best matches your requirement.

- To learn about cloning an existing Oracle Database Replay Client, see Cloning a Running Oracle Database Replay Client.

- To learn about provisioning Oracle Database Replay Client using a gold image, see Provisioning Oracle Database Replay Client Using Gold Image.

- To learn about provisioning Oracle Database Replay Client from a staged location, see Provisioning Oracle Database Replay Client from Staged Location.

- To learn about provisioning a standalone Oracle Database Replay Client, see Provisioning Oracle Database Replay Client Using Archived Software Binaries.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in cloning an existing Oracle Database Replay Client, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle Database Replay Client using a gold image, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle Database Replay Client from a staged location, see Deployment Phases.

- To learn about the deployment phases involved in provisioning a standalone Oracle Database Replay Client, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about the prerequisites for cloning an existing Oracle Database Replay Client, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle Database Replay Client using a gold image, see Prerequisites.

- To learn about the prerequisites for provisioning Oracle Database Replay Client from a staged location, see Prerequisites.

- To learn about the prerequisites for provisioning a standalone Oracle Database Replay Client, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle Database Replay Client.

- To clone an existing Oracle Database Replay Client, follow the steps explained in Cloning Procedure.

- To provision Oracle Database Replay Client using a gold image, follow the steps explained in Provisioning Procedure.

- To provision Oracle Database Replay Client from a staged location, follow the steps explained in Provisioning Procedure.

- To provision a standalone Oracle Database Replay Client, follow the steps explained in Provisioning Procedure.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning Oracle RAC:

- Oracle Database Replay Client Provisioning

This Deployment Procedure is much like the Oracle Database Provisioning Deployment Procedure that helps you deploy a standalone Oracle Database across your enterprise configuration.

The Oracle Database Replay Client you want to provision may be available in different formats such as an installer in the installation medium, a running instance on a host monitored by Enterprise Manager Grid Control, or even a gold image in Oracle Software Library (Software Library). Using this Deployment Procedure, you can provisioning any of these formats.

For example, if you want to have a fresh installation of Oracle Database Replay Client, the recommended option is to provision the database replay client from an installation medium. However, if you want to have a copy of a running instance that is stable and has all the latest patches applied, the recommended option is to clone that existing instance so that you retain the same configuration settings.

Supported Releases

Using these Deployment Procedures, you can provision the following releases of Oracle Database Replay Client:

- Oracle Database 10g Release 2 (10.2.0.4 and higher)

- Oracle Database 11g Release 1 (11.1.0.6 and higher)

Cloning a Running Oracle Database Replay Client

This section describes how you can clone an existing Oracle Database Replay Client that is running on a host monitored by Enterprise Manager Grid Control.

This option is best suited when you have a running instance of Oracle Database Replay Client that is stable and has all the latest patches applied, and you want to make identical copies of it on multiple hosts. However, the risk involved in using an existing instance is that the instance may be deleted or deinstalled anytime without prior notice, and as a result, the Deployment Procedure may fail. Therefore, use this option when you know that the running instance is available for cloning.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Cloning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 8-2 Deployment Phases Involved in Cloning Oracle Database Replay Client

Phase

Description

Select Source and Destination

Allows you to select an existing database replay client installation that you want to clone, specify the target hosts on which you want to clone, include additional parameters you want to run, and schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for cloning the database replay client.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database Replay Client.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Cloning Procedure

To clone an existing instance of Oracle Database Replay Client, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Replay Client Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page of the Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Existing Database Replay Client Installation. Then click the torch icon for Source Host and select the host on which the existing Oracle Database Replay Client is running.
In the Source Host Details section, by default, Oracle Home, Working Directory, and Files to exclude are prefilled. Oracle Home shows where the existing instance is installed, but this is a non-editable field. For Working Directory, specify the full path to a directory on source host where the files related to cloning can be staged temporarily. For Files to exclude, specify file names that must not be cloned to the source host. Use a comma to separate the file name, and use the wildcard (*) to indicate all files with the same extension. For example, *.trc. Note that any file or folder corresponding to the regular expressions provided here will be excluded.

In the Source Host Credentials section, select Use Preferred Credentials to use the credentials stored in the Management Repository.

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to clone the existing instance of Oracle Database Replay Client.

By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the Advanced section, specify any additional parameters you want to run while installing the Oracle Database Replay Client. For example, -debug, -invptrloc. You can specify any Oracle Universal Installer (OUI) parameter that can be used in this provisioning operation.
While installing software binaries from an existing Oracle Database Replay Client location, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Continue.

5. On the Review page, review the details you have provided for provisioning an Oracle Database Replay Client, and click Submit.

Provisioning Oracle Database Replay Client Using Gold Image

This section describes how you can provision a gold image of Oracle Database Replay Client from the Software Library.

This option is best suited when you have a copy of a stable, well-tested, and patched Oracle Database Replay Client stored in the Software Library. This option scores over a fresh installation because you save time in patching and testing a fresh instance.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 8-3 Deployment Phases Involved in Provisioning Gold Image from Software Library

Phase

Description

Select Source and Destination

Allows you to select the gold image from the Software Library, specify the target hosts on which you want to deploy the gold image, include additional parameters you want to run, and schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for deploying the gold image.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that you create a gold image of an existing Oracle Database Replay Client.
To understand how you can create a gold image, see Creating Gold Image.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database Replay Client.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a gold image of Oracle Database Replay Client from the software library, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Replay Client Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page of the Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Software Library. Then click the torch icon for Component and select the generic component that has the gold image. Ensure that you select only components that are in "Ready" status.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the gold image of Oracle Database Replay Client.

By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the section, specify any additional parameters you want to run while installing the Oracle Database Replay Client. For example, -debug, -invPtr. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.
While installing the Oracle Database Replay Client location, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Continue.

5. On the Review page, review the details you have provided for provisioning an Oracle Database Replay Client, and click Submit.

Provisioning Oracle Database Replay Client from Staged Location

This section describes how you can provision a gold image of Oracle Database Replay Client from a staged location.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 8-4 Deployment Phases Involved in Provisioning Gold Image from Staged Location

Phase

Description

Select Source and Destination

Allows you to select the gold image from a staged location, specify the target hosts on which you want to deploy the gold image, include additional parameters you want to run, and schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for deploying the gold image.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database Replay Client.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a gold image of Oracle Database Replay Client from the software library, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page of the Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, select Staging Location, and then select Gold Image. Click the torch icon for Select Host and select the host on which the gold image is staged. Then click the torch icon for Stage Location and select the location where the gold image is staged.

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the gold image of Oracle Database Replay Client.

By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the section, specify any additional parameters you want to run while installing the Oracle Database Replay Client. For example, -debug, -invPtr. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.
While installing, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Continue.

5. On the Review page, review the details you have provided for provisioning an Oracle Database Replay Client, and click Submit.

Provisioning Oracle Database Replay Client Using Archived Software Binaries

This section describes how you can provision Oracle Database Replay Client that is identical to the one available on the installation medium.

This option is best suited when you want a completely new installation to be provisioned across multiple hosts. Of course, understandably, this is a fresh installation and you will have to update it with all the latest patches that have been released so far.

Note:

The Oracle Database Replay Client version to be used for replaying workload must be the same version as the version of the test database on which the workload has to be replayed. Oracle Database Replay Client is supported in Oracle Database 10g Release 4 (10.2.0.4) and higher. While you can use archived software binaries for installing Oracle Database Replay Client of Oracle Database 11g Release 1 (11.1.0.6), for test database versions 10.2.0.4, 10.2.0.5 (future) and 11.1.0.7, you must create a gold image of the respective versions of Oracle Database Replay Client homes and use the same.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 8-5 Deployment Phases Involved in Provisioning Oracle Database Replay Client

Phase

Description

Select Source and Destination

Allows you to select a generic component from the Software Library, specify the target hosts on which you want to deploy the database replay client, include additional parameters you want to run, and schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for deploying the database replay client.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Note:

If you want to create a component for the software binaries of Oracle Database Replay Client, then before you access the Software Library, see My Oracle Support note 815567.1. This note explains the different requirements for each OS platform prior to using the media with Grid Control Deployment Procedure.

- Ensure that you upload the software binaries of Oracle Database Replay Client to the Software Library.
To understand how you can upload the software binaries to the Software library, see Uploading Software Binaries to Oracle Software Library.

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- Ensure that operating system users such as oracle and crsuser are available on all nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

- Ensure that you use an operating system user that has write permission on the staging areas used for placing software binaries of Oracle Database Replay Client.
Deployment Procedures allow you to use staging locations for quick file-transfer of binaries and prevent high traffic over the network. While providing a staging location, ensure that the operating system user you use has write permission on those staging locations. For information about staging area, see Staging Area.

- Ensure that the umask value on the target host is 022.

Provisioning Procedure

To provision a fresh Oracle Database Replay Client, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Database Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Database Replay Client Provisioning. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Select Source and Destination page of the Deployment Procedure.

4. On the Select Source and Destination page, do the following:

1. In the Select Source section, retain the default selection, that is, Software Library. Then click the torch icon for Component and select the generic component that has the software binaries of Oracle Database Replay Client. Ensure that you select only components that are in "Ready" status.

Note:

If you do not see the required component in the Software Library, then follow the workaround described in Appendix A, "Troubleshooting Issues".

2. In the Specify Destination Host Settings section, click Add and select the target hosts on which you want to install the Oracle Database Replay Client.

By default, Oracle Base, Oracle Home, and Working Directory are prefilled with sample values. Edit them and specify values that match with your environment and standards. If the directories you specify do not exist on the target hosts, then they will be created by the Deployment Procedure.

From the Credentials list, retain the default selection, that is, Preferred, so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

If you have selected multiple hosts, then from the Path list, select Same for all hosts if you want to use the same path across hosts, or select Different for each host if you want to use different paths for each host.

3. (Optional) In the section, specify any additional parameters you want to run while installing the Oracle Database Replay Client. For example, -debug, -invptrloc. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.
While installing software binaries from the Software Library, if you want to also stage them to a shared location, then select Stage to Shared Location and specify a location that is shared across all destination hosts. This staged location can also act as a source for future deployments.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Continue.

5. On the Review page, review the details you have provided for provisioning an Oracle Database Replay Client, and click Submit.

Part III

Provisioning Linux Operating System

This part describes how you can provision Linux operating system on bare metal servers and virtual servers.

This part contains the following chapters:

- Chapter 9, "Provisioning Linux Operating System"

9 Provisioning Linux Operating System

This chapter explains how you can provision Linux on bare metal servers and virtual servers using the bare metal application. In particular, this chapter covers the following. In particular, this chapter contains the following sections:

- Getting Started

- Supported Releases

- Provisioning Bare Metal Boxes

- Provisioning Oracle VM Servers

- Provisioning Single Server Images

Tip:

Before you begin provisioning of Linux on bare metal boxes, make sure that preferred credentials are set for the Stage server and Reference Host. If not, follow instructions in Setting Up Preferred Credentials for Bare Metal Provisioning in Enterprise Manager to set up preferred credentials.

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Linux operating system. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Linux operating system. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 9-1 Getting Started with Provisioning Linux Operating System

Step

Description

Reference Links

Knowing About The Supported Releases

Know what releases of Linux are supported by the Deployment Procedure.

To learn about the releases supported for Linux Provisioning, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Linux. Select the use case that best matches your requirement.

- To learn about provisioning bare metal boxes, see Provisioning Bare Metal Boxes.

- To learn about provisioning Oracle VM Servers, see Provisioning Oracle VM Servers.

- To learn about provisioning Single Server Images, see Provisioning Single Server Images.

Meeting the Prerequisites

Before you perform Linux provisioning, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about the prerequisites to be met for provisioning bare metal boxes, see Prerequisites.

- To learn about the prerequisites to be met for provisioning Oracle VM Servers, see Prerequisites.

- To learn about the prerequisites to be met for provisioning Single Server Images, see Prerequisites.

Provisioning

Provisioning Linux on bare metal boxes, Oracle VM Servers, or performing single image provisioning.

- To provision Linux on bare metal boxes, follow the steps explained in Creating a Default Image, Setting Up a Default Image, and Staging the Default Image in the same order.

- To provision Oracle VM Servers, follow the steps explained in Provisioning Procedure.

- To provision Single Server Images, follow the steps explained in Creating a Network Component, Creating Disk Layout Component, Creating OS Component, Creating Single Server Image, Creating Assignments, and Provisioning Assignments in the same order.

Supported Releases

Enterprise Manager Grid Control supports bare metal provisioning of 32-bit and 64-bit variants of the following operating systems:

- Oracle Enterprise Linux 5.0 Update 2

- Oracle Enterprise Linux

- Oracle Enterprise Linux 4.0 or higher

- RedHat Enterprise Linux (RHEL) 5.0

- RedHat Enterprise Linux (RHEL) 4.0 update 2 or higher

- RedHat Enterprise Linux (RHEL) 3.0 update 6 or higher

- SuSE Linux (SLES) 10

Provisioning Bare Metal Boxes

Provisioning only Linux Operating system on target servers involves creation of a Default Image and then deploying the image. The following sections explain how to provision Linux on bare metal boxes:

- Prerequisites

- Creating a Default Image

- Setting Up a Default Image

- Staging the Default Image

- Ready to Go

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Creating a Default Image

A Default Image is a special type of image that installs operating system based on a reference Linux installation. It then deploys an Oracle Management Agent on the bare metal box so that it can subsequently be managed as an Enterprise Manager target. A default image can be created for a particular IP prefix or MAC address and provisioned on bare metal boxes as they are added to a given subnet.

The Default Image setup consists of following steps:

1. Go to the Images tab and click Create Image. The following page is displayed:

In the Describe step, choose appropriate type of Default Image depending on the Operating System that needs to be provisioned on the bare metal servers. Enter a name for the image and other information that you may want to associate with it. Click Next.

2. The Configuration step comes up as shown below.

The Configure step depends on the type of the type of Image selected in the earlier step and is different for different types of Images. On this page, specify the following details:

Reference Installation is the reference host or gold host used for creating OS components for this image. For information about reference host, see Overview of the Bare Metal Provisioning Environment.

RPM repository allows you to choose an RPM repository from a list of RPM repositories configured for use with the provisioning application.

Additional RPM allows you to add RPMs for installation on the servers to be provisioned.

Exclude RPM allows you to specify the RPMs to be excluded from the image.

Time Zone and UTC Clock are used for setting the time zone of the bare-metal boxes after provisioning the operating system on them. Select the time zone corresponding to the OMS time zone.

Root Password is the root password that needs to be set for the newly provisioned Linux box.

User List is the list of operating system users you want to configure for the newly provisioned Linux box. You can create users with sudo permission.

Clicking Next brings up the Customize and Set Directives steps. For Default Image case, the out-of-the-box directives are automatically associated during creation.

Final step is the Review step where all the entries made in the earlier steps can be reviewed. Clicking Finish on the review page kicks off a job to create the necessary components and directives required for the Default Image.

Clicking on the job link will show the various steps executed by the job.

Once the job is finished a new Image can be seen in the Images table on the Images tab. This Image is created with version 0.1 is in Ready state for use. Any subsequent changes to the Image will lead to an increment of 0.1 in revision.

As a check, go to the components tab to check the components that have been created automatically created for the Default Image under the node "Oracle Components". The components created for the Default Image are non-editable as shown below:

Note:

If you want to remove an existing image from the Software Library, do the following:

1. Make sure the Image is not set as a default image in the Deployments->Administration->Default Images section. If it is, remove the entry from the table.

2. Remove the assignments (if any) for the image from the Deployment->Provisioning->Assignments table.

3. Remove the image from the Software Library by removing it from Deployment->Provisioning->Images table.

4. Remove the components associated with this image from the Software Library by removing it from the Deployments->Provisioning->Components->Oracle Components section.

Setting Up a Default Image

1. Go to the Administration tab and click Add in the Default Images section on the Administration tab as shown below.

2. The Add Default Image page appears.

Enter the following values on this page:

- IP Address Prefix or MAC Address:

- IP Address Prefix is used to specify the IP prefix of subnet where the bare-metal machines would be added.

- MAC Address is used to specify the MAC addresses of the bare metal machines to be added.

- Choose a desired Boot Server and Stage Server from the list of servers configured with the provisioning application.

- Specify the Image name to be used as the Default Image, select Use Preferred Credentials for the Stage server.
Specify the number of network cards for the target machine in the Number of NICs field.

- Click Edit Advanced Properties.

You can provide the following properties:

- In the Agent Settings section, specify the agent user, group, and Oracle home for the install, and the location of the agent RPM. If the agent RPM location is not specified, the RPMs will be picked up from the stage location. You can also specify the location where you want the Oracle Central Inventory to be created.

- In the Security Settings section, you can add a script in the Security Parameters field. You can enable or disable SELinux.

- In the Kernel Settings section, you can add a script in the Kernel Parameters field.

- In the Disk Partition Settings section, you can specify the disk partition for new Linux machines. These entries are picked up from the reference anaconda installation file available at /root/anaconda-ks.cfg on the reference host. You can modify these entries to suit the disk partition requirements of the target machines being provisioned.

- In the Boot Configuration Settings section, specify the name of the network interface card such as eth0 or its MAC address or options like bootif and link.

- In the Mount Point Settings section, you can specify entries for the /etc/fstab file. You can specify mount points on the newly provisioned Linux machine. By default, mount point settings from the reference Linux machine are inherited.

- In the NTP Settings section, you can specify entries for the /etc/ntp.conf file. You can specify NTP settings for the newly provisioned Linux machine. By default, NTP settings from the reference Linux machine are inherited.

- In the NIS Settings section, specify entries for the /etc/yp.conf file. You can specify NIS settings for the newly provisioned Linux machine. By default, NIS settings from the reference Linux machine are inherited.

- In the Post section, specify any set of commands that need to be executed on the newly provisioned machine. These commands will be appended to the post section of the kickstart file.

Note:

If setting up of the default image fails, delete the image, delete the component, and retry.
Running this job may take a few minutes.

Staging the Default Image

Once the Image is created, click Stage in the Default Images section and select the Image created earlier.

This prepares the default image ready for installation on the staging server. You will be asked to enter the OMS registration password before staging starts.

An Enterprise Manager job is submitted to do the staging of default image. The on-going status can be seen using the Enterprise Manager job console.

Note:

If staging of the image fails, correct the pre-requisite failures mentioned in the failed job and retry the staging operation. Click Edit in the Default Images section and re-submit the staging job by clicking Finish.
You can also clean up the image from the Default Images table and try again.

Running this job may take a few minutes.

Ready to Go

Once the image is in the Staged status, you are ready to go. Plug in the bare metal boxes in the network and the provisioning application will automatically provision them to have the default image and management agent on it.

Note:

Once Linux is provisioned on the bare metal box, out-of-box Deployment Procedures can be used to provision Database and other Oracle products on the server.

Provisioning Oracle VM Servers

Enterprise Manager supports bare metal provisioning of Oracle VM servers.

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Provisioning Procedure

To provision a virtual server, do the following:

1. In the Images tab, click Create Image.

2. In the Create Image: Describe page, select Type as OVS Default Image, and specify a name and other details for the image. Click Next.

3. In the Create Image: Configure page, select the RPM repository.
Select the Time Zone and specify the root password for the operating system and the OVM agent password. The OVM agent password is used when registering the Virtual Server with the Server Pool.

In the User List section, you can add users for the operating system during the provisioning process.

Note:

Unlike bare metal provisioning of Linux boxes, when you provision virtual servers, you do not require a reference installation.

4. In the Create Image: Set Directives page, the directives required for OVS provisioning are selected by default. You can customize the provisioning operation by adding directives.

5. In the Create Image: Review page, review all the information you have provided and submit the job for creating the image.

6. After the image is created, in the Administration tab, go to the Default Images section.

7. In the Default Images section, click Add.

8. In the Add Default Image page, specify the target type as a MAC address or IP Address Prefix.
Specify the Boot Server, Staging Storage, and Number of NICs.

9. Select the OVS Image you created earlier.

10. Click Edit Advanced Properties.

11. In the Edit Advanced Properties page, specify advanced properties for the operating system.

In the Security Settings section, specify the following values:

- Request tty - Select this option to set the "Defaults require tty" property in the /etc/sudoers file.

- SELinux - Choose to disable or enable SELinux.

- Firewall Settings - Specify firewall settings for the virtual server target.

- Dom0 Memory (MB) - Specify memory size for the virtual server.

In the Disk Partition Settings section, specify the disk partition configuration to be applied to the target machines.

In the Boot Configuration Settings section, specify the network device name.

In the Package section, you can specify the packages to be installed during the provisioning operation.

In the Xend Configuration section, you can specify entries for the /etc/xen/xend-config.sxp file.

In the Post section, specify any set of commands that need to be executed on the newly provisioned machine. These commands will be appended to the post section of the kickstart file. You can specify Kernel, NFS, NTP, and other configurations in the Post section.

Note:

Unlike bare metal provisioning of Linux boxes, when you provision virtual servers, you will not configure the agent, since the virtual server will not explicitly contain an agent to monitor it.

12. Click OK.

13. Once the Image is created, click Stage in the Default Images section and select the Image created earlier.

14. Plugin the baremetal box in the subnet where the OVS image has been staged.

After the virtual server is provisioned, you can register it with a server pool. See Chapter 10, "Provisioning Virtualization Systems" for more information.

Provisioning Single Server Images

A Single server image contains an operating system and other applications. During provisioning, the operating system and other applications are installed on the machines being provisioned.

For provisioning single server images, follow these steps:

Table 9-2 Getting Started with Provisioning Single Server Images

Step

Description

Reference Links

Step 1

Creating A Network Component

Create a network component to provide network details for the machines you are provisioning.

To learn about creating a network component, see Creating a Network Component.

Step 2

Creating A Disk Layout Component

Create a disk layout component to provide profiles for hard disk, physical disk partition, RAID configuration, logical volumes, and logical volume groups for the machines you are provisioning.

To learn about creating a disk layout component, see Creating Disk Layout Component.

Step 3

Creating An OS Component

Create an OS component to provide operating system details for the machines you are provisioning.

To learn about creating a disk layout component, see Creating OS Component.

Step 4

Creating A Single Server Image

Create a Single Server Image and add the disk layout and OS components created earlier.

To learn about creating a single server image, see Creating Single Server Image.

Step 5

Creating An Assignment

Create an Assignment by associating the single-server image with the network component and any hardware component.

To learn about creating an assignment, see Creating Assignments.

Step 6

Provisioning The Assignment

Provision the assignment containing single server images.

To learn about provisioning the assignment, see Provisioning Assignments.

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Creating a Network Component

The network component created in this section will provide the network details for the machines you provision using this component.

To create a network profile, do the following:

1. In the Networks tab, click Create Network.

2. In the Create Network: Describe page, specify the name, description, and product details for the network component. Click Next.

3. In the Create Network: Configure page, add the network configuration. Select:

- Static if you want to specify the IP addresses

- Dynamic if you want the DHCP server to assign a network address

- Network Configuration if you want to assign network addresses from a network pool. Ensure that the network pool is configured.

4. Specify network information for bonding or non bonding interface. Click Next.

5. In the Create Network: Set Directives page, choose the out-of-box network directives for the network component for single server component creation. The directive will be available at Oracle Directives/Baremetal Provisioning/Single Server/Linux/Network Layout. Click Next.

6. Review the information you have provided and click Finish.

The network component is created.

Creating Disk Layout Component

Follow these steps to create a disk layout component:

1. In the Components tab, click Create Component.

2. In the Create Component: Describe page, select Type as Linux Disk Layout, and specify the name and other product details. Click Next.

3. In the Create Component: Configure page, add the profiles for hard disk, physical disk partition, RAID configuration, logical volumes, and logical volume groups. Click Next.

4. In the Create Component: Set Directives page, choose the out-of-box disk layout directives for the disk layout component for single server component creation. The directive will be available at Oracle Directives/Baremetal Provisioning/Single Server/Linux/Disk Layout. Click Next.

5. Review the information you have provided and clickFinish.

The disk layout component is created.

Creating OS Component

Follow these steps to create an OS component:

1. In the Components tab, click Create Component.

2. In the Create Component: Describe page, select Type as Linux Operating System, (RedHat Linux, Oracle Enterprise Linux, or SuSE Linux), and specify the name and other product details. Click Next.

3. In the Create Component: Configure page, select the target host for the reference installation for the operating system, select the RPM repository, add or delete RPMs, specify the root password for the operating system and the list of operating system users you want to configure when the machine is provisioned. Click Next.

4. In the Create Component: Set Directives page, choose the out-of-box operating system directives for the operating system component for single server component creation. The directive will be available at Oracle Directives/Baremetal Provisioning/Single Server/Linux/OS Staging. Click Next.

5. Review the information you have provided and clickFinish.

The operating system component is created.

Creating Single Server Image

Follow these steps to create a single server image:

1. In the Images tab, click Create Images.

2. In the Create Image: Describe page, select Type as Single-Server and specify the name and other product details. Click Next.

3. In the Create Image: Customize page, add properties if you want to customize the image. Click Next.

4. In the Create Image: Set Directives page, choose the out-of-box single server directives. The directives are available at Oracle Directives/Baremetal Provisioning/Single Server/Linux/Image Staging. Click Next.

5. In the Create Image: Add Components page, add the disk layout component and OS component created earlier. Click Next.

6. Review the information you have provided and click Finish.

The single server image is created.

Creating Assignments

Follow these steps to create an assignment:

1. In the Assignments tab, click Create New Assignment.

2. In the Create New Assignment: Select Type page, select Create Image Assignment. Click Next.

3. In the Create New Assignment: Select Image/Suite page, select the single server image you created earlier. Click Next.

4. In the Create New Assignment: Configure page, specify the name, boot server, staging storage, and staging server credentials. Select the network profile created earlier to assign network properties during provisioning.
Specify Advanced Properties for the assignment. Select the hardware servers (Enterprise Manager host targets) you want to provision. Click Next.

5. Review the information you have provided and click Finish.

Provisioning Assignments

After creating the assignment, follow these steps to provision assignments:

1. In the Assignments tab, select the assignment and click Provision.

2. In the Provision Assignments page, specify a schedule, provide the agent password, and select the assignment. Click Provision.

The hardware specified will be provisioned after the reboot with the specified image assignment.

Part IV

Provisioning Virtualization Systems

This part describes how you can provision virtualization systems.

This part contains the following chapters:

- Chapter 10, "Provisioning Virtualization Systems"

10 Provisioning Virtualization Systems

Virtualization Management (VM) involves the monitoring, administration, and maintenance of virtual servers and guest virtual machines in your enterprise. Oracle provides the customer increased value by extending Enterprise Manager Grid Control capabilities to monitor virtualized entities alongside the physical infrastructure and perform complete lifecycle management of virtual servers and software running on them.

This chapter explains how you can provision Oracle VM. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Provisioning Guest Virtual Machines

- Virtualization Central Dashboard

- Live Migrating Guest Virtual Machines

- High Availability and Fault Tolerance

- Advanced Operations

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning virtualized systems. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision virtualized systems. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 10-1 Getting Started with Oracle VM Provisioning

Step

Description

Reference Links

Understanding the Deployment Procedures

Understand the Deployment Procedures offered by Enterprise Manager Grid Control for provisioning Oracle VM.

To learn about the Deployment Procedures, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases are supported by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Oracle VM. Select the use case that best matches your requirement

- To learn about provisioning guest virtual machines, see Provisioning Guest Virtual Machines.

- To learn about provisioning Oracle VM Servers, see Bare Metal Provisioning of Oracle VM Servers.

- To learn about cloning guest virtual machines, see Cloning Guest Virtual Machines.

- To learn about live migrating guest virtual machines, see Live Migrating Guest Virtual Machines.

Meeting the Prerequisites

Before you perform Oracle VM provisioning, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about prerequisites for provisioning guest virtual machines, see Prerequisites.

- To learn about prerequisites for cloning guest virtual machines, see Prerequisites.

- To learn about prerequisites for live migrating guest virtual machines, see Prerequisites.

Provisioning

Provisioning guest virtual machines, cloning guest virtual machines, or live migrating guest virtual machines.

- To learn about provisioning guest virtual machines, see Creating Guest Virtual Machines.

- To learn about cloning guest virtual machines, see Cloning Procedure.

- To learn about live migrating guest virtual machines, see Live Migrating Selected Guest Virtual Machines and Live Migrating All Guest Virtual Machines.

Configuring for High Availability

Configure Oracle VM for failover support.

To learn about high availability and fault tolerance, see High Availability and Fault Tolerance.

Deployment Procedures

Enterprise Manager Grid Control provides the following Deployment Procedures for provisioning Oracle VM:

- Virtual Machine Cloning
This deployment procedure clones a guest virtual machine to one or more guest virtual machines

- Virtual Machine Provisioning Using ISO
This deployment procedure creates a new guest virtual machines using an ISO image.

- Virtual Machine Provisioning Using PXE
This deployment procedure creates a new guest virtual machines using Preboot Execution Environment. The new guest virtual machines will be PXE-booted and they will get provisioned via network.

- Virtual Machine Provisioning Using Template
This deployment procedure creates new guest virtual machines using templates. The new virtual machines will be based on the template.

- Edit Virtual Machine
This deployment procedure edits guest virtual machine configuration.

- Live Migration
This deployment procedure performs live migration of a particular guest virtual machine or live migration of all guest virtual machines in a particular virtual server.

- Save Virtual Machine as Template
This deployment procedure saves a guest virtual machine as template and exports the template to an external location, if provided.

- Import Template
This deployment procedure imports an Oracle VM template into a server pool.

- Import ISO Image
This deployment procedure imports an ISO Image into a server pool.

- Create Shared Disk
This deployment procedure creates a shared disk image and registers it with the server pool.

Deployment Procedures cannot be run directly. Deployment procedures for Oracle VM provisioning run when provisioning is performed through Virtualization Central.

Supported Releases

Following are some of the supported operating system versions for virtualization:

Table 10-2 Supported Releases

Operating System

Version

Linux

Oracle Enterprise Linux 4 - 32-bit and 64-bit

Oracle Enterprise Linux 5 - 32-bit and 64-bit

Red Hat Enterprise Linux 3 - 32-bit and 64-bit

Red Hat Enterprise Linux 4 - 32-bit and 64-bit

Red Hat Enterprise Linux 5 - 32-bit and 64-bit

Microsoft Windows

Microsoft Windows Server 2000

Microsoft Windows Server 2003 Edition - 32-bit and 64-bit

Microsoft Windows Vista

Microsoft Windows XP

Provisioning Guest Virtual Machines

Guest Virtual machines can be provisioned using Oracle VM templates, ISO images, or by PXE boot. Oracle VM templates and ISO images can be downloaded from OTN or other sources.

You can create guest virtual machines from the following three sources:

- Using Oracle VM Templates

- Using ISO images of Linux and Windows operating systems

- PXE bootable guest virtual machines that can boot over a network

Oracle VM template or ISO binaries can be available in any of the following locations:

- In the virtual server pool as a resource

- In the Software Library as a software component

- In a HTTP or NFS accessible external location

This section describes the following:

- Creating Software Library Components

- Importing Oracle VM Templates and ISO Binaries as Server Pool Resources

- Creating Guest Virtual Machines

- Configuring the Guest Virtual Machine for Agent and Other Software

Creating Software Library Components

Enterprise Manager Grid Control allows you to create guest virtual machines from Oracle VM Templates and Linux and Windows ISO images. Oracle VM templates may contain operating system and pre-installed and pre-configured Oracle software. This section explains the following:

- Prerequisites

- Creating a Software Component from an ISO Image

- Creating a Software Component from an Oracle VM Template

- Discovering ISO Images and Oracle VM Templates

- Creating Shared Disk

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Creating a Software Component from an ISO Image

To create a software component from an ISO image, do the following:

1. In the Software Components tab, select Components as ISO and click Create.

2. In the Create ISO page, specify the name and description of the ISO component and the operating system details.
Select the Binary Upload Mechanism option to choose the option to store the template in the Software Library or specify an external location where the binary is stored.

If you choose Upload from Agent Machine, select the host and the location of the binary. Specify the host credentials to select the file from the agent machine.

If you specify an external location for the binary, specify the HTTP or NFS location of the binary. The binary will not be stored in the Software Library. It will be directly downloaded to the server pool when this resource is imported to a server pool.

Click OK.

Navigate to the Software Components tab. The software component you have created will be displayed on this page.

Creating a Software Component from an Oracle VM Template

To create a software component from an Oracle VM template, do the following:

1. In the Software Components tab, select Components as Template and click Create.

2. In the Create Component: Describe page, select the Creation Method as Oracle VM Template Binary. Specify the name and operating system details.

3. In the Create Component: Configure page, select Virtualization Type as Para Virtualized or Hardware Virtualized based on the template you are creating.
Select the Binary Upload Mechanism option to choose the option to store the template in the Software Library or specify an external location where the binary is stored.

If you choose Upload from Agent Machine, select the host and the location of the binary.

If you specify an external location for the binary, specify the HTTP or NFS location of the binary. The binary will not be stored in the Software Library. It will be directly downloaded to the server pool when this resource is imported to a pool.

4. In the Create Component: Review page, review the information you have provided and submit the component creation job.
Navigate to the Software Components tab. The software component you have created will be displayed on this page.

Discovering ISO Images and Oracle VM Templates

You can store your Oracle VM templates and ISO images in the following directories and add them as resources to the server pool using the Discover functionality:

- /OVS/seed_pool

- /OVS/<repos_guid>/seed_pool

- /OVS/iso_pool

- /OVS/<repos_guid>/iso_pool

<repos_guid> is the GUID of any additional storage repository that might have been added to the server pool.

To discover ISO images and Oracle VM templates, do the following:

1. In Virtualization Central, select the Virtual Server Pool, select Action Virtual Server Pool - Manage Virtual Server Pool and click Go.

2. In the Oracle VM Server Pool: Resources page, select Resources as ISO Images or Oracle VM Templates and click Discover.

3. If you have selected Oracle VM Templates, in the Discover GVM Template page, select the undiscovered template and provide a description. Select the OS Type and Operating System details.

4. If you have selected Oracle VM Templates, in the Discover GVM Template page, select the undiscovered template and provide a description. Select the Virtualization Type, OS Type, and Operating System details. Click OK.
Navigate to the Resources page. The ISO image or Oracle VM template you have discovered will be displayed on this page.

Creating Shared Disk

You can also create shared disks that can be used by guest virtual machines and assign them at the time of guest virtual machine creation.

Oracle VM allows sharing of disks between multiple guest virtual machines. Create a shared disk that the guest virtual machine can access. Follow these steps:

1. In Virtualization Central, select the Virtual Server Pool, and select Action Virtual Server Pool - Manage Virtual Server Pool and click Go.

2. In the Oracle VM Server Pool: Resources page, select Resources as Shared Disks and click Create.

3. In the Create Shared Disk page, specify the name, size of the disk, and provide a description. Click OK.
After clicking OK, the deployment procedure to create shared disk will be submitted. The initial status will be Creating. Once the deployment procedure completes successfully, the status will be Ready. In case the deployment procedure fails, the status will be Error.

Importing Oracle VM Templates and ISO Binaries as Server Pool Resources

To create guest virtual machines, you can import Oracle VM Templates and ISO binaries to the server pools and use them for provisioning. This section explains the following:

- Prerequisites

- Importing Software Components from Software Components Tab

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

Importing Software Components from Software Components Tab

To import a software component, do the following:

1. In the Software Components tab, select Components as Template or ISO depending on the component you are importing, select the component, and click Import.

2. In the Import Template or Import ISO Image Page, specify the name of the imported resource, add the server pools to which you want to import the component, and specify monitoring server and virtual server credentials.

3. Click OK.
After importing the software component, it will appear in the Server Pool Resources page as an imported resource.

Importing Software Components from Server Pool Resources Tab

To import a software component, do the following:

1. In Virtualization Central, select the Server Pool, select Action as Virtual Server Pool Manage Virtual Server Pool and click Go.

2. In the Resources tab, select Resources as Oracle VM Templates or ISO Images depending on the component you are importing, select the component, and click Import.

3. In the Import Template or Import ISO Image Page, specify the name of the imported resource, select the component to be imported or specify the external location of the component, and specify monitoring server and virtual server credentials.

4. Click OK.
After importing the software component, it will appear in the Server Pool Resources page as an imported resource.

Creating Guest Virtual Machines

You can create guest virtual machines from software components. You can also create PXE bootable guest virtual machines with no operating system on them. This section explains the following:

- Phases for Provisioning Guest Virtual Machines

- Prerequisites

- Provisioning Guest Virtual Machines Using Oracle VM Templates

- Provisioning Guest Virtual Machines Using ISO Images

- Provisioning Guest Virtual Machines Using PXE Boot

Phases for Provisioning Guest Virtual Machines

The following table describes the phases involved in the provisioning operation:

Table 10-3 Phases for Provisioning Guest Virtual Machines

Phase

Description

Select Server Pool

Allows you to specify the number of guest virtual machines to be created, preferred servers for guest virtual machines, and select the server pool with which you want to associate the guest virtual machines.

Select Source

Allows you to select the source from which you want to create the guest virtual machine. The source can be PXE Boot, Oracle VM Template, or ISO Image created earlier. The location can be Software Library Component location or an external location or location of the imported resource of the selected server pool.

Configure

Allows you to configure the disk, network, agent and other details.

Schedule

Allows you to specify the Schedule and Credentials for the provisioning activity.

Review

Allows you to review the information you have provided for provisioning the guest virtual machine.

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Software component to create the guest virtual machine is available in the Software Library or any other location.

Provisioning Guest Virtual Machines Using Oracle VM Templates

To provision a guest virtual machine using Oracle VM template, follow these steps:

1. Download the Oracle VM template for Linux to an external location (either HTTP or NFS location).

2. Import the Oracle VM template to the server pool. For steps to import templates to server pool, see Importing Oracle VM Templates and ISO Binaries as Server Pool Resources.

3. Use the Software Components tab in Virtualization Central to create a software component in the Software Library pointing to the template in the shared storage.

4. In Virtualization Central, select Action as Guest VM, Create Guest VM and click Go.

5. In the Create Guest Virtual Machines: Server Pool page, specify the number of guest virtual machines to be created and the server pool with which you want to associate the guest virtual machines.
'Specify the preferred virtual servers where the guest virtual machines will run. Choose Automatic to select the virtual server automatically. Click Next.

6. In the Create Guest Virtual Machines: Source page, select Oracle VM Template.

- If the Oracle VM template is of type imported resources, select the template from the table.

- If the Oracle VM template binary is not stored in the Software Library, specify the NFS or HTTP location where the Oracle VM template is stored. Specify the resource name for the binary to be imported. Specify if you want hardware virtualized or para-virtualized type.

- If the Oracle VM template is a software component stored in the Software Library, specify the resource name for the software component to be imported into the selected server pool and description. If the software component is not imported, it will be imported and the guest virtual machine will be created.

Click Next.

7. In the Create Guest Virtual Machines: Configure page, specify the configuration details shown in Table 10-4. The Configure Network button will be enabled only when the 'Preferred Server List' in Server Pool page is chosen as Manual. By default, the network configuration will be DHCP.

8. In the Create Guest Virtual Machines: Schedule/Credentials page, specify the schedule for creating the guest virtual machine and the monitoring server and virtual server host credentials.

9. In the Create Guest Virtual Machines: Review page, review the information you have provided and submit the job for guest virtual machine creation.
After clicking Finish, the deployment procedure to create the guest virtual machine will be submitted. The initial status of the guest virtual machine(s) being created will be Creating. The guest virtual machine will appear under the server pool. Once the guest virtual machine gets created, the status will be Halted. If the guest virtual machine is started successfully, then the status will be Running.

Table 10-4 Guest Virtual Machine Configuration Details for Oracle VM Templates

Element

Description

Virtual Machine Name Prefix

This string that will be used as a prefix in the guest virtual machine name. When a guest virtual machine is created using the Enterprise Manager Grid Control Console, guest virtual machine names will be prefix1, prefix2, and so on.

Number of Cores

When creating guest virtual machine from imported template resource, specify the number of CPU cores to assign to this guest virtual machine. This will show up as virtual CPU (vCPU) configuration parameter for the guest virtual machine.

Memory Size (MB)

When creating guest virtual machine from imported template resource, specify the amount of memory to be allocated to the guest virtual machine. The physical virtual server machine should have sufficient memory to run the guest virtual machine. Otherwise, the guest virtual machine will be created, but will not be started.

Root Password/Confirm Root Password

When creating guest virtual machine from a Linux-based Oracle VM template, specify the operating system "root" password to log in to the guest virtual machine once it is up and running.

VNC Console Password

Enterprise Manager Grid Control provides a VNC console to the newly created guest virtual machine. This is the VNC password to access the VNC console.

Number of Network Interfaces

Number of virtual network interfaces this guest virtual machine should have. The minimum value is 1 and the maximum value is 8.

If you have manually selected the virtual servers for the guest virtual machine creation, specify the network details by clicking Configure Network. To configure the network, specify the following values:

Virtual Machine - Select the guest virtual machine you are configuring.

Configuration Type - Specify the type of configuration whether dynamic or static.

MAC Address - Specify the MAC address of the network interface. This is not a mandatory field. If not specified, MAC address will be automatically generated. The format of MAC address is XX:XX:XX:XX:XX:XX, where the first three octets should be 00:16:3E.

Bridge - Select a network bridge from the available bridges.

IP Address - Specify the IP address to be assigned to the network interface. Specify the value in /ddd.ddd.ddd.ddd/ format.

Host Name - Specify the Hostname associated with the specified IP address. For example, myhost1.The hostname specified for "VIF0" will be set as host name of the machine. For remaining interfaces, the hostname entries are made to /etc/hosts file.

Domain Name - Specify the domain name associated with the specified IP address.

Subnet Mask - Specify the mask used to determine what subnet the specified IP address belongs to. For example, 255.255.252.0

Default Gateway - Specify the IP address of the node (or router) on the network that serves as an access point to another network. The default gateway specified for "VIF0" is set as the default gateway of the machine.

DNS Server - Specify the DNS server configured with the virtual server.

Enable High Availability Mode

When creating the guest virtual machine, if the "Enable High Availability Mode" flag is selected, this guest virtual machine will participate in the High Availability functionality. If its parent virtual server fails, this guest virtual machine will be auto-restarted on another Oracle VM server.

Configure Agent

Select this option if you want to configure the agent to monitor the guest virtual machine.

Load Balancer Host

In case of multiple OMS setup, specify the load balancer host name to be used for agent configuration.

By default, the agent will be configured with one of OMS hosts in a multiple OMS setup. If load balancer host is provided, then agent will be configured with the load balancer host.

Load Balancer Port

In case of multiple OMS setup, specify the load balancer port.

Management Server Registration Password

Password to register the agent.

Email

Specify the Email address for contact.

My Oracle Support Password

Password credentials for My Oracle Support.

Proxy Server

HTTP Proxy server used to connect to My Oracle Support.

Proxy Port

Proxy server port number

Proxy User name/Proxy Password

User name and password for the proxy server.

Start VM after creation

When creating guest virtual machine from template, specify whether the guest virtual machine should be started automatically after it is created.

Additional Disks

Every guest virtual machine is created with at least one disk. Specify additional disks and their sizes. These disks will be added to the guest virtual machine. After the guest virtual machine is created, log in to the guest virtual machine and reformat and mount the additional disks.

Shared Disks

Oracle VM allows sharing of disks between multiple guest virtual machines. You can specify multiple shared disks that the guest virtual machines can access.

Provisioning Guest Virtual Machines Using ISO Images

To provision a guest virtual machine using ISO image, follow these steps:

1. Import the ISO image to the server pool. For steps to import ISO images to server pool, see Importing Oracle VM Templates and ISO Binaries as Server Pool Resources.

2. Use the Software Components tab in Virtualization Central to create a software component in the Software Library pointing to the ISO image in the shared storage.

3. In Virtualization Central, select Action as Guest VM, Create Guest VM and click Go.

4. In the Create Guest Virtual Machines: Server Pool page, specify the number of guest virtual machines to be created and the server pool with which you want to associate the guest virtual machines.
You can select the virtual server for the guest virtual machine manually or allow the server pool to automatically allocate the virtual server.

Click Next.

5. In the Create Guest Virtual Machines: Source page, specify the ISO image source from which you want to create the guest virtual machine.

- If the ISO image is an imported resource and the Virtualization type is para-virtualized, specify the NFS Mount Point, that is, the NFS location where the ISO image will be mounted.

- If the ISO image is not stored in the Software Library, specify the external location where the ISO image is stored. Specify the resource name using which the binary will be imported, OS name, and OS type. Specify if you want hardware virtualized or para-virtualized type.

- If the ISO image is a software component stored in the Software Library, specify Name and Description and if the Virtualization type is para-virtualized, specify the NFS Mount Point also.

6. In the Create Guest Virtual Machines: Configure page, specify the configuration details shown in Table 10-5.

7. In the Create Guest Virtual Machines: Schedule/Credentials page, specify the schedule for creating the guest virtual machine and the monitoring server and virtual server host credentials.

8. In the Create Guest Virtual Machines: Review page, review the information you have provided and submit the job for guest virtual machine creation.
Clicking Finish will submit the deployment procedure to create guest virtual machine(s). The initial status of the guest virtual machine will be 'Creating'. If the creation is successful, the status will be 'Running'.

Table 10-5 Guest Virtual Machine Configuration Details for ISO Images and PXE Boot

Element

Description

Virtual Machine Name Prefix

This string that will be used as a prefix in the guest virtual machine name. When a guest virtual machine is created using the Enterprise Manager Grid Control Console, guest virtual machine names will be prefix1, prefix2, and so on.

Number of Cores

The number of CPU cores to assign to this guest virtual machine. This will show up as virtual CPU (vCPU) configuration parameter for the guest virtual machine.

Memory Size (MB)

The amount of memory to be allocated to the guest virtual machine. The physical virtual server machine should have sufficient memory to run the guest virtual machine. Otherwise, the guest virtual machine will be created, but will not be started.

Primary Disk Name

For guest virtual machine provisioning using ISO image or PXE boot, there must atleast one hard disk. Specify this hard disk on which the guest virtual machine will be created.

Primary Disk Size (MB)

For ISO and PXE boot, specify the size of the hard disk in megabytes.

VNC Console Password

Enterprise Manager Grid Control provides a VNC console to the newly created guest virtual machine. This is the VNC password to access the VNC console.

Number of Network Interfaces

Number of virtual network interfaces this guest virtual machine should have. The minimum value is 1 and the maximum value is 8.

Enable High Availability Mode

When creating the guest virtual machine, if the "Enable High Availability Mode" flag is selected, this guest virtual machine will participate in the High Availability functionality. If its parent virtual server fails, this guest virtual machine will be auto-restarted on another Oracle VM server.

Additional Disks

Every guest virtual machine is created with at least one disk. Specify additional disks and their sizes. These disks will be added to the guest virtual machine. After the guest virtual machine is created, log in to the guest virtual machine and reformat and mount the additional disks.

Shared Disks

Oracle VM allows sharing of disks between multiple guest virtual machines. You can specify multiple shared disks that the guest virtual machines can access.

Provisioning Guest Virtual Machines Using PXE Boot

To provision a guest virtual machine using PXE boot, follow these steps:

1. In Virtualization Central, select Action as Guest VM, Create Guest VM and click Go.

2. In the Create Guest Virtual Machines: Server Pool page, specify the number of guest virtual machines to be created and the server pool with which you want to associate the guest virtual machines.
You can select the virtual server for the guest virtual machine manually or allow the server pool to automatically allocate the virtual server.

Click Next.

3. In the Create Guest Virtual Machines: Source page, specify the PXE Boot source from which you want to create the guest virtual machine. Specify if you want hardware virtualized or para-virtualized type.
Specify the MAC addresses for the guest virtual machines:

- If you want Enterprise Manager Grid Control to assign a MAC addresses for the new guest virtual machines, select Automatic.

- If you want to specify MAC addresses manually, select Manual and provide the MAC addresses in the text fields. The format of MAC address is XX:XX:XX:XX:XX:XX where the first three octets are 00:13:6E.

4. In the Create Guest Virtual Machines: Configure page, specify the configuration details shown in Table 10-5.

5. In the Create Guest Virtual Machines: Schedule/Credentials page, specify the schedule for creating the guest virtual machine and the monitoring server and virtual server host credentials.

6. In the Create Guest Virtual Machines: Review page, review the information you have provided and submit the job for guest virtual machine creation.
Clicking Finish will submit the deployment procedure to create guest virtual machine(s). The initial status of guest virtual machine will be 'Creating'. If the creation is successful, the status will be 'Running'.

Configuring the Guest Virtual Machine for Agent and Other Software

To enable Enterprise Manager Grid Control to monitor your guest virtual machine, you will need to configure the agent.

Table 10-6 lists all the options available for configuring the agent when creating a guest virtual machine from Oracle VM template and the action you can take.

Table 10-6 Agent Configuration Options

Option

Result

Oracle VM template used for guest virtual machine creation has a Oracle Management Agent (Management Agent)

- Configure Agent option is selected when creating the guest virtual machine

The fields to specify agent configuration details are displayed in the Create Guest Virtual Machine: Configure page.

The agent is configured when the guest virtual machine is started for the first time. For details about configuring the agent, see Creating Guest Virtual Machines.

- Oracle VM template used for guest virtual machine creation has a Management Agent

- Configure Agent option is not selected when creating the guest virtual machine

The fields to specify agent configuration details are not displayed in the Create Guest Virtual Machine: Configure page.

The agent is not configured during guest virtual machine creation. You will need to manually log in to the guest virtual machine using the VNC Console and install and configure the agent. To install and configure the agent, see Oracle Enterprise Manager Grid Control Installation Guide.

- Oracle VM template used for guest virtual machine creation does not have a Management Agent

- Configure Agent option is selected when creating the guest virtual machine

Even though the Configure Agent option is selected, when creating the guest virtual machine, the agent will not be configured.

You will need to manually log in to the guest virtual machine using the VNC Console and install and configure the agent. To install and configure the agent, see Oracle Enterprise Manager Grid Control Installation Guide.

- Oracle VM template used for guest virtual machine creation does not have a Management Agent

- Configure Agent option is not selected when creating the guest virtual machine

When creating the guest virtual machine, the agent will not be configured.

You will need to manually log in to the guest virtual machine using the VNC Console and configure the agent. To install and configure the agent, see Oracle Enterprise Manager Grid Control Installation Guide.

Virtualization Central Dashboard

The Enterprise Manager Virtualization Central page allows you to monitor Oracle VM, guest virtual machines, and manage resources. This section covers the following:

- Overview

- Editing Guest Virtual Machines

- Updating Preferred Virtual Server List

- Opening a VNC Console to the Guest Virtual Machine

- Deleting Server Pools, Oracle VM Servers, and Guest Virtual Machines

Overview

The Enterprise Manager Virtualization Central page allows you to monitor Oracle VM servers and guest virtual machines, and manage resources. Resource management includes packaging and management of various resources like ISO images, Oracle VM templates, and shared disk.

Managed resources can be imported or associated with a server pool. Resources associated with server pools can be chosen for virtualization life cycle management operations such as creating, cloning, and live migrating guest virtual machines.

Enterprise Manager Grid Control provides support for packaging and associating Oracle VM template and ISO component with server pools.

In addition, the Virtualization Central page also provides the following information:

- A quick view of the status of the virtual server and guest virtual machines and basic information about them

- CPU and Memory utilization of virtual servers

- Information about the server pool to which the virtual servers are registered

- Drilldowns to server pools, virtual servers, and guest virtual machines home pages from where you can view more information about these targets

- Administrative tasks such as starting and stopping guest virtual machines

- Provisioning activities such as creating virtual server pools, registering virtual servers, and creating guest virtual machines

- VNC Support to access guest virtual machines

Starting from the Virtualization Central page, you can access additional details and management functions by drilling down through the user interface. In addition, the Virtualization Central page provides a list of Related Links. From these links you can perform activities such as bare metal provisioning of Oracle VM server software, customization of table columns, and deployment of Management Agent on a guest virtual machine. The following figure shows the Virtualization Central Page.

For more information about administration and monitoring of Oracle VM, see Enterprise Manager Concepts Guide available at:

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

For information about the privileges required for administrative operations, see Privileges Required for Administrative and Provisioning Operations.

Editing Guest Virtual Machines

Enterprise Manager Grid Control allows you to modify the virtual CPU count, allocated memory, and other configuration of the guest virtual machine.

Table 10-7 shows the editable fields for the guest virtual machine and the time when the changes will take effect.

Table 10-7 Guest Virtual Machines: Editable Fields

Editable Field

Action for Changes to Take Effect

Virtual Machine Name

This field can be edited only for guest virtual machines in the Halted status. Changes will take effect when the guest virtual machine is started.

Memory

This field can be edited only for guest virtual machines in the Halted status. Changes will take effect immediately when the guest virtual machine is started.

Dynamic Memory

Dynamic memory specified should be lesser than or equal to the Memory specified. For para-virtualized guest virtual machines, changes to the memory take effect without stopping and starting the guest virtual machine. For hardware-virtualized guest virtual machines, changes to memory take effect only after stopping and starting the guest virtual machine.

Virtual CPUs

For para-virtualized guest virtual machines, number of vCPUs can be edited and changes take effect without stopping and starting the guest virtual machine. For hardware-virtualized guest virtual machines, changes to vCPUs take affect only after stopping and starting the guest virtual machine.

VNC Console Password

New password takes effect after the guest virtual machine is stopped and restarted.

Enable High Availability Mode

If High Availability was enabled during guest virtual machine creation, you can edit the guest virtual machine to enable or disable High Availability.

Add/Remove Disk Storage

Changes take place immediately. CDs cannot be attached with para-virtualized guest machines.

Add/Remove Network Interface

Changes take place immediately. The primary network interface VIF0 cannot be removed.

Boot Order

This field can be edited only for guest virtual machines in the Halted status. Requires the guest virtual machine to be stopped and restarted. Boot Order cannot be set to CD for para-virtualized guest virtual machines.

Editing a Guest Virtual Machine

1. In Virtualization Central, select the Guest Virtual Machine you want to edit, and select Action Guest VM, Edit Guest VM and click Go.

2. In the Edit Guest Virtual Machine page, edit the values. Click Continue.

The Edit deployment procedure will be submitted. The guest virtual machine being edited will appear with the status 'Editing' in Virtualization Central. Once the deployment procedure completes successfully, the guest virtual machine status will be changed to the current state.

Updating Preferred Virtual Server List

If you want to restrict certain guest virtual machines to run on only certain Oracle VM servers, use the Preferred server list feature. Preferred server list contains all the Oracle VM servers on which this guest virtual machine is allowed to run. If the "Automatic" option is selected when creating a guest virtual machine, Enterprise Manager Grid Control picks the Oracle VM server with maximum resources to run the guest virtual machine. When auto-restarting guest virtual machines during fail-over scenario, Enterprise Manager Grid Control picks a preferred Oracle VM server to auto-restart the guest virtual machine.

To update preferred virtual server list, follow these steps:

1. In Virtualization Central, select the Guest Virtual Machine for which you want to update the preferred server list, and select Action Guest VM, Update Preferred Server List and click Go.

2. In the Update Preferred Server List page, choose the preferred server list as manual or automatic. If you choose automatic, add the preferred virtual servers for the guest virtual machine. Click Apply.

Enterprise Manager picks the preferred Oracle VM server to start the guest virtual machine.

Opening a VNC Console to the Guest Virtual Machine

You can log in to guest virtual machines using VNC Console.

1. In Virtualization Central, select the guest virtual machine you want to access and select Action Guest VM VNC Console.
The VNC Console to the guest virtual machine opens.

2. In the VNC Console, specify the VNC password.

Deleting Server Pools, Oracle VM Servers, and Guest Virtual Machines

On removing a server pool, the virtual servers associated with the server pool will be removed. This section explains the following:

- Prerequisites for Deleting a Server Pool

- Deleting a Server Pool

- Prerequisites for Deleting an Oracle VM Server

- Deleting an Oracle VM Server

- Deleting a Guest Virtual Machine

Prerequisites for Deleting a Server Pool

Following are the prerequisites for deleting a server pool:

- The virtual server pool must not have any running guest virtual machines.

- No Import Resource operation must be running in the virtual server pool.

- Agents running on all the virtual servers in the virtual server pool should be accessible.

Note:

If you select the Force Remove option, the validations mentioned above will not be performed.

Deleting a Server Pool

Follow these steps to delete a server pool:

1. In Virtualization Central, select the Server Pool, select Action Virtual Server Pool, Remove Server Pool, and click Go.

2. Confirm that you want to remove the server pool. You can choose Remove all working directories and/or Force Remove. Select Remove all working directories from the server pool if you want to delete all the related directories (under /OVS). If you leave this option unselected, only the server pool data is removed from the database, while the relevant directories and files of the server pool remain on the server.
If you select the Force Remove option, the virtual servers in the server pool will not be updated with the changes.

The deleted Server Pool and the associated virtual servers will not appear in Virtualization Central.

Prerequisites for Deleting an Oracle VM Server

Following are the prerequisites for deleting an Oracle VM server:

- The master agent of the virtual server should be connected and accessible.

- There should not be any running guest virtual machines on the virtual server.

- The virtual server should not be a preferred server of any guest virtual machine.

- The virtual server should not be the master server. The master virtual server cannot be directly removed. To remove the master virtual server, the virtual server pool has to be deleted.

Note:

If you select the Force Remove option, the validations mentioned above will not be performed.

Deleting an Oracle VM Server

Follow these steps to delete an Oracle VM server:

1. In Virtualization Central, select the Oracle VM Server, select Action Virtual Server, Deregister Virtual Server, and click Go.

2. Confirm that you want to deregister the virtual server. You cannot deregister the master server from a server pool.

The deleted virtual server and the associated guest virtual machines will not appear in Virtualization Central.

Deleting a Guest Virtual Machine

Follow these steps to delete a guest virtual machine:

1. In Virtualization Central, select the guest virtual machine, select Action Guest VM, Delete Guest VM, and click Go.

2. Confirm that you want to delete the guest virtual machine.

In Virtualization Central, verify that the deleted guest virtual machine does not appear.

When you delete a guest virtual machine, all the files and data associated with this guest virtual machine are removed from the virtual server and server pool.

Live Migrating Guest Virtual Machines

Administrators may want to move guest virtual machines to another Oracle VM server for balancing the application workload, or during planned downtime of the Oracle VM server. Enterprise Manager Grid Control allows users to live migrate one or all guest virtual machines. Applications running in the guest virtual machines continue to be accessible during live migration. Live migration ensures high availability of guest virtual machines.

Enterprise Manager Grid Control supports the following live migration cases:

- Live migrate one guest virtual machine to another virtual server

- Live migrate all guest virtual machines from one virtual server to another

This section explains the following:

- Prerequisites

- Live Migrating Selected Guest Virtual Machines

- Live Migrating All Guest Virtual Machines

Prerequisites

Live migration requires the following preconditions to be met:

- The virtual servers participating in the live migration must belong to the same server pool and reside in the same subnet.

- The computer make and model number of both the source computer and the destination computer must be identical.

- The destination computer must have enough memory and free space.

Live Migrating Selected Guest Virtual Machines

To live migrate a guest virtual machine, do the following:

1. In Virtualization Central, select the guest virtual machine you want to live migrate and select Action Guest VM Live Migrate Guest VM. Ensure that the guest virtual machine is in the Running state. Click Go.

2. In the Live Migrate: Guest Virtual Machine page, specify the virtual server to which you want to live migrate the running guest virtual machine and also schedule the guest virtual machine live migration job to run either immediately or later. Select the virtual server allocation type as either Automatic or Manual.

- If you choose Automatic, the system will pick up a suitable virtual server from the server pool for the guest virtual machine live migration.

- If you choose Manual, click Add and select the virtual server from the list of virtual servers available in the server pool.

3. Click OK.

After performing the live migration activity, navigate to Virtualization Central. The guest virtual machines must now be displayed under the new virtual server.

Live Migrating All Guest Virtual Machines

To live migrate all guest virtual machines, do the following:

1. In Virtualization Central, select the virtual server from which you want to live migrate all guest virtual machines, and select Action Virtual Server Live Migrate All Guest VM. Ensure that it is in the Up state.

2. In the Live Migrate: Guest Virtual Machine page, schedule the guest virtual machine live migration job to run either immediately or later. The virtual server allocation type is Automatic.

3. Click OK.

After performing the live migration activity, navigate to Virtualization Central. The guest virtual machines must now be displayed under the new virtual server.

High Availability and Fault Tolerance

Oracle VM server uses Oracle Clusterware to maintain network and storage heartbeat in a cluster of Oracle VM servers. When an Oracle VM server failure is detected, Enterprise Manager Grid Control automatically restarts the guest virtual machines that were running on the failed server on a new Oracle VM server.

This section explains how you can create a cluster and enable high availability (HA). You can create either an NFS-based cluster, or an OCFS2 cluster. In particular, this section covers the following:

- Creating an NFS Cluster for High Availability

- Creating an OCFS2 Cluster for High Availability

- Configuring Oracle VM Servers for High Availability

Creating an NFS Cluster for High Availability

To create an NFS-based cluster for HA:

1. On the master virtual server, start the cluster service:

# /usr/lib/ovs/ovs-cluster-configure

This script generates the /etc/ocfs2/cluster.conf file if it does not already exist, and configures and starts the o2cb service.

2. On the master virtual server, configure the shared storage with /usr/lib/ovs/ovs-makerepo source C description, for example.

# /usr/lib/ovs/ovs-makerepo example.com:/OVS C "cluster root"

3. On the master virtual server, check the cluster has been configured correctly and is running:

# /usr/lib/ovs/ovs-cluster-check --master --alter-fstab

The --master parameter should only be used on the master virtual server. The --alter-fstab parameter modifies the /etc/fstab file. A backup of the original /etc/fstab file is created in /tmp.

4. Log in to Oracle Enterprise Manager and create an HA-enabled server pool. See Configuring Oracle VM Servers for High Availability for steps to enable high availability on server pools.

Creating an OCFS2 Cluster for High Availability

To create an OCFS2-based cluster for HA:

1. On the master virtual server, format a volume to be an OCFS2 partition with the mkfs.ocfs2 utility. For example, to create an OCFS2 partition with a 4k block size, 4k cluster size, and 16 node slots:

# mkfs.ocfs2 -L mylabel -b 4K -C 4K -J size=64M -N 16 /dev/sda1

2. On the master virtual server, start the cluster service:

# /usr/lib/ovs/ovs-cluster-configure

This script generates the /etc/ocfs2/cluster.conf file if it does not already exist, and configures and starts the o2cb service.

3. On the master virtual server, configure the OCFS2 partition as shared storage with /usr/lib/ovs/ovs-makerepo source C description, for example.

# /usr/lib/ovs/ovs-makerepo /dev/sdb1 C "cluster root"

4. Check the cluster has been configured correctly and is running:

# /usr/lib/ovs/ovs-cluster-check --master --alter-fstab

The --master parameter should only be used on the master virtual server. The --alter-fstab parameter modifies the /etc/fstab file. A backup of the original /etc/fstab file is created in /tmp.

5. Log in to Oracle Enterprise Manager and create an HA-enabled server pool. See Configuring Oracle VM Servers for High Availability for steps to enable high availability on server pools.

Configuring Oracle VM Servers for High Availability

You can set up High Availability for Oracle VM to guarantee the availability of guest virtual machines if the Oracle VM server they are running on fails or restarts. When a virtual server is restarted or shut down, the guest virtual machines running on it are either restarted on, or migrated to, another virtual server.

Enabling High Availability mode for the virtual server pool allows all the Oracle VM servers in the pool to be clustered.

To enable High Availability, you will need the following configuration:

- High Availability mode should be enabled for the virtual server pool.

- Clustering configuration should be done for master server and other virtual servers in the server pool.

- High Availability flag must be set for the guest virtual machines.

Steps to enable High Availability

1. When creating a server pool, in the Create Server Pool page, select Enable for the High Availability Mode field.

2. When creating a guest virtual machine, in the Create Guest Virtual Machine: Configure page, select Enable High Availability Mode check box.

3. When editing a guest virtual machine, in the Edit Guest Virtual Machine page, select Enable High Availability Mode check box.

If High Availability is configured for both server pool and the guest virtual machine, if the virtual server is shutdown, the guest virtual machine will be stopped and restarted on another virtual server.

Advanced Operations

This section explains the advanced operations that can be performed in your virtualization environment. In particular, this section explains the following:

- Cloning Guest Virtual Machines

- Saving Guest Virtual Machine as Template

- Bare Metal Provisioning of Oracle VM Servers

Cloning Guest Virtual Machines

Cloning creates a copy of a guest virtual machine on the same server pool. When a guest virtual machine is cloned, the software on the source guest virtual machine is also copied onto the cloned guest virtual machine.

Cloning Phases

The following table describes the phases involved in the provisioning operation:

Table 10-8 Phases for Cloning Guest Virtual Machines

Phase

Description

Select Server Pool

Allows you to specify the number of guest virtual machines to be created. The new guest virtual machines will be associated with the same server pool as the guest virtual machine you are cloning.

Configure

Allows you to configure the disk, network, agent and other details.

Schedule

Allows you to specify the Schedule and Credentials for the provisioning activity.

Review

Allows you to review the information you have provided for provisioning the guest virtual machine.

Prerequisites

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Software component to create the guest virtual machine is available in the Software Library or any other location.

- Guest virtual machine to be cloned must be in the Halted status.

Cloning Procedure

During cloning, new guest virtual machines are created from a source guest virtual machine.

To clone a guest virtual machine, do the following:

1. In Virtualization Central, select the guest virtual machine you want to clone and select Action Guest VM Clone Guest VM. Ensure that it is in the Halted state. Click Go.

2. In the Clone Guest Virtual Machines: Server Pool page, specify the number of guest virtual machines to be created. The new guest virtual machines will be associated with the same server pool as the guest virtual machine you are cloning. You can also select the virtual server for the guest virtual machine manually or allow the server pool to automatically allocate the virtual server. Click Next.

3. In the Clone Guest Virtual Machines: Configure page, configure the guest virtual machines by specifying the values in Table 10-9.

4. In the Clone Guest Virtual Machines: Schedule/Credentials page, provide a schedule for the provisioning and user credentials for the monitoring server and Virtual Server host. The credentials you specify for the Virtual Server host must have sudo privileges.

5. In the Clone Guest Virtual Machines: Review page, review the information you have provided and submit the job.
The cloned guest virtual machine will appear with the status Creating.. in Virtualization Central under the same server pool as the source guest virtual machine. The source guest virtual machine will appear with the status Creating.. in Virtualization Central. If you have selected the Start VM after creation option during cloning, the guest virtual machines will be started after the clone process.

Table 10-9 Clone Guest Virtual Machines

Element

Description

Virtual Machine Name Prefix

Specify the prefix you want to assign to each guest virtual machine name you are creating.

VNC Console Password

Enterprise Manager Grid Control provides a VNC console to the newly created guest virtual machine. This is the VNC password to access the VNC console.

Number of Network Interfaces

Number of virtual network interfaces for this guest virtual machine will be the same as the source guest virtual machine.

Start VM after creation

Specify whether the guest virtual machine should be started automatically after it is created.

Enable High Availability Mode

When creating the guest virtual machine, if the "High Availability" flag is selected, this guest virtual machine will participate in the High Availability functionality. If its parent virtual server fails, this guest virtual machine will be auto-restarted on another Oracle VM server.

Additional Disks

Every guest virtual machine is created with at least one disk. Specify additional disks and their sizes. These disks will be added to the guest virtual machine. After the guest virtual machine is created, log in to the guest virtual machine and reformat and mount the additional disks.

Shared Disks

Oracle VM allows sharing of disks between multiple guest virtual machines. Specify a shared disk that the guest virtual machine can access.

Saving Guest Virtual Machine as Template

A guest virtual machine can be saved as a template in the Software Library or an external location and used for provisioning other guest virtual machines.

Saving a Guest Virtual Machine as a Template

1. In Virtualization Central, choose the guest virtual machine you want to save, select Action Guest VM, Save Guest VM as Template and click Go. Ensure that the guest virtual machine is in the Halted status.

2. In the Create Component: Describe page, specify the creation method as:

- From Existing Guest VM to store an existing guest VM configuration details.

Specify the template name and OS details. Click Next.

3. In the Create Component: Configure page, specify the external location to store the template. The template can then be imported to server pools that can access this location. Specify the monitoring server and virtual server credentials.
Click Next.

4. In the Create Component: Review page, review the information you have provided and click Submit.

The template will be saved in the location you specified. The template saved will be imported to the server pool to which the Halted guest virtual machine belongs, you can view the imported template in the Server Pool Resources page.

Bare Metal Provisioning of Oracle VM Servers

Enterprise Manager Grid Control allows you to provision Oracle VM server software on bare metal machines. For information about bare metal provisioning, see Provisioning Linux.

During bare metal provisioning of Oracle VM server, the Management Agent will not be installed. After completing bare metal provisioning, register the Oracle VM server with the server pool using the steps explained in Registering Virtual Servers.

Migrating from Oracle VM Manager to Enterprise Manager

If you are using Oracle VM Manager to manage Oracle VM servers, guest virtual machines, and resources, and want to move to Enterprise Manager to manage your Oracle VM systems, follow these steps:

1. Delete the virtual server from Oracle VM Manager. For information about deleting a virtual server from Oracle VM Manager, see Oracle VM Manager User's Guide available at http://download.oracle.com/docs/cd/E11081_01/doc/doc.21/e10901/toc.htm

2. Shutdown the virtual server.

3. Create virtual server pool in Enterprise Manage. For information about creating virtual server pools, see Creating Server Pools.

4. Register virtual servers with the server pool. For information about registering virtual servers, see Registering Virtual Servers.

5. Create guest virtual machines. For information about creating guest virtual machines, see Creating Guest Virtual Machines.

Part V

Middleware Provisioning

This part describes the Deployment Procedures you can run for provisioning Middleware targets. In particular, this part the Deployment Procedures for:

- Chapter 11, "Provisioning Oracle Application Server"

- Chapter 12, "Provisioning Oracle Service Bus Resources"

- Chapter 13, "Provisioning Oracle BPEL Processes"

11 Provisioning Oracle Application Server

This chapter explains how you can provision Oracle Application Servers. In particular, this chapter covers the following:

- Deployment Procedures, Supported Releases, and Core Components Deployed

- Provisioning Oracle Application Server 10g Release 1 (10.1.3)

- Provisioning Oracle Application Server 10g Release 1 (10.1.2.0.2)

- Provisioning Oracle SOA Suite 10g (10.1.3.x)

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle Application Server. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Oracle Application Server. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 11-1 Getting Started with Provisioning Oracle Application Server

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle Application Server. Know how the Deployment Procedure functions, what use cases it covers, what releases it supports, and what core components it provisions.

To learn about the Deployment Procedure, see Deployment Procedures, Supported Releases, and Core Components Deployed.

Selecting the Release to Provision

This chapter covers use cases for different releases of Oracle Application Server. Identify the release you want to provision and understand the use cases that are covered for each release.

- To learn about provisioning Oracle Application Server 10g Release 1 (10.1.3), see Provisioning Oracle Application Server 10g Release 1 (10.1.3).

- To learn about provisioning Oracle Application Server 10g Release 1 (10.1.2.0.2), see Provisioning Oracle Application Server 10g Release 1 (10.1.2.0.2).

- To learn about provisioning Oracle SOA Suite 10g (10.1.3.x), see Provisioning Oracle SOA Suite 10g (10.1.3.x).

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for provisioning Oracle Application Server, access the reference links provided for Step (2) and navigate to the Prerequisites subsection.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle Application Server.

To provision Oracle Application Server, access the reference links provided for Step (2) and navigate to the Provisioning Procedure subsection.

Deployment Procedures, Supported Releases, and Core Components Deployed

Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning Oracle Application Server:

Deployment Procedure

Supported Releases

Core Components Deployed

Application Server Deployment (myJ2EE) 10.1.2.0.2

Oracle Application Server 10g Release 2 (10.1.2.0.2)

- Application tier

- Web tier

Application Server Deployment 10.1.3

Oracle Application Server 10g Release 3 (10.1.3.x)

- Application tier

- Web tier

Application Server Deployment 10.1.3.xSOA

Oracle SOA Suite 10g (10.1.3.x)

Deploys Oracle SOA Suite 10g (10.1.3.x) with the application tier and Web tier of Oracle Application Server 10g Release 3 (10.1.3.x)

Note:

These Deployment Procedures do not install the database tier. However, they facilitate the configuration of Java Authentication and Authorization Service (JAAS) provider (also called as JAZN) with an existing data tier.

Oracle Application Server you want to provision may be available in different formats such as an installation kit in the installation medium, a running instance on a host monitored by Enterprise Manager Grid Control, or even a gold image in Oracle Software Library (Software Library).

Using the Application Server Deployment 10.1.3 Deployment Procedure, you can provision any of these formats. However, using the Application Server Deployment (myJ2EE) 10.1.2.0.2 Deployment Procedure, you can provision only a new installation using the software binaries stored in the Software Library.

For example, if you want to have a new installation of Oracle Application Server 10g Release 3 (10.1.3.x), the recommended option is to store the software binaries of the application server from an installation medium onto the Software Library, and then provision it from the Software Library. However, if you want to have a copy of a running instance that is stable and has all the latest patches applied, the recommended option is to clone that existing instance so that you retain the same configuration settings. Similarly, if you have created a gold image of this stable, well-patched application server instance in the Software Library, then you can use it to deploy a similar instance in your enterprise configuration.

Note:

Provisioning of a gold image from the Software Library is not supported for Microsoft Windows Vista.

Provisioning Oracle Application Server 10g Release 1 (10.1.3)

This section describes how you can provision Oracle Application Server 10g Release 1 (10.1.3). In particular, this section covers the following:

- Cloning a Running Oracle Application Server Instance

- Provisioning a New Installation or Gold Image of Oracle Application Server

Cloning a Running Oracle Application Server Instance

This section describes how you can clone an existing Oracle Application Server instance that is running on a host monitored by Enterprise Manager Grid Control.

This option is best suited when you have a running instance of Oracle Application Server that is stable and has all the latest patches applied, and you want to make identical copies of it on multiple hosts.

However, the risk involved in using a existing instance is that the instance may be deleted or deinstalled anytime without prior notice, and as a result, the Deployment Procedure may fail. Therefore, use this option when you know that the running instance is available for cloning.

This section covers the following:

- Cloning from an Existing Cluster, Scaling Up the Existing Cluster, and Using the Same Internet Directory

- Provisioning from an Existing Cluster and Creating a New Cluster Without Internet Directory

- Provisioning from an Existing Cluster and Creating a New Cluster With Internet Directory

Cloning from an Existing Cluster, Scaling Up the Existing Cluster, and Using the Same Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3) from an existing cluster, extend the cluster to include the new node, and by using the same Internet Directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment. Enterprise Manager Grid Control displays the Source Selection page of the Deployment Procedure.

4. On the Source Selection page, in the Source Selection section, in the Select the source Oracle Homes from the Installed Cluster Environment subsection, do the following:

1. Retain the default selection, that is, Select from Existing Cluster Installation.

2. From the Select Cluster list, select an existing cluster from where the Web tier and application tier can be deployed. On selection of an existing cluster, the table gets populated with information about the Web tier and application tier that are part of it.

3. In the table, for Files to Exclude, specify the files in the Oracle home that you do not want to include while running this Deployment Procedure. You can specify either the file names or the file extensions, and separate multiple entries with a comma.
And for Working Directory, retain the default value or specify another location that already exists on the source host and can be used to stage the file for cloning.

4. If you want to deploy only one of the two products (application server or web server) from the selected source cluster, then click Reset to delete all values in the table. Once the values are reset, click the torch icon corresponding to the product that you want to deploy, and select the required target.

5. If you want to save the Oracle homes as an image in the Software Library, select Save to Software Library.

6. Click Next.

Note:

When you click Next, if there are no prerequisites in the Software Library for that particular platform, then you will see Next, Ignore Warnings option. In this case, you can do one of the following:

- Upload the components to the Software Library under Components/Oracle Components/Prerequisite-fixup components/<Platform name>/Prerequisite-Fixup component and click Next.

- Click Next, Ignore Warnings to skip the prerequisite check while running the Deployment Procedure.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, retain the default selection, that is, Extend existing cluster.

2. In the Instance Details section, retain the default instance names, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, retain the default port number (7777) that is displayed if Oracle Web Cache is not configured.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, retain the default selection.

7. Click Next.

8. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

9. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning from an Existing Cluster and Creating a New Cluster Without Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3) from an existing cluster, and create a new cluster without Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the source Oracle Homes from the Installed Cluster Environment subsection, do the following:

1. Retain the default selection, that is, Select from Existing Cluster Installation.

2. From the Select Cluster list, select an existing cluster from where the Web tier and application tier can be deployed. On selection of an existing cluster, the table gets populated with information about the Web tier and application tier that are part of it

3. In the table, for Files to Exclude, specify the files in the Oracle home that you do not want to include while running this Deployment Procedure. You can specify either the file names or the file extensions, and separate multiple entries with a comma.
And for Working Directory, retain the default value or specify another location that already exists on the source host and can be used to stage the file for cloning.

4. If you want to deploy only one of the two products (application server or web server) from the selected source cluster, then click Reset to delete all values in the table. Once the values are reset, click the torch icon corresponding to the product that you want to deploy, and select the required target.

5. If you want to save the Oracle homes as an image in the Software Library, select Save to Software Library.

6. Click Next.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Create new Cluster. By default, Grid Control prefills the details based on an existing cluster. You can either use the default values or specify a new cluster name, installation directory, and multicast address and port. Also ensure that the multicast address and port are different from the ones configured for the source cluster.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively.

For Multicast Address, ensure that the address is within the range of 224.0.0.0 and 239.255.255.255. This is a single IP address for a set of nodes that are joined in a multicasting group.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select None.

7. Click Next.

8. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

9. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning from an Existing Cluster and Creating a New Cluster With Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3) from an existing cluster, and create a new cluster with Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the source Oracle Homes from the Installed Cluster Environment subsection, do the following:

1. Retain the default selection, that is, Select from Existing Cluster Installation.

2. From the Select Cluster list, select an existing cluster from where the Web tier and application tier can be deployed. On selection of an existing cluster, the table gets populated with information about the Web tier and application tier that are part of it

3. In the table, for Files to Exclude, specify the files in the Oracle home that you do not want to include while running this Deployment Procedure. You can specify either the file names or the file extensions, and separate multiple entries with a comma.
And for Working Directory, retain the default value or specify another location that already exists on the source host and can be used to stage the file for cloning.

4. If you want to deploy only one of the two products (application server or web server) from the selected source cluster, then click Reset to delete all values in the table. Once the values are reset, click the torch icon corresponding to the product that you want to deploy, and select the required target.

5. If you want to save the Oracle homes as an image in the Software Library, select Save to Software Library.

6. Click Next. Enterprise Manager Grid Control displays the Target List page.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Create new Cluster. By default, Grid Control prefills the details based on an existing cluster. You can either use the default values or specify a new cluster name, installation directory, and multicast address and port. Also ensure that the multicast address and port are different from the ones configured for the source cluster.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively.

For Multicast Address, ensure that the address is within the range of 224.0.0.0 and 239.255.255.255. This is a single IP address for a set of nodes that are joined in a multicasting group.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select Configure Java Authentication and Authorization Service (JAZN) with a LDAP-based provider.
Using this option, you can set up JAZN LDAP-based provider for authentication and authorization for OC4J application.

Java Authentication and Authorization Service (JAAS) is a Java package that enables services and applications to authenticate and enforce access controls upon users. Oracle Application Server 10g Containers for J2EE (OC4J) supports JAAS by implementing a JAAS provider (also called as JAZN).

The JAAS provider provides application developers with user authentication, authorization, and delegation services to integrate into their application environments. It also supports JAAS policies. Policies contain the rules (permissions) that authorize a user to use resources, such as reading a file and so on.

7. Click Next. Enterprise Manager Grid Control displays the Identity Management page.

8. On the Identity Management page, do the following:

1. In the Identity Management Host Details section, specify the connection information for the Internet Directory to be used for Identity Management of the Oracle Application Server users and groups. If you do not have an Internet Directory installed, install it using the OracleAS Infrastructure component.

2. In the Internet Directory Login Details section, specify credentials of the user who belongs to the iASAdmin group in the Internet Directory.

3. Click Next. Enterprise Manager Grid Control displays the Configure Oracle Home page.

9. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

10. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning a New Installation or Gold Image of Oracle Application Server

This section describes how you can provision a new installation or a gold image of Oracle Application Server. In particular, this section covers the following:

- Provisioning and Creating a New Cluster Without Internet Directory

- Provisioning and Creating a New Cluster With Internet Directory

- Provisioning and Treating It as a Standalone Instance Without Internet Directory

- Provisioning and Treating It as a Standalone Instance With Internet Directory

Provisioning and Creating a New Cluster Without Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical either to the ones available on the installation medium or a gold image available in the Software Library, and create a new cluster without Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the Gold Image of an Oracle Home or a shiphome from the Software Library subsection, do the following:

1. Select Select from Software Library.

2. In the Source for Web Tier section, click the torch icon and select the generic component that contains the Web tier.

3. In the Source for App Tier section, click the torch icon and select the generic component that contains the application tier.

Note:

When you click the torch icon to search for components, the Select Component page displays the components available in the Software Library.

- If you want to deploy a fresh installation, then select the shiphome component that is in "Ready" status. By default, the Select Component page does not display components with "Active" status.

- If you want to deploy a gold image, then select the gold image component that is either in "Ready" or "Active" status.

4. Click Next.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Create new Cluster. By default, Grid Control prefills the details based on an existing cluster. You can either use the default values or specify a new cluster name, installation directory, and multicast address and port. Also ensure that the multicast address and port are different from the ones configured for the source cluster.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively.

For Multicast Address, ensure that the address is within the range of 224.0.0.0 and 239.255.255.255. This is a single IP address for a set of nodes that are joined in a multicasting group.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select None.

7. Click Next.

8. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

9. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning and Creating a New Cluster With Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical either to the ones available on the installation medium or a gold image available in the Software Library, and create a new cluster with Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the Gold Image of an Oracle Home or a shiphome from the Software Library subsection, do the following:

1. Select Select from Software Library.

2. In the Source for Web Tier section, click the torch icon and select the generic component that contains the Web tier.

3. In the Source for App Tier section, click the torch icon and select the generic component that contains the application tier.

Note:

When you click the torch icon to search for components, the Select Component page displays the components available in the Software Library.

- If you want to deploy a fresh installation, then select the shiphome component that is in "Ready" status. By default, the Select Component page does not display components with "Active" status.

- If you want to deploy a gold image, then select the gold image component that is either in "Ready" or "Active" status.

4. Click Next.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Create new Cluster. By default, Grid Control prefills the details based on an existing cluster. You can either use the default values or specify a new cluster name, installation directory, and multicast address and port. Also ensure that the multicast address and port are different from the ones configured for the source cluster.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively.

For Multicast Address, ensure that the address is within the range of 224.0.0.0 and 239.255.255.255. This is a single IP address for a set of nodes that are joined in a multicasting group.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select Configure Java Authentication and Authorization Service (JAZN) with a LDAP-based provider.
Using this option, you can set up JAZN LDAP-based provider for authentication and authorization for OC4J application.

Java Authentication and Authorization Service (JAAS) is a Java package that enables services and applications to authenticate and enforce access controls upon users. Oracle Application Server 10g Containers for J2EE (OC4J) supports JAAS by implementing a JAAS provider (also called as JAZN).

The JAAS provider provides application developers with user authentication, authorization, and delegation services to integrate into their application environments. It also supports JAAS policies. Policies contain the rules (permissions) that authorize a user to use resources, such as reading a file and so on.

7. Click Next.

8. On the Identity Management page, do the following:

1. In the Identity Management Host Details section, specify the connection information for the Internet Directory to be used for Identity Management of the Oracle Application Server users and groups. If you do not have an Internet Directory installed, install it using the OracleAS Infrastructure component.

2. In the Internet Directory Login Details section, specify credentials of the user who belongs to the iASAdmin group in the Internet Directory.

3. Click Next.

9. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

10. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning and Treating It as a Standalone Instance Without Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical either to the ones available on the installation medium or a gold image available in the Software Library, and treat that as a standalone instance without Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the Gold Image of an Oracle Home or a shiphome from the Software Library subsection, do the following:

1. Select Select from Software Library.

2. In the Source for Web Tier section, click the torch icon and select the generic component that contains the Web tier.

3. In the Source for App Tier section, click the torch icon and select the generic component that contains the application tier.

Note:

When you click the torch icon to search for components, the Select Component page displays the components available in the Software Library.

- If you want to deploy a fresh installation, then select the shiphome component that is in "Ready" status. By default, the Select Component page does not display components with "Active" status.

- If you want to deploy a gold image, then select the gold image component that is either in "Ready" or "Active" status.

4. Click Next.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Standalone AS.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select None.

7. Click Next.

8. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

9. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning and Treating It as a Standalone Instance With Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical either to the ones available on the installation medium or a gold image available in the Software Library, and treat that as a standalone instance with Internet directory.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Compare the configuration of the source and target hosts and ensure that they have the same configuration. If the configurations are different, then contact your system administrator and fix the inconsistencies before running the Deployment Procedure.
To compare the configuration of the hosts, in Grid Control, click Targets and then Hosts. On the Hosts page, click the name of the source host to access its Home page, and then click the Configuration tab. On the Configuration page, click Compare Configuration and select the target host.

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Source Selection page, in the Source Selection section, in the Select the Gold Image of an Oracle Home or a shiphome from the Software Library subsection, do the following:

1. Select Select from Software Library.

2. In the Source for Web Tier section, click the torch icon and select the generic component that contains the Web tier.

3. In the Source for App Tier section, click the torch icon and select the generic component that contains the application tier.

Note:

When you click the torch icon to search for components, the Select Component page displays the components available in the Software Library.

- If you want to deploy a fresh installation, then select the shiphome component that is in "Ready" status. By default, the Select Component page does not display components with "Active" status.

- If you want to deploy a gold image, then select the gold image component that is either in "Ready" or "Active" status.

4. Click Next.

5. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

6. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Agent Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

3. In the Source Oracle Home Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.
To override the preferred credentials with another set of credentials, select Override Preferred Credentials. From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

4. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

5. Click Next.

7. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, select Standalone As.

2. In the Instance Details section, specify unique instance names for the Web tier instance and application tier instance, and specify the OC4J administrator password for the source host and the target host.
You can always change the default instance names with any other custom names. However, ensure that the names you specify are unique because, by default, the host name and domain name of that host are appended to the instance name you specify here.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in the Additional Parameters section. For more information, see Step 7 (e).

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host and listener ports to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777. Select Enable SSL if you want to secure the communications.

4. In the Load Balancer Details section, select Configure Load Balancer and provide the required information if you have an F5 BIG-IP Local Traffic Manager load balancer configured.

NOTE:

Enterprise Manager Grid Control supports only F5 BIG-IP Local Traffic Manager. If you have any other load balancer, then deselect Configure Load Balancer, and manually configure that load balancer and the HTTP servers associated with it. Do not use this section in this case.

5. In the Additional Parameters section, specify any additional Web tier-specific or application tier-specific parameters you want to pass to the Deployment Procedure. For example, -debug. You can specify any other Oracle Universal Installer (OUI) parameter that can be in this provisioning operation.

IMPORTANT:

If you are cloning an application server with multiple OC4J instances that have different passwords, then ensure that you use the -force command as an additional parameter in this section.
This is to ensure that the password you specify in the Instance Details section is uniformly propagated to all OC4J instances that are being provisioned.

However, if you still want to maintain different passwords for the provisioned OC4J instances, then after the deployment procedure ends successfully, access the application server console and change the passwords for the individual OC4J instances.

6. In the Identify Management Configuration section, select Configure Java Authentication and Authorization Service (JAZN) with a LDAP-based provider.
Using this option, you can set up JAZN LDAP-based provider for authentication and authorization for OC4J application.

Java Authentication and Authorization Service (JAAS) is a Java package that enables services and applications to authenticate and enforce access controls upon users. Oracle Application Server 10g Containers for J2EE (OC4J) supports JAAS by implementing a JAAS provider (also called as JAZN).

The JAAS provider provides application developers with user authentication, authorization, and delegation services to integrate into their application environments. It also supports JAAS policies. Policies contain the rules (permissions) that authorize a user to use resources, such as reading a file and so on.

7. Click Next.

8. On the Identity Management page, do the following:

1. In the Identity Management Host Details section, specify the connection information for the Internet Directory to be used for Identity Management of the Oracle Application Server users and groups. If you do not have an Internet Directory installed, install it using the OracleAS Infrastructure component.

2. In the Internet Directory Login Details section, specify credentials of the user who belongs to the iASAdmin group in the Internet Directory.

3. Click Next. Enterprise Manager Grid Control displays the Configure Oracle Home page.

9. On the Configure Oracle Home page, do the following:

1. If the hosts where the Web tier and application tier are being provisioned have 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the hosts where the Web tier and application tier are being provisioned have 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned application server.

3. If the hosts where the Web tier and application tier are being provisioned do 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

4. Click Next.

10. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Submit.

Provisioning Oracle Application Server 10g Release 1 (10.1.2.0.2)

This section describes how you can provision Oracle Application Server 10g Release 1 (10.1.2.0.2). In particular, this section covers the following:

- Provisioning Oracle Application Server and Creating a New Cluster Without Internet Directory

- Provisioning Oracle Application Server and Creating a New Cluster With Internet Directory

Note:

You can provision Oracle Application Server 10g Release 1 (10.1.2.0.2) only using the software binaries archived from the installation medium and stored in the Software Library.

Provisioning Oracle Application Server and Creating a New Cluster Without Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical to the ones available on the installation medium, and create a new cluster without Internet directory.

This option is best suited when you want a completely new installation to be provisioned across multiple hosts. Of course, understandably, this is a fresh installation and you will have to update it with all the latest patches that have been released so far.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

5. On the Upload page, from the Shiphomes from Software Library section, click Upload to select a component from the software library that contains the gold images of the application tier and Web tier that you want to deploy.

6. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, for Cluster Name, specify a name for the cluster. Alternatively, you can retain the default name provided.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively. For example, if you specify /scratch/appserver/ as the Web tier install base directory, then the Web tier is installed in /scratch/appserver/10gWebTier.

2. In the Instance Details section, for Instance Name, specify a unique name and the ias_admin password. Alternatively, you can retain the default name provided.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host, the listener port, and the Application Server Control port to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777 and 1810, for Oracle HTTP Server Port and Application Server Control port, respectively. Select Enable SSL if you want to secure the communications.

4. In the Identify Management Configuration section, select None.

5. Click Next.

7. On the Library Step Properties page, specify property values for the custom library steps, and click Next.

8. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

3. Click Next.

9. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Finish.

Provisioning Oracle Application Server and Creating a New Cluster With Internet Directory

This section describes how you can provision the application tier and Web tier of Oracle Application Server 10g Release 1 (10.1.3), which are identical to the ones available on the installation medium, and create a new cluster with Internet directory.

This option is best suited when you want a completely new installation to be provisioned across multiple hosts. Of course, understandably, this is a fresh installation and you will have to update it with all the latest patches that have been released so far.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- If you are deploying multiple Web tiers, then ensure that a Software Load Balancer is set up and is accessible from the Web tier's hosts.
The Software Library provides a script to configure the F5 Big IP Application Switch (Software Version 4.5 PTF.5) load balancer on the selected Web tiers. For other systems such as Cisco CSM 3.1, overwrite the script with your specific configuration. The script is available in the following location of the Software Library:

Directives/Oracle Directives/Loadbalancer

- Ensure that the installation base directory, where the Web tier and application tier will be installed, is accessible (but not shared) on all target hosts.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision a Web tier and an application tier, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Application Server Provisioning Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Application Server Deployment 10.1.3. Then click Schedule Deployment.

4. On the Target List page, do the following:

1. In the Web Tier Hosts section, click Add to add hosts on which you want to deploy the Web tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the application tier.

2. In the Application Tier Hosts section, click Add to add hosts on which you want to deploy the application tier. Ensure that the platform of this host is the same as the platform of the host on which you want to deploy the Web tier.

3. Click Next.

5. On the Upload page, from the Shiphomes from Software Library section, click Upload to select a component from the software library that contains the gold images of the application tier and Web tier that you want to deploy.

6. On the Application and Web Tier page, do the following:

1. In the Cluster Details section, for Cluster Name, specify a name for the cluster. Alternatively, you can retain the default name provided.
For Web Tier Install Base Directory and Application Tier Install Base Directory, ensure that you specify the absolute path to the directory where you want to deploy the Web tier and application tier, respectively. For example, if you specify /scratch/appserver/ as the Web tier install base directory, then the Web tier is installed in /scratch/appserver/10gWebTier.

2. In the Instance Details section, for Instance Name, specify a unique name and the ias_admin password. Alternatively, you can retain the default name provided.

IMPORTANT:

- Each Oracle Application Server 10g instance has its own password, regardless of which user performed the installation. Passwords are not shared across instances, even if the instances were installed by the same user.

- The passwords you specify here must contain a minimum of 5 and a maximum of 30 alphanumeric characters. It can include underscore (_), dollar ($), or pound (#) characters. It must start with an alphabet and must contain at least one numeric value.

3. In the Port Details section, specify the HTTP load balancer host, the listener port, and the Application Server Control port to manage HTTP connections made by client applications. Alternatively, you can retain the default value, that is, 7777 and 1810, for Oracle HTTP Server Port and Application Server Control port, respectively. Select Enable SSL if you want to secure the communications.

4. In the Identify Management Configuration section, select Configure Java Authentication and Authorization Service (JAZN) with a LDAP-based provider.

5. Click Next.

7. On the Identity Management page, do the following:

1. In the Identity Management Host Details section, specify the connection information for the Internet Directory to be used for Identity Management of the Oracle Application Server users and groups. If you do not have an Internet Directory installed, install it using the OracleAS Infrastructure component.

2. In the Internet Directory Login Details section, specify credentials of the user who belongs to the iASAdmin group in the Internet Directory.

3. Click Next.

8. On the Library Step Properties page, specify property values for the custom library steps, and click Next.

9. On the Credentials/Schedule page, do the following:

1. In the Target Host Credentials section, retain the default section, that is, Preferred Credentials so that the preferred credentials stored in the Management Repository can be used.

Note:

You can optionally override these preferred credentials. The credentials you specify here are used by the Deployment Procedure to run the provisioning operation. If this environment is secure and has locked accounts, then make sure that:

- The credentials you specify here have the necessary privileges to switch to the locked account for performing the provisioning operation.

- The Deployment Procedures has been customized to support locked environments.

For more information, see Chapter 23, "Customizing Steps to Run as Another User".

From the Host Credentials list, select Same for all Oracle Homes if you want to use the same operating system credentials across hosts, or select Different for each Oracle Home if you want to use different credentials for each host. According to the selection you make, specify the credentials. Ensure that the users belong to the same operating system group.

2. In the Schedule section, schedule the Deployment Procedure to run either immediately or later.

3. Click Next.

10. On the Review page, review the details you have provided for provisioning a Web tier and application tier, and click Finish.

Provisioning Oracle SOA Suite 10g (10.1.3.x)

The use cases and the prerequisites and deployment instructions for each of the use cases for provisioning Oracle SOA Suite 10g (10.1.3.x) are almost the same as the ones described in Provisioning Oracle Application Server 10g Release 1 (10.1.3).

The only differences are:

- You cannot provision Oracle SOA Suite using the software binaries from an installation medium.

- In Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Application Server Deployment 10.1.3.xSOA. Then click Schedule Deployment.

12 Provisioning Oracle Service Bus Resources

Oracle Service Bus is an enterprise-class service bus that connects, manages, and mediates interactions between heterogeneous services. Oracle Service Bus accelerates service configuration, integration, and deployment, thus simplifying management of shared services across the Service-Oriented Architecture (SOA). For information about discovering and monitoring Oracle Service Bus, see the Enterprise Manager Getting Started with Management Pack for SOA Guide available at:

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

The resources of Oracle Service Bus can be organized into individual projects. Projects are non-hierarchical, disjointed, top-level grouping constructs. All resources (such as business services, proxy services, WS-Policies, WSDLs, schemas, XQuery transformations, JARs, and so on) reside in exactly one non-overlapping project. Resources can be created directly under a project or be further organized into folders. Folders may be created inside projects or inside other folders, and the folders are similar to directories in a file system, with the project level being the root directory.

While Enterprise Manager Grid Control allows you to discover and monitor these Oracle Service Bus targets, it also provides Deployment Procedures that help you provision Oracle Service Bus resources.

This chapter explains how you can provision Oracle Service Bus resources. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Supported Releases

- Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain

- Provisioning Oracle Service Bus Resources from Oracle Software Library

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle Service Bus resources. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Oracle Service Bus resources. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 12-1 Getting Started with Provisioning Oracle Service Bus Resources

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle Service Bus resources. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

Knowing About The Supported Releases

Know what releases of Oracle Service Bus can be provisioned by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Use Case

This chapter covers a few use cases for provisioning Oracle Service Bus resources. Select the use case that best matches your requirement.

- To learn about provisioning Oracle Service Bus resources from the an Oracle Service Bus domain, see Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain.

- To learn about provisioning Oracle Service Bus resources from the Software Library, see Provisioning Oracle Service Bus Resources from Oracle Software Library.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in provisioning Oracle Service Bus resources from the an Oracle Service Bus domain, see Deployment Phases.

- To learn about the deployment phases involved in provisioning Oracle Service Bus resources from the Software Library, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

- To learn about the prerequisites for provisioning Oracle Service Bus resources from the an Oracle Service Bus domain, see Prerequisites.

- To learn the prerequisites for provisioning Oracle Service Bus resources from the Software Library, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle Service Bus resources.

- To provision Oracle Service Bus resources from the an Oracle Service Bus domain, follow the steps explained in Provisioning Procedure.

- To provision Oracle Service Bus resources from the Software Library, follow the steps explained in Provisioning Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedure for provisioning Oracle Service Bus resources:

- Oracle Service Bus Resource Provisioning

Supported Releases

Using this Deployment Procedure, you can provision the resources for Oracle Service Bus 2.6, 2.6.1, 3.0, and 10gR3 (3.1).

Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain

This section describes how you can provision Oracle Service Bus resources directly from an Oracle Service Bus domain.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 12-2 Deployment Phases Involved in Provisioning Oracle Service Bus Resources from Oracle Service Bus Domain

Phase

Description

Select Source

Allows you to select an Oracle Service Bus domain from where the resources can be exported.

Select Projects

Allows you to select the projects you want to export, and optionally enable security options and save the project to the Software Library.

Select Target

Allows you to select the Oracle Service Bus domain where you want to deploy the selected resources, optionally select the settings you want to retain if you have done some customization to the resources, and specify a customization file that can be used to modify the environment settings.

Credentials

Allows you to specify the credentials of the source and target Oracle Service Bus domains, and the credentials of the hosts where the Management Agents are running.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for provisioning Oracle Service Bus resources.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that the source Oracle Service Bus (from where you want to export the resources) is already discovered and monitored in Enterprise Manager Grid Control.

- If you want to use a customization file to customize the environment variables in the changed (target) environment, then you must ensure that the customization file is available as a generic component in Oracle Software Library. For instructions to create generic components, see Setting Up Oracle Software Library.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision Oracle Service Bus resources from a source Oracle Service Bus domain, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Service Bus Resource Provisioning. Then click Schedule Deployment.

4. On the Select Source page, in the Source section, select Oracle Service Bus Domain.

1. For Domain, click the torch icon and select the Oracle Service Bus domain from where the resources can be exported and deployed to a target Oracle Service Bus domain. In the following page of the wizard, you will be allowed to select the domain's projects that you want to export.

2. For BEA Home Directory, specify the full path to the BEA home directory where all BEA product-related files are stored. For example, /home/mark/bea.

3. Click Next.

5. On the Select Projects page, do the following:

1. In the Resource Summary section, select the projects you want to export and deploy to the target OSB domain. The selected projects are exported to a JAR file, and the JAR file is moved to the host where the target OSB domain is running.

Note that the resources of the selected projects that exist in the target OSB domain but not in the exported JAR file will be deleted.

2. In the Export Mode section, do one of the following:
Select Export Projects if you want to export the resources at project level. While deploying the exported JAR file to the target host, the entire project is deployed. This may add, overwrite, or delete resources depending on the availability of resources on the target host.

Select Export Resources if you want to export the resources at resource level. While deploying the exported JAR file to the target host, only the resources are deployed. This may add or overwrite resources depending on the availability of resources on the target host.

To understand these options better, read the use cases described in Understanding Export Modes.

3. (Optional) In the Security Options section, if the projects you want to export contain any resources with sensitive data, then specify a pass-phrase to protect them. The same pass-phrase will be used to import the protected resources during deployment.

4. (Optional) In the Save Projects to Software Library section, select Save Projects to Software Library and specify a component name and location if you want to save the exported project JAR file as a generic component in the Software Library.

By default, the projects you select here are exported to a JAR file and moved to the host where the Administration server of the target Oracle Service Bus domain is running. However, the JAR files are not saved in the Software Library for future use. Using this option, you can save them as a component in the Software Library.

6. On the Select Target page, do the following:

1. In the Target section, specify the following:
For Domain, click the torch icon and select the Oracle Service Bus domain where you want to deploy the selected resources.

For BEA Home Directory, specify the full path to the BEA home directory where all BEA product-related files are stored.

2. (Optional) In the Advanced Options section, select the settings you want to retain if you have done some customization to the resources selected for deployment, and if you want to preserve those changes in the target Oracle Service Bus domain.

Note that for Oracle Service Bus 2.6.x, Security and Policy Configuration, Credentials, and Access Control Policies cannot be preserved.

3. In the Customization section, provide details about the customization file that can be used to modify the environment settings in the target OSB domain.

If you do not want to use a customization file, select None.

If you are using a customization file and if it is available on the host where the target OSB domain is running, then select Use the Customization file on the target host and specify the full path to the location where the file is present.

If the customization file is stored as a generic component in Oracle Software Library, then select Select the customization file from the Software Library and specify the full path to the location in Oracle Software Library where the generic component is stored.

4. Click Next.

7. On the Set Credentials page, specify the following and click Next.

1. Specify the login credentials of the source and target Oracle Service Bus (OSB) domains.

2. Specify the credentials of the hosts where the Management Agents, which are monitoring the administration servers of the OSB domains, are running

8. On the Schedule page, schedule the deployment procedure to run immediately or later, and specify a unique name for the deployment procedure so that it can be tracked. Click Next. Enterprise Manager Grid Control displays the Review page.

9. On the Review page, review the details you have provided for provisioning Oracle Service Bus resources, and click Submit.

Understanding Export Modes

The following describes the different use cases and explains how the export modes will work for those circumstances.

While the first column shows the project selected from the source domain and the resources contained in that selected project, the second column shows the availability of that project in the target domain. And, while the third column shows how Export at Project Level work, the fourth column shows how Export at Resource Level works.

Table 12-3 Understanding Export Modes

Source Domain

Target Domain

Export at Project Level

Export at Resource Level

You have selected Project_1 from the source domain, and this project has Resource_1, Resource_2, and Resource_3.

The target domain has no projects at all.

The entire Project_1 will be deployed to the target domain.

The entire Project_1 will be deployed to the target domain.

You have selected Project_1 from the source domain, and this project has Resource_1, Resource_2, and Resource_3.

The target domain has Project_1, and this project has Resource_1.

The entire Project_1 will be deployed to the target domain, wherein, Resource_1 will be overwritten because it is already available in the target domain, and Resource_2 and Resource_3 will be ADDED.

Only the resources of Project_1 will be deployed to the target domain, wherein, Resource_1 will be overwritten because it is already available in the target domain, and Resource_2 and Resource_3 will be ADDED.

You have selected Project_1 from the source domain, and this project has Resource_1.

The target domain has Project_1, and this project has Resource_1, Resource_2, and Resource_3.

The entire Project_1 will be deployed to the target domain, wherein, Resource_1 will be overwritten because it is already available in the target domain, and Resource_2 and Resource_3 will be DELETED.

Only the resources of Project_1 will be deployed to the target domain, wherein, only Resource_1 will be overwritten because it is already available in the target domain. The other two resources already available in the target domain, that is, Resource_2 and Resource_3 will NOT be affected.

Provisioning Oracle Service Bus Resources from Oracle Software Library

This section describes how you can provision Oracle Service Bus resources from the Software Library.

In particular, this section covers the following:

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 12-4 Deployment Phases Involved in Provisioning Oracle Service Bus Resources from Oracle Software Library

Phase

Description

Select Source

Allows you to select the generic component, which contains the resources to be exported, from the Software Library.

Select Target

Allows you to select the Oracle Service Bus domain where you want to deploy the selected resources, optionally select the settings you want to retain if you have done some customization to the resources, and specify a customization file that can be used to modify the environment settings.

Credentials

Allows you to specify the credentials of the source and target Oracle Service Bus domains, and the credentials of the hosts where the Management Agents are running.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for provisioning Oracle Service Bus resources.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Export the resources of an Oracle Service Bus domain as a JAR file. Use Oracle Service Bus console for this.

- Ensure that the JAR file is available as a generic component in Oracle Software Library. For instructions to create generic components, see Setting Up Oracle Software Library.

- If you want to use a customization file to customize the environment variables in the changed (target) environment, then you must ensure that the customization file is available as a generic component in Oracle Software Library. For instructions to create generic components, see Setting Up Oracle Software Library.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision Oracle Service Bus resources from a source Oracle Service Bus domain, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Service Bus Resource Provisioning. Then click Schedule Deployment.

4. On the Select Source page, in the Source section, select Oracle Software Library.

1. For Component, click the torch icon and select the generic component that contains the resources to be deployed to a target Oracle Service Bus domain.

2. (Optional) For Pass Phrase, specify a pass-phrase if any of the resources in the JAR file contain sensitive data and are protected. The same pass-phrase is used while importing these resources to the target domain.

3. Click Next. Enterprise Manager Grid Control displays Select Target page.

5. On the Select Target page, do the following:

1. In the Target section, specify the following:
For Domain, click the torch icon and select the Oracle Service Bus domain where you want to deploy the selected resources.

For BEA Home Directory, specify the full path to the BEA home directory where all BEA product-related files are stored.

2. (Optional) In the Options section, select the settings you want to retain if you have done some customization to the resources selected for deployment, and if you want to preserve those changes in the target Oracle Service Bus domain.

Note that for Oracle Service Bus 2.6.x, Security and Policy Configuration, Credentials, and Access Control Policies cannot be preserved.

3. In the Customization section, provide details about the customization file that can be used to modify the environment settings in the target OSB domain.

If you do not want to use a customization file, select None.

If you are using a customization file and if it is available on the host where the target OSB domain is running, then select Use the Customization file on the target host and specify the full path to the location where the file is present.

If the customization file is stored as a generic component in Oracle Software Library, then select Select the customization file from the Software Library and specify the full path to the location in Oracle Software Library where the generic component is stored.

4. Click Next.

6. On the Set Credentials page, specify the following and click Next.

1. Specify the login credentials of the source and target Oracle Service Bus (OSB) domains.

2. Specify the credentials of the hosts where the Management Agents, which are monitoring the administration servers of the OSB domains, are running

7. On the Schedule page, schedule the deployment procedure to run immediately or later, and specify a unique name for the deployment procedure so that it can be tracked. Click Next. Enterprise Manager Grid Control displays the Review page.

8. On the Review page, review the details you have provided for provisioning Oracle Service Bus resources, and click Submit.

13 Provisioning Oracle BPEL Processes

Business Process Execution Language (BPEL) is an XML-based language for enabling task sharing across multiple enterprises using a combination of Web services. BPEL is based on the XML schema, simple object access protocol (SOAP), and Web services description language (WSDL). BPEL provides enterprises with an industry standard for business process orchestration and execution.

Oracle BPEL Process Manager (BPEL Process Manager) provides a framework for easily designing, deploying, monitoring, and administering processes based on BPEL standards. For information about discovering and monitoring these SOA applications, see the Enterprise Manager Getting Started with Management Pack for SOA Guide available at:

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

While Enterprise Manager Grid Control allows you to discover and monitor these BPEL Process Managers, it also provides Deployment Procedures that help you provision BPEL processes on BPEL Process Managers.

This chapter explains how you can provision BPEL processes on BPEL Process Managers. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Supported Releases

- Provisioning Oracle BPEL Processes

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in provisioning Oracle BPEL processes. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully provision Oracle BPEL processes. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 13-1 Getting Started with Provisioning Oracle BPEL Processes

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for provisioning Oracle BPEL processes. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

Knowing About The Supported Releases

Know what releases of Oracle BPEL Process Manager are supported by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

To learn about the deployment phases involved in provisioning Oracle BPEL processes, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the provisioning environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for provisioning Oracle BPEL processes, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully provision Oracle BPEL processes.

To provision Oracle BPEL processes, follow the steps explained in Provisioning Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedure for provisioning BPEL processes on BPEL Process Managers:

- BPEL Process Provisioning

Supported Releases

Using this Deployment Procedure, you can provision BPEL processes for Oracle BPEL Process Manager 10.1.3.1, 10.1.3.3, and 10.1.3.4.

Provisioning Oracle BPEL Processes

This section describes how you can provision BPEL processes for Oracle BPEL Process Manager.

In particular, this section covers the following:

- Deployment Phases

- Prerequisites

- Provisioning Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 13-2 Deployment Phases Involved in Provisioning Oracle BPEL Processes

Phase

Description

Source Selection

Allows you to select the BPEL Process suitcase files that you want to deploy and a deployment plan that can be associated with a BPEL process suitcase file.

Target Selection

Allows you to select the BPEL Process Managers on which you want to deploy the BPEL processes.

Credentials

Allows you to specify application server credentials and BPEL administrator credentials.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for provisioning Oracle BPEL processes.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Ensure that BPEL Process Manager on which the process suitcase files have to be deployed is already discovered and monitored in Enterprise Manager Grid Control.

- Store the BPEL process suitcase files as generic components in the Software Library. For instructions to create generic components, see Setting Up Oracle Software Library.

Note:

While adding a generic component for BPEL processes, on the Create Component: Describe page of the Software Library Wizard, select Generic Component from the Type list, provide a name for the parent folder, and navigate to the Upload File page to upload the files. You DO NOT have to provide details for Customize and Set Directives page.

- If you want to use a deployment plan that can be associated with a BPEL process suitcase file (JAR file), then store this deployment file as a generic component in the Software Library. For instructions to create generic components, see Setting Up Oracle Software Library.

Prerequisites for Operators

- Ensure that you do NOT use an NIS-based operating system user.

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Provisioning Procedure

To provision BPEL processes to a target BPEL Process Manager, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select BPEL Process Provisioning. Then click Schedule Deployment.

4. On the Source Selection page, do the following:

1. In the Source section, click Add and select the BPEL Process suitcase files that you want to deploy to a target BPEL Process Manager. The table is populated based on the selection made.

If you have selected multiple suitcase files, then from the table, select the BPEL process suitcase file and use Move Up and Move Down to order the components the way they should be deployed by the Deployment Procedure.

2. In the Select Deployment Plan, select a deployment plan that can be associated with a BPEL process suitcase file (JAR file).

The deployment plan helps you modify the configuration details and partner link binding properties, which have been set for a particular environment, at run time. You can also use it to search and replace strings and URLs that have been set for a particular environment. This way, you can deploy the same BPEL processes on BPEL Process Managers that are in development, test, and production environments; without having to reconfigure your settings across these environments.

3. Click Next.

5. On the Target Selection page, in the Target section, click Add and select the BPEL Process Managers on which you want to deploy the BPEL processes. If there are multiple domains available for a BPEL target, then you can select an appropriate domain from the BPEL Domain list, on which the suitcase files can be deployed. Click Next.

Note:

When you click Next, Enterprise Manager Grid Control internally checks to see if the Context Provider URL is captured. If this URL is not captured, then you may see some errors. To resolve this issue, set the URL in the Monitoring Configuration page of the BPEL target.

6. On the Credentials page, specify the following:

1. Credentials of application server instances on which the selected BPEL Process Managers are running.

2. BPEL administrator credentials (and RMI credentials for 10.1.2 BPEL targets) for the selected Oracle BPEL Process Managers.

The credentials required for BPEL Process Managers vary according to the supported BPEL Process Manager version. For BPEL 10.1.3 targets, you need to provide only one set of credentials that will be used for accessing the BPEL Process Manager. However, for BPEL 10.1.2 targets, you need to provide the BPEL administrator password and another set of OC4J RMI Access credentials for remote access.

If the preferred credentials are already set and stored in the Management Repository, then by default, they are prefilled on this page. You can choose to either use these prefilled preferred credentials or edit them to use the changed credentials. If the preferred credentials are not stored, then the fields are blank. In this case, you have to specify the credentials. The credentials specified here apply only to the current deployment procedure session and do not get stored in the Management Repository for future use.

Note that if you change the credentials, the change applies only to the current deployment procedure session and does not override the preferred credentials stored in the Management Repository.

3. Click Next.

7. On the Schedule page, schedule the deployment procedure to run immediately or later, and specify a unique name for the deployment procedure so that it can be tracked. Click Next.

8. On the Review page, review the details you have provided for provisioning BPEL processes, and click Submit.

Part VI

Patching

This part describes all patching-related Deployment Procedures. In particular, this part describes the Deployment Procedures for:

- Chapter 14, "Running Patch Prerequisite Checker Deployment Procedures"

- Chapter 15, "Patching Oracle Database"

- Chapter 16, "Patching Oracle RAC"

- Chapter 17, "Patching Oracle Clusterware"

- Chapter 18, "Patching Oracle Automatic Storage Management (ASM)"

- Chapter 19, "Patching Oracle Application Server"

- Chapter 20, "Patching Linux Hosts"

- Chapter 21, "Patching Solaris Hosts"

- Chapter 22, "Patching Microsoft Windows Hosts"

14 Running Patch Prerequisite Checker Deployment Procedures

Enterprise Manager Grid Control offers patching Deployment Procedures that help you patch targets such as Oracle Database, Oracle RAC, Oracle ASM, and Oracle Clusterware. However, before you run these actual patching Deployment Procedures, Oracle strongly recommends you to run prerequisite checkers to ensure that you meet all the necessary requirements for online and offline patching, and also resolve all operational conflicts and issues beforehand.

This chapter lists the patching prerequisite checker Deployment Procedures offered by Enterprise Manager Grid Control, and explains how you can run them. In particular, this chapter covers the following:

- Meeting Prerequisites

- Running Patch Prerequisite Checker for Standalone Database

- Running Patch Prerequisite Checker for Oracle RAC

- Running Patch Prerequisite Checker for Oracle Clusterware

- Running Patch Prerequisite Checker for Oracle ASM

Meeting Prerequisites

Before running the prerequisite checker Deployment Procedures, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- If you want to run the prerequisite checker Deployment Procedure in online mode, then meet the prerequisites described in Setting Up Infrastructure for Online Patching.

- If you want to run the prerequisite checker Deployment Procedure in offline mode, then meet the prerequisites described in Setting Up Infrastructure for Offline Patching.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Running Patch Prerequisite Checker for Standalone Database

To run the prerequisite checker Deployment Procedure before patching Oracle Database, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle Database. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the database to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the Standalone Database Updates section, click Add to search and select software updates from either My Oracle Support or the Software Library. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, if you are running the prerequisite checker Deployment Procedure in online mode, then select Search My Oracle Support. If you are running it in offline mode, then select Search Software Library. Specify the details of the patches you want to search, and click Go.

In online mode, Enterprise Manager Grid Control connects to My Oracle Support and searches the patches there. In offline mode, Enterprise Manager Grid Control searches the patches in the Software Library. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the patches are applied on the database targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the database to be patched are blacked out while the patching is in progress.

For example, if the Oracle Database to be patched is running in an Oracle home location where Oracle ASM is running, then before patching that Oracle Database, all associated targets such as Oracle Listener and Oracle ASM instances will be blacked out.

5. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

6. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

7. Click Next.

5. On the Target List page, in the Database Targets to be Patched section, click Add to add the database targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the database is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch database Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the databases are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases, and click Analyze.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Analyze button on the Review page does not appear.

After the Deployment Procedure runs in Analyze mode, Enterprise Manager Grid Control displays the Procedure Completion page.

10. On the Procedure Completion page, monitor the execution of the Deployment Procedure and check the status.
If you want to drill down to individual steps and check the status at a step level, then click the Deployment Procedure name or the status. Enterprise Manager Grid Control displays the Status page.

On the Status page, in the Steps tab, you can view the status of each of the steps. If you want to view the results of the steps, click the Results tab.

Running Patch Prerequisite Checker for Oracle RAC

This section describes how you can run the prerequisite checker for Oracle RAC. In particular, this section covers the following:

- Patching Oracle RAC Nodes Individually

- Patching Oracle RAC Nodes Collectively

Patching Oracle RAC Nodes Individually

This section describes how you can run the prerequisite checker on the nodes of Oracle RAC one by one, using the Rolling methodology.

IMPORTANT:

- You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use Deployment Procedure that support the All Nodes methodology. For more information, see Patching Oracle RAC Nodes Collectively.

- Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

To run the prerequisite checker Deployment Procedure on the nodes of Oracle RAC one by one, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle RAC Database - Rolling. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the Oracle RAC to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the RAC Database Updates section, click Add to search and select software updates from either My Oracle Support or the Software Library. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, if you are running the prerequisite checker Deployment Procedure in online mode, then select Search My Oracle Support. If you are running it in offline mode, then select Search Software Library. Specify the details of the patches you want to search, and click Go.

In online mode, Enterprise Manager Grid Control connects to My Oracle Support and searches the patches there. In offline mode, Enterprise Manager Grid Control searches the patches in the Software Library. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target host is upgraded before the patches are applied on the database targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the clusterware to be patched are blacked out while the patching is in progress.

5. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

6. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

7. Click Next.

5. On the Target List page, in the RAC Database Targets to be Patched section, click Add to add the Oracle RAC database targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the Oracle RAC database is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the Oracle RAC database is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the Oracle RAC database is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases, and click Analyze.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Analyze button on the Review page does not appear.

After the Deployment Procedure runs in Analyze mode, Enterprise Manager Grid Control displays the Procedure Completion page.

10. On the Procedure Completion page, monitor the execution of the Deployment Procedure and check the status.
If you want to drill down to individual steps and check the status at a step level, then click the Deployment Procedure name or the status. Enterprise Manager Grid Control displays the Status page.

On the Status page, in the Steps tab, you can view the status of each of the steps. If you want to view the results of the steps, click the Results tab.

Patching Oracle RAC Nodes Collectively

The prerequisites and the deployment instructions for patching all the nodes of Oracle RAC at a time, in parallel, using the All Nodes methodology, are the same as the ones described in Patching Oracle RAC Nodes Individually. However, in Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Patch Oracle RAC Database - All Nodes. Then click Schedule Deployment.

Note:

- Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

Running Patch Prerequisite Checker for Oracle Clusterware

To run the prerequisite checker Deployment Procedure before patching Oracle Clusterware, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Patch Prerequisite Checker for CRS. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.

This default value refers to a location on the target host where the clusterware to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library (Software Library), and then staged in this location on the target hosts.

2. In the Oracle Software Updates section, click Add to search and select software updates from either My Oracle Support or the Software Library. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, if you are running the prerequisite checker Deployment Procedure in online mode, then select Search My Oracle Support. If you are running it in offline mode, then select Search Software Library. Specify the details of the patches you want to search, and click Go.

In online mode, Enterprise Manager Grid Control connects to My Oracle Support and searches the patches there. In offline mode, Enterprise Manager Grid Control searches the patches in the Software Library. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the prerequisite checks are run on the clusterware targets.
Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. Click Next.

5. On the Target List page, in the Clusterware Targets to Perform Prerequisite Checks section, click Add to add the clusterware targets you want to patch. Then click Next.
When you click Add, Enterprise Manager Grid Control displays the Select Target page. On this page, search and select the clusterware you want to patch, and click Continue. On the next page, select the associated instances, and click Select to return to the Target List page.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the clusterware is being patched 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.

2. If the host where the clusterware is being patched 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.

3. If the host where the clusterware is being patched does not have a direct or indirect connection to the Internet, then specify the e-mail address and leave the other fields blank.

7. On the Credentials page, in the Home Credentials section, specify the credentials of the clusterware Oracle homes, and in the Host Credentials section, specify the credentials of the hosts where the clusterware Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for running the prerequisite checks on the selected clusterware targets, and click Submit.

Running Patch Prerequisite Checker for Oracle ASM

To run the prerequisite checker Deployment Procedure before patching Oracle ASM, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Oracle Patch Prerequisite Checker for ASM. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.

This default value refers to a location on the target host where the ASM to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library (Software Library), and then staged in this location on the target hosts.

2. In the Oracle Software Updates section, click Add to search and select software updates from either My Oracle Support or the Software Library. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, if you are running the prerequisite checker Deployment Procedure in online mode, then select Search My Oracle Support. If you are running it in offline mode, then select Search Software Library. Specify the details of the patches you want to search, and click Go.

In online mode, Enterprise Manager Grid Control connects to My Oracle Support and searches the patches there. In offline mode, Enterprise Manager Grid Control searches the patches in the Software Library. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the prerequisite checks are run on the ASM targets.
Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. Click Next.

5. On the Target List page, in the ASM Targets to Perform Prerequisite Checks section, click Add to add the ASM targets you want to patch. Then click Next
When you click Add, Enterprise Manager Grid Control displays the Select Target page. On this page, search and select the ASM target you want to patch, and click Select.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the ASM is being patched 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.

2. If the host where the ASM is being patched 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.

3. If the host where the ASM is being patched does not have a direct or indirect connection to the Internet, then specify the e-mail address and leave the other fields blank.

7. On the Credentials page, in the Home Credentials section, specify the credentials of the ASM Oracle homes, and in the Host Credentials section, specify the credentials of the hosts where the ASM targets s are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for running the prerequisite checks on the selected ASM instances, and click Submit.

15 Patching Oracle Database

This chapter explains how you can patch Oracle Database. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Standalone Oracle Database in Online Mode

- Patching Standalone Oracle Database in Offline Mode

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Oracle Database. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Oracle Database. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 15-1 Getting Started with Patching Oracle Database

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Oracle Database. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About the Supported Releases

Know what releases of Oracle Database can be patched by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Patching Mode

Identify whether the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. If it has, then choose to patch in online mode. Otherwise, choose to patch in offline mode.

- To learn about patching a standalone Oracle Database in online mode, see Patching Standalone Oracle Database in Online Mode.

- To learn about patching standalone Oracle Database in offline mode, see Patching Standalone Oracle Database in Offline Mode.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in patching a standalone Oracle Database in online mode, see Deployment Phases.

- To learn about the deployment phases involved in patching a standalone Oracle Database in offline mode, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the environment for online or offline patching, applying mandatory patches, setting up of Oracle Software Library, and so on.

- To learn about the prerequisites for patching a standalone Oracle Database in online mode, see Prerequisites.

- To learn about the prerequisites for patching a standalone Oracle Database in offline mode, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Oracle Database.

- To patch a standalone Oracle Database in online mode, follow the steps explained in Patching Procedure.

- To patch a standalone Oracle Database in offline mode, follow the steps explained in Patching Procedure.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for patching Oracle Database:

- Patch Oracle Database

Note:

- If the Oracle home of the database you are patching also has an ASM installed, then the Deployment Procedure patches only the database instance, but appropriately shuts down the ASM instance before patching the database and restarts it after the operation is complete.

- The Deployment Procedure leaves several .log and .lst files per database instance in the Oracle home of the database being patched. For example, with a databases named UPGRD1, the following files will be left in the oracle home after patching:
-rw-r----- 1 oraets92 oinstall 0 Mar 27 12:19 UPGRD1_is_running.lst-rw-r----- 1 oraets92 oinstall 86 Mar 27 12:18 UPGRD1_shutdown.log-rw-r----- 1 oraets92 oinstall 401 Mar 27 12:19 UPGRD1_shutdown.lst

You cannot avoid the creation of these log files. If you want to delete them, you can either navigate to the Oracle home directory and manually delete them or customize the Deployment Procedure to include a step to automatically delete them.

Supported Releases

Using this Deployment Procedure, you can patch the following releases of Oracle Database:

- Oracle Database 10g Release 1 (10.1.x.x)

- Oracle Database 10g Release 2 (10.2.x.x)

- Oracle Database 11g Release 1 (11.1.x.x)

Patching Standalone Oracle Database in Online Mode

This section describes how you can patch a standalone Oracle Database in online mode, that is, by connecting to My Oracle Support. This option is best suited when you have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 15-2 Deployment Phases Involved in Patching Oracle Database in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, apply SQL script, and run OPatch options.

Target List

Allows you to select the database targets you want to patch.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Credentials

Allows you to specify Oracle home credentials required to patch database Oracle homes, and host credentials to access the hosts where the database are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected databases.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

- Ensure that you run the patchability report to understand whether the Oracle Database you want to patch is suitable for this patching operation. In the report, if the Oracle Database you want to patch appears as a target that cannot be patched, then resolve the conflicts to make it a target that can be patched. For more information about the patchability report, and to understand how you can diagnose the issues with an Oracle Database target and take corrective actions, see Appendix H, "About Patching Automation Reports".

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Standalone Database.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch a standalone Oracle Database, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle Database. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the database to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the Standalone Database Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search My Oracle Support, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control connects to My Oracle Support, searches the patches, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the patches are applied on the database targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the database to be patched are blacked out while the patching is in progress.

For example, if the Oracle Database to be patched is running in an Oracle home location where Oracle ASM is running, then before patching that Oracle Database, all associated targets such as Oracle Listener and Oracle ASM instances will be blacked out.

5. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

6. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

7. Click Next.

5. On the Target List page, in the Database Targets to be Patched section, click Add to add the database targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the database is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the database is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the database is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch database Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the databases are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases, and click Deploy.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Deploy button on the Review page appears as Submit.

Patching Standalone Oracle Database in Offline Mode

This section describes how you can patch a standalone Oracle Database in offline mode, that is, without connecting to My Oracle Support. This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 15-3 Deployment Phases Involved in Patching Oracle Database in Offline Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, apply SQL script, and run OPatch options.

Target List

Allows you to select the database targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch database Oracle homes, and host credentials to access the hosts where the database are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected databases.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Offline Patching

- Ensure that you run the patchability report to understand whether the Oracle Database you want to patch is suitable for this patching operation. In the report, if the Oracle Database you want to patch appears as a target that cannot be patched, then resolve the conflicts to make it a target that can be patched. For more information about the patchability report, and to understand how you can diagnose the issues with an Oracle Database target and take corrective actions, see Appendix H, "About Patching Automation Reports".

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Standalone Database.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch a standalone Oracle Database, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle Database. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the database to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the Standalone Database Updates section, click Add to search and select software updates from Oracle Software Library (Software Library). Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search Software Library, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control searches the patches in the Software Library, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the patches are applied on the database targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the database to be patched are blacked out while the patching is in progress.

For example, if the Oracle Database to be patched is running in an Oracle home location where Oracle ASM is running, then before patching that Oracle Database, all associated targets such as Oracle Listener and Oracle ASM instances will be blacked out.

5. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

6. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

7. Click Next.

5. On the Target List page, in the Database Targets to be Patched section, click Add to add the database targets you want to patch. Then click Next

6. On the Oracle Configuration Manager page, click Next.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch database Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the databases are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases, and click Deploy.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Deploy button on the Review page appears as Submit.

16 Patching Oracle RAC

This chapter explains how you can patch Oracle RAC. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Core Components Patched

- Supported Releases

- Patching Oracle RAC in Online Mode

- Patching Oracle RAC in Offline Mode

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Oracle RAC. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Oracle RAC. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 16-1 Getting Started with Patching Oracle RAC

Step

Description

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Oracle RAC. Know how the Deployment Procedure functions, what use cases it covers, what core components are patched, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

To learn about the core components that are patched, see Core Components Patched.

Knowing About The Supported Releases

Know what releases of Oracle RAC can be patched by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Patching Mode

Identify whether the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. If it has, then choose to patch in online mode. Otherwise, choose to patch in offline mode.

- To learn about patching Oracle RAC in online mode, see Patching Oracle RAC in Online Mode.

- To learn about patching Oracle RAC in offline mode, see Patching Oracle RAC in Offline Mode.

Patching RAC Nodes Individually or Collectively

Decide whether you want to patch the nodes one by one, using the Rolling methodology, or all at a time, in parallel, using the All Nodes methodology.

Online Mode:

- To learn about patching Oracle RAC nodes individually in online mode, see Patching Oracle RAC Nodes Individually.

- To learn about patching Oracle RAC nodes collectively in online mode, see Patching Oracle RAC Nodes Collectively.

Offline Mode:

- To learn about patching Oracle RAC nodes individually in offline mode, see Patching Oracle RAC Nodes Individually.

- To learn about patching Oracle RAC nodes collectively in offline mode, see Patching Oracle RAC Nodes Collectively.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

Online Mode:

- To learn about the deployment phases involved in patching Oracle RAC nodes individually in online mode, see Deployment Phases.

- To learn about the deployment phases involved in patching Oracle RAC nodes collectively in online mode, see Patching Oracle RAC Nodes Collectively.

Offline Mode:

- To learn about the deployment phases involved in patching Oracle RAC nodes individually in offline mode, see Deployment Phases.

- To learn about the deployment phases involved in patching Oracle RAC nodes collectively in offline mode, see Patching Oracle RAC Nodes Collectively.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the environment for online or offline patching, applying mandatory patches, setting up of Oracle Software Library, and so on.

Online Mode:

- To learn about the prerequisites for patching Oracle RAC nodes individually in online mode, see Prerequisites.

- To learn about the prerequisites for patching Oracle RAC nodes collectively in online mode, see Patching Oracle RAC Nodes Collectively.

Offline Mode:

- To learn about the prerequisites for patching Oracle RAC nodes individually in offline mode, see Prerequisites.

- To learn about the prerequisites for patching Oracle RAC nodes collectively in offline mode, see Patching Oracle RAC Nodes Collectively.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Oracle RAC.

Online Mode:

- To patch Oracle RAC nodes individually in online mode, see Patching Procedure.

- To patch Oracle RAC nodes collectively in online mode, see Patching Oracle RAC Nodes Collectively.

Offline Mode:

- To patch Oracle RAC nodes individually in offline mode, follow the steps explained in Patching Procedure.

- To patch Oracle RAC nodes collectively in offline mode, follow the steps explained in Patching Oracle RAC Nodes Collectively.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for patching Oracle RAC:

- Patch Oracle RAC Database - Rolling

- Patch Oracle RAC Database - All Nodes

While the former one allows you to patch the nodes one by one, the latter one allows you to patch all the nodes at a time, in parallel. For more information about these patching methodologies and circumstances under which you must use the Rolling methodology or All Nodes methodology, see Understanding Patching Methodologies.

Core Components Patched

When you patch Oracle RAC, essentially, the Deployment Procedures patch the following core components:

- Oracle RAC Database

- Optionally, Automatic Storage Management (ASM)

Supported Releases

Using these Deployment Procedures, you can patch the following releases of Oracle RAC:

- Oracle Clusterware 10g Release 1 (10.1.x.x)

- Oracle Clusterware 10g Release 2 (10.2.x.x)

- Oracle Clusterware 11g Release 1 (11.1.x.x)

IMPORTANT:

- You cannot run this procedure on Oracle RAC installations that are registered on different Clusterware (CRS).

- You can run this procedure on Oracle RAC installations that have shared Oracle homes, as long as they are not multi-shared.
For example, let us consider that the Oracle RAC installation is cluster1 and it has four nodes, mainly node1, node2, node3, and node4. You can run this procedure on this cluster if all the nodes are part of the same shared Oracle home, say /nfs_1/home/oracle/db10g. However, you cannot run this procedure if two of the nodes are from one shared Oracle home, say /nfs_1/home/oracle/db10g, and the other two are from another shared Oracle home, say /nfs_2/home/oracle/db10g.

- This deployment procedure supports patching of shared Oracle home RAC installations only for Oracle Real Application Clusters (RAC) 10g Release 2 (10.2.0.1) or higher.

Patching Oracle RAC in Online Mode

This section describes how you can patch Oracle RAC in online mode, that is, by connecting to My Oracle Support. This option is best suited when you have an Internet connection on the host where Enterprise Manager Grid Control is running.

In online mode, you can either patch the nodes one by one, or patch all the nodes at a time, in parallel. This section provides instructions for both these methodologies.

In particular, this section provides instructions for the following:

- Patching Oracle RAC Nodes Individually

- Patching Oracle RAC Nodes Collectively

Patching Oracle RAC Nodes Individually

This section describes how you can patch the nodes of Oracle RAC one by one, using the Rolling methodology.

This methodology is best suited when you are applying one-off patches that support this methodology, and when you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service. For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node, and so on, until all the nodes are patched successfully.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

IMPORTANT:

- You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use Deployment Procedure that support the All Nodes methodology. For more information, see Patching Oracle RAC Nodes Collectively.

- Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 16-2 Deployment Phases for Patching Oracle RAC in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, black out associated targets, apply SQL script, and run OPatch options.

Target List

Allows you to select the Oracle RAC targets you want to patch.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Credentials

Allows you to specify Oracle home credentials required to patch RAC Oracle homes, and host credentials to access the hosts where the Oracle RAC instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected Oracle RAC instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

- Ensure that operating system users such as oracle and crsuser are available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that you run the patchability report to understand whether the Oracle Database you want to patch is suitable for this patching operation. In the report, if the Oracle Database you want to patch appears as a target that cannot be patched, then resolve the conflicts to make it a target that can be patched. For more information about the patchability report, and to understand how you can diagnose the issues with an Oracle Database target and take corrective actions, see Appendix H, "About Patching Automation Reports".

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle RAC.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch an Oracle Cluterware, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle RAC Database - Rolling. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the Oracle RAC to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the RAC Database Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search My Oracle Support, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control connects to My Oracle Support, searches the patches, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target host is upgraded before the patches are applied on the database targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the clusterware to be patched are blacked out while the patching is in progress.

5. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

6. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

7. Click Next.

5. On the Target List page, in the RAC Database Targets to be Patched section, click Add to add the Oracle RAC database targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the Oracle RAC database is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the Oracle RAC database is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the Oracle RAC database is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected Oracle RAC databases, and click Deploy.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Deploy button on the Review page appears as Submit.

Patching Oracle RAC Nodes Collectively

The prerequisites and the deployment instructions for patching all the nodes of Oracle RAC at a time, in parallel, using the All Nodes methodology, are the same as the ones described in Patching Oracle RAC Nodes Individually. However, in Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Patch Oracle RAC Database - All Nodes. Then click Schedule Deployment.

Although the instructions remain the same, when you submit the Deployment Procedure, Enterprise Manager Grid Control internally patches all the nodes of Oracle RAC collectively, that is, all the nodes are shut down and the patch is applied on all of them at the same time.

This methodology is best suited when you are applying a patch set or those one-off patches that support this methodology, or when you want to patch a shared Oracle home clusterware. For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, not on all the nodes.

Note:

- Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

Patching Oracle RAC in Offline Mode

This section describes how you can patch Oracle RAC in offline mode, that is, without connecting to My Oracle Support. This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running.

In offline mode, you can either patch the nodes one by one, or patch all the nodes at a time, in parallel. This section provides instructions for both these methodologies.

In particular, this section provides instructions for the following:

- Patching Oracle RAC Nodes Individually

- Patching Oracle RAC Nodes Collectively

Patching Oracle RAC Nodes Individually

This section describes how you can patch the nodes of Oracle RAC one by one, using the Rolling methodology.

This methodology is best suited when you are applying one-off patches that support this methodology, and when you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service. For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node, and so on, until all the nodes are patched successfully.

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 16-3 Deployment Phases for Patching Oracle RAC in Offline Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, black out associated targets, apply SQL script, and run OPatch options.

Target List

Allows you to select the Oracle RAC targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch RAC Oracle homes, and host credentials to access the hosts where the Oracle RAC instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected Oracle RAC instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Offline Patching

- Ensure that operating system users such as oracle and crsuser are available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that you run the patchability report to understand whether the Oracle Database you want to patch is suitable for this patching operation. In the report, if the Oracle Database you want to patch appears as a target that cannot be patched, then resolve the conflicts to make it a target that can be patched. For more information about the patchability report, and to understand how you can diagnose the issues with an Oracle Database target and take corrective actions, see Appendix H, "About Patching Automation Reports".

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle RAC.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch an Oracle Cluterware, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle RAC Database - Rolling. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the Oracle RAC to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the RAC Database Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search Software Library, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control searches the patches in Oracle Software Library, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the Oracle RAC database to be patched are blacked out while the patching is in progress.

4. In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas.

If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available. For example, %oracle_home%/rdbms/admin/catupgrd.sql .

The variables you can use for the directory location are %emd_root% to indicate a location on the target host, %oracle_home% to indicate the current home location being patched, or %perlbin% to indicate the location of perl binary used by the Management Agent.

You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options. If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs.

5. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

6. Click Next.

5. On the Target List page, in the RAC Database Targets to be Patched section, click Add to add the Oracle RAC database targets you want to patch. Then click Next.

6. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

7. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

8. On the Review page, review the details you have provided for patching the selected Oracle RAC databases, and click Deploy.

Note:

If you have not applied the one-off patch as described in Applying One-Off Patch to Introduce Analyze Mode and Reports, then the Deploy button on the Review page appears as Submit.

Patching Oracle RAC Nodes Collectively

The prerequisites and the deployment instructions for patching all the nodes of Oracle RAC at a time, in parallel, using the All Nodes methodology, are the same as the ones described in Patching Oracle RAC Nodes Individually. However, in Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Patch Oracle RAC Database - All Nodes. Then click Schedule Deployment.

Although the instructions remain the same, when you submit the Deployment Procedure, Enterprise Manager Grid Control internally patches all the nodes of Oracle RAC collectively, that is, all the nodes are shut down and the patch is applied on all of them at the same time.

This methodology is best suited when you are applying a patch set or those one-off patches that support this methodology, or when you want to patch a shared Oracle home clusterware. For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, not on all the nodes.

Note:

- Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

17 Patching Oracle Clusterware

This chapter explains how you can patch Oracle Clusterware. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Oracle Clusterware in Online Mode

- Patching Oracle Clusterware in Offline Mode

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Oracle Clusterware. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Oracle Clusterware. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 17-1 Getting Started with Patching Oracle Clusterware

Step

Description

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Oracle Clusterware. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases of Oracle Clusterware can be patched by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Patching Mode

Identify whether the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. If it has, then choose to patch in online mode. Otherwise, choose to patch in offline mode.

- To learn about patching Oracle Clusterware in online mode, see Patching Oracle Clusterware in Online Mode.

- To learn about patching Oracle Clusterware in offline mode, see Patching Oracle Clusterware in Offline Mode.

Patching Clusterware Nodes Individually or Collectively

Decide whether you want to patch the nodes one by one, using the Rolling methodology, or all at a time, in parallel, using the All Nodes methodology.

Online Mode:

- To learn about patching clusterware nodes individually in online mode, see Patching Oracle Clusterware Nodes Individually.

- To learn about patching clusterware nodes collectively in online mode, see Patching Oracle Clusterware Nodes Collectively.

Offline Mode:

- To learn about patching clusterware nodes individually in offline mode, see Patching Oracle Clusterware Nodes Individually.

- To learn about patching clusterware nodes collectively in offline mode, see Patching Oracle Clusterware Nodes Collectively.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

Online Mode:

- To learn about the deployment phases involved in patching clusterware nodes individually in online mode, see Deployment Phases.

- To learn about the deployment phases involved in patching clusterware nodes collectively in online mode, see Patching Oracle Clusterware Nodes Collectively.

Offline Mode:

- To learn about the deployment phases involved in patching clusterware nodes individually in offline mode, see Deployment Phases.

- To learn about the deployment phases involved in patching clusterware nodes collectively in offline mode, see Patching Oracle Clusterware Nodes Collectively.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the environment for online or offline patching, applying mandatory patches, setting up of Oracle Software Library, and so on.

Online Mode:

- To learn about the prerequisites for patching clusterware nodes individually in online mode, see Prerequisites.

- To learn about the prerequisites for patching clusterware nodes collectively in online mode, see Patching Oracle Clusterware Nodes Collectively.

Offline Mode:

- To learn about the prerequisites for patching clusterware nodes individually in offline mode, see Prerequisites.

- To learn about the prerequisites for patching clusterware nodes collectively in offline mode, see Patching Oracle Clusterware Nodes Collectively.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Oracle Clusterware.

Online Mode:

- To patch clusterware nodes individually in online mode, see Patching Procedure.

- To patch clusterware nodes collectively in online mode, see Patching Oracle Clusterware Nodes Collectively.

Offline Mode:

- To patch clusterware nodes individually in offline mode, follow the steps explained in Patching Procedure.

- To patch clusterware nodes collectively in offline mode, follow the steps explained in Patching Oracle Clusterware Nodes Collectively.

Deployment Procedures

Enterprise Manager Grid Control offers the following Deployment Procedures for patching Oracle Clusterware:

- Patch Oracle Clusterware - Rolling

- Patch Oracle Clusterware - All Nodes

While the former one allows you to patch the nodes one by one, the latter one allows you to patch all the nodes at a time, in parallel. For more information about these patching methodologies and circumstances under which you must use the Rolling methodology or All Nodes methodology, see Understanding Patching Methodologies.

Supported Releases

Using these Deployment Procedures, you can patch the following releases of Oracle Clusterware:

- Oracle Clusterware 10g Release 1 (10.1.x.x)

- Oracle Clusterware 10g Release 2 (10.2.x.x)

- Oracle Clusterware 11g Release 1 (11.1.x.x)

IMPORTANT:

These Deployment Procedures are not supported on Microsoft Windows.

Patching Oracle Clusterware in Online Mode

This section describes how you can patch Oracle Clusterware in online mode, that is, by connecting to My Oracle Support. This option is best suited when you have an Internet connection on the host where Enterprise Manager Grid Control is running.

In online mode, you can either patch the nodes one by one, or patch all the nodes at a time, in parallel. This section provides instructions for both these methodologies.

In particular, this section provides instructions for the following:

- Patching Oracle Clusterware Nodes Individually

- Patching Oracle Clusterware Nodes Collectively

Patching Oracle Clusterware Nodes Individually

This section describes how you can patch the nodes of Oracle Clusterware one by one, using the Rolling methodology.

This methodology is best suited when you are applying one-off patches that support this methodology, and when you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service. For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node, and so on, until all the nodes are patched successfully.

This section covers the following:

- Prerequisites

- Deployment Phases

- Patching Procedure

iMPORTANT:

- You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use Deployment Procedure that support the All Nodes methodology. For more information, see Patching Oracle Clusterware Nodes Collectively.

- Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 17-2 Deployment Phases for Patching Oracle Clusterware in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, black out associated targets, and run OPatch options.

Target List

Allows you to select the clusterware targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch clusterware Oracle homes, and host credentials to access the hosts where the clusterware instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected clusterware instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

- Ensure that you have the latest release of the OPatch software on the target host (where the clusterware to be patched is running).

- Ensure that operating system users such as oracle and crsuser are available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle Clusterware.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch an Oracle Cluterware, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle Clusterware - Rolling. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the clusterware to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the CRS Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search My Oracle Support, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control connects to My Oracle Support, searches the patches, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the clusterware to be patched are blacked out while the patching is in progress.

4. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

5. Click Next.

5. On the Target List page, in the Clusterware Targets to be Patched section, click Add to add the clusterware targets you want to patch. Then click Next.
When you click Add, Enterprise Manager Grid Control displays the Select Target page. On this page, search and select the clusterware you want to patch, and click Continue. On the next page, select the associated instances, and click Select to return to the Target List page.

6. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the clusterware Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the clusterware Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

7. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

8. On the Review page, review the details you have provided for patching the selected clusterware, and click Submit.

Patching Oracle Clusterware Nodes Collectively

The prerequisites and the deployment instructions for patching all the nodes of Oracle Clusterware at a time, in parallel, using the All Nodes methodology, are the same as the ones described in Patching Oracle Clusterware Nodes Individually. However, in Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Patch Oracle Clusterware - All Nodes. Then click Schedule Deployment.

Although the instructions remain the same, when you submit the Deployment Procedure, Enterprise Manager Grid Control internally patches all the nodes of the clusterware collectively, that is, all the nodes are shut down and the patch is applied on all of them at the same time.

This methodology is best suited when you are applying a patch set or those one-off patches that support this methodology, or when you want to patch a shared Oracle home clusterware. For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, not on all the nodes.

Note:

- Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

- If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

Patching Oracle Clusterware in Offline Mode

This section describes how you can patch Oracle Clusterware in offline mode, that is, without connecting to My Oracle Support. This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running.

In offline mode, you can either patch the nodes one by one, or patch all the nodes at a time, in parallel. This section provides instructions for both these methodologies.

In particular, this section provides instructions for the following:

- Patching Oracle Clusterware Nodes Individually

- Patching Oracle Clusterware Nodes Collectively

Patching Oracle Clusterware Nodes Individually

This section describes how you can patch the nodes of Oracle Clusterware one by one, using the Rolling methodology.

This methodology is best suited when you are applying one-off patches that support this methodology, and when you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service. For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node, and so on, until all the nodes are patched successfully.

This section covers the following:

- Prerequisites

- Deployment Phases

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 17-3 Deployment Phases for Patching Oracle Clusterware in Offline Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, black out associated targets, and run OPatch options.

Target List

Allows you to select the clusterware targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch clusterware Oracle homes, and host credentials to access the hosts where the clusterware instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected clusterware instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Offline Patching

- Ensure that you have the latest release of the OPatch software on the target host (where the clusterware to be patched is running).

- Ensure that operating system users such as oracle and crsuser are available on all the nodes of the cluster. These users must be a part of the relevant operating system groups such as dba and oinstall.

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle Clusterware.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch an Oracle Cluterware, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Oracle Clusterware - Rolling. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the clusterware to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the CRS Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search Software Library, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control searches the patches in Oracle Software Library, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the clusterware to be patched are blacked out while the patching is in progress.

4. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

5. Click Next.

5. On the Target List page, in the Clusterware Targets to be Patched section, click Add to add the clusterware targets you want to patch. Then click Next.
When you click Add, Enterprise Manager Grid Control displays the Select Target page. On this page, search and select the clusterware you want to patch, and click Continue. On the next page, select the associated instances, and click Select to return to the Target List page.

6. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the Oracle homes are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

7. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

8. On the Review page, review the details you have provided for patching the selected clusterware, and click Submit.

Patching Oracle Clusterware Nodes Collectively

The prerequisites and the deployment instructions for patching all the nodes of Oracle Clusterware at a time, in parallel, using the All Nodes methodology, are the same as the ones described in Patching Oracle Clusterware Nodes Individually. However, in Step (3), on the Deployment Procedure Manager page, in the Procedures tab, from the table, select Patch Oracle Clusterware - All Nodes. Then click Schedule Deployment.

Although the instructions remain the same, when you submit the Deployment Procedure, Enterprise Manager Grid Control internally patches all the nodes of the clusterware collectively, that is, all the nodes are shut down and the patch is applied on all of them at the same time.

This methodology is best suited when you are applying a patch set or those one-off patches that support this methodology, or when you want to patch a shared Oracle home clusterware. For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, not on all the nodes.

Note:

Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

Note:

If the Deployment Procedure abruptly stops or terminates at any step while it is being run, you may rerun the same procedure from where it stopped or from the beginning, all over again.

18 Patching Oracle Automatic Storage Management (ASM)

This chapter explains how you can patch Oracle ASM. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Supported Releases

- Patching a Standalone Oracle ASM in Online Mode

- Patching a Standalone Oracle ASM in Offline Mode

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Oracle ASM. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Oracle ASM. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 18-1 Getting Started with Patching Oracle ASM

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Oracle ASM. Know how the Deployment Procedure functions, what use cases it covers, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

Knowing About The Supported Releases

Know what releases of Oracle ASM can be patched by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Patching Mode

Identify whether the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. If it has, then choose to patch in online mode. Otherwise, choose to patch in offline mode.

- To learn about patching a standalone Oracle ASM in online mode, see Patching a Standalone Oracle ASM in Online Mode.

- To learn about patching standalone Oracle ASM in offline mode, see Patching a Standalone Oracle ASM in Offline Mode.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in patching a standalone Oracle ASM in online mode, see Deployment Phases.

- To learn about the deployment phases involved in patching a standalone Oracle ASM in offline mode, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the environment for online or offline patching, applying mandatory patches, setting up of Oracle Software Library, and so on.

- To learn about the prerequisites for patching a standalone Oracle ASM in online mode, see Prerequisites.

- To learn about the prerequisites for patching a standalone Oracle ASM in offline mode, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Oracle ASM.

- To patch a standalone Oracle ASM in online mode, follow the steps explained in Patching Procedure.

- To patch a standalone Oracle ASM in offline mode, follow the steps explained in Patching Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedures for patching Oracle ASM:

- Patch Standalone Oracle ASM

Supported Releases

Using this Deployment Procedure, you can patch the following releases of Oracle ASM:

- Oracle Database 10g Release 1 (10.1.x.x)

- Oracle Database 10g Release 2 (10.2.x.x)

- Oracle Database 11g Release 1 (11.1.x.x)

Patching a Standalone Oracle ASM in Online Mode

This section describes how you can patch a standalone Oracle ASM in online mode, that is, by connecting to My Oracle Support. This option is best suited when you have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 18-2 Deployment Phases for Patching Oracle ASM in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, and run OPatch options.

Target List

Allows you to select the ASM targets you want to patch.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Credentials

Allows you to specify Oracle home credentials required to patch ASM Oracle homes, and host credentials to access the hosts where the ASM instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected ASM instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle ASM.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch a standalone Oracle ASM instance, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Standalone Oracle ASM. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the ASM to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the ASM Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search My Oracle Support, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control connects to My Oracle Support, searches the patches, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the patches are applied on the ASM targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the Oracle home of the ASM target to be patched are blacked out while the patching is in progress.

5. In the OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

6. Click Next.

5. On the Target List page, in the Clusterware Targets to be Patched section, click Add to add the database targets that contain the ASM targets you want to patch. Then click Next

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the ASM is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the ASM is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the ASM is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch ASM Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the ASM targets are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases that contain the ASM instances, and click Submit.

Patching a Standalone Oracle ASM in Offline Mode

This section describes how you can patch a standalone Oracle ASM in offline mode, that is, without connecting to My Oracle Support. This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 18-3 Deployment Phases for Patching Oracle ASM in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, and run OPatch options.

Target List

Allows you to select the ASM targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch ASM Oracle homes, and host credentials to access the hosts where the ASM instances are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected ASM instances.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Offline Patching

- Ensure that you run the prerequisite checker Deployment Procedure as described in Running Patch Prerequisite Checker for Oracle ASM.

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch a standalone Oracle ASM instance, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Standalone Oracle ASM. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the ASM to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the ASM Database Updates section, click Add to search and select software updates from Oracle Software Library (Software Library). Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search Software Library, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control searches the patches in the Software Library, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target hosts are upgraded before the patches are applied on the ASM targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the Oracle home of the ASM target to be patched are blacked out while the patching is in progress.

5. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

6. Click Next.

5. On the Target List page, in the Clusterware Targets to be Patched section, click Add to add the database targets that contain the ASM targets you want to patch. Then click Next

6. On the Oracle Configuration Manager page, click Next.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch ASM Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the ASM targets are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected databases that contain the ASM instances, and click Submit.

19 Patching Oracle Application Server

This chapter explains how you can patch Oracle Application Server. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedure

- Core Components Patched

- Supported Releases

- Patching Oracle Application Server in Online Mode

- Patching Oracle Application Server in Offline Mode

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Oracle Application Server. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Oracle Application Server. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 19-1 Getting Started with Patching Oracle Application Server

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Oracle Application Server. Know how the Deployment Procedure functions, what use cases it covers, what core components are patched, and so on.

To learn about the Deployment Procedure, see Deployment Procedure.

To learn about the core components that are patched, see Core Components Patched.

Knowing About The Supported Releases

Know what releases of Oracle Application Server can be patched by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Selecting the Patching Mode

Identify whether the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. If it has, then choose to patch in online mode. Otherwise, choose to patch in offline mode.

- To learn about patching Oracle Application Server in online mode, see Patching Oracle Application Server in Online Mode.

- To learn about patching Oracle Application Server in offline mode, see Patching Oracle Application Server in Offline Mode.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

- To learn about the deployment phases involved in patching Oracle Application Server in online mode, see Deployment Phases.

- To learn about the deployment phases involved in patching Oracle Application Server in offline mode, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the environment for online or offline patching, applying mandatory patches, setting up of Oracle Software Library, and so on.

- To learn about the prerequisites for patching Oracle Application Server in online mode, see Prerequisites.

- To learn about the prerequisites for patching Oracle Application Server in offline mode, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Oracle Application Server.

- To patch Oracle Application Server in online mode, follow the steps explained in Patching Procedure.

- To patch Oracle Application Server in offline mode, follow the steps explained in Patching Procedure.

Deployment Procedure

Enterprise Manager Grid Control offers the following Deployment Procedure for patching Oracle Application Server:

- Patch Application Server

Core Components Patched

When you patch Oracle Application Server, essentially, the Deployment Procedure patches the following core components:

- Oracle HTTP Server

- Oracle Web Cache

- Oracle Containers for J2EE (OC4J)

- Oracle Portal

Supported Releases

Using this Deployment Procedure, you can patch the following releases of Oracle Application Server:

- Oracle Application Server 10g Release 2 (10.1.2.0.2)

- Oracle Application Server 10g Release 3 (10.1.3.x)

Patching Oracle Application Server in Online Mode

This section describes how you can patch an Oracle Application Server in online mode, that is, by connecting to My Oracle Support. This option is best suited when you have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 19-2 Deployment Phases for Patching Oracle Application Server in Online Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, and run OPatch options.

Target List

Allows you to select the application server targets you want to patch.

Oracle Configuration Manager

Allows you to configure Oracle Configuration Manager so that security updates can be sent.

Credentials

Allows you to specify Oracle home credentials required to patch application server Oracle homes, and host credentials to access the hosts where the application servers are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected application servers.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Online Patching

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch an Oracle Application Server, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Application Server. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the application server to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library (Software Library), and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the Application Server Updates section, click Add to search and select software updates from My Oracle Support. Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search My Oracle Support, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control connects to My Oracle Support, searches the patches, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target host is upgraded before the patches are applied on the application server targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the application server to be patched are blacked out while the patching is in progress.

5. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

6. Click Next.

5. On the Target List page, in the Application Server Targets to be Patched section, click Add to add the application server targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, do the following:

1. If the host where the application server is being patched 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 My Oracle Support password is incorrect, you will be allowed two more attempts. However, if your password is incorrect in all three attempts or if it is left blank, then you are registered anonymously, which means, the configuration information will be collected and uploaded to My Oracle Support but the uploaded information will not be associated with your My Oracle Support account. Therefore, if you log in to My Oracle Support with your credentials, you will not see this information displayed against your account. However, if you had specified an e-mail address, then you will continue to receive security updates and other notifications from Oracle to that e-mail address.

2. If the host where the application server is being patched 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 Deployment Procedure ends. To do so, run the configCCR command from the /ccr/bin/ directory within the Oracle home directory of the provisioned database.

3. If the host where the application server is being patched 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. To understand how the configuration information can be manually collected and uploaded, see the steps outlined in Manually Collecting and Uploading Configuration Information to My Oracle Support.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the application server Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the application servers are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected application servers, and click Submit.

Patching Oracle Application Server in Offline Mode

This section describes how you can patch an Oracle Application Server in offline mode, that is, without connecting to My Oracle Support. This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running.

This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following describes the different phases involved in this Deployment Procedure:

Table 19-3 Deployment Phases for Patching Oracle Application Server in Offline Mode

Phase

Description

Software Updates

Allows you to select the software updates (patches and patch sets) you want to apply, upgrade OPatch, black out associated targets, and run OPatch options.

Target List

Allows you to select the application server targets you want to patch.

Credentials

Allows you to specify Oracle home credentials required to patch application server Oracle homes, and host credentials to access the hosts where the application servers are present.

Schedule

Allows you to schedule the Deployment Procedure to run immediately or later.

Review

Allows you to review the details you have provided for patching the selected application servers.

Prerequisites

Before running the Deployment Procedure, meet the following prerequisites:

Prerequisites for Designers

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Setting Up Infrastructure for Offline Patching

Prerequisites for Operators

- Ensure that you use an operating system user that has the privileges to run the Deployment Procedure and its commands on the target hosts. If you do not have the privileges to do so, that is, if you are using a locked account, then request your administrator (a designer) to either customize the Deployment Procedure to run it as another user or ignore the steps that require special privileges. For information about customization, see Chapter 23, "Customizing Steps to Run as Another User".

Patching Procedure

To patch Oracle Application Server, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, in the Deployment Procedure Manager section, click Patch Procedures.

3. On the Deployment Procedure Manager page, in the Procedures subtab, from the table, select Patch Application Server. Then click Schedule Deployment.
Enterprise Manager Grid Control displays the Software Updates page of the Deployment Procedure.

4. On the Software Updates page, do the following:

1. In the Select Stage Location section, retain the default selection, that is, Enter Stage Location that has the value %emd_root%/EMStage.
This default value refers to a location on the target host where the database to be patched is running. The software updates are downloaded from My Oracle Support to Oracle Software Library, and then staged in this location on the target hosts.

You can modify the location if you want to, and click Save. If you save multiple custom locations, then the Select Stage Location option gets enabled and allows you to select any of the saved custom locations the next time you visit the same page.

Instead of %emd_root%, you can also specify %oracle_home% to indicate the current home location being patched or %perlbin% to indicate the location of perl binary used by Oracle Management Agent (Management Agent).

2. In the Application Server Updates section, click Add to search and select software updates from Oracle Software Library (Software Library). Alternatively, if you have a text file that contains details about the patches, then click Upload From File to select and upload that text file.
On clicking Add, Enterprise Manager Grid Control displays the Search and Select Software Updates page. On this page, select Search Software Library, specify the details of the patches you want to search, and click Go.

Enterprise Manager Grid Control searches the patches in the Software Library, and displays details about them on the Search and Select Software Updates page. Select the ones you want to apply using the Deployment Procedure, and click Select.

On clicking Upload From File, Enterprise Manager Grid Control displays the Upload File page. On this page, select Upload from Local Machine or Upload from Software Library depending on where the text file is available, click Browse to search and select that file, and then click Upload.

3. In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target host is upgraded before the patches are applied on the application server targets.

Enterprise Manager Grid Control uses OPatch software to apply the one-off patches. It is assumed that this software is already available on the target hosts managed by Oracle Management Agents (Management Agent), but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release.

4. In the Black Out Associated Targets section, retain the default selection so that all targets associated with the application server to be patched are blacked out while the patching is in progress.

5. In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure. For example, if you want the Deployment Procedure to ignore duplicate patches, then specify -skip_duplicate.

The following are the options you can specify:

-skip_duplicate, skips duplicate patches

-skip_conflict, skips conflicting patches

-skip_missing_component, skips patches whose components are missing

-invPtrLoc, the location of oraInst.loc file

Note:

If you want to specify multiple options, then separate the list with a white space. For example, -skip_duplicate -skip_conflict

6. Click Next.

5. On the Target List page, in the Application Server Targets to be Patched section, click Add to add the application server targets you want to patch. Then click Next.

6. On the Oracle Configuration Manager page, click Next.

7. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the application server Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the application servers are present. Then click Next.

Note:

When there are Oracle home active steps, the Home Credentials section appears. When there are host-level active steps, the Host Credentials section appears. When Oracle home active steps and host-level active steps are present, both the sections appear.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used.

Of course, you can always override the preferred credentials with a new set of credentials. If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host.

After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository.

8. On the Schedule page, schedule the Deployment Procedure to run either immediately or later.
For Instance Name, specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

9. On the Review page, review the details you have provided for patching the selected application servers, and click Submit.

20 Patching Linux Hosts

Linux Host Patching is a feature in Enterprise Manager Grid Control that helps in keeping the machines in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm.

This feature support in Enterprise Manager Grid Control enables you to:

- Set up Linux RPM Repository based in Unbreakable Linux Network (ULN) channels.

- Download Advisories (Erratas) from ULN.

- Set up Linux Patching Group to update a group of Linux hosts and collect compliance information.

- Allow non-compliant packages to be patched.

- Rollback/Uninstall packages from host.

- Manage RPM repositories and channels (clone channels, copy packages from one channel into another, delete channels).

- Add RPMs to custom channels.

- Manage Configuration file channels (create/delete channels, upload files, copy files from one channel into another)

This chapter explains how you can patch Linux hosts. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Linux Hosts

- Linux Patching Home Page

- Configuration File Management

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Linux hosts. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Linux hosts. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 20-1 Getting Started with Patching Linux Hosts

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Linux hosts.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases of Linux are supported by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

To learn about the deployment phases involved in patching Linux hosts, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the patching environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for patching Linux hosts, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Linux hosts.

To patch Linux hosts, follow the steps explained in Patching Procedure.

Performing Other Linux Patching Activities

There are other activities that you can perform such as registering custom channels, configuration file management, and so on.

- To register a custom channel, follow the steps explained in Registering a Custom Channel.

- To clone a channel, follow the steps explained in Cloning a Channel.

- To perform configuration file management, follow the steps explained in Configuration File Management.

Deployment Procedures

Enterprise Manager Grid Control provides the following Deployment Procedures for Linux patching:

- Patch Linux Hosts
This deployment procedure allows you to patch Linux hosts. The steps to run this deployment procedure is specified in the next section.

- Linux RPM Repository server setup
This deployment procedure allows you to set up a Linux RPM repository server. Follow the steps mentioned in Setting Up the RPM Repository to set up the Linux RPM repository server.

Supported Releases

Following are the releases supported for Linux patching:

Table 20-2 Supported Releases

Feature

Linux Distributions Supported

Compliance

Oracle Enterprise Manager Linux, RedHat

Update Job

Oracle Enterprise Manager Linux, RedHat, SuSE Linux

Emergency Patching

Oracle Enterprise Manager Linux, RedHat

Linux Patching Deployment Procedures

Oracle Enterprise Manager Linux, RedHat, SuSE Linux

Undo Patching

Oracle Enterprise Manager Linux, RedHat

Channel management

Oracle Enterprise Manager Linux, RedHat

Patching Linux Hosts

This section explains how you can patch Linux hosts. This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following table describes the different phases involved in this Deployment Procedure:

Table 20-3 Deployment Phases for Patching Linux Hosts

Phase

Description

Package Repository

Allows you to select the Linux distribution and the RPM repository.

Select Updates

Allows you to select the packages to be updated.

Select Hosts

Allows you to select the targets to be updated.

Credentials

Allows you to enter the credentials for the patching operation.

Pre/Post Scripts

Allows you to specify any scripts to be run before and after the patching job.

Schedule

Allows you to specify the schedule for the patching job.

Review

Allows you to review the information and submit the patching job.

Prerequisites

Before running the deployment procedure, ensure that you meet the following requirements:

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Software Library must be configured in OMS.

- All the target machines must have yum or up2date installed in it, and must also have sudo enabled for the patch user.

Patching Procedure

Follow these steps to patch Linux hosts using deployment procedures:

1. In the Deployments tab, click Patching through Deployment Procedures. Select Patch Linux Hosts and click Schedule Deployment.

2. In the Linux Distribution section, select the correct distribution and also select the update tool to use.

3. In the Package Repository section, click the torch icon to select the RPM Repository.

4. In the Select Updates page, select the packages to be updated.

5. In the Select Hosts page, select the targets to be updated. You can also select a group by changing the target type to group.

6. In the Credentials page, enter the credentials to be used for the updates.

7. In the Pre/Post script page, enter the pre/post scripts, if any.

8. In the Schedule page, enter the schedule to be used.

9. Review the update parameters and click Finish.

10. A deployment procedure will be submitted to update the selected packages. Follow all the steps of the procedure until it completes successfully.

11. Once the procedure is completed, you can view the updated versions of the packages by clicking Targets, selecting the target name, clicking Configuration, and then clicking Packages.

Linux Patching Home Page

In the Linux Patching Home page, you can do the following:

- Manage and monitor out-of-date and rogue packages for each host in the enterprise

- Configure targets that need to be automatically updated

- View compliance reports

Viewing Compliance History

The Compliance History page provides compliance details for the selected Group, for a specific time period. You can select the required time period from the View Data drop-down list and click Refresh.

Prerequisites

- At least one Linux patching group must be defined.

- You must have View privileges on the Linux host comprising the patching group.

Procedure to View Compliance History

To view the compliance history of a Linux patching group:

1. In the Deployments tab, select Linux Patching.

2. In the Linux Patching page, under Related Links, click Compliance History.

3. In the Compliance History page, the Groups table in this page lists all the accessible Linux patching groups and the number of hosts corresponding to each group.

4. If there are multiple Linux patching groups, the Compliance History page will display the historical data (for a specific time period) for the first group that is listed in that table.

5. To view the compliance history of a Linux patching group, click the View icon corresponding to that group.

Note:

By default, the compliance data that is displayed is retrieved from the last seven days. To view compliance history of a longer time period, select an appropriate value from the View Data drop-down list. The page refreshes to show compliance data for the selected time period.

Patching Non-Compliant Packages

Patch non-compliant packages from the Linux Patching home page.

Prerequisites

Before patching non-compliant packages, ensure that:

- A Linux Patching group is created and the Compliance Collection job has succeeded.

Procedure to patch Non-Compliant Packages

Do the following to patch non-compliant packages:

1. Log in to Enterprise Manager Grid Control.

2. In the Deployments tab, select Linux Patching.

3. In the Linux Patching page, in the Compliance Reporting section, select the Group and click Schedule Patching.

4. Control is transferred to the Credentials page of the "Patch Linux Hosts" deployment procedure. Click Back to change the list of packages to update or the targets to update.

5. Enter the credentials and click Next.

6. Enter the pre/post scripts, if any.

7. Enter the schedule.

8. Review the updated parameters and click Finish.

9. A deployment procedure is submitted to update the host. Check if all the steps finished successfully.

Undo Patching

You can uninstall packages from the Linux Patching home page.

Prerequisites

Before rolling back packages, ensure that:

- A Linux Patching group is created.

- The lower version of the package must be present in the RPM repository.

Procedure to Undo Patching

Do the following to uninstall or rollback packages installed:

1. Log in to Enterprise Manager Grid Control.

2. In the Deployments tab, select Linux Patching.

3. In the Linux Patching page, from the Compliance report table, click Undo Patching.

4. In the Undo Patching: Action page, select Uninstall Packages.

5. Select the Rollback Last Update Session option and click Next.

6. Select the Group and click Next.

7. In the Undo Patching: Credentials page, specify the credentials to be used while performing the undo patching job.

8. In the Undo Patching: Patching Scripts page, select the pre/post patching scripts if any.

9. Review the selected options and click Finish.

10. A job is submitted to rollback the updates done in the previous session.

11. Examine the job submitted to see if all the steps are successful.

Registering a Custom Channel

You can register a custom channel.

Prerequisites

Following are the prerequisites for registering a custom channel:

- RPM Repository must be under /var/www/html and accessible through http protocol.

- Metadata files should be created by running yum-arch and createrepo commands.

- Management Agent must be installed in the RPM repository machine and pointed to the OMS.

Procedure to Register a Custom Channel

Do the following to register a custom RPM Repository in Enterprise Manager Grid Control:

1. Log in to Enterprise Manager Grid Control.

2. Go to Setup and select Patching Setup.

3. In the Linux Patching Setup tab, click the Manage RPM Repository link.

4. In the Manage Repository Home page, click Register Custom Channel.

5. In the Register Custom Channel page, specify a unique channel name.

6. Click Browse and select the host where custom RPM repository was setup.

7. Specify the path where RPM repository resides. The directory location must start with /var/www/html/. Click OK.

8. A Package Information job is submitted. Follow the job until it completes successfully.

Cloning a Channel

You can clone a channel.

Prerequisites

Following are the prerequisites before you can clone a channel:

1. There must at least one channel already present.

2. Patching user must have read/write access in both the source and target channel machine.

3. Check if enough space is present in the target channel machine.

4. Patch user must have write access under the agent home. Patch user must have sudo privilege.

Procedure to Clone a Channel

Follow these steps to clone a channel:

1. Log in to Enterprise Manager Grid Control.

2. Go to Setup and select Patching Setup.

3. In the Linux Patching Setup tab, click the Manage RPM Repository link.

4. Select the source channel that you want to create-like (clone) and click Create Like.

5. Enter the credentials to use for the source channel. The credentials must have both read and write access.

6. Enter a unique target channel name.

7. Click Browse to select the target host name.

8. Enter the directory location of the target channel. This directory should be under /var/www/html.

9. Enter the credentials to use for the target channel. This credential should have both read and write access. Click OK.

10. A Create-Like job is submitted. Follow the job until it completes successfully.

Copying Packages from One Channel to Another

You can copy packages from one channel to another.

Prerequisites

Following are prerequisites to copy packages from one channel to another:

1. Atleast 2 channels must be present.

2. Patching user must have read/write access on both the source and target channel machine.

3. The target channel machine must have adequate space.

4. Patch user must have write access under the agent home. Patch user must have sudo privilege.

Procedure to Copy Packages from One Channel to Another

Follow these steps to copy packages from one channel to another:

1. Log in to Enterprise Manager Grid Control.

2. Go to Setup and select Patching Setup.

3. In the Linux Patching Setup tab, click the Manage RPM Repository link.

4. Select the source channel and click Copy Packages.

5. Select the target channel.

6. From the source channel section, select and copy the packages to the target channel section.

7. Enter credentials for the source and target channels. These credentials should have read/write access to the machines. Click OK.

8. A Copy Packages job is submitted. Follow the job until it completes successfully.

Adding Custom Packages to a Channel

You can add custom RPMs to a channel.

Prerequisites

Following are the prerequisites for adding custom RPMs to a channel:

1. Atleast one channel must be present.

2. Patching user must have write access on the channel machine.

3. Patch user must have write access under the agent home. Patch user must have sudo privilege.

Procedure to Add Custom Packages to a Channel

Follow these steps to add custom RPMs to a channel:

1. Log in to Enterprise Manager Grid Control.

2. Go to Setup and select Patching Setup.

3. In the Linux Patching Setup tab, click the Manage RPM Repository link.

4. Select the channel name where you want to add the RPM and click Add.

5. Select the source target name and the credentials to be used for the machine. The credentials you use must have read/write access.

6. In the Upload Files section, click the search icon to browse for the RPM files.

7. Enter the credentials to be used on the channel's machine. Click OK.

8. An Add Package job is submitted. Follow the job until it completes successfully.

Deleting a Channel

You can delete a channel.

Prerequisites

Following are the prerequisites for deleting a channel:

1. Atleast one channel must be present.

2. Patching user must have write access to delete the RPM files from the channel machine.

3. Patch user must have write access under the agent home. Patch user must have sudo privilege.

Procedure to Delete a Channel

Follow these steps to delete a channel:

1. Log in to Enterprise Manager Grid Control.

2. Go to Setup and select Patching Setup.

3. In the Linux Patching Setup tab, click the Manage RPM Repository link.

4. Select the channel name you want to delete and click Delete.

5. If you want to delete the packages from the RPM Repository machine, select the check box and specify credentials for the RPM Repository machine. Click Yes.

6. If you have not selected to delete the packages from RPM Repository machine, you will get a confirmation message saying "Package Channel <channel name> successfully deleted". If you have selected the Delete Packages option, a job will be submitted to delete the packages from the RPM Repository machine. Follow the job until it completes successfully.

Configuration File Management

This section explains the configuration file management activities. In particular, this section covers the following:

- Prerequisites

- Creating Config File Channel

- Uploading Configuration Files

- Importing Files

- Deploying Files

- Deleting Channels

Prerequisites

Check if Software Library is already configured in OMS or not. If not configured, create one.

Creating Config File Channel

To create a configuration file channel, do the following:

1. In the Deployments tab, click Linux Patching, and then click Configuration Files. Click Create Config File Channel.

2. Enter a unique channel name and description for the channel and click OK.

3. You will see a confirmation message saying that a new configuration file is created.

Uploading Configuration Files

You can upload configuration files.

Prerequisites

To upload configuration files, atleast one configuration file must be present.

Procedure to Upload Configuration Files

Follow these steps to upload configuration files:

1. In the Deployments tab, click Linux Patching, and then click Configuration Files.

2. Select the file and click Upload Configuration Files.

3. You can either upload files from local machine (where the browser is running) or from a remote machine (agent should be installed on this machine and pointed to OMS). Select the mode of upload.

4. In the File Upload section, enter the file name, path where the file will be deployed in the target machine, and browse for the file on the upload machine.

5. For uploading from remote machine, click Upload from Agent Machine. Click Select Target and select the remote machine.
Before browsing for the files on this machine, set preferred credential for this machine.

6. After selecting the files, click OK.

7. You will see a confirmation message saying "Files are uploaded".

Importing Files

You can import files.

Prerequisites

To import files, atleast two channels present.

Procedure to Import Files

Follow these steps to import files:

1. In the Deployments tab, click Linux Patching, and then click Configuration Files.

2. Select the source channel and click Import Files.

3. Select the target channel.

4. From Source channel section, select the files and copy it to the target channel section. Click OK.

5. You will see a confirmation message saying, "Selected files are successfully imported".

Deploying Files

You can deploy files.

Prerequisites

Following are the prerequisites to deploy files:

- Patch user must have write access under the agent home. Patch user must have sudo privilege.

- There should be at least one channel with some files uploaded

Procedure to Deploy Files

Follow these steps to deploy files:

1. In the Deployments tab, click Linux Patching, and then click Configuration Files.

2. Select the source channel and click Deploy Files.

3. In the wizard that opens up, select the files that you want to deploy and click Next.

4. Click Add to select the targets where you want to deploy the files.

5. Enter the credentials for the selected targets.

6. Enter the Pre/Post scripts that need to be applied before or after deploying the files.

7. Review the deploy parameters and click Finish.

8. A Deploy job will be submitted. Follow the job's link until it completes successfully.

Deleting Channels

You can delete channels.

Prerequisites

To delete channels, at least one configuration file must be present.

Procedure to Delete Channels

Follow these steps to delete a channel:

1. In the Deployments tab, click Linux Patching, and then click Configuration Files.

2. Select the channel to delete and click Delete. Click Yes.

3. You will see a confirmation message saying, "Config File Channel (channel name) successfully deleted".

21 Patching Solaris Hosts

Solaris Host Patching is a feature in Enterprise Manager Grid Control that helps in keeping the machines in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm.

This feature support in Enterprise Manager Grid Control enables you to patch Solaris hosts.

This chapter explains how you can patch Solaris hosts. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Solaris Hosts

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Solaris hosts. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Solaris hosts. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 21-1 Getting Started with Patching Solaris Hosts

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Solaris hosts.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases of Solaris are supported by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

To learn about the deployment phases involved in patching Solaris hosts, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the patching environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for patching Solaris hosts, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Solaris hosts.

To patch Solaris hosts, follow the steps explained in Patching Procedure.

Deployment Procedures

Enterprise Manager Grid Control provides the following Deployment Procedures for Solaris patching:

- Patch Solaris Hosts
This deployment procedure allows you to patch Solaris hosts. The steps to run this deployment procedure is specified in the next section.

Supported Releases

Following are the releases supported for Solaris patching:

- Solaris 8 and higher

Patching Solaris Hosts

This section explains how you can patch Solaris hosts. This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following table describes the different phases involved in this Deployment Procedure:

Table 21-2 Deployment Phases for Patching Solaris Hosts

Phase

Description

Package Repository

Allows you to select the patchdiag.xref file and the type of patches.

Select Updates

Allows you to select the packages to be updated.

Select Hosts

Allows you to select the targets to be updated.

Credentials

Allows you to enter the credentials for the patching operation.

Pre/Post Scripts

Allows you to specify any scripts to be run before and after the patching job.

Schedule

Allows you to specify the schedule for the patching job.

Review

Allows you to review the information and submit the patching job.

Prerequisites

Before running the deployment procedure, ensure that you meet the following requirements:

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Software Library must be configured in OMS.

- All the target machines must have sudo enabled for the patch user.

Patching Procedure

Follow these steps to patch Solaris hosts using deployment procedures:

1. In the Deployments tab, click Patching through Deployment Procedures. Select Patch Solaris Hosts and click Schedule Deployment.

2. In the Package Repository page, specify the Solaris package repository source.
You can choose to get the updates from the following locations:

- Update from SUN Server - Connect to the SUN server and download the Solaris updates from this Web site.

- Update from Local Server - set up a repository on a local server. To do this, you will require a Sun Spectrum contract account. Refer to the Sun web site for more details.

Depending on the type of application policy you select, you can either just stage the updates (and not apply them automatically), or choose to stage and apply the updates when the deployment procedure is executed.

To simply stage the updates and not apply, select Stage Updates.

To stage and apply the updates, select Apply Updates.

The patches when applied will have metadata (updates) that are classified as the following types:

- Standard: Updates of this type will take effect as soon as they are applied. The effects of this patch are visible as soon as it is applied, unless the application being patched is running while the patch is applied.

- Reboot-After: Updates of this type will take effect only after a reboot.

- Reconfigure-After: Updates of this type will take effect only after the application is reconfigured.

- Reboot-Immediate: If you select updates of this type, the selected hosts must be restarted immediately after the patch is applied.

- Reconfigure-Immediate: If you select updates of this type, the selected hosts must be reconfigured immediately after the patch is applied. If the patched hosts are not reconfigured immediately, such hosts become unstable.

3. In the Select Updates page, select the packages to be updated. Click Next.

4. In the Select Hosts page, select the targets to be updated. You can also select a group by changing the target type to group. Click Next.

5. In the Credentials page, enter the credentials to be used for the updates. Click Next.

6. In the Pre/Post Scripts page, specify any scripts to be run before and after patching. Click Next.

7. In the Schedule page, enter the schedule to be used. Click Next.

8. Review the update parameters and click Finish.

9. A deployment procedure will be submitted to update the selected packages. Follow all the steps of the procedure until it completes successfully.

10. Once the procedure is completed, you can view the updated versions of the packages by clicking Targets, selecting the target name, clicking Configuration, and then clicking Packages.

22 Patching Microsoft Windows Hosts

Microsoft Windows Host Patching is a feature in Enterprise Manager Grid Control that helps in keeping the machines in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm.

This feature support in Enterprise Manager Grid Control enables you to patch Microsoft Windows hosts.

This chapter explains how you can patch Microsoft Windows hosts. In particular, this chapter covers the following:

- Getting Started

- Deployment Procedures

- Supported Releases

- Patching Microsoft Windows Hosts

Getting Started

This section helps you get started with this chapter by providing an overview of the steps involved in patching Microsoft Windows hosts. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully patch Microsoft Windows hosts. Click the reference links provided against the steps to reach the relevant sections that provide more information.

Table 22-1 Getting Started with Patching Microsoft Windows Hosts

Step

Description

Reference Links

Understanding the Deployment Procedure

Understand the Deployment Procedure that is offered by Enterprise Manager Grid Control for patching Microsoft Windows hosts.

To learn about the Deployment Procedure, see Deployment Procedures.

Knowing About The Supported Releases

Know what releases of Windows are supported by the Deployment Procedure.

To learn about the releases supported by the Deployment Procedure, see Supported Releases.

Understanding the Deployment Phases

The Deployment Procedure consists of a series of interview screens that take you through the different deployment phases and capture the required information. Understand the different phases involved and know what information is captured in each phase.

To learn about the deployment phases involved in patching Microsoft Windows hosts, see Deployment Phases.

Meeting the Prerequisites

Before you run any Deployment Procedure, you must meet the prerequisites, such as setting up of the patching environment, applying mandatory patches, setting up of Oracle Software Library.

To learn about the prerequisites for patching Microsoft Windows hosts, see Prerequisites.

Running the Deployment Procedure

Run the Deployment Procedure to successfully patch Microsoft Windows hosts.

To patch Microsoft Windows hosts, follow the steps explained in Patching Procedure.

Deployment Procedures

Enterprise Manager Grid Control provides the following Deployment Procedures for Microsoft Windows patching:

- Patch Windows Hosts
This deployment procedure allows you to patch Microsoft Windows hosts. The steps to run this deployment procedure is specified in the next section.

Supported Releases

Following are the releases supported for Microsoft Windows patching:

- Windows XP

- Windows 2000

Patching Microsoft Windows Hosts

This section explains how you can patch Microsoft Windows hosts. This section covers the following:

- Deployment Phases

- Prerequisites

- Patching Procedure

Deployment Phases

The following table describes the different phases involved in this Deployment Procedure:

Table 22-2 Deployment Phases for Patching Microsoft Windows Hosts

Phase

Description

Package Repository

Allows you to select the Microsoft Windows repository URL.

Select Updates

Allows you to select the packages to be updated.

Select Hosts

Allows you to select the targets to be updated.

Credentials

Allows you to enter the credentials for the patching operation.

Pre/Post Scripts

Allows you to specify any scripts to be run before and after the patching job.

Schedule

Allows you to specify the schedule for the patching job.

Review

Allows you to review the information and submit the patching job.

Prerequisites

Before running the deployment procedure, ensure that you meet the following requirements:

- Ensure that you meet the prerequisites described in the following sections:

- Mandatory Infrastructure Requirements for Provisioning and Patching

- Optional Infrastructure Requirements

- Software Library must be configured in OMS.

- Microsoft Windows repository must be set up.

Patching Procedure

Follow these steps to patch Microsoft Windows hosts using deployment procedures:

1. In the Deployments tab, click Patching through Deployment Procedures. Select Patch Windows Hosts and click Schedule Deployment.

2. In the Package Repository page, enter the Microsoft Windows installer updates repository URL or select a repository configured earlier. You can also remove the selected URL from the database. Click Next.

3. In the Select Updates page, select the packages to be updated. Click Next.

4. In the Select Hosts page, select the targets to be updated. Click Next.

5. In the Credentials page, enter the credentials to be used for the updates. Click Next.

6. In the Pre/Post Scripts page, specify the scripts to be run before or after patching. Click Next.

7. In the Schedule page, enter the schedule for patching. Click Next.

8. Review the update parameters and click Finish.

9. A deployment procedure will be submitted to update the selected packages. Follow all the steps of the procedure until it completes successfully.

Once the procedure is completed, you can view the updated versions of the packages by clicking Targets, selecting the target name, clicking Configuration, and then clicking Packages.

Part VII

Customization

This part explains how you can customize Deployment Procedures. If you are already familiar with Deployment Procedures and have already used the out-of-box procedures for provisioning and patching, then this part will help you understand how you can create custom copies of those default procedures with changes specific to your environment. As "power users" of Deployment Procedures, you will now learn to add additional custom steps, use authentication utilities to switch as another user, and so on.

In particular, this part contains the following chapters:

- Chapter 23, "Customizing Deployment Procedures"

23 Customizing Deployment Procedures

The Deployment Procedures offered by Enterprise Manager Grid Control are default procedures that have been created considering all the best practices in the industry. The steps embedded within a Deployment Procedure ensure that they meet all your provisioning and patching requirements. You can, of course, use them with the default settings to provision or patch your targets in the environment, however, you also have the choice of customizing them to include additional custom steps, disable unwanted steps, and use authentication tools to run some steps as another user.

By customizing Deployment Procedures, you can also implement different error handling methods. For example, in a patching operation where multiple hosts are patched in parallel, it may be wise to skip the host on which a failure occurs. However, failure on a device creation could render the remaining provisioning operation ineffective. Therefore, it may be necessary to abort the entire procedure for failure of such a step.

This chapter helps you understand how you can customize Deployment Procedures to make them suit your needs. In particular, this chapter covers the following:

- Understanding Customization Types

- Understanding the Limitations

- Creating Copy of Deployment Procedure

- Adding Phases or Steps

- Deleting Phases or Steps

- Enabling or Disabling Phases or Steps

- Customizing Steps to Run as Another User

- Changing Error Handling Modes

- Customizing Directives

- Setting Up E-Mail Notifications

- Customizing Deployment Procedures to RollBack Patches

Understanding Customization Types

The following describes the types of customization you can perform with Deployment Procedures:

Type 1

Type 2

Editing Default Deployment Procedures
You can edit an existing, default Deployment Procedure that is offered by Enterprise Manager Grid Control.

You can perform the following tasks:

- Add your own phases and steps

- Enable and disable phases and steps

- Delete phases and steps

- Change privilege levels

- Change error handling modes

- Enable e-mail notifications

Creating Custom Deployment Procedures
You can create your own custom Deployment Procedure with new steps, phases, privilege levels, and so on. However, note that you can create custom Deployment Procedures only using Patching Deployment Procedures.

You can perform the following tasks:

- Delete all default phases and steps

- Add your own phases and steps

- Enable and disable phases and steps

- Change privilege levels

- Change error handling modes

- Enable e-mail notifications

The following shows the different sections that need to be edited while customizing a Deployment Procedure to add or delete steps, enable or disable steps, enable e-mail notifications, and enable other privilege-level settings.

Understanding the Limitations

Before you start customizing the Deployment Procedures, keep in mind the following points:

- When you customize any default patching Deployment Procedure offered by Enterprise Manager Grid Control, you must not disable or delete the Stage step and the Apply Patch step. You can disable or delete one of them, but not both. If you still do so, then the <Target> Updates section on the Software Updates page of the Deployment Procedure will not appear. As a result, you will not be able to select a patch. If you want to add a custom step to replace them, them without disabling or deleting these steps, add an additional step while customizing the Deployment Procedure.

- When you create a new custom patching Deployment Procedure with the default steps disabled or deleted, you must also disable or delete the Initialize step. Otherwise, the custom Deployment Procedure will fail.

- If you do not have the privileges of a super administrator, then you will not be able to customize the Deployment Procedures (The Create Like button will be disabled for the Deployment Procedures). You will also not be able to update Oracle Software Library (Software Library).

Creating Copy of Deployment Procedure

The first step towards customizing a Deployment Procedure is to create a copy of the default Deployment Procedure that is offered by Enterprise Manager Grid Control. Note that only a copy can be edited and customized with your changes; the default Deployment Procedures must always and will always remain unchanged.

To create a copy of a default Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, edit the procedure to customize it according to your needs, and click Save.

Adding Phases or Steps

You can add additional phases or steps to a Deployment Procedure to run additional custom scripts, host commands, or jobs. For more information about phases and steps, see Understanding Phases and Steps.

This section explains how you can add different types of phases or steps to a Deployment Procedure. In particular, it covers the following:

- Adding Rolling or Parallel Phase

- Adding Job Step

- Adding Directive Step

- Adding Generic Component Step

- Adding Registered Component Step

- Adding Host Command Step

- Adding Manual Step

Adding Rolling or Parallel Phase

To add a rolling phase to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the phase before or after which you want to add a new phase, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the phase as described in Table 23-1.

2. On the Select Target List page, select a target list to indicate the type of targets on which the new phase should run.

3. On the Review page, review the information you have provided for creating a new phase, and click Finish.

Table 23-1 Field Description - Adding Rolling Phase

Field Name

Description

Select

Select Phase.

Name

Specify a name for the custom phase.

Description

Provide a description for the custom phase.

Condition

Leave this field blank.

Insert Location

If you want to insert the custom phase after the phase or step you selected, then select After <phase or step name>. Otherwise, select Before <phase or step>.

Type

If you are adding a rolling phase, then select Rolling. If you are adding a parallel phase, then select Parallel.

Error Handling

Select the error handling mode you want to set for the custom phase. To understand these error handling modes, see Changing Error Handling Modes.

Adding Job Step

To add a job step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Select Type page, select a job type that best describes the task that you want the step to perform. For example, if you want to job to transfer files across the network, then select File Transfer.

3. On the Map Properties page, specify values for the parameters that are required by the selected job type.

4. On the Review page, review the information you have provided for creating a new step, and click Finish.

Adding Directive Step

To add a directive step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Select Directive page, select a directive from the Software Library that you want to run on the targets.

3. On the Map Properties page, specify values for the properties associated with the selected directive.

4. On the Review page, review the information you have provided for creating a new step, and click Finish.

Adding Generic Component Step

To add a generic component step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Select Component page, select a component from the Software Library that you want to stage on the targets.

3. On the Select Directive page, select a directive from the Software Library that you want to run on the targets.

4. On the Map Properties page, specify values for the properties associated with the selected component and directive.

5. On the Review page, review the information you have provided for creating a new step, and click Finish.

Adding Registered Component Step

To add a registered component step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Select Type page, select a component type.
The list is a subset of the component types displayed on the Components page in the Provisioning tab. Each type in the list has a specific job associated with it. These jobs stage and install the components.

3. On the Select Component page, select a component from the Software Library that you want to stage on the targets.

4. On the Map Properties page, specify values for the parameters that are required by the job associated with the selected component.

5. On the Review page, review the information you have provided for creating a new step, and click Finish.

Adding Host Command Step

To add a host command step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Enter Command page, specify the command or script, which you want to run on the target, and the privilege to run it.
To run the host command as a script, select Script from the Command Type list. Specify the shell that can interpret the script. The script is passed as standard input to the specified interpreter.

To run the host command as a command line, select Single Operation from the Command Type list. Specify the text you want to execute used as a command line. No assumptions are made about the shell to interpret this command line. The first entry in the command line is assumed to be the process to spawn and the rest of the command line as passed as arguments to this process. Therefore, a command line of ls -a /tmp spawns a process of "ls" (from the current path; also depends on the Oracle Management Agent) and passes "-a" as the first argument and then "/tmp" as the second argument to this process.

Note: The command line mode assumes that the first part of the command line is the process to be spawned. Therefore, shell internals and the commands that rely on the PATH environment variable for resolution are not recognized. If any such commands need to be used, then you need to prepend the shell that interprets the command line.

For example, the command cd /tmp && rm -rf x expands to "cd" as a process and then "/tmp, &&, rm, -rf, x" as arguments. To fix this, change the command line to /bin/csh -c "cd /tmp && rm -rf x".

Another example, the command export PATH=/opt:${PATH}; myopt -install expands to "export" as a process and then "PATH=/opt:${PATH};, myopt, -install" as arguments. To fix this, use /bin/sh -c "export PATH=/opt:${PATH}; myopt -install".

3. On the Map Properties page, specify values for the parameters that are required by the job associated with the selected component.c

4. On the Review page, review the information you have provided for creating a new step, and click Finish.

Adding Manual Step

To add a manual step to a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step before or after which you want to add a new step, and click Insert.

5. In the Create wizard, do the following:

1. On the Create page, specify general information about the step as described in Table 23-2.

2. On the Enter Instructions page, provide a message to inform the operator about a manual step. For example, if want to instruct the operator to log in to a system and update the kernel parameter, then specify the following:

You have been logged out of the system. Log in and update the Kernel parameters.

3. On the Review page, review the information you have provided for creating a new step, and click Finish.

Table 23-2 Field Description - Adding Steps

Field Name

Description

Select

Select Step.

Name

Specify a name for the custom step.

Description

Provide a description for the custom step.

Condition

Leave this field blank.

Insert Location

If you want to insert the custom step after the step you selected, then select After <step name>. Otherwise, select Before <step>.

Type

- For a job step, select Job.

- For a directive step, select Library: Directive.

- For a generic component, select Library: Generic Component.

- For a registered component, select Library: Registered Component.

- For a manual step, select Manual.

- For a host command step, select Host Command.

Error Handling

Select the error handling mode you want to set for the custom step. To understand these error handling modes, see Changing Error Handling Modes.

Deleting Phases or Steps

You can delete the phases or steps that you do not want in a Deployment Procedure. For more information about phases and steps, see Understanding Phases and Steps.

To delete phases or steps in a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select the step or phase you want to delete, and click Delete.
Oracle recommends that you disable the steps or phases instead of deleting them because steps or phases once deleted cannot be retrieved, but steps or phases disabled can always be enabled later. For information about enabling and disabling steps or phases, see Enabling or Disabling Phases or Steps.

Enabling or Disabling Phases or Steps

If you do not want to have some phases or steps in a Deployment Procedure, you can always disable them instead of deleting them. This is a preferred option because phases or steps once deleted cannot be retrieved, but phases or steps disabled can always be enabled later. For more information about phases and steps, see Understanding Phases and Steps.

To enable or disable phases or steps in a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, do the following:

1. To disable a phase or step, select the phase or step you want to disable, and click Disable.

2. To enable a phase or step, select the phase or step you want to enable, and click Enable.

The following is an example that illustrates how you customize the Oracle Database Provisioning Deployment Procedure to enable the Prepare Create Directory step:

Customizing Steps to Run as Another User

All the Deployment Procedures offered by Enterprise Manager Grid Control require administrator privileges to run. While most steps within a Deployment Procedure can be run as a normal user, there are some steps that require special permissions and privileges, and unless you provide the administrator's credentials, you cannot proceed with the deployment. For more information about steps, see Understanding Phases and Steps.

Under such circumstances, you can do one of the following. Although the former option is recommended, you are always free to use the latter option to suit your needs.

- Customize the Deployment Procedure to disable the steps that require special privileges, run the other steps as a normal user, and have the administrator run the disabled steps later.

- Use authentication utilities to run some steps within the Deployment Procedure with the privileges of another user. The authentication utilities supported by Enterprise Manager Grid Control are SUDO, PowerBroker, and Privilege Delegation.

This section explains the how Privilege Delegation scores over other two utilities, and describes how you can customize the steps within a Deployment Procedure to run them as another user.

In particular, this section covers:

- Choosing Privilege Delegation Over SUDO and PowerBroker

- Updating SUDOERS File with a List of Commands

- Creating Privilege Delegation Templates

- Using SUDO, PowerBroker, and Privilege Delegation Settings

Choosing Privilege Delegation Over SUDO and PowerBroker

While SUDO and PowerBroker are third-party utilities supported in Enterprise Manager Grid Control, Privilege Delegation is proprietary to Oracle. Privilege Delegation is a framework that allows you to use either SUDO or PowerBroker to perform an activity with the privileges of another user. Privilege Delegation can use either SUDO or PowerBroker, but not both, and the settings are only for a single host. Therefore, if a host is set up with pbrun, then it will use only pbrun.

The support for SUDO and PowerBroker is offered in Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) or lower, but the support for Privilege Delegation is offered only in Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or higher.

Note:

The supported version of SUDO is 1.6.9.5 P5, and the supported version of PBRUN is 4.0.8.

You can use any of these authentication utilities to run the deployment procedure. However, some limitations involved in using SUDO and PowerBroker are:

- While SUDO is supported in a password-protected mode, PowerBroker is not. Therefore, every time you use PowerBroker, you will have to run them without a password.

- You have to configure SUDO and PowerBroker settings every time you edit a deployment procedure. You cannot create a standard template with these settings that can be reused wherever required.

- You can use SUDO and PowerBroker settings only for deployment procedures, and not for jobs that can be run for performing critical tasks on hosts.

Privilege Delegation, a framework that combines SUDO and PowerBroker, offers the same functionality with the following advantages:

- You have the flexibility to use either SUDO or PowerBroker within the same framework.

- Using the framework, you can now run PowerBroker in a password-protected mode. This offers more security.

- You can create a template with these Privilege Delegation settings and reuse it for multiple hosts. This not only allows you to standardize Privilege Delegation setting across your enterprise, but also facilitates the process of configuring Privilege Delegation Settings. It simplifies the Privilege Delegation setting management as well.

- You can use the Privilege Delegation settings not only for deployment procedures, but also for jobs in Enterprise Manager Grid Control.

Updating SUDOERS File with a List of Commands

If you want to use SUDO authentication utility, then before editing a Deployment Procedure, update the /etc/sudoers file to allow a normal user to switch to another user who has the privileges to run the Deployment Procedure. Also, if you want to restrict the normal user to have SUDO access only to certain commands, then specify a list of those commands for which SUDO access is required.

The following provides a list of commands for which SUDO access is required for different Deployment Procedures:

Table 23-3 Updating SUDOERS File with a List of Commands

Deployment Procedure Name

Commands Requiring SUDO Access

- Oracle Clusterware / RAC Provisioning For UNIX

- Oracle Clusterware / RAC Provisioning For Windows

- One Click Extend Cluster Database

- Delete/Scale down Oracle Real Application Clusters

/bin/sh, $ENV{EMDROOT}/perl/bin/perl, $ENV{EMDROOT}/bin/nmupm, $ENV{EMDROOT}/bin/nmhs, /bin/pwd, /usr/bin/tee, /bin/echo, /bin/cut,/sbin/ifconfig, /usr/bin/tr, /bin/awk,/bin/rpm, /bin/grep,/bin/sed, /sbin/sysctl, /usr/bin/free, /usr/sbin/useradd, /bin/cp,/sbin/service, /usr/bin/head, /usr/bin/tail, /bin/chmod, /bin/chown, /sbin/ifconfig, /usr/sbin/usermod, /sbin/depmod, /bin/uname, /bin/ln, /bin/umount, /bin/mount, /bin/mkdir, /bin/ls, /bin/rm, /bin/basename, /bin/netstat, /bin/df, /bin/hostname, /bin/mv

In addition, add the following line:

env_keep +="PERL5LIB"

Creating Privilege Delegation Templates

If you want to use Privilege Delegation authentication utility, then before editing a Deployment Procedure, create a Privilege Delegation template with the required settings for a host. To do so, follow these steps:

1. In Grid Control, from the top-right corner, click Setup.

2. On the Overview of Setup page, from the vertical menu, click Manage Privilege Delegation Settings.

3. On the Manage Privilege Delegation Settings page, from the Related Links section, click Manage Privilege Delegation Settings Template.

4. On the Manage Privilege Delegation Settings Templates page, from the Create list, select a privilege delegation type, either Sudo or PowerBroker, and click Go.

5. On the Create '<delegation type>' Setting Template page, provide the template name and the command to run (for PowerBroker, you can optionally provide the password prompt), and click Save.

6. On the Manage Privilege Delegation Setting Templates page, select the template you created and click Apply.

7. On the Apply '<delegation type>' Setting: New page, click Add Targets to apply the privilege delegation template settings to selected hosts, and click Apply.

Note:

If you do not apply the privilege delegation template to a target, and if you configure a step in the deployment procedure to run in Privilege Delegation mode, then the deployment procedure for that target runs the step in normal mode instead.

8. After creating the template, to understand how it can be applied to Deployment Procedures, see Using SUDO, PowerBroker, and Privilege Delegation Settings.

Using SUDO, PowerBroker, and Privilege Delegation Settings

You can use SUDO, PowerBroker, and Privilege Delegation Settings globally, that is, for all steps, or only for some steps within a Deployment Procedure. This section explains the following:

- Making Global Settings

- Making Step-Level Settings

Making Global Settings

For SUDO and PowerBroker, you can specify the SUDO and PowerBroker commands to run, and also set environment variables and the preferred command interpreter for them.

For Privilege Delegation, you can specify the user and the profile that the step must run as.

Making Step-Level Settings

For each step, from the Run Privilege column, you can select either SUDO, PAM, or Privilege Delegation.

If you select SUDO or PAM, then in the Run Privilege Command/Privilege Delegation column, specify the Run As command. If you select Privilege Delegation, then specify the Run As value in the first text box and the Profile value in the second text box.

Note:

If you select SUDO or PAM, and leave the Run Privilege Command column blank, then the commands as set in the SUDO Command and PAM Command fields are used. However, if you want some steps to override these globally declared commands, then in the Run Privilege Command column for that step, specify the commands that need to be used instead. If these settings are not made, then the Run As and Profile values specified along with preferred credential are used.

See Also:

You can access My Oracle Support note 603108.1 to view use cases that describe how SUDO and PAM settings can be applied.

For file transfer-based job steps, you can apply the Privilege Delegation settings while editing that step. For example, one of the steps in the One Click Extend Cluster Database deployment procedure is Copy Archives. This is a file transfer-based job step for which you can apply the Privilege Delegation settings. To do so, you can click the step name and on the Map Parameters page, in the Run Mode section, from the Run Privilege for Source Target list and Run Privilege for Destination Target list, select Privilege Delegation. Then provide the Run As value and profile that must be used.

Note:

For configuration collection-based job step, you can NOT apply any Privilege Delegation settings. For example, one of the steps in the One Click Extend Cluster Database deployment procedure is Refresh Host Configuration. This is a configuration collection-based step for which Privilege Delegation settings cannot be applied.

Changing Error Handling Modes

Every step in a Deployment Procedure is preconfigured with an error handling mode that indicates how the Deployment Procedure will behave when the phase or step encounters an error. The error handling modes offered by Enterprise Manager Grid Control are:

- Inherit - Inherits the error handling mode that was set for the enclosing phase. (When set for a step that is outside a phase, it inherits the error handling mode from the Deployment Procedure).

- Stop On Error - Stops when an error is encountered. Deployment Procedure does not proceed to the next step until you correct the errors or override them.

- Continue On Error - Continues even when an error is encountered.

- Skip Target - Ignores the failed target on the list and continues with other targets.

For more information about steps, see Understanding Phases and Steps.

To change the error handling modes, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure you want to customize, and click Create Like.

4. On the Create Like Procedure page, select a phase or step, and from the list provided in the Error Handling Mode column against that phase or step, select the mode you want to set.
Once the mode is selected from the list, Enterprise Manager Grid Control automatically refreshes the page with the newly selected mode for that phase or step.

The following is an example that illustrates how you customize the Oracle Database Provisioning Deployment Procedure to change the error handling mode of the Destination User Permission Checks phase:

Customizing Directives

Directives are essentially scripts stored in the Software Library. They are used in Deployment Procedures within a Directive Step, which is a special type of action step. For more information about Directive Step, see Understanding Phases and Steps.

If you want to customize a directive offered by Enterprise Manager Grid Control, then first create a copy of the Perl script associated with that Directive and make a new directive out of that copy. Then customize the Deployment Procedure to modify a step to use this new directive, and then schedule the deployment. This section explains the following:

- Creating Copy of a Default Directive

- Storing the New Directive

- Customizing Deployment Procedure to Use the New Directive

- Running the Customized Deployment Procedure

Creating Copy of a Default Directive

To create a new customized directive using a default directive, follow these steps:

1. In Grid Control, click the Deployments tab and then the Provisioning secondary tab.

2. On the Provisioning page, click Directives.

3. On the Directives page, from the table, expand Oracle Directives and then expand other levels under this category to reach the directive you want to copy.
For example, if you want to copy the Apply Patch directive of a patching operation, then expand Oracle Directives and then expand Patching. From this level, expand Common, and then All, and finally Generic. Under Generic, you should see the directive Apply Patch.

4. Select the directive you want to copy and click Edit. Open the Perl script, copy the contents of it to a local editor, and save it locally.

Storing the New Directive

To store the new directive, follow these steps:

1. In Grid Control, click the Deployments tab and then the Provisioning secondary tab.

2. On the Provisioning page, click Directives.

3. On the Directives page, click Create Folder to create a folder titled Custom Directives. This is to ensure that you separate the custom directives from the default directives.

4. On the Directives page, from the table, select Custom Directives and click Create Directives.

5. In the Create Directive wizard, do the following:

1. On the Describe page, describe the directive you are creating.

2. On the Configure page, click Add to specify the command line arguments to be passed to the Directive. Set the Shell Type to Perl because you are adding a Perl script. If the script is neither Perl nor Bash, then set it to Defined in Script.
Each entry represents a single command line argument. Each argument may include a variable to be set later, a prefix and suffix. The prefix and suffix text are appended before and after the property value to produce the command line argument.

Repeat this step to add all the command line arguments.

3. On the Upload File page, select Upload from Local Machine and click Browse to select the script from the local system where you saved the file.

4. On the Review page, review the information you have provided for this new directive, and click Finish.

Customizing Deployment Procedure to Use the New Directive

To customize a Deployment Procedure to use the new directive, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure for which you want to use this new directive, and click Create Like.

4. On the Create Like Procedure page, do the following:

1. From the table that lists all the steps within that Deployment Procedure, select the directive step with which you want to associate the new directive, and click Edit Step.

2. In the Edit Directive Step wizard, do the following:

1. On the Edit page, click Next.

2. On the Select Directive page, select Select New Directive. Then search and select the new directive you created, and click Next.

3. On the Map Properties page, specify the values for the directive properties, and click Next.

4. On the Review page, click Finish.

3. Click Save.

Running the Customized Deployment Procedure

To run the customized Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the customized Deployment Procedure and click Schedule Deployment.

Setting Up E-Mail Notifications

Enterprise Manager Grid Control can send e-mail notifications to report the status of a Deployment Procedure. However, by default, Deployment Procedures do not have this feature enabled. To configure Deployment Procedures to send e-mail notifications, you must first customize them and enable the e-mail notification option, and then enable the Send E-mail option for the standard PAF Status Notification rule. This section describes how you can enable e-mail notifications for Deployment Procedures. In particular, this section covers the following:

- Enabling E-Mail Notifications

- Customizing PAF Status Notification Rule

IMPORTANT:

As a prerequisite, you are expected to have configured the Mail Server and set up the e-mail address in Enterprise Manager Grid Control. If you have not already done this, see the chapter on Configuring Notifications in the Enterprise Manager Configuration Guide available at:
http://www.oracle.com/technology/documentation/oem.html

Enabling E-Mail Notifications

To enable e-mail notifications in a Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the Deployment Procedure for which you want to set up e-mail notification, and click Create Like.

4. On the Create Like Procedure page, do the following:

1. Select Enable Notification.

2. (Optional) For Procedure Status Notification Job Tag, provide a notification tag name.

Note:

Ensure that you specify not more than 30 characters. The text you specify here will be prepended to the notification job name.

3. For Status for which Notification is to be Sent, select the state for which you want the notifications to be sent.

4. Click Save.
Enterprise Manager Grid Control displays the Deployment Procedure Manager page.

5. On the Deployment Procedure Manager page, from the top-right corner, click Preferences.

6. On the General page, do the following:

1. In the E-mail Address section, click Add Another Row to add a row in the table, and specify the e-mail address to which the notification should be sent.

2. Click Apply.

3. From the left menu bar, click Rules.

7. On the Notification Rules page, do the following:

1. From the table, select PAF Status Notification, and for this notification rule, enable the Send E-mail option from the Subscribe (Send E-mail) column.

2. Click Apply.

Customizing PAF Status Notification Rule

You can customize the standard PAF Status Notification rule to receive notifications in required ways for specific deployment procedures. For example, you might want to be notified by e-mail for a test system procedure, but for a production run you might want to be informed of the status through SMS Alerts.

To incorporate specific requirements and enable different methods of notification, you should use the Create Like function to modify the standard notification rule and edit the job with the specific notification tag name used in the Deployment Procedure and associating specific method of notification from the pre-defined notification methods.

To customize the standard PAF Status Notification rule, follow these steps:

1. In Grid Control, from the top-right corner, click Preferences.

2. On the General page, from the left menu bar, click Rules.

3. On the Notification Rules page, from the table, select PAF Status Notification, and click Create Like.

4. On the Create Notification Rule page, do the following:

1. On the General page, specify a notification rule name and a brief description for the rule.

Customizing Deployment Procedures to RollBack Patches

To roll back patches, you must first download the rollback Perl script, then upload it as a directive to the Software Library, and then use it with a customized Deployment Procedure. This section explains how can perform each of these tasks. In particular, this section covers the following:

- Downloading Rollback Perl Script

- Storing the Script as a Directive

- Customizing Deployment Procedure to Use Rollback Directive

- Running the Customized Deployment Procedure

Downloading Rollback Perl Script

To roll back patches, you have to use the Perl script rollback_patch.pl. This script is available as an attachment to My Oracle Support Note: 577557.1. Access this note and download the script to your local system.

Storing the Script as a Directive

To store the rollback_patch.pl script as a directive in the Software Library, follow these steps:

1. In Grid Control, click the Deployments tab and then the Provisioning secondary tab.

2. On the Provisioning page, click Directives.

3. On the Directives page, click Create Folder to create a folder titled Custom Directives. This is to ensure that you separate the custom directives from the default directives.

4. On the Directives page, from the table, select Custom Directives and click Create Directives.

5. In the Create Directive wizard, do the following:

1. On the Describe page, specify the name Rollback Patches and provide the description Directive to roll back patches in rollback or nrollback mode. Click Next.

2. On the Configure page, click Add to specify the following command line arguments to be passed to the Directive: oh, patchid, stageDir, command, patchsetRelease.
Set the Shell Type to Perl because you are adding a Perl script.

3. On the Upload File page, select Upload from Local Machine and click Browse to select the script from the local system where you saved the rollback_patch.pl file.

4. On the Review page, review the information you have provided for this new directive, and click Finish.

Customizing Deployment Procedure to Use Rollback Directive

To customize a Deployment Procedure to use the new Rollback Patches directive, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select a patching Deployment Procedure that you want to customize for using this new directive, and click Create Like.

4. On the Create Like Procedure page, do the following:

1. From the table that lists all the steps within that Deployment Procedure, select the Apply Patch directive step with which you want to associate the new directive, and click Insert.

2. In the Insert Directive Step wizard, do the following:

1. On the Create page, provide a name and description. From the Insert Location list, select Before "Apply Patches". From the Type list, select Library: Directive. Click Next.

2. On the Select Directive page, select Select New Directive. Then search and select the new Rollback Patches directive you created. Select Always Use Latest Revision. Click Next.

3. On the Map Properties page, specify the following values for the directive properties, and click Next.

Table 23-4 Map Properties

Directive Property

Display Name to be Specified

Description to be Specified

Variable to be Specified

Oh

ORACLE_HOME

Oracle home of the target

Select Choose Variable and then select Target Variable: oraHome from the associated list.

patchid

Patch ID

Comma-separated list of patch numbers

Select Ask User at Run-Time

stageDir

Stage Directory

Directory where the patch can be staged

Select Choose Variable and then select replacedStageDir from the associated list.

It can be also be set to a value where the patch is staged. However, this is required only for patches of release 10.1.0.x

command

Rollback Command

Rollback command to run

Select Ask User at Run-Time

patchsetRelease

Patch Set Release Version

Patch set release number

Select Ask User at Run-Time

4. On the Review page, click Finish.

3. Click Save.

Running the Customized Deployment Procedure

To run the customized Deployment Procedure, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, select the customized Deployment Procedure and click Schedule Deployment.

4. In the Deployment Procedure Wizard, provide the required information and submit it for deployment.
On the Library Step Properties page, you will be prompted to specify the patch ID, the rollback command, and the patch set release version. Specify the following vales on this page:

Table 23-5 Values for Library Step Properties Page for Rolling Back Patches

Library Step

Values to be Specified

Patch ID

Specify the patch number you want to roll back. If you want to roll back multiple patches, then specify the patch number separated by a comma.

Rollback Command

Specify rollback for normal patches and nrollback for Napply CPU patches.

Patchset Release Version

Specify the release for which the patch is being applied.

Part VIII

Enterprise Manager Command Line Interface (EMCLI)

This part describes how you can use Enterprise Manager Command Line Interface (EMCLI) commands to run Deployment Procedures.

This part contains the following chapters:

- Chapter 24, "Using EMCLI to Run Deployment Procedures"

24 Using EMCLI to Run Deployment Procedures

This chapter introduces the usage of EMCLI commands to run Deployment Procedures. In particular, this chapter covers the following:

- EMCLI Concepts

- EMCLI Requirements

- Using EMCLI to Run Deployment Procedures

- Use Cases for EMCLI-based Provisioning and Patching

- Setting Up Preferred Credentials for Targets

- Queries to Acquire Data for Patching Runtime

- EMCLI Verbs for Deployment Procedures

- EMCLI Verbs for Deployment Instances

EMCLI Concepts

To gain a better understanding for using EMCLI, you should familiarize yourself with the following EMCLI concepts:

- RuntimeData xml
Runtime data response file (known as RuntimeData xml) is required to run any out-of-the-box or customized procedures. This file provides input for the configuration parameters consumed by a given procedure during execution.

Each time you use the Enterprise Manager Console to run an out-of-box or customized Deployment Procedure, a RuntimeData xml file is automatically created based on the user input for the various parameters required by the procedure.

- RuntimeData Template
Oracle provides out of the box templates for creating runtime data response files for the Deployment Procedures used in the most common use cases. These are known as "RuntimeData templates". These templates are available under the emcli/samples directory in OMS oracle home. The user needs to modify the configuration properties in these templates in order to generate RuntimeData xml file for a executing a procedure.

For example, in order to provision RAC/AS you need to provide inputs such as install base location, shared device paths for the OCR, Voting disk and data files (in case of RAC). Similarly, for patching procedures inputs such as targets to be patched and patch number would be needed.

- Procedure GUID
Both out-of-box and customized procedures are associated with a global unique identifier (GUID). This GUID is required while executing the procedures using EMCLI.

- Procedure Instance GUID
Each execution of a given out-of-box or customized procedures is associated with an instance global unique identifier (GUID). This instance GUID is generated at runtime and can be used to monitor the execution of the procedure.

- Properties File
For every execution of Deployment Procedure you must modify the values of the required configuration parameters for a RuntimeData xml or RuntimeData template. Instead of manually editing the xml files, you can populate a simple properties with name-value pairs for listing values of configuration parameters such as hosts, platform for deployment, and so on.

- Procedure Execution Scripts
Oracle provides out of box scripts for the execution of procedures for Provisioning and Patching. These Perl scripts are available under the emcli/scripts directory in the OMS Oracle home. The user needs to copy the scripts to the working directory location where the EMCLI client is setup for execution.

The properties file, the associated RuntimeData xml or RuntimeData template, and GUID of the relevant procedure are then submitted as input to an out-of-box script which creates a new runtime data response file and runs the procedure.

EMCLI Requirements

You must ensure that the following requirements are met prior to using EMCLI to run Deployment Procedures:

- EMCLI client must be set up. Refer to the Installation and Configuration section of the Oracle Enterprise Manager Command Line Interface 10g Release 5 (10.2.0.5.0) for configuring the EMCLI client. The document is available in the following location:
http://download.oracle.com/docs/cd/B16240_01/doc/nav/portal_booklist.htm

- Targets that will be supplied to the Deployment Procedures are managed by Management Agents of version 10.2.0.2 or higher.

- Download the procedure execution scripts, out-of-box templates and properties files on the machine where the EMCLI client is setup. The out-of-box templates and properties files for patching and provisioning are available in the respective directories under OMS HOME/emcli/samples/.

- EMCLI-based patching and provisioning uses the Oracle Home credentials set in Oracle Enterprise Manager. The preferred credentials can be set for the targets during the execution of the Deployment Procedures in Oracle Enterprise Manager. It can also be set explicitly from the Oracle Enterprise Manager user interface or by using EMCLI. Refer to Setting Up Preferred Credentials for Targets to set credentials for the Oracle Homes.

Using EMCLI to Run Deployment Procedures

Oracle provides out-of-the-box templates for creating run time data for Deployment Procedures used in the most common use cases. These are known as runtimedata templates. You can access them under the emcli/samples directory in the OMS Oracle home and you can then modify the configuration properties in these templates.

The following depicts the process to use EMCLI to run Deployment Procedures:

Figure 24-1 EMCLI Process to Run Deployment Procedures

There are four required actions to run Deployment Procedures. Those steps are described below:

1. Step 1: Find the GUID of the procedure to be run using EMCLI. This is a one-time activity.

2. Step 2: Obtain the RuntimeData xml or RuntimeData template for the procedure that needs to be run. This is also a one-time activity.

3. Step 3: Create the properties file for the RuntimeData xml or RuntimeData template. This step is required for each execution of the procedure.

4. Step 4: Submit the RuntimeData template or RuntimeData, properties file for the given execution and procedure GUID as input to an out-of-box script that will generate a new runtime data response file and then use this response file to run the procedure using EMCLI.

Each of these steps is discussed in detail in the subsequent sections.

Step 1: Finding Procedure GUID

EMCLI is case-sensitive so be sure to use the correct EMCLI verb and pass correct input. GUID out-of-box and customized procedures can be found using the following EMCLI verbs:

get_procedures

Usage: emcli get_procedures -type="procedure type"

Description: Get a list of Deployment Procedures.

Option:

-type="procedure type"Display all the Deployment Procedure of type {procedure type}.

Output Columns: GUID, Procedure Type, Name, Version, Created By

RAC procedures are of type: RACPROVAS procedures are of type: AS ProvisioningThe Standalone Database, RAC rolling, and CRS patching procedures are of type: PatchOracleSoftware

Alternatively the type associated with procedures can be found using the get_procedure_type EMCLI command.

get_procedure_types

Usage: emcli get_procedure_types

Description: Get the list of all Deployment Procedure types

Output Columns: Procedure Type

Step 2: Obtaining RuntimeData Template And RuntimeData XML

For out-of-box procedures, RuntimeData Templates are located in the emcli/samples directory in the Oracle Management Service (OMS) Oracle home.

For customized procedures you has to download the RuntimeData xml generated from an earlier execution of this procedure. To obtain the RuntimeData xml you first need to find the Instance GUID associated with the earlier execution of the procedure and then use it to download the RuntimeData xml generated for it. The following EMCLI verbs can be used to download a RuntimeData xml:

emcli get_instances -type="procedure type"

Usage: emcli get_instances -type="procedure type"

Description: Display list of procedure instances. EMCLI verb to obtain Instance GUID associated with an earlier execution of the customized procedure.

Option: -type="procedure type"Display all the Procedure Instances of a given type.

Output Columns: Instance GUID, Procedure Type, Instance Name, Status

To find the type associated with procedures, use the get_procedures_type verb.

emcli get_instance_data_xml -instance="instance_guid"

Usage: emcli get_instance_data_xml -instance="instance_guid"

Description: Download Instance Data XML. EMCLI verb to download a RuntimeData xml using Instance GUID.

Option: -instance is used to specify the instance GUID.

Example: emcli get_instance_data_xml -instance="16B15CB29C3F9E6CE040578C96093F61"

Output: The Instance Data XML.

Step 3: Creating Properties File

The following sections describe the properties files for out-of-box procedures, customized procedures, and extending procedure execution.

Properties File for Out-Of-Box Procedures

If you are using an out-of-box RuntimeData template, a user identifies the variables in the RuntimeData template file that need to be replaced with values for the configuration properties for a given execution of the procedure. Of all the variables present in the Runtime Data templates, only some might be mandatory for running a given procedure. Once this is done you can create the properties file, which would contain name value pairs mentioning the variables and the values with which they would be replaced for generating the RuntimeData xml file.

For out-of-box procedures, a sample properties file can be found in Appendix B, "Sample Property Files for the Out-of-Box RuntimeData Templates". The corresponding RuntimeData Templates can be obtained from the zip file where this document is present.

Note that each sample properties files in the appendix mentioned above contains a section for mandatory variables which should be present in the properties file with relevant values to be substituted at run time. You can optionally provide values for other variables present in the templates.

Properties File for Customized Procedures

In case of customized procedures, the RuntimeData xml actually have values instead of placeholder variables for the configuration properties. You need to replace the old runtime values in the RuntimeData xml of the previous run with the new runtime values, which are relevant to the new run.

For this, you can have a properties file of the form:

<old_value>=<new_value>

For example, consider this snippet from the RuntimeData xml used to patch an Oracle Database:

…

<scalar value="dbtarget1" classname="java.lang.String" name="targetsToPatch"/><scalar value=" HostPrefNormal" classname="java.lang.String" name="hostCredentialSet"/>   <list classname="java.util.Vector" name="patchIDs">   <scalar value="=%oracle_home%/EMStagedPatches " classname="java.lang.String" name="stageDir"/><scalar value="false" classname="java.lang.String"     name="isPatchset"/><scalar value="true" classname="java.lang.String"     name="isNotPatchset"/><scalar value="defaultSqlScript" classname="java.lang.String" name="sqlScript"/>...

To patch another database you need to create a properties file with oldvalue=newvalue type of entries for at least the mandatory parameters (in case of patching on the mandatory property is targetsToPatch). Hence the new properties file would look something as below:

dbtarget1=dbtarget2

Since this approach would simply replace an old-string with a new-string, you might run into issues if the old-string is substring in multiple strings in the DP runtime xml. In that case the resulting runtime xml might be erroneous. To circumvent this issue, it is strongly advised to format the properties file a proper fashion. The thumb-rule here is: put the specifics before the generics. A fragment of a properties file in the form of old-value=new-value pairs shown below, illustrates this point.

node1.test.com=node2example.com

node1=node2

node1,node2=node3,node4

Also, for specifying the passwords in the properties file please make sure you include the following line in the properties file before mentioning any passwords.

oracle.sysman.pp.paf.impl.EncryptedString =oracle.sysman.pp.paf.impl.UnencryptedString

After this you can mention the password as shown in the examples below:

1. For a password value to replace the placeholder variable in the template file

oracle.sysman.pp.paf.impl.EncryptedString=oracle.sysman.pp.paf.impl. UnencryptedStringcrsasmrac_provisioning_USER_PASSWORD=mypassword

2. For a new password value to replace an older one in a RuntimeData xml

oracle.sysman.pp.paf.impl.EncryptedString=oracle.sysman.pp.paf.impl. UnencryptedStringmyOLDpass=myNEWpassword

Note that mypassword and myNewpassword used in the above examples are clear text passwords.

Note:

The elements var_runOpatchUpgrade and var_isUpgradeStepEnabled have been added to support Opatch upgrade. The first element should be set to "true" to run the opatch upgrade step. var_isUpgradeStepEnabled should be set to "true" if opatch is to be upgraded, otherwise, it should be "false".

Properties File For Extending Procedure Execution

Properties file allows you to use the same RuntimeData xml for extending the use case. For example, you might have performed a successful procedure execution (partial cluster scale- up or scale down or patching) for a target and you want to extend it to a set of new targets.

You can do this by using a Properties file and replacing the parameter values in it (Refer to the Mandatory parameter section in Appendix B, "Sample Property Files for the Out-of-Box RuntimeData Templates". For example:

node1 = node2,node 3

Wherein node1 is the target for which you had run the procedure previously and node2 and node3 are the targets to which you want to extend the procedure execution.

An exception to this rule is extending the patching procedures to a different set of targets, which would require you to have a properties file with the following mandatory parameter (Instead of the approach of <old-value>=<new-value>):

PA_VAR_targetsToPatch=Tgt2, Tgt3, Tgt4

Wherein Tgt2, Tgt3 and Tgt4 are the new targets to which you want to extend the procedure execution.

Refer to Queries to Acquire Data for Patching Runtime for the list of queries which can be used to acquire data for creating properties file.

Properties File For Applying Multiple Patches At Once

The new elements added in RuntimeData xml to support multiple patches are:

- patchesToBeApplied - Enter comma-separated list of patch IDs for this element.
Example: <scalar value="patchesToBeApplied" classname="java.lang.String" name="patchListToApply"/>

- patchSourceForPatches - Enter patch source, which is either SWLIB or METALINK. Default source is SWLIB
Example: <scalar value="patchSourceForPatches" classname="java.lang.String" name="patchListSource"/>

- patchPlatformForPatches - This is optional. Enter supported platforms for patchOptional. You must provide a valid platform ID. To get platform IDs, run the displayPlatformInfo.pl script in <EMCLI working directory>/scripts.
Example: <scalar value="patchPlatformForPatches" classname="java.lang.String" name="patchPlatform"/>

- patchReleaseForPatches - Enter the release of the patchset. This is optional, but required for patchsets.
Example: <scalar value="patchReleaseForPatches" classname="java.lang.String" name="patchRelease"/>

Step 4: Procedure Execution

First download and apply the Metalink patch - 5890474 on OMS 10.2.0.3 which will update the EMCLI procedure execution scripts, out-of-box templates, and properties files. This updates the emcli/samples and emcli/scripts directory in OMS Oracle home. After applying the patch on the OMS, download the procedure execution scripts, out-of-box templates, and properties files on the machine where the EMCLI client is set up. The out-of-box templates and properties files for patching and provisioning are available in the respective directories under OMSHOME/emcli/samples/.

Once the RuntimeData template or RuntimeData xml and properties file are ready, then the procedure can be run using the following script.

Usage:

perl executeDP.pl -t <template> -p <properties file name> -g <DP GUID> [-s <schedule> in the format yyyy/MM/dd HH:mm] [-z <time zone ID>] [-d <emcli directory path>, mandatory if emcli executable is not in the current directory]

Template -- The name of the RuntimeData template for out-of-box procedures or location of the RuntimeData xml file downloaded after the execution of a customized procedure.

Properties file name -- The location of the properties file created for executing the procedure.

DP GUID -- The GUID of the procedure that needs to be run.

emcli Directory -- The directory which contains the EMCLI executable. If the current working directory contains the EMCLI executable, this parameter is optional.

Schedule -- The time when the Deployment Procedure would be scheduled to run. If not specified it defaults to running the Deployment Procedure immediately. The HH:MM is based on 24 hrs clock, for example, 22:30.

Time Zone ID -- The time zone to which the Deployment Procedure run is scheduled. If not specified it defaults to the time zone of the OMS.

Below is a sample code string executing RAC provisioning procedure for UNIX using out-of-box procedure:

perl executeDP.pl -t crsasmrac_gold_prov_template.xml -p Properties.txt -g 31ABCFF2199BB77990B057AC4A442DAC -t 2007/02/03 10:00 -z Americas/New_York -d /oracle/prod/orahome/

The following parameter descriptions apply to the script:

crsasmrac_gold_prov_template.xml is the name of the out-of-box template.

Properties.txt is the properties file

31ABCFF2199BB77990B057AC4A442DAC is the GUID for the RAC provisioning procedure for UNIX

2007/02/03 10:00 is the date and time during which the Deployment Procedure is scheduled to run.

Americas/New_York is the Time Zone ID for which the time schedule is set.

/oracle/prod/orahome/ is the directory location for the EMCLI executables.

The properties file and the out-of-box template are located in the same directory as the script that was run.

Executing SIDB Patching for UNIX Using An Out-of-Box Procedure

Below is a sample code string executing single instance database patching for UNIX using an out-of-box procedure:

perl executeDP.pl patch_standalone_DB.xml Properties.txt 2EECED3592A0175FE040578CE808291F

The following parameter descriptions apply to the script:

patch_standalone_DB.xml is the name of the out-of-box template.

Properties.txt is the properties file.

2EECED3592A0175FE040578CE808291F is the GUID for the Single Instance Database patching procedure for UNIX.

The templates, properties file, and the EMCLI executables are located in the same directory as the script. Also, the Deployment Procedure is scheduled to run immediately in the time zone of the OMS.

Use Cases for EMCLI-based Provisioning and Patching

The following sections describe various use cases for EMCLI-based provisioning and patching procedures. You must first download and apply the Metalink patch - 5890474 on OMS 10.2.0.3 which will update the EMCLI procedure execution scripts, out-of-box templates, and properties files. This updates the emcli/samples and emcli/scripts directory in OMS oracle home. After applying the patch on OMS, download the procedure execution scripts, out-of-box templates, and properties files on the machine where the EMCLI client is setup. The out-of-box templates and properties files for patching and provisioning are available in the respective directories under OMS HOME/emcli/samples/.Before using any Real Application Cluster (RAC) related procedure, ensure that the Management Agents on the nodes are cluster Management Agents.

Use Cases for CRS/ASM/RAC Provisioning Procedure

Use Case 1: User wants to use the EMCLI to provision a 2-node RAC using a Gold Image from the software library. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with the mandatory configuration parameters required for RAC provisioning procedure and assigns appropriate values for the variables. Refer Sample Properties file with Mandatory parameters for out-of-box RAC provisioning procedure using Gold Image

- User finds the appropriate GUID for the RAC provisioning procedure. Refer to section "Out-of-box RuntimeData Templates For RAC Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box RAC provisioning procedure using Gold Image from Software Library.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID.

Use Case 2: User wants to use EMCLI to provision another 4 node RAC using the same out-of-box templates and properties file as used in Use case 1 to perform this operation.

- User takes the properties file from the previous use case and makes the necessary changes for the mandatory parameters to provision a 4-node RAC.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID. Sample usage of the script is shown below.

Use Case 3: User wants to use the EMCLI to provision a 2-node RAC using a Reference Installation. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with the mandatory configuration parameters required for RAC provisioning procedure and assigns appropriate values for the variables. Refer Sample Properties file with Mandatory parameters for out-of-box RAC provisioning procedure using Reference Installation.

- User finds the appropriate GUID for the RAC provisioning procedure. Refer to section "Out-of-box RuntimeData Templates For RAC Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box RAC provisioning procedure using Reference Installation.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID.

Use Case 4: User customizes and tests the out-of-box RAC provisioning procedure using reference host. He wants to use the EMCLI to provision a 2-node RAC. He uses the runtime data xml of the trial runs of his customized procedure and properties file to perform this operation on a similar 2-node RAC.

- Locates the instance GUID of the previous trial run.

- User downloads the Runtime data xml for the previous execution of the procedure.

- User identifies the parameters in the Runtime data xml that need to be substituted with new values. He then creates a properties file with name-value pairs like <old-value>=<new-value> for carrying out the necessary runtime substitutions. This properties file should at least contain the substitution rule for the values corresponding to the mandatory parameters mentioned in Sample Properties file with Mandatory parameters for out-of-box RAC provisioning procedure using Reference Installation in addition to the other values that he might want to substitute.

- User finds the GUID for the customized RAC provisioning procedure. Refer to section Finding Procedure GUID.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the downloaded Runtime data xml, and procedure GUID.

Use Case 5: User customizes and tests the out-of-box RAC provisioning procedure. He wants to use EMCLI to provision a N-node RAC. He uses the runtime data xml of a trial run of his customized procedure and properties file to perform this operation on a M-node cluster (where M>N).

- Locates the instance GUID of the previous trial run of the customized procedure.

- User downloads the Runtime data xml for the previous execution of the procedure.

- User identifies the parameters in the Runtime data xml that need to be substituted with new values. He then creates a properties file with name-value pairs like <old-value>=<new-value> for carrying out the necessary runtime substitutions. This properties file should at least contain the substitution rule for the values corresponding to the mandatory parameters mentioned in Sample Properties file with Mandatory parameters for out-of-box Oracle RAC provisioning procedure using Gold Image, in addition to the other values that he might want to substitute.

- User finds the GUID for the customized Oracle RAC provisioning procedure. Refer to section Finding Procedure GUID.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the downloaded Runtime data xml and procedure GUID.

Use Cases for Extend Cluster Procedure

Use Case 1: User wants to use the EMCLI to extend a 2-node Oracle RAC to 4-node cluster. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with at least the mandatory parameters required for cluster Extension procedure and assigns appropriate values for the variables. Refer to Sample Properties file with Mandatory parameters for out-of-box Cluster Extend procedure.

- User finds the appropriate GUID for the RAC provisioning procedure. Refer to section "Out-of-box RuntimeData Templates For RAC Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box Cluster Extend procedure.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, name of the out-of-box template and procedure GUID.

Use Cases For RAC Delete/Descale Procedure

Use Case 1: User wants to use EMCLI to delete the 2-node RAC cluster. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with at least the mandatory parameters required for RAC Delete procedure and assigns appropriate values for the variables. Refer Sample Properties file with Mandatory parameters for out-of-box Cluster Delete procedure.

- User finds the appropriate GUID for the RAC Delete procedure. Refer to section "Out-of-box RuntimeData Templates For RAC Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box Scale Down/Delete RAC procedure. Note that template used for Cluster Scale down and Cluster Delete use cases differ.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, name of the out-of-box template and procedure GUID.

Use Case 2: User wants to use the EMCLI to descale a 2-node RAC cluster. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with at least the mandatory parameters required for RAC Scale Down procedure and assigns appropriate values for the variables. Refer Sample Properties file with Mandatory parameters for out-of-box Cluster Descale procedure.

- User finds the appropriate GUID for the RAC Descale procedure. Refer to section "Out-of-box RuntimeData Templates For RAC Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box Scale Down/Delete RAC procedure. Note that template used for Cluster Scale down and Cluster Delete use cases are different.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, name of the out-of-box template and procedure GUID.

Use Cases for Patching

Use Case 1: User wants to use the out-of-box Database Patching procedure to apply a one-off patch to a database. He uses the out-of-box templates and properties file to perform this operation.

- User creates a Properties file with the mandatory configuration parameters required for patching the database with a particular one-off and assigns appropriate values for these variables. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.

- User finds the appropriate GUID for the Patch provisioning procedure. Refer to section "Out-of-box RuntimeData Templates For Patching Procedures" of Appendix A, "Out-Of-Box RuntimeData Templates" for GUID, procedure type, and template name information for the out-of-box Patch Oracle Database procedure.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID.

Use Case 2: User wants to use the Database Patching procedure to apply multiple one-off patches to multiple databases. He uses the out-of-box templates and properties file created in use User Case 1 above to perform this operation.

- User creates a Properties file with the mandatory configuration parameters required for patching the database with a particular one-off and assigns appropriate values for these variables. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID.

Use Case 3: User wants to use the Database Patching procedure to apply a patchset to a set of databases. He uses the out-of-box templates and properties file created in use Use Case 1 above to perform this operation.

- User creates a Properties file with the mandatory configuration parameters required for patching the database with a particular one-off and assigns appropriate values for these variables. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.

- User find the appropriate GUID for the Patch provisioning procedure.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the out-of-box template and procedure GUID.

Use Case 4: User customizes and tests the out-of-box Oracle Clusterware Patching procedure. He wants to use the EMCLI to patch a 2-node cluster. He uses the runtime data xml of the trial runs of his customized procedure and properties file to perform this operation on a similar 2-node cluster.

- User creates a Properties file with the mandatory configuration parameters required for patching the database with a particular one-off and assigns appropriate values for these variables. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.

- User finds the GUID for the customized patching procedure.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the run time data xml and procedure GUID.

Use Case 5: User customizes and tests the out-of-box Oracle Clusterware Patching procedure. He wants to use the EMCLI to patch a 2-node cluster. He uses the runtime data xml of the trial runs of his customized procedure and properties file to perform this operation on a similar N-node cluster.

- User creates a Properties file with the mandatory configuration parameters required for patching the database with a particular one-off and assigns appropriate values for these variables. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.
For example, use the mandatory variable of the Properties file for scaling up to multiple Targets as seen here:

PA_VAR_targetsToPatch=NewTarget1, NewTarget2, NewTarget3…

- User finds the GUID for the customized patching procedure.

- User submits the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the runtime data xml and procedure GUID.

Limitations

There is a limitation to consider when using patching Deployment Procedures through EMCLI.

Out-of -box templates are not available for patching Deployment Procedures like Application Server patching, Real Application Cluster -All nodes and pre-requisite checkers for Database, Real Application Cluster (RAC), Automatic Storage Management (ASM) and Clusterware. To use EMCLI for these procedures:

- Run the procedure once through the UI.

- Export the run time data xml
emcli get_instance_data_xml -instance="instance_guid"

Where, instance_guid is of the Deployment Procedure. (Refer to step 2-Obtaining Runtime Data Template and Data xml.)

- Create a properties file with the mandatory configuration parameter required for patching or running pre-requisite checker and assign appropriate values for the other changes. List of the mandatory values can be found from the Sample Properties file with Mandatory parameters for all the patching procedures.
For example, use the mandatory variable of the Properties file for scaling up to multiple Targets

PA_VAR_targetsT=NewTarget1, NewTarget2, NewTarget3…

- Submit the procedure for execution by invoking the executeDP.pl script and providing the location details of the properties file, location of the runtime data xml and procedure GUID.

Setting Up Preferred Credentials for Targets

The EMCLI execution looks for the credentials for the Targets under the Enterprise Manager with the OMS user executing the procedures. The preset credentials is looked up for the Targets under patching or for the ones used as a reference during provisioning procedures.

The credentials can be stored while doing any patching or provisioning operations through the Enterprise Manager user interface in the 'Credentials' section of the procedure run. If not, you can set up the credentials either through the Enterprise Manager OMS explicitly or through the use of EMCLI commands.

Setting Credentials from the Oracle Enterprise Manager User Interface

You can set the credentials for targets through the Oracle Enterprise Manager user interface by following these steps:

1. Log in to Oracle Enterprise Manger.

2. Access the link "Preferences" on the top right corner of the page.

3. Click on "Preferred Credentials" link in the Options section of the page.

4. Setup 'Normal' or 'Preferred Credentials' from this page for the Target type. (Example: Database Instance, Cluster Database or Cluster).

Setting Credentials through EMCLI

You can set the credentials for targets through EMCLI command line interface using the following code sequence:

set_credential              -target_type="ttype"             [-target_name="tname"]              -credential_set="cred_set"             [-user="user"]              -columns="col1:newval1;col2:newval2;..."             [-input_file="tag1:file_path1;tag2:file_path2;..."]             [-oracle_homes="home1;home2"]

The following list describes the options used in the EMCLI code:

- target_type - Type of target. Must be "host" in case "-oracle_homes" parameter is specified.

- target_name - Name of target. Omit this argument to set enterprise preferred credentials. Must be hostname in case "-oracle_homes" parameter is specified.

- user - Enterprise Manager user whose credentials are affected. If omitted, the current user's credentials are affected.

- columns - The name and new value of the column(s) to set. Every column of the credential set must be specified. Alternatively, a tag from the -input_file argument may be used so that the credential values are not seen on the command line. This argument may be specified more than once.

- input_file - Path of file that has -columns argument(s). This option is used to hide passwords. Each path must be accompanied by a tag, which is referenced in the -columns argument. This argument may be specified more than once.

- oracle_homes - Name of oracle homes on the target host. Credentials will be added/updated for all specified homes.

The list of columns and the credential sets they belong to is included in the metadata file for each target type. This and other credential information is in the <CredentialInfo> section of the metadata.

The following is an example of the sequence:

emcli set_credential -target_type=host -target_name=host.us.oracle.com -credential_set=OHCreds -user=admin1 -column="OHUsername:joe;OHPassword:newPass" -oracle_homes="database1;mydb"

For more details on EMCLI, refer to the verb reference section of Oracle® Enterprise Manager Command Line Interface 10g Release 5 (10.2.0.5.0). This document is available at:

http://download.oracle.com/docs/cd/B16240_01/doc/nav/portal_booklist.htm

Clearing Credentials through EMCLI

You can clear preferred or monitoring credentials for given users through the EMCLI command line interface using the following code sequence:

emcli clear_credential
-target_type="ttype"
[-target_name="tname"]
-credential_set="cred_set"
[-user="user"]
[-oracle_homes="home1;home2"]

The following list describes the options used in the EMCLI code:

- target_type - Type of target. Must be "host" in case "-oracle_homes" parameter is specified.

- target_name - Name of target. Omit this argument to set enterprise preferred credentials. Must be hostname in case "-oracle_homes" parameter is specified.

- credential_set - Credential set affected. This value is ignored for monitoring credentials.

- user - Enterprise Manager user whose credentials are affected. If omitted, the current user's credentials are affected.

- oracle_homes - Name of oracle homes on the target host. Credentials will be cleared for all specified homes.

Example 1:

emcli clear_credential
-target_type=oracle_database
-target_name=myDB
-credential_set=DBCredsNormal
-user=admin1

Example 2:

emcli clear_credential
-target_type=oracle_database
-credential_set=DBCredsNormal
-user=admin1

Queries to Acquire Data for Patching Runtime

Use the following queries to acquire data for patching runtime:

- Use the following query to acquire an Instance name from a host:
select target_name, target_type, oracle_home from em$ECM_TARGETS_VIEW where host = '<host name>';

- Get the instance name for a given host:
select target_name, target_type, oracle_home from em$ECM_TARGETS_VIEW where host = '<host name>';

- Get the instances of a CRS given the name of the CRS:
select assoc_target_name, crs_instance from sysman.mgmt$target_associations where assoc_def_name='contains' and source_target_name='<crs_name>' and source_target_type='cluster'

- Get all CRS and its instances:
select source_target_name crs_name, assoc_target_name, crs_instance from sysman.mgmt$target_associations where assoc_def_name='contains' and source_target_type='cluster' order by source_target_name

- Get instances of a RAC cluster given the name of the RAC cluster:
select assoc_target_name rac_instance from sysman.mgmt$target_associations where assoc_def_name='contains' and source_target_name='<rac_name>' and source_target_type='rac_database'

- Get all RAC clusters and their instances:
select source_target_name rac_name, assoc_target_name rac_instance from sysman.mgmt$target_associations where assoc_def_name='contains' and source_target_type='rac_database' order by source_target_name

EMCLI Verbs for Deployment Procedures

Following are the EMCLI verbs related to deployment procedures:

get_instance_status

Description

Display Procedure Instance status identified by the GUID on the command line.

Usage

emcli get_instance_status  -guid={guid number} [-xml [-details] [-showJobOutput [-tailLength={Last N Characters}]]]

Option

-guid={guid number}

Mandotory option to display the details of a Procedure Instance identified by the guid number.

{guid number} can be found using the emcli get_instances.

-xml

Show the complete status of each of the steps in XML format

-details

Optional option to display more details to the output of the command. Can only be used in conjunction with the -xml option.

-showJobOutput

Show output or error of the Job Execution steps.

-tailLength={Last N Characters}

Optional argument to limit the number of characters in the job step output or error. Can only be used with the -showJobOutput option.

{Last N Characters} is a positive non-zero number till which the characters would be picked from the end of the job step output

Max permissible characters to dump as part of the above is set by system.

If this option is not provided, then max permissible characters would be dumped.

Example

emcli get_instance_status -guid=16B15CB29C3F9E6CE040578C96093F61 -xml -showJobOutput -tailLength=1024
emcli get_instance_status -guid=16B15CB29C3F9E6CE040578C96093F61 -xml -details -showJobOutput
emcli get_instance_status -guid=16B15CB29C3F9E6CE040578C96093F61 -xml -details
emcli get_instance_status -guid=16B15CB29C3F9E6CE040578C96093F61

get_procedure_types

Description

Get the list of all Deployment Procedure types.

Usage

emcli get_procedure_types

Example

emcli delete_instance -instance=16B15CB29C3F9E6CE040578C96093F61

Output Column

Procedure Type

get_procedure_xml

Description

Get the Deployment Procedure XML file. XML will be printed on standard output.

Usage

emcli get_procedure_xml -procedure={procedure guid}

Option

-procedure

The procedure GUID.

Example

emcli get_procedure_xml -procedure=16B15CB29C3F9E6CE040578C96093F61 > proc.xml

Output

The Deployment Procedure XML

get_procedures

Description

Get a list of Deployment Procedures.

Usage

emcli get_procedures [-type={procedure type}]

Option

-type={procedure type}

display all the Deployment Procedure of type {procedure type}.

Output Columns

GUID, Procedure Type, Name, Version, Created By.

EMCLI Verbs for Deployment Instances

Following are the emcli verbs for deployment instances.

confirm_instance

Description

Confirm manual step.

Usage

emcli confirm_instance -instance={instance_guid} -stateguid={state_guids}

Option

-instance

The instance GUID.

-stateguid

The separated list of State GUIDs.

Example

emcli confirm_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=51F762417C4943DEE040578C4E087168
emcli confirm_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid='51F762417C4943DEE040578C4E087168,51F762417C4944DEE040578C4E087168'

delete_instance

Description

Delete a stopped or completed Deployment Instance.

Usage

emcli confirm_instance -instance={instance_guid} -stateguid={state_guids}

Option

-instance

The instance GUID.

Example

emcli delete_instance -instance=16B15CB29C3F9E6CE040578C96093F61

get_instance_data_xml

Description

Download Instance Data XML.

Usage

emcli get_instance_data_xml -instance={instance_guid}

Option

-instance

The instance GUID.

Example

emcli get_instance_data_xml -instance=16B15CB29C3F9E6CE040578C96093F61 > data.xml

Output

The Instance Data XML.

get_instances

Description

Display list of Procedure Instances.

Usage

emcli get_instances -type={procedure type}

Option

-type={procedure type}

display all the Procedure Instances of type {procedure type}.

Example

emcli delete_instance -instance=16B15CB29C3F9E6CE040578C96093F61

Output Columns

GUID, Procedure Type, Instance Name, Status

get_retry_arguments

Description

Get arguments of failed steps which can be retried.

Usage

emcli get_retry_arguments -instance={instance_guid} [-stateguid={state_guid}]

Option

-instance

The instance GUID.

-stateguid

The State GUID.

Example

emcli get_retry_arguments -instance=16B15CB29C3F9E6CE040578C96093F61
emcli get_retry_arguments -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=51F762417C4943DEE040578C4E087168

ignore_instance

Description

Ignore failed step.

Usage

emcli ignore_instance -instance={instance_guid} -stateguid={state_guid}

Option

-instance

The instance GUID.

-stateguid

The State GUID.

Example

emcli ignore_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=51F762417C4943DEE040578C4E087168
emcli ignore_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid='51F762417C4943DEE040578C4E087168,51F762417C4944DEE040578C4E087168'

reschedule_instance

Description

Reschedule a submitted Procedure Instance Note that only scheduled instances can be rescheduled

Usage

emcli reshedule_instance        -instance={instance guid}        -schedule=            start_time:yyyy/MM/dd HH:mm;            tz:{java timezone ID};            grace_period:xxx

Option

-instance

The GUID of the instance to execute.

-schedule

The schedule for the Procedure Instance. start_time - when the procedure should start tz - the timezone ID ( optional ) grace_period - grace period in minutes( optional )

Example

emcli reschedule_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -schedule="start_time:2006/6/21 21:23;tz:America/New_York;grace_period:60

resume_instance

Description

Resume a suspended Deployment Instance.

Usage

emcli resume_instance -instance={instance_guid}

Option

-instance

The instance GUID

Example

emcli resume_instance -instance=16B15CB29C3F9E6CE040578C96093F61

retry_instance

Description

Retry failed instance or failed step.

Usage

emcli retry_instance -instance={instance_guid} [-stateguid={state_guid}]

Option

-instance

The instance GUID

-stateguid

The State GUID.

Example

emcli retry_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=51F762417C4943DEE040578C4E087168
emcli retry_instance -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid='51F762417C4943DEE040578C4E087168,51F762417C4944DEE040578C4E087168'

set_instance_jobgrants

Description

Set the user access privilege for jobs of the Deployment Instance.

Usage

emcli set_instance_jobgrants -instance_guid={instance guid} -grants={user:privilege}

Option

-instance

The instance GUID

-grants

String of user:privilege pairs each separated by ; .

where user = em user name,

privilege = VIEW_JOB or FULL_JOB.

Example

emcli set_instance_jobgrants -instance_guid=16B15CB29C3F9E6CE040578C96093F61 -grants="user1:VIEW_JOB;user2:FULL_JOB"

start_paf_daemon

Description

Start Deployment Procedure Manager Daemon.

Usage

emcli start_paf_daemon -interval={number in minutes}

Option

-interval

Number in minutes that Deployment Procedure Manager Daemon should wait between each run.

status_paf_daemon

Description

Get Deployment Procedure Manager Daemon status.

Usage

emcli status_paf_daemon

stop_instance

Description

Stop a scheduled, failed, or running Deployment Instance.

Usage

emcli stop_instance -instance={instance_guid}

Option

-instance

The instance GUID

Example

emcli stop_instance -instance=16B15CB29C3F9E6CE040578C96093F61

stop_paf_daemon

Description

Stop Deployment Procedure Manager Daemon.

Usage

emcli stop_paf_daemon

submit_procedure

Description

Submit a Deployment Procedure.

Usage

emcli submit_procedure
-procedure="guid of the procedure"
-input_file="data:{file_path}"
[-instance_name="name for the procedure instance"]
[-grants="users and their correspoding access levels"]
[-schedule=
start_time:yyyy/MM/dd HH:mm;
tz:{java timezone ID};
grace_period:xxx];
]

Option

-procedure

The GUID of the procedure to execute.

-input_file=data:file_path

The input data for the Deployment Procedure.

The file_path should point to a file containing the data XML file.

-instance_name

The name of the procedure instance ( optional )

-grants

Users and their corresponding access levels ( optional )

String of user:privilege pairs each separated by ; .

where user = em user name,

privilege = VIEW_JOB or FULL_JOB.

-schedule

The schedule for the Deployment Procedure ( optional ).

If not specified, the procedure will be executed immediately.

start_time - when the procedure should start

tz - the timezone ID ( optional )

grace_period - grace period in minutes( optional )

Example

emcli submit_procedure -input_file=data:data.xml -procedure=16B15CB29C3F9E6CE040578C96093F61 -grants="user1:VIEW_JOB;user2:FULL_JOB" -schedule="start_time:2006/6/21 21:23;tz:America/New_York;grace_period:60" -instance_name="MyProcedureInstance_0001"

Output

Instance GUID

suspend_instance

Description

Suspend a running Deployment Instance.

Usage

emcli suspend_instance -instance={instance_guid}

Option

-instance

The instance GUID

Example

emcli suspend_instance -instance=16B15CB29C3F9E6CE040578C96093F61

update_and_retry_step

Description

Update arguments of the failed step and retry it.

Usage

emcli update_and_retry_step -instance={instance_guid} -stateguid={state_guid} [-args="command1:value1;command2:value2;..."]

Option

-instance

The instance GUID

-stateguid

The State GUID.

-args

Arguments, which will be updated.

Example

emcli update_and_retry_step -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=51F762417C4943DEE040578C4E087168 -args="command:ls"

Part IX

Additional Information

This part contains additional information related to provisioning and patching features offered by Enterprise Manager Grid Control.

This part contains the following chapters:

- Appendix A, "Troubleshooting Issues"

- Appendix B, "Using PARDeploy Utility"

- Appendix C, "Using Oracle Software Library"

- Appendix D, "Creating Templates for Oracle Database"

- Appendix E, "Out-Of-Box RuntimeData Templates"

- Appendix F, "Sample Property Files for the Out-of-Box RuntimeData Templates"

- Appendix G, "PXE Booting and Kickstart Technology"

A Troubleshooting Issues

This appendix provides solutions to common issues you might encounter when using provisioning and patching Deployment Procedures. In particular, this appendix covers the following:

- Filing Bugs with Relevant Information

- Troubleshooting Provisioning and Patching Issues

- Frequently Asked Questions

Filing Bugs with Relevant Information

While using the Deployment Procedures, if you encounter issues that are not documented in this chapter, then you can always file bugs to bring them to our notice. Oracle will try to resolve your issues as soon as possible.

However, while filing bugs, ensure that you provide all the necessary information that will be help us understand the issue you are facing and suggest a suitable workaround. To understand the information you need to supply while filing bugs, access the following URL:

http://stang12.us.oracle.com/twiki/bin/view/ProvisioningApplns/BugFilingTemplate

Troubleshooting Provisioning and Patching Issues

Ths section provides troubleshooting tips for some common provisioning and patching issues. In particular, this section covers the following:

- Troubleshooting Common Provisioning and Patching Issues

- Troubleshooting Virtualization Management Issues

- Troubleshooting Linux Provisioning Issues

- Troubleshooting Linux Patching Issues

Troubleshooting Common Provisioning and Patching Issues

To troubleshoot common provisioning and patching issues, see My Oracle Support note 816656.1. You can access My Oracle Support at:

https://metalink.oracle.com/

IMPORTANT:

Besides this My Oracle Support note, you can also find known issues described in Oracle Enterprise Manager Grid Control Release Notes for Linux and Microsoft Windows 10g Release 5 (10.2.0.5.0) available at:
http://www.oracle.com/technology/documentation/oem.html

Troubleshooting Virtualization Management Issues

How do I view Enterprise Management agent errors?

- Check the Alerts from the Virtual Server Home Page where the error occurs.

- Check the following EM Agent logs for errors. This will be the EM Agent monitoring the Virtual Server on which we have observed a collection error.

<AGENT_STATE>/sysman/log/sysman/log/emagent.log
<AGENT_STATE>/sysman/log/sysman/log/emagent.nohup
<AGENT_STATE>/sysman/log/sysman/log/emagent.trc
<AGENT_STATE>/sysman/log/sysman/log/emagentfetchlet.log
<AGENT_STATE>/sysman/log/sysman/log/emagentfetchlet.trc

- Enhance the logging level at the Agent to Debug, reproduce the issue, and take a look at the above-mentioned files for errors. Do remember to restore the logging level to what it was after getting the required data.
Update the following properties in <AGENT_STATE>/sysman/config/emagentlogging.properties file to the below-mentioned values:

log4j.rootCategory=DEBUG, emagentlogAppender, emagenttrcAppender

Also update the following properties in the <AGENT_STATE>/sysman/config/emd.properties file to the below-mentioned values:

tracelevel.command=DEBUG
tracelevel.Dispatcher=DEBUG

After making these changes, the EM Agent will need to be bounced as follows:

<AGENT_HOME>/bin/emctl reload agent

How do I view OMS errors?

To enable enhanced logging at the OMS update the following properties in OMS_ORACLE_HOME/sysman/config/emomslogging.properties on each OMS with the following and bounce each OMS after the update:

log4j.category.em.ovm=DEBUG, emovmlogAppender
log4j.appender.emovmlogAppender=org.apache.log4j.RollingFileAppender
log4j.appender.emovmlogAppender.File=/private/rahgupta/app/oracle/product/10.2.0/EMHomes/oms10g/sysman/log/emovm.log
log4j.appender.emovmlogAppender.Append=true
log4j.appender.emovmlogAppender.MaxFileSize =5000000
log4j.appender.emovmlogAppender.MaxBackupIndex=100
log4j.appender.emovmlogAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.emovmlogAppender.layout.ConversionPattern=%d [%t] %-5p %c{2} %M.%L - %m\n

From each OMS the following logs need to be looked into:

$ORACLE_HOME/sysman/log/emoms.log
$ORACLE_HOME/sysman/log/emoms.trc
$ORACLE_HOME/sysman/log/emovm.log*
$ORACLE_HOME/opmn/logs/OC4J~OC4J_EM~default_island~1

It is possible that the log files get rolled over, particularly if reproducing the issue takes a while. In that case increase the following parameter in the above-mentioned file to a larger number:

LogFileMaxRolls=50

How do I view Virtual Server errors?

View the following logs for virtual server errors:

/var/log/ovs-agent/ovs_operation.log
/var/log/ovs-agent/ovs_query.log
/var/log/ovs-agent/ovs_root.log

Troubleshooting Linux Provisioning Issues

I cannot see my stage, boot server in the UI to configure them with the provisioning application?

Either Management Agents have not been installed on the Stage/Boot Server machine or its not uploading data to the OMS. Refer to the Agent Deployment Best Practices document available at http://www.oracle.com/ocom/technology/products/oem/pdf/10gr2_agent_deploy_bp.pdf for troubleshooting information and known issues.

"Cannot create under the software library, please contact your administrator" error comes up while creating default image.

This may happen because the Software Library is not configured. Refer to Configuring Oracle Software Library. If it is configured and the error still occurs, then check if the library directory is accessible from the OMS server. The software library location should be accessible from the OMS and should have enough space.

Default Image or OS component creation fails with a '404' status while copying the header.info.

This may happen because of the RPM Repository URL being incorrect or because the RPM Repository has not been configured properly. Please refer to Setting Up RPM Repository and Configuring RPM Repository.

Default Image or OS component creation fails with an error message "Following RPMs are not found in Repository".

Reference machine has additional RPMs that are not available in the RPM repository. One of the following alternatives can be selected:

- Choose a different reference machine.

- Add extra RPMs in RPM repository (Make sure the RPMs are added in the repository as per Redhat specifications. Header files should be updated with the new RPM).

- If the RPMs are not required on the provisioned machine, add them to the Deny RPM list in the OS Component creation user interface.

Default Image or OS component creation job is suspended.

This may happen if the Preferred Credentials are not set for Reference machine. Please set the Preferred Credentials.

Default Image or OS component creation fails "Sudo error".

This may happen if:

- Sudo is not installed on the reference machine

- The user mentioned for the Reference Machine is not in the sudoers list. Edit /etc/sudoers file and add the user in the list.

Default Image staging fails with "Cannot stage default image".

This happens if there is already a default image staged for the same IP address range as the current one. Remove the staged image by clicking on the Remove button in the Default Image section on the Administration tab.

Default Image or OS component staging/provision fails with "Sudo error".

This may happen if:

- Sudo is not installed on the reference machine.

- The user mentioned for the Reference Machine is not in the sudoers list. Edit /etc/sudoers file and add the user in the list.

Default Image or OS component staging/provision job is suspended.

This may happen if Preferred Credentials are not set for Reference machine. Please set the Preferred Credentials.

Default Image or OS component staging/provision job fails "with directory permission error".

This error happens because of insufficient user privileges on the stage server machine. STAGE_TOP_LEVEL_DIRECTORY should have the write permission for the Stage user. In case of NAS, the NAS directory should be mounted on the staging server. If the error is while writing to the '/tftpboot directory then it has to have the write permission for the Stage user.

Bare metal machine is not coming up since it cannot locate the Boot file.

Verify the dhcp settings (/etc/dhcpd.conf) & tftp settings for the target machine. Check whether the services (dhcpd, xinted, portmap) are running. Make the necessary setting changes if required or start the required services if they are down.

Even though the environment is correctly setup, bare metal box is not getting booted over network

OR

DHCP server does not get a DHCPDISCOVER message for the MAC address of the bare metal machine.

Edit the DHCP configuration to include the IP address of the subnet where the bare metal machine is being booted up.

Provisioning Default image on the bare metal box fails with "reverse name lookup failed" error.

Verify that the DNS has the entry for the IP address and the host name.

Agent Installation fails after operating system has been provisioned on the bare metal box?

OR

No host name is assigned to the bare metal box after provisioning the OS?

This might happen if the "get-lease-hostnames" entry in the dhcpd.conf file is set to true. Edit the dhcpd.conf file to set get-lease-hostnames entry to false.

Also, ensure that length of the host name is compatible with length of the operating system host name.

Bare metal machine hangs after initial boot up (tftp error/kernel error).

This may happen if the tftp service is not running. Enable the tftp service. Go to the '/etc/xinetd.d/tftp' file and change the 'disable' flag to 'no' (disable=no). Also verify the dhcp settings.

Kernel panic occurs when the Bare Metal machine boots up.

Verify the dhcp settings and tftp settings for the target machine and make the necessary changes as required. In a rare case, the intird and vmlinuz copied may be corrupted. Copying them from RPM repository again would fix the problem.

Bare metal machine hangs after loading the initial kernel image.

This may happen if the network is half duplex. Half duplex network is not directly supported but following steps below would fix the problem:

- On the Reference Machine modify 'ethtool -s eth0 duplex half' entry to 'ethtool -s eth0 duplex full' in the kickstart file.

- Once done recreate the Default Image.

Bare metal machine cannot locate the kickstart file (Redhat screen appears for manually entering the values such as 'language', 'keyboard' etc).

This happens if STAGE_TOP_LEVEL_DIRECTORY is not mountable or not accessible. Make sure the stage top level is network accessible to the target machine. Though very rare but this might also happen because of any problem in resolving the stage server hostname. Enter the IP address of the stage/NAS server instead of hostname on which they are located and try the provisioning operation again.

Bare metal machine does not go ahead with the silent installation (Redhat screen appears for manually entering the network details).

Verify that DNS is configured for the stage server host name and DHCP is configured to deliver correct DNS information to the target machine. If the problem persists, specify the IP address of the stage/NAS server instead of hostname and try the provisioning operation again.

After provisioning, the machine is not registered in Enterprise Manager.

This happens if Enterprise Manager Agent is not placed in the STAGE_TOP_LEVEL_DIRECTORY before provisioning operation. Place the EM agent in this directory and try the operation again. It might also happen if the OMS registration password provided for securing the agents is incorrect. Go to the agent oracle home on the target machine and run the emctl secure agent command supplying the correct OMS registration password.

Check the time zone of the OMS and the provisioned operating system. Modify the time zone of the provisioned operating system to match with the OMS time zone.

Component creation fails with "Cannot create under the software library, please contact your administrator".

This may happen if the Software Library is not configured with the Enterprise Manager. Refer Configuring Oracle Software Library. Create the components once the software library is configured.

"Cannot create under the Software Library, please contact your administrator" error comes up while creating default image.

This may happen because the Software Library is not configured. Refer to Configuring Oracle Software Library. If it is configured and the error still occurs, then check if the library directory is accessible from the OMS server. The software library location should be accessible from the OMS and should have enough space.

Target does not appear under the hardware tab or while selecting hardware during assignment creation.

When you have multiple Oracle Management Services managed by a load balancer, you must configure a common directory that can be used by the Management Agents to upload data. To configure a common directory for this purpose, run the following command:

emctl config oms loader -shared yes -dir <directory>

With 64-bit OS provisioning, agent is not installed.

During OS provisioning, specify the full path of the agent RPM in the Advanced Properties page.

Troubleshooting Linux Patching Issues

My Staging Server Setup DP fails at "Channels Information Collection" step with the error message "Could not fetch the subscribed channels properly". How do I fix this?

This error is seen if there is any network communication error between up2date and ULN. Check if up2date is configured with correct proxy setting by following https://linux.oracle.com/uln_faq.html - 9. You can verify if the issue is resolved or not by using the command, "up2date –nox –show-channels". If the command lists all the subscribed channels, the issue is resolved.

My "up2date –nox –show-channels" command does not list the subscribed channels properly. How do I fix this?

Go to /etc/sysconfig/rhn/sources files, uncomment "up2date default" and comment out all the local RPM Repositories configured.

How can I register to channels of other architectures and releases?

Refer to https://linux.oracle.com/uln_faq.html for this and more such related FAQs.

After visiting some other page, I come back to "Setup Groups" page; I do not see the links to the jobs submitted. How can I get it back?

Click "Show" in the details column.

Package Information Job fails with "ERROR: No Package repository was found" or "Unknown Host" error. How do I fix it?

Package Repository you have selected is not good. Check if metadata files are created by running yum-arch and createrepo commands. The connectivity of the RPM Repository from OMS might be a cause as well.

Even after the deployment procedure finished its execution successfully, the Compliance report still shows my Group as non-compliant, why?

Compliance Collection is a job that runs once in every 24 hour. You should wait for the next cycle of the job for the Compliance report to update itself. Alternately, you can go to the Jobs tab and edit the job to change its schedule.

Package Information Job fails with "ERROR: No Package repository was found" or "Unknown Host" error. How do I fix it?

Package Repository you have selected is not good. Check if metadata files are created by running yum-arch and createrepo commands. The connectivity of the RPM Repository from OMS might be a cause as well.

I see a UI error message saying "Package list is too long". How do I fix it?

Unselect some of the selected packages. The UI error message tells you from which package to unselect.

Frequently Asked Questions

This section provides answers to some frequently asked questions. In particular, this section covers the following:

- Frequently Asked Questions on Setting Up the Provisioning Environment

- Frequently Asked Questions on Directives and Components

- Frequently Asked Questions on Network Profiles and Images

Frequently Asked Questions on Setting Up the Provisioning Environment

What is PXE (Pre-boot Execution Environment)?

The Pre-boot Execution Environment (PXE, aka Pre-Execution Environment) is an environment to bootstrap computers using a network interface card independently of available data storage devices (like hard disks) or installed operating systems. Refer to Appendix G, "PXE Booting and Kickstart Technology" for more information.

Can my Boot server and Stage server be located on different machine?

It is recommended that the Boot server and Stage server are co-located on the same physical machine. If this is not done, then one has to ensure that the network boot directory (say /tftpboot/pxelinux0.cfg) is exposed to Stage server via NFS and can be mounted by it.

Can my boot server reside on a subnet other than the one on which the bare metal boxes will be added?

Yes. But it is a recommended best practice to have boot server in the same subnet on which the bare metal boxes will be added. If the network is subdivided into multiple virtual networks, and there is a separate DHCP/PXE boot server in each network, the Assignment must specify the boot server on the same network as the designated hardware server.

If one wants to use a boot server in a remote subnet then one of the following should be done:

-- Router should be configured to forward DHCP traffic to a DHCP server on a remote subnet. This traffic is broadcast traffic and routers do not normally forward broadcast traffic unless configured to do so. A network router can be a hardware-based router, such as those manufactured by the Cisco Corporation or software-based such as Microsoft's Routing and Remote Access Services (RRAS). In either case, you need to configure the router to relay DHCP traffic to designated DHCP servers.

-- If routers cannot be used for DHCP/BOOTP relay, set up a DHCP/BOOTP relay agent on one machine in each subnet. The DHCP/BOOTP relay agent relays DHCP and BOOTP message traffic between the DHCP-enabled clients on the local network and a remote DHCP server located on another physical network by using the IP address of the remote DHCP server.

Why is Agent rpm staged on the Stage server?

Agent rpm is used for installing the agent on the target machine after booting over the network using PXE. With operating system provisioning, agent bits are also pushed on the machine from the staging location specified in the Advanced Properties.

Can I use the Agent rpm for installing Agent on Stage and Boot Server?

This is true only if the operating system of the Stage or Boot Server machine is RedHat Linux 4.0, 3.1 or 3.0. Refer to section Using agent rpm for Oracle Management Agent Installation on the following page for more information:

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

Can the yum repository be accessed by any protocol other than HTTP?

Though the rpm repository can be exposed via file:// or ftp:// as well, the recommended method is to expose it via http://. The latter is faster and more secure.

Frequently Asked Questions on Directives and Components

Are directives associated with Components or Images?

Directives can be associated with both components and images. As explained later during the creation of components and images, directives are actually associated with one of Staging, Pre-Install, Install or Post-Installation provisioning steps of a component. In case of an Image, directives can be associated with Stage, Cleanup, Post-Install, and Diagnostics provisioning steps of an Image.

What is the significance of the Status of a directive? How can one change it?

Look at the following table to know the possible Status values and what they signify.

Table A-1 Status Values

Status

Description

Incomplete

This Status signifies that some step was not completed during the directive creation, for example uploading the actual script for the directive, or a user saved the directive while creating it and still some steps need to be performed to make complete the directive creation.

Ready

his signifies that the directive creation was successful and the directive is now ready to be used along with any component/image.

Active

A user can manually change the status of a Ready directive to Active to signify that it is ready for provisioning. Clicking Activate changes the Status to Active.

What is a Maturity Level of a directive? How can one change it?

Look at the following table to know the possible Status values and what they signify:

Table A-2 Maturity Levels

Maturity Level

Maturity Level Description

Untested

This signifies that the directive has not been tested and is the default maturity level that is assigned to the directive when it is created.

Beta

A directive can be manually promoted to Beta using the Promote button after testing the directive.

Production

A directive can be manually promoted to Production using the Promote button after a user is satisfied that the directive can be used for actual provisioning on production systems.

Can a same component be used in multiple images?

Yes. Components are reusable and a given component can be a part of multiple images at the same time.

Do I need to modify the images associated with a component, if the component is edited?

No. If the component is changed for some reason then the change is propagated to all the images with contain that component.

For creating the Linux OS component does the Reference Machine need to have a management agent running on it?

Yes. Reference Machine has to be one of the managed targets of the Enterprise Manager.

What if the working directory does not have enough space while creating a clone component?

The component creation job that is kicked off in the end will indicate that the component creations failed because of insufficient space. Create the component again by specifying a temporary directory with sufficient space and the creation will succeed.

What is the significance of the Status of a component? How can one change it?

Status of a component is similar to that of a directive. Refer to What is the significance of the Status of a directive? How can one change it?.

What is a Maturity Level of a component? How can one change it?

Maturity Level of a component is similar to that of a directive. Refer to What is a Maturity Level of a component? How can one change it?.

What is the purpose of associating Properties with Generic Components?

Properties are used to provide flexibility for customizing the components depending on need. The property values are fed to the directives, which then customize the installation depending upon the values.

Frequently Asked Questions on Network Profiles and Images

Can I use 10.1.x IP addresses for Private Network Configuration?

No. Because of a known limitation, this type of addressing cannot be done for private IPs of the cluster nodes.

What is Reset Timeout?

After the OS installation on a target machine, management agent is installed on it, which reports to OMS and makes the machine a managed target of the Enterprise Manager. The time duration between the start of OS provisioning to agent reporting back to OMS server is known is the Reset Timeout. This is used by the provisioning application for deciding it provisioning process has timed out. If the machine or network is slow then it is advisable to set a high reset value.

B Using PARDeploy Utility

This appendix introduces you to the PARDeploy utility and explains how you can use it to perform critical tasks such as exporting Deployment Procedures, importing PAR files, and so on. In particular, this appendix covers the following:

- Overview of Provisioning Archive (PAR) Files

- Overview of PARDeploy Utility

- Checking Oracle Software Library

- Exporting Deployment Procedures

- Importing PAR Files

Overview of Provisioning Archive (PAR) Files

Provisioning Archive (PAR) files are archive files that contain one of the following:

- Deployment Procedures and the associated Oracle Software Library (Software Library) entities, such as components, directives, images, and so on.

- Only the Software Library entities, such as components, directives, images, and so on.

When you install Enterprise Manager Grid Control, by default, all Deployment Procedures are installed in the form of Provisioning Archive (PAR) files at the following location:

$ORACLE_HOME/sysman/prov/paf

For example, all application server-related Deployment Procedures are stored in asprov.par file.

To use the Deployment Procedures in Enterprise Manager Grid Control, you need not have to import or export these PAR files. The only prerequisite is to set up Oracle Software Library (Software Library). Once you set up the Software Library, Enterprise Manager Grid Control will automatically extract the contents of these default PAR files and configure them so that you can start using the Deployment Procedures from the Grid Control console.

Overview of PARDeploy Utility

Over a period of time, you might have customized some Deployment Procedures, and you might want to reuse them in another instance of Enterprise Manager Grid Control. Under such circumstances, you might want to export the customized Deployment Procedures from one instance of Enterprise Manager Grid Control, and deploy them to another instance of Enterprise Manager Grid Control.

PARDeploy utility is a tool offered by Enterprise Manager Grid Control that helps you perform these functions using the command line interface. Essentially, PARDeploy utility helps you:

- Export Deployment Procedures and its associated components and directives as PAR files

- Import PAR files to the same instance or any other instance of Enterprise Manager Grid Control

PARDeploy utility is located in the $ORACLE_HOME/bin directory, and the PAR files are located at $ORACLE_HOME/sysman/prov/paf.

The following is the usage information displayed when you run $ORACLE_HOME/bin/PARDeploy:

PARDeploy -action <deploy|view> -parFile <file> -force(optional)
PARDeploy -action <deploy|view> -parFile <file> -force(optional) -ssPasswd <password>
PARDeploy -action <deploy|view> -parDir <dir> -force(optional)
PARDeploy -action export -guid <procedure guid> -file <file>      -displayName <name> -description <desc> -metadataOnly(optional)
PARDeploy -check
PARDeploy -help

Additionally, the following options are provided:

Table B-1 PARDeploy Options

Option

Description

-force

Forces the Software Library entities to be created or uploaded again. If already present, it creates a new revision.

-check

Checks whether the Software Library is configured.

-file <file>

Represents the PAR file.

-action <deploy|view|export>

Deploys, views, or exports PAR files.

-verbose

Indicates verbose mode.

-help

Displays Help information.

-displayName <displayName>

Indicates PAR file name.

-parDir <dir>

Directory where the PAR files are located.

-metadataOnly

Flag for metadata-only exports.

-guid <guid>

Procedure GUID to export.

To export multiple procedures, provide the GUIDs separated by ","

-parFile <file>

Path to the PAR file.

-description <description>

PAR file description.

-ssPasswd <secretStorePassword>

This is optional.

If used with -action export; if any of the exported Software Library entity contains a secret property, an Oracle Wallet is created to store the value of the secret property. Oracle Wallet is created using the specified password. You are prompted to enter a password if -ssPasswd switch is used and if password is not supplied as a command line argument. You must use the same password while importing the PAR file in a new repository.

If used with -action <deploy|view>; if the PAR file contains any password protected Oracle Wallet (that stores an entity's secret property values), then this parameter is required to open the store. You are prompted to enter a password if -ssPasswd switch is used and password is not specified as a command line argument.

Checking Oracle Software Library

Before running the PARDeploy utility to export or import PAR files, ensure that the $ORACLE_HOME environment variable is set to the Oracle home directory of Oracle Management Service (OMS) and a Software Library path is configured.

To check the Software Library, run the following command:

$ORACLE_HOME/bin/PARDeploy -check

Exporting Deployment Procedures

To export Deployment Procedures, you must first obtain the GUID of those Deployment Procedures, and then run the PARDeploy utility to create a PAR file. This section explains the following:

- Obtaining Deployment Procedure's GUID

- Creating PAR File

Obtaining Deployment Procedure's GUID

To obtain the GUID of a Deployment Procedure using Enterprise Manager Grid Control, follow these steps:

1. In Grid Control, click the Deployments tab.

2. On the Deployments page, from the Deployment Procedure Manager section, click Deployment Procedures.

3. Deployment Procedure Manager page, in the Procedures table, click the deployment procedure you want to export.

4. On the View Procedure page, note the URL of the page from the address bar of the browser.
The format of the URL should be similar to this:

http://<OMS host>:<port>/em/console/paf/procedureView?guid=<value of GUID>

To obtain the GUID of a Deployment Procedure using Enterprise Manager Command Line Interface (EM CLI), run the get_procedures verb. This command displays information such as GUID, Procedure Type, Name, Version, and Created By.

emcli get_procedures [-type={procedure type}]

[ ] denotes that the parameter is optional. If you do not provide this paramaeter, then the verb displays information about all the Deployment Procedures. If you provide this parameter, then the verb displays information only about the procedure type you have specified.

Creating PAR File

To create a PAR file that contains one or more Deployment Procedures, run the PARDeploy utility with the export option as the action, and quote the GUIDs of the Deployment Procedures you want to export. Ensure that you separate the GUIDs by a comma.

$ORACLE_HOME/bin/PARDeploy -action export -guid <GUID> -file exportedDP.par -displayName "User exported DP" -description "<description>"

For example, if the GUID of the Deployment Procedure that you want to export is FAC05DD31E3791C3E030579D23106C67, then run the following command:

$ORACLE_HOME/bin/PARDeploy -action export -guid FAC05DD31E3791C3E030579D23106C67 -file exportedDP.par -displayName "User exported DP" -description "Deployment Procedure to be copied to other OMS"

After you run this command, a new PAR file named exportedDP.par is created in the directory where you ran the command. You can then import this PAR file to the same instance of Enterprise Manager Grid Control or another instance, multiple times.

Note:

When a procedure is exported using PARDeploy, any directives or components referred by the procedure are also exported. However, only the latest revision of these directives or components will be exported. If you do not want to export components or directives, you can specify the -metadataOnly flag when running PARDeploy.

Importing PAR Files

You can import PAR files using the command line interface or the graphical user interface offered by Enterprise Manager Grid Control, that is, the console. This section explains the following:

- Importing Using Command Line Interface

- Importing Using Grid Control Console

Importing Using Command Line Interface

This section covers the following:

- Importing Specific PAR File

- Importing All PAR Files

Importing Specific PAR File

To import or deploy a specific PAR file, run the following command:

$ORACLE_HOME/bin/PARDeploy -action deploy -parFile $ORACLE_HOME/sysman/prov/paf/<par_file_name> -force

For example:

$ORACLE_HOME/bin/PARDeploy -action deploy -parFile $ORACLE_HOME/sysman/prov/paf/asprov.par -force

Note:

If you have multiple OMSes in your environment, then you need run the PARdeploy utility only once to deploy any PAR files or to perform other related operations.

Importing All PAR Files

To import or deploy all the PAR files in a directory, run the following command:

$ORACLE_HOME/bin/PARDeploy -action deploy -parDir $ORACLE_HOME/sysman/prov/paf/ -force

Importing Using Grid Control Console

To import PAR files or deploy them to an OMS, you can use the PARDeploy utility. Alternatively, you can also log in to Enterprise Manager Grid Control, navigate to the Deployment Procedure Manager page, and click Upload to upload a PAR file.

Note:

When importing or exporting components and/or directives that contain properties with secret values, you must use the -ssPasswd command and provide the secret store password to create Oracle Wallet. This ensures that the properties with secret values are securely stored using an Oracle Wallet, and can be accessed while importing with only the Oracle Wallet password.
For more information about the -ssPasswd command, see Table B-1, "PARDeploy Options". For more information about importing and exporting Software Library entities, see Exporting and Importing Entities Across Oracle Enterprise Manager Deployments.

C Using Oracle Software Library

This appendix provides an overview of Oracle Software Library (Software Library) and explains how you can use it to export and import entities, delete and purge entities, and so on. In particular, this appendix covers the following:

- Using the Software Library

- De-Configuring a Software Library Location

- Software Library Maintenance Tasks

- Software Library Issues

Using the Software Library

There exists only one Software Library in Enterprise Manager. But, you can configure multiple filesystem locations for the Software Library for storing files associated with its entities. The graphical user interface of the Provisioning application has various tabs for creating Components, Directives, Images, Network and Hardware Templates, which are created and stored in the Software Library. Various subdirectories for storing the entities can be created in the Software Library. These tabs also allow a user to delete and edit an entity stored in the Software Library. They also allow a user to view metadata information for an entity. Multiple Software Library locations can be configured and when a file/binary is being associated with an entity, the location with the most space is picked.

The following figure shows the Software Library section on the Administration page.

The Software Library section lists the directory location, free space, used space, and space used by deleted entities. In addition, the following functionalities are also available in the Software Library Configuration section:

Purge

When an entity is deleted, the binary file associated with the entity continues to exists on the disk till it is completely removed. The space usage by such binary files can be monitored using "Used Space By Deleted Entities" column against every location. Use the Purge functionality in the Software Library section to permanently remove deleted entities and their respective binary files from the Software Library.

Refresh

The space usage for all Software Library locations can be computed using the Refresh functionality. On clicking Refresh, the Free Space, Used Space, and Used Space by Deleted Entities display the latest space usage details for each location. The Last Computed column gives the date when free space was computed last.

Check Accessibility

Use Check Accessibility to verify that the Software Library location is accessible from all Oracle Management Services (OMS), in case of multiple OMS in your Enterprise Manager deployment. Ensure that normal preferred credentials are set for all hosts running Oracle Management Service to use the Check Accessibility functionality. You can also use the out-of-box Enterprise Manager policy "Non-Shared Software Library Existence" to check if any non-shared Software Library location exists among all OMS.

Export and Import

You can export Software Library entities and import Provisioning Archive (PAR) files in the Software Library. For more details, see Exporting and Importing Entities Across Oracle Enterprise Manager Deployments.

Caution:

Do not attempt to export Software Library entities from a higher version of Enterprise Manager Grid Control and import them to a lower version of Enterprise Manager Grid Control. Attempting such an unsupported operation will produce undesired results. However, you can always export the entities from a lower version to a higher version of Enterprise Manager Grid Control.

Add, Remove, and Edit

You can add a new Software Library directory location and edit or remove an existing Software Library directory location.

Exporting and Importing Entities Across Oracle Enterprise Manager Deployments

Software Library entities can be exported and imported across different Software Libraries used by different Enterprise Manager deployments.

Caution:

Do not attempt to export Software Library entities from a higher version of Enterprise Manager Grid Control and import them to a lower version of Enterprise Manager Grid Control. Attempting such an unsupported operation will produce undesired results. However, you can always export the entities from a lower version to a higher version of Enterprise Manager Grid Control.

Provisioning Archive (PAR) files contain deployment procedures and/or Software Library entities such as components and directives from Software Library. Oracle provides PAR files that contain Oracle best-practices deployment procedures and the Software Library entities required to run them for Provisioning and Patching applications.

Click Export in the Software Library section to select Components/Images/Directives/Suites/Networks to be exported as a PAR (Provisioning Archive) file. This PAR file can then be imported back in a new repository. The following shows the Export Software Library Entities Page.

To export the Software Library entities, you will need to specify the following values:

Element

Description

Directory Location

Location where the PAR file will be created. This is a required parameter.

PAR Filename

The file name must end with a .par extension. If the given filename already exists in the specified location, then filename_1.par is created. If that also exists, then filename_2.par is created and so on. The name of file can be viewed in the Job output page. This is a required parameter.

Oracle Wallet Password

This is used to securely store all secret property values in an encrypted Oracle Wallet. This is a required parameter. However, the password is used only if any exported entity has a secret property.

Exclude File

Select this option to exclude file, binary, or script associated with an entity to be exported.

Export

You can choose to either export all entities or export a selected entity.
If you choose to export a selected entity, click Add to select entity. In popup to select the entity, search for the entities you want to export, select and add them. You need not select all referenced entities. For example, if an image is referring to a component and a directive, you can select only the image. During the export process, the component and the directive are also exported.

Click Import to import a PAR (Provisioning Archive) file in the Software Library. The following shows the Import Software Library Entities Page.

To import the Software Library entities, you will need to specify the following values:

Element

Description

PAR File Location

Location of the PAR file. This location must be accessible by the Oracle Management Server.

Oracle Wallet Password

This is an optional field. The password is required if the PAR file contains an Oracle Wallet that stores secret property values. PAR files provided by Oracle will not have any associated Oracle Wallet. Hence, if you are importing an Oracle provided PAR file, then password need not be provided. However, if you are importing a PAR file that was created by the Export process (using Enterprise Manager Console or PARDeploy script) then you will need to provide this password.
The same password that was used during export should be used during import. You can ignore this password if there is no Oracle Wallet contained in the PAR file. If the PAR file has an associated Oracle Wallet, the import process will fail if no password is provided.

Force New Revision

If an entity being imported is already present in the Software Library, then this option allows the user to force a newer revision of the entity to be created during import. If the option is not selected and the PAR file contains an entity in a directory that already exists in the repository, then the import process will fail.

You can also use the deploymentLibrabryExport and deploymentLibrabryImport scripts for importing and exporting the Software Library entities respectively. These scripts are present in /bin directory of the OMS Oracle Home and provide the flexibility to transfer entities from a test to production or between different production environments.

The scripts support the following import/export use cases:

- Exporting all directives and importing the same.

- Exporting all components and importing the same.

- Exporting all entities in the Software Library (including Network profiles, Images etc.) and importing the same.

The export script is available at the <OMS HOME>/bin/deploymentLibraryExport.pl location on Linux and Windows.

The import script is available at the <OMS HOME>/bin/deploymentLibraryImport.pl location on Linux and Windows.

For information on using the import and export scripts, type --help in the command line.

Deleting and Purging Software Library Entities

Software Library entities can be deleted from the relevant tabs provided by the provisioning application. By deleting an entity, the entity is no longer available for selection, view, or edit, and will not show up in the user interface. But it is to be noted that deleting the entity does not purge the file associated with it from the Software Library file system. If you delete an entity, it will not appear in the user interface, but will continue to exist on disk and take up disk space. To clean up and delete entities completely from the file system of the Software Library, you will need to purge the deleted entities.

To purge deleted entities, click Purge in the Software Library section.

You can also purge deleted entities by running the purgeDeploymentLibrary script. The script is located at the following location:

For OMS on Linux: <OMS HOME>/bin/purgeDeploymentLibrary

De-Configuring a Software Library Location

Go to the Administration tab, Software Library section, choose the Software Library entry and then click Remove to de-configure a Software Library location. Once a Software Library entry is deleted, it becomes inaccessible.

Even though the deleted location is not used further for storing binaries/files/scripts of newly-created Software Library entities, it may still store files of already created entities. If the location is not accessible from all Oracle Management Servers, user can experience problems during deployment of such entities later.

If multiple locations for the Software Library are configured, when you deconfigure the Software Library locations, you can remove all except one Software Library location.

Software Library Maintenance Tasks

It is recommended that the system administrator periodically performs the following administrative tasks to ensure that the Software Library is functioning properly:

- Refresh the Software Library regularly to compute the free and used disk space.

- Purge deleted entities to conserve disk space.

- Check accessibility of the configured Software Library locations to ensure that they are accessible to all Oracle Management Servers. If you add another Oracle Management Server, use the Check Accessibility feature to ensure that the Software Library location is accessible to the new Oracle Management Server.

For information about these features, see Using the Software Library.

Software Library Issues

Component/Directive/Image creation sometimes fail with "There was an error saving '<Component Name>' below '<Folder Name>' in the Software Library. Contact your administrator. You can find a detailed report in the log file at ORACLE_HOME/sysman/log/emoms.log."

This may happen if the Software Library is not configured with Enterprise Manager. Configure the Software Library as explained in Setting Up Oracle Software Library. Create the components once the Software Library is configured.

"Unable to access binary of a Software Library Entity (Components/Directives) during deployment time even though all Software Library locations are accessible"

If the contents of Software Library location (that stores binaries of Software Library entities such as components or directives) are deleted, then the user will encounter problems during the deployment of such entities. Since the metadata of the entities is not removed from the Management Repository, the entities will continue to show up on the Console. Upload the binary of all such entities again.

D Creating Templates for Oracle Database

This appendix explains how you can use Database Configuration Assistant (DBCA) to create templates for structuring newly created databases.

Note that DBCA can also be used to create scripts for creating databases using the templates. The necessary options for creating templates and scripts in the DBCA help have been highlighted in this appendix.

This appendix covers the following:

- Overview

- Creating Database and Templates Using DBCA

- Creating Database and Templates Without Using DBCA

Overview

DBCA uses patterns, or otherwise called Templates, which create either a new database with existing patterns or a pattern itself based on an existing base. The following are the template files that DBCA can create:

- .dbc - Database Clone (for a new database)

- .dbt - Template Database (for an existing database)

These templates, which are in the form of XML files, contain information about the database including database options, init.ora parameters, and storage attributes (datafiles, tablespaces, controlfiles and redologs).

The demo templates such as Data_Warehouse.dbc, General_Purpose.dbc, Transaction_Processing.dbc, and New_Database.dbt are available at the following location:

% ORACLE_HOME% /assistants/dbca/templates

Creating Database and Templates Using DBCA

You can launch DBCA in interactive mode, provide details for creating a database, and in the end, instead of creating a database, you can save the specified information as a template. You can then use this template to create databases.

This section explains how you can create a database and other templates using DBCA.

Creating a Database using DBCA

Example: Create db glob - use template glob1.dbc

dbca-silent-createDatabase-templateName glob1.dbc-gdbname glob glob-sid-characterset AL32UTF8

Example: Create db glob with the location of datafiles - creating a database with the location where datafiles have to be placed in a given location

dbca-silent-createDatabase-templateName glob1.dbc-gdbname glob glob-sid-characterset AL32UTF8-datafiledestination D: \ oracle \ product \ 10.2.0 \ oradata \ glob

Note:

If you want these databases to be monitored by Enterprise Manager Grid Control, then unlock the DBSNMP password of the databases.

Creating .dbt Template File from Existing Bases

template dbt dbca-silent-createTemplateFromDB-sourceDB GLOB-sysDBAUserName sys-sysDBAPassword change_on_install-templateName glob_template

Creating .dbc Template File from Existing Bases

template dbc dbca-silent-createCloneTemplate-sourceDB GLOB-sysDBAUserName sys-sysDBAPassword change_on_install-templateName glob_clone

Creating a Template File, Deleting Bases, Using a Template

- Create a clone template glob_clone from an existing database by specifying the following parameters:
dbca-silent-createCloneTemplate-sourceDB GLOB-sysDBAUserName sys-sysDBAPassword change_on_install-templateName glob_clone

- Delete database glob silently or copy glob_clone.dbc and GLOB_CLONE.DFB to other host:
dbca-silent-deleteDatabase-sourceDB GLOB-sysDBAUserName sys-sysDBAPassword change_on_install

- Create database using database template clone:
dbca-silent-createDatabase-templateName glob_clone.dbc-gdbname glob glob-sid-characterset AL32UTF8

Creating Sample Script (template) and Bases

- Create db scripts in the directory D: \ oracle \ product \ 10.2.0 \ db_1 \ assistants \ dbca \ templates \ scr
dbca-silent-generateScripts-templateName glob_clone.dbc-gdbName glob-scriptDest D: \ oracle \ product \ 10.2.0 \ db_1 \ assistants \ dbca \ templates \ scr

- Create database using scripts
set ORACLE_SID = GLOB

glob.bat

Creating Database and Templates Without Using DBCA

dbca [-silet |-progressOnly |-customCreate] (<command> <options>) | ([<command> [options]]-responseFile <response file>) [-continueOnNonFatalErrors <true | false>]

Creating a Database

- - createDatabase

- - templateName <name of an existing template>

- [-cloneTemplate]

- - gdbName <global database name>

- [- Sid <database system identifier>]

- [-sysPassword <SYS user password>]

- [-systemPassword <SYSTEM user password>]

- [-emConfiguration <CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE>
[-emConfiguration <CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE>

- -dbsnmpPassword <DBSNMP user password> - dbsnmpPassword <DBSNMP user password>

- -sysmanPassword <SYSMAN user password> - sysmanPassword <SYSMAN user password>

- [-hostUserName <Host user name for EM backup job> [-hostUserName <Host user name for EM backup job>

- -hostUserPassword <Host user password for EM backup job> - hostUserPassword <Host user password for backup EM job>

- -backupSchedule <Daily backup schedule in the form of hh:mm>] - backupSchedule <Daily backup schedule in the form of hh:mm>]

- [-smtpServer <Outgoing mail (SMTP) server for email notifications> [smtpServer <Outgoing-mail server for (SMTP) email notifications>

- -emailAddress <Email address for email notifications>] - emailAddress <Email email address for notifications>]

- [-centralAgent <Enterprise Manager central agent home>]] [-centralAgent <Enterprise Manager central agent home>]]

- [-datafileDestination <destination directory for all database files> | -datafileNames <a text file containing database objects such as controlfiles, tablespaces, redo log files and spfile to their corresponding raw device file names mappings in name=value format.>] [-datafileDestination <destination directory database for all files> |-datafileNames <a text file containing database objects such as controlfiles, tablespaces, redo log files and spfile to their corresponding raw device file names mappings in name=value format.>]

- [-recoveryAreaDestination <destination directory for all recovery files>] [-recoveryAreaDestination <destination directory for all recovery files>]

- [- datafileJarLocation < location of the data file jar, used only for clone database creation>] [- DatafileJarLocation <location of the data file jar, used only for clone database creation>]

- [-storageType < FS | ASM | RAW> [-storageType <FS | ASM | RAW>

- [-asmSysPassword <SYS password for ASM instance>] [-asmSysPassword <SYS password for ASM instance>]

- [-diskString <disk discovery path to be used by ASM>] [-diskString <disk discovery path to be used by ASM>]

- [-diskList <comma seperated list of disks for the database area disk group> [diskList <comma-seperated list of disks for the database area disc group>

- -diskGroupName <database area disk group name> diskGroupName <database-area disk group name>

- -redundancy <HIGH|NORMAL|EXTERNAL>] - redundancy <HIGH|NORMAL|EXTERNAL>]

- [-recoveryDiskList <comma seperated list of disks for the recovery area disk group> [recoveryDiskList <comma-seperated list of disks for the recovery area disc group>

- -recoveryGroupName <recovery area disk group name> recoveryGroupName <recovery-area disk group name>

- -recoveryGroupRedundancy <HIGH|NORMAL|EXTERNAL>]] - recoveryGroupRedundancy <HIGH|NORMAL|EXTERNAL>]]

- [-characterSet <character set for the database>] [-characterSet <character set for the database>]

- [- nationalCharacterSet < national character set for the database>] [- NationalCharacterSet <national character set for the database more]

- [-registerWithDirService <true | false> [-registerWithDirService <true | false>

- -dirServiceUserName <user name for directory service> - dirServiceUserName <user name for directory service>

- -dirServicePassword <password for directory service > - dirServicePassword <password for directory service>

- -walletPassword <password for database wallet >] - walletPassword <password wallet database for more]

- [- listeners < list of listeners to configure the database with>] [- Listeners <list of listeners to configure the database with more]

- [-variablesFile <file name for the variable-value pair for variables in the template>]] [-variablesFile <file name for the pair variable-value for variables in the template>]]

- [- variables < comma seperated list of name=value pairs>] [- Variables <comma seperated list of name = value pairs>]

- [-initParams <comma seperated list of name=value pairs>] [initParams <comma-seperated list of name=value pairs>]

- [-memoryPercentage <percentage of physical memory for Oracle>] [-memoryPercentage <percentage of physical memory for Oracle>]

- [-databaseType <MULTIPURPOSE|DATA_WAREHOUSING|OLTP>]] [-databaseType <MULTIPURPOSE|DATA_WAREHOUSING|OLTP>]]

Configuring a Database

- - configureDatabase

- -sourceDB <source database sid > - sourceDB <source database sid>

- [-sysDBAUserName <user name with SYSDBA privileges> [-sysDBAUserName <user name with SYSDBA privileges>

- -sysDBAPassword <password for sysDBAUserName user name>] - sysDBAPassword <password for sysDBAUserName user name>]

- [-registerWithDirService|-unregisterWithDirService|-regenerateDBPassword <true | false> [registerWithDirService-|-unregisterWithDirService |-regenerateDBPassword <true | false>

- -dirServiceUserName <user name for directory service> - dirServiceUserName <user name for directory service>

- -dirServicePassword <password for directory service > - dirServicePassword <password for directory service>

- -walletPassword <password for database wallet >] - walletPassword <password wallet database for more]

- [-emConfiguration <CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE> [-emConfiguration <CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE>

- -dbsnmpPassword <DBSNMP user password> - dbsnmpPassword <DBSNMP user password>

- -symanPassword <SYSMAN user password> - symanPassword <SYSMAN user password>

- [-hostUserName <Host user name for EM backup job> [-hostUserName <Host user name for EM backup job>

- -hostUserPassword <Host user password for EM backup job> - hostUserPassword <Host user password for backup EM job>

- -backupSchedule <Daily backup schedule in the form of hh:mm>] - backupSchedule <Daily backup schedule in the form of hh:mm>]

- [-smtpServer <Outgoing mail (SMTP) server for email notifications> [smtpServer <Outgoing-mail server for (SMTP) email notifications>

- -emailAddress <Email address for email notifications>] - emailAddress <Email email address for notifications>]

- [-centralAgent <Enterprise Manager central agent home>]] [-centralAgent <Enterprise Manager central agent home>]]

Creating a Template from an Existing Database

- - createTemplateFromDB

- -sourceDB <service in the form of <host >: <port>:<sid>> - sourceDB <service in the form of <host>: <port>: <sid>>

- -templateName <new template name> - templateName <new template name>

- -sysDBAUserName <user name with SYSDBA privileges> - sysDBAUserName <user name with SYSDBA privileges>

- -sysDBAPassword <password for sysDBAUserName user name> - sysDBAPassword <password for sysDBAUserName user name>

- [-maintainFileLocations <true | false>] [-maintainFileLocations <true | false>]

Creating a Clone Template from an Existing Database

- - createCloneTemplate

- -sourceSID <source database sid > - sourceSID <source database sid>

- -templateName <new template name> - templateName <new template name>

- [-sysDBAUserName <user name with SYSDBA privileges> [-sysDBAUserName <user name with SYSDBA privileges>

- -sysDBAPassword <password for sysDBAUserName user name>] - sysDBAPassword <password for sysDBAUserName user name>]

- [-maintainFileLocations <true | false>] [-maintainFileLocations <true | false>]

- [-datafileJarLocation <directory to place the datafiles in a compressed format>] [-datafileJarLocation <directory to place the datafiles in a compressed format>]

Generate Scripts to Create Database

- - generateScripts

- -templateName <name of an existing template > - templateName <name of an existing template>

- -gdbName <global database name> - gdbName <global database name>

- [-scriptDest <destination for all the scriptfiles>] [-scriptDest <destination for all the scriptfiles>]

Deleting a Database

- - deleteDatabase

- -sourceDB <source database sid > - sourceDB <source database sid>

- [-sysDBAUserName <user name with SYSDBA privileges> [-sysDBAUserName <user name with SYSDBA privileges>

- -sysDBAPassword <password for sysDBAUserName user name>] - sysDBAPassword <password for sysDBAUserName user name>]

Configure ASM Disk Groups

- - configureASM

- [-asmSysPassword <SYS password for ASM instance>] [-asmSysPassword <SYS password for ASM instance>]

- [-diskString <disk discovery path to be used by ASM>] [-diskString <disk discovery path to be used by ASM>]

- [-diskList <comma seperated list of disks for the database area disk group> [diskList <comma-seperated list of disks for the database area disc group>

- -diskGroupName <database area disk group name> diskGroupName <database-area disk group name>

- -redundancy <HIGH|NORMAL|EXTERNAL>]] - redundancy <HIGH|NORMAL|EXTERNAL>]]

- [-recoveryDiskList <comma seperated list of disks for the database area disk group> [recoveryDiskList <comma-seperated list of disks for the database area disc group>

- -recoveryGroupName <database area disk group name> recoveryGroupName <database-area disk group name>

- -recoveryGroupRedundancy <HIGH|NORMAL|EXTERNAL>] - recoveryGroupRedundancy <HIGH|NORMAL|EXTERNAL>]

- [-emConfiguration <CENTRAL|NONE> [-emConfiguration <CENTRAL|NONE>

- -centralAgent <Enterprise Manager central agent home>]] - centralAgent <Enterprise Manager central agent home>]]

- Query for help by specifying the following options: -h | -help Query for help by specifying the following options:-h |-help

E Out-Of-Box RuntimeData Templates

This apendix lists the out-of-box runtime data templates for different Deployment Procedures. In particular, this appendix covers the following:

- Out-Of-Box RuntimeData Templates for Oracle RAC Deployment Procedures

- Out-Of-Box RuntimeData Templates for Oracle Application Server Deployment Procedures

- Out-Of-Box RuntimeData Templates for Patching Procedures

Note:

For Enterprise Manager 10g Grid Control Release 3 (10.2.0.3), the latest templates are available in patch 5890474 that can be downloaded from My Oracle Support.

For Enterprise Manager 10g Grid Control Release 4 (10.2.0.4) and higher, these templates are present in the following directory of the Oracle Management Service (OMS):

%ORACLE_HOME%/emcli/samples

Out-Of-Box RuntimeData Templates for Oracle RAC Deployment Procedures

The following tables lists the out-of-box runtimedata templates for Oracle RAC deployment procedures.

Table E-1 Out-of-Box RuntimeData Templates for Oracle RAC Deployment Procedures

Procedure Name

Provisioning Mode

Procedure Type

Template Name

Oracle Clusterware/Oracle Real Applications Clusters (RAC) Provisioning for UNIX

Using a Gold Image from the Software Library

RACPROV

crsasmrac_gold_prov_template.xml

Oracle Clusterware/Oracle Real Applications Clusters (RAC) Provisioning for UNIX

Using an existing installation, that is, a reference host

RACPROV

crsasmrac_inshome_prov_template.xml

Extend Cluster Database

NA

RACPROV

crsasmrac_extend_cluster_template.xml

Scale Down/Delete Oracle Real Applications Clusters (RAC)

Scale down

RACPROV

rac_partial_delete_node_template.xml

Scale Down/Delete Oracle Real Applications Clusters (RAC)

Complete deletion

RACPROV

rac_complete_delete_node_template.xml

Oracle Database Provisioning

Database provisioning

SIDB

single_instance_database_template.xml

Out-Of-Box RuntimeData Templates for Oracle Application Server Deployment Procedures

The following tables lists the out-of-box runtimedata templates for Oracle RAC deployment procedures.

Table E-2 Out-of-Box RuntimeData Templates for Oracle Application Server Deployment Procedures

Procedure Name

Provisioning Mode

Procedure Type

Template Name

10.1.3 AS Provisioning

Using a gold image from the Software Library

ASPROV

as_gold_imgage_cloning_template.xml

Out-Of-Box RuntimeData Templates for Patching Procedures

The following tables lists the out-of-box runtimedata templates for patching procedures.

Table E-3 Out-of-Box RuntimeData Templates for Patching Procedures

Procedure Name

Template Name

Patch Oracle Database

StandAlone_template.xml

Patch Oracle Clusterware (Rolling Upgrade)

CRS_Rolling_template.xml

Patch Oracle RAC Database (Rolling)

RAC_Rolling_template.xml

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

This appendix lists the sample property files for out-of-box RuntimeData templates. These property files are packaged with the product. To see the contents of a file, access the file location that is mentioned against the property file.

Table F-1 Sample Property Files for the Out-of-Box RuntimeData Templates

Procedure Name

Property File Name

File Location

RAC Provisioning using gold image

CRS-ASM-RAC_provisioning_using_GOLD-Image.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/crsasmracgoldprov

RAC Provisioning using an existing, running, reference node

CRS-ASM-RAC_provisioning_using_Reference-Installation.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/crsasmracinshomeprov

RAC Provisioning using software binaries archived from the installation medium

CRS-ASM-RAC_provisioning_using_SHIPHOME-Image.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/crsasmracshiphomeprov

Extend cluster

Cluster_Extend.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/crsasmracextendcluster

Delete cluster

Cluster_Complete_Delete.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/raccompletedeletenode

Delete node

Cluster_Partial_Delete.properties

%ORACLE_HOME%/emcli/samples/provisioning/racprovisioning/10.2.0.1.0/racpartialdeletenode

Database provisioning by cloning on Linux

SidbCloneLinux.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning by cloninng on Linux (software only)

SidbCloneLinuxSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning by cloning on Microsoft Windows

SidbCloneWin.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning by cloning on Microsoft Windows (software only)

SidbCloneWinSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning using gold image on Linux

SidbGoldImgLinux.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning using gold image on Linux (software only)

SidbGoldImgLinuxSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning using gold image on Microsoft Windows

SidbGoldImgWin.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning using gold image on Microsoft Windows (software only)

SidbGoldImgWinSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning on Linux using software binaries archived from the installation medium

SidbInstallLinux.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning on Linux using software binaries archived from the installation medium (software only)

SidbInstallLinuxSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning on Microsoft Windows using software binaries archived from the installation medium

SidbInstallWin.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

Database provisioning on Microsoft Windows using software binaries archived from the installation medium (software only)

SidbInstallWinSwOnly.txt

%ORACLE_HOME%/emcli/samples/provisioning/dbprovisioning/10.2

G PXE Booting and Kickstart Technology

This appendix explains the PXE booting and kickstart technology.

About PXE Booting and Kickstart Technology

One of the key requirements of provisioning is the hardware server's ability to boot over the network instead of a diskette or CD-ROM. There are several ways computers can boot over a network, and Preboot Execution Environment (PXE) is one of them. PXE is an open industry standard supported by a number of hardware and software vendors. PXE is part of the "Wired for Management" (WfM) specification, which is part of a bigger PC98 specification defined by Intel and Microsoft in 1998. A detailed document on PXE specification can be found at http://www.pix.net/software/pxeboot/archive/pxespec.pdf.

PXE works with Network Interface Card (NIC) of the system by making it function like a boot device. The PXE-enabled NIC of the client sends out a broadcast request to DHCP server, which returns with the IP address of the client along with the address of the TFTP server, and the location of boot files on the TFTP server. The following steps describe how it works:

1. Target Machine (either bare metal or with boot sector removed) is booted.

2. The Network Interface Card (NIC) of the machine triggers a DHCP request.

3. DHCP server intercepts the request and responds with standard information (IP, subnet mask, gateway, DNS etc.). In addition, it provides information about the location of a TFTP server and boot image (pxelinux.0).

4. When the client receives this information, it contacts the TFTP server for obtaining the boot image.

5. TFTP server sends the boot image (pxelinux.0), and the client executes it.

6. By default, the boot image searches the pxelinux.cfg directory on TFTP server for boot configuration files on the TFTP server using the following approach:
First, it searches for the boot configuration file that is named according to the MAC address represented in lower case hexadecimal digits with dash separators. For example, for the MAC Address "88:99:AA:BB:CC:DD", it searches for the file 01-88-99-aa-bb-cc-dd.

Then, it searches for the configuration file using the IP address (of the machine that is being booted) in upper case hexadecimal digits. For example, for the IP Address "192.0.2.91", it searches for the file "C000025B".

If that file is not found, it removes one hexadecimal digit from the end and tries again. However, if the search is still not successful, it finally looks for a file named "default" (in lower case).

For example, if the boot file name is /tftpboot/pxelinux.0, the Ethernet MAC address is 88:99:AA:BB:CC:DD, and the IP address 192.0.2.91, the boot image looks for file names in the following order:

/tftpboot/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/tftpboot/pxelinux.cfg/C000025B
/tftpboot/pxelinux.cfg/C000025
/tftpboot/pxelinux.cfg/C00002
/tftpboot/pxelinux.cfg/C0000
/tftpboot/pxelinux.cfg/C000
/tftpboot/pxelinux.cfg/C00
/tftpboot/pxelinux.cfg/C0
/tftpboot/pxelinux.cfg/C

7. The client downloads all the files it needs (kernel and root file system), and then loads them.

8. Target Machine reboots.
The Provisioning application uses Redhat's Kickstart method to automate the installation of Redhat Linux on target machines. Using kickstart, the system administrator can create a single file containing answers to all the questions that will usually be asked during a typical Red Hat Linux installation.

The host specific boot configuration file contains the location of the kickstart file. This kickstart file would have been created earlier by the stage directive of the OS image based on the input from user.

H About Patching Automation Reports

This appendix describes the patching automation reports offered by Enterprise Manager Grid Control. In particular, this appendix covers the following:

- About Patchability Report

- About Patching Deployment Procedure Execution Summary Report

Note:

The patching automation reports described in this appendix are introduced by a one-off patch released by Oracle in July 2009. To view these reports, you must apply the one-off patch to all your Oracle Management Services. For more information about the one-off patch, see Applying One-Off Patch to Introduce Analyze Mode and Reports.

About Patchability Report

The Patchability Report helps you analyze the environment and identify the Oracle Databases that are suitable and not suitable for a patching operation. Before running a patching Deployment Procedure for Oracle Database and Oracle RAC, Oracle strongly recommends you to run this report so that you know whether the database targets you want to patch can be patched successfully. You can diagnose whether the database target is not suitable for patching due to missing properties or unsupported configuration.

To access the Patchability Report, in Grid Control, click Reports. On the Report Definitions page, in the table, expand Deployment and Configuration, and then expand Patching Automation Reports and click EM Target Patchability Report.

Note:

In general, the missing properties error is due to inadequate or incomplete target information collected by Oracle Management Agent.
To resolve this issue, recompute the dynamic properties and refresh the host configuration so that Oracle Management Repository is updated with the latest configuration of the host. To do so, follow these steps:

1. To recompute the dynamic properties, do one of the following:
Option A: Stop and restart Oracle Management Agent:

$ emctl stop agent

$ emctl start agent

For a cluster, restart Oracle Management Agent on all the nodes of the cluster.

Option B: Reload the dynamic properties. This option is simpler because you do not have to restart Oracle Management Agent.

$ emctl reload agent dynamicproperties

For a cluster, run the following command:

$ emctl reload agent dynamicproperties [<Target_name>:<Target_Type>]

For example:

$ emctl reload agent dynamicproperties crs:cluster

$ emctl reload agent dynamicproperties oradb:oracle_database

$ emctl reload agent dynamicproperties server1.xyz.com:host

$ emctl reload agent dynamic properties racdb_1:rac_database

2. To update Oracle Management Repository with the latest configuration information, click Deployments. On the Deployments page, from the Configuration section, click Refresh Host Configuration. On the Refresh Host Configuration page, select the hosts whose configuration needs to be updated in Oracle Management Repository.

About Patching Deployment Procedure Execution Summary Report

The Patching Deployment Procedure Execution Summary Report helps you analyze the results of the patching Deployment Procedures that were run over a period of time in the past. The report helps you understand the number of patching failures, prerequisite failures, successful executions, and unsupported configurations encountered by the Deployment Procedures.

To access the Patching Deployment Procedure Execution Summary Report, in Grid Control, click Reports. On the Report Definitions page, in the table, expand Deployment and Configuration, and then expand Patching Automation Reports and click Patching Deployment Procedures Execution Summary.

I Converting Standalone Oracle Management Agent to Cluster Agent

For using the RAC-related procedures, you must have cluster-compatible Oracle Management Agents (Management Agents) on the cluster nodes, and not standalone Management Agents. However, if the Management Agents on the cluster nodes are indeed standalone Management Agents, then you must convert them to cluster-compatible Management Agents.

This appendix explains how you can convert a standalone Management Agent to a cluster-compatible Management Agent. In particular, this chapter covers the following:

- Using Graphical Mode to Convert

- Using Silent Mode to Convert

Using Graphical Mode to Convert

To convert a standalone Management Agent to a cluster-compatible Management Agent in a graphical mode, follow these steps:

1. Meet the prerequisites for installing a Management Agent as described in the Oracle Enterprise Manager Grid Control Installation and Configuration Guide available at:
http://www.oracle.com/technology/documentation/oem.html

2. In Grid Control, click Deployments.

3. On the Deployments page, from the Agent Installation section, click Install Agent.

4. On the following page, click Fresh Install.

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

Using Silent Mode to Convert

To convert a standalone Management Agent to a cluster-compatible Management Agent in a silent mode, follow these steps:

1. Invoke the agentca utility using the -f and -c option from the <Agent Oracle home>/bin directory of the standalone Management Agent on each cluster node. Also use the -n option to specify the name of the cluster.
For example:

<Agent Oracle Home>/bin/agentca -f -n <cluster name> -c "{<comma separated cluster node list like node1, node 2…>}"

2. Update the node list by running the following command:

- In case SSH connection is set up between the cluster nodes, then run the following command from <Agent Oracle Home>/oui/bin directory on one of the nodes:
./runInstaller -updateNodelist ORACLE_HOME=<Agent Oracle Home> "CLUSTER_NODES={<comma separated list of nodes in the cluster>}"

- In case SSH connection is not setup between the nodes then run the following command from <Agent Oracle Home>/oui/bin directory on each node:
./runInstaller -updateNodelist ORACLE_HOME=< Agent Oracle Home > "CLUSTER_NODES={< comma separated list of nodes in the cluster >}" -local

3. Resynchronize the Management Agent by following these steps:

1. In Grid Control, click Targets, and then All Targets.

2. On the All Targets page, from the Search list, select Agent and click Go.

3. Click the name of the Management Agent you clusterized.

4. On the Agent Home page, from the Related Links section, click Agent Resynchronization.

5. On the Agent Resynchronization page, click Continue.

Index

A  B  C  D  E  G  H  I  L  M  N  O  P  R  S  U  V

A

assignments

creating, 9.5.6

overview, 2.5.5

provisioning, 9.5.7

B

bare metal provisioning

concepts

boot server, 2.8.1

reference host, 2.8.1

RPM repository, 2.8.1

stage server, 2.8.1

overview, 2.8

prerequisites, 3.7.1

process, 2.8.2

provisioning linux, 2.8.2.2

setting up environment, 2.8.2.1

boot server

configuring, 3.7.12

overview, 2.8.1

setting up, 3.7.3

Business Process Execution Language (BPEL), 13

C

clone

cloning a running Oracle Application Server instance, 11.3.1

cloning a running Oracle database replay client, 8.4

cloning a running Oracle RAC instance, 5.5

cloning existing Oracle database software, 4.4

components, 2.5.2

customization

customization types, 23.1

customizing directives, 23.9

limitations, 23.2

overview, 23

phases or steps

adding phases or steps, 23.4

customizing steps, 23.7

deleting, 23.5

enabling or disabling, 23.6

D

default image

creating, 9.3.2

setting up, 9.3.3

staging, 9.3.4

deployment procedures

activities, 2.2.3

exporting deployment procedures, B.4

overview, 2.2.1

patching deployment procedures, 2.4

phases and steps, 2.2.2

provisioning deployment procedures, 2.3

users, 2.2.4

using EMCLI, 24.3

designers

creating designers, 3.1.1.1

overview, 2.2.4

directives, 2.5.3

disk layouts

creating disk layout component, 9.5.3

overview, 2.5.4

E

e-mail notifications

customizing PAF rule, 23.10.2

enabling, 23.10.1

overview, 3.2.2

setting up, 23.10

EMCLI, 24

EMCLI Verbs, 24.7

error handling modes, 23.8

G

gold image

provisioning Oracle database replay client using gold image, 8.5

provisioning Oracle database using gold image, 4.5

provisioning Oracle RAC using gold image, 5.6

guest virtual machine

overview, 2.7.1

guest VM server, 2.7.1

H

hardware templates, 2.5.4

I

images, 2.5.4

importing PAR files, B.5

L

lifecycle management

challenges, 1.1

solutions, 1.2

linux patching

overview, 2.6

prerequisites, 3.5.1

setting up group, 3.5.3

M

master server, 2.7.1

monitoring server, 2.7.1

My Oracle Support credentials, 3.3.2

N

network templates, 2.5.4

notifications, 3.2.2

O

operators

creating operators, 3.1.1.2

overview, 2.2.4

Oracle Service Bus, 12

Oracle VM

overview, 2.7.1

provisioning Oracle VM servers, 9.4

P

PAM, 2.9.4

PAR (provisioning archive) files, 2.9.1

PARDeploy utility, B

patch advisories

identifying patches, 3.4.7

overview, 2.9.2

uploading information, 3.4.4

patch sets, 2.1.5

patches, 2.1.4

patching

deployment procedures, 2.4

enabling offline mode, 3.4.1

enabling online mode, 3.3.1

linux patching, 2.6

methodologies, 2.4.3

modes, 2.4.2

overview, 2.1.2

patch prerequisite checker, 14

patch solaris hosts, 21.2

patch standalone Oracle ASM, 18.2

patching linux hosts, 20

patching Microsoft Windows hosts, 22

patching Oracle Application Server, 19

patching Oracle clusterware, 17

patching Oracle database, 15

patching Oracle RAC, 16

patching solaris hosts, 21

rolling back patches, 23.11

setting up online settings, 3.3.3

setting up preferred credentials, 3.2.3.2

preferred credentials

setting up for bare metal provisioning, 3.7.8

setting up for patching, 3.2.3.2

setting up for provisioning, 3.2.3.1

setting up using EMCLI, 24.5

privilege delegation, 2.9.4

provisioning

deleting or scaling down Oracle RAC (Real Application Cluster), 7

deployment procedures, 2.3

extending Oracle RAC (Real Application Cluster), 6

overview, 2.1.1

provisioning linux operating system, 9

provisioning Oracle Application Server, 11

provisioning Oracle BPEL processes, 13

provisioning Oracle database, 4

provisioning Oracle database replay client, 8

provisioning Oracle RAC, 5

provisioning Oracle Service Bus resources, 12

setting up preferred credentials, 3.2.3.1

provisioning linux, 2.8.2.2

proxy connection settings, 3.3.2

R

reference host, 2.8.1

RPM repository

configuring, 3.7.11

overview, 2.8.1

setting up, 3.5.2, 3.7.5

S

software library

adding, deleting, and editing location, C.1

checking accessibility to location, C.1

concepts

assignments, 2.5.5

components, 2.5.2

directives, 2.5.3

disk layouts, 2.5.4

hardware templates, 2.5.4

images, 2.5.4

network templates, 2.5.4

configuring, 3.1.2.1

creating and deleting entities, C.1

creating components, 3.1.2.2

de-configuring, C.2

exporting and importing entities, C.1

maintaining software library, C.3

overview, 2.5.1, C.1

purging entities, C.1

refreshing space-usage details, C.1

setting up, 3.1.2

uploading OPatch patches, 3.4.6

uploading patch, 3.4.8

stage server

configuring, 3.7.10

overview, 2.8.1

setting up, 3.7.4

staging area, 2.9.3

SUDO, 2.9.4

U

user accounts

creating designer, 3.1.1.1

creating operator, 3.1.1.2

overview, 3.1.1

utility server, 2.7.1

V

virtual server

configuring, 3.6.1

overview, 2.7.1

virtual server pool

creating, 3.6.2

overview, 2.7.1

registering, 3.6.3

virtualization management

concepts

guest virtual machine, 2.7.1

guest VM server, 2.7.1

master server, 2.7.1

monitoring server, 2.7.1

Oracle VM, 2.7.1

utility server, 2.7.1

virtual server, 2.7.1

virtual server pool, 2.7.1

overview, 2.7

privileges required, 2.7.2

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