Vous êtes sur la page 1sur 62

Oracle Change Management Application

Users Guide
Release 3.6.1.2.0

June 2012
Oracle Change Management Application User's Guide, Release 3.6.1.2.0

Copyright 2012, 2013, Oracle. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in
the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these
Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States 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, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation
and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license
agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial
Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA
94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

The Programs may provide links to Web sites and access to content, products, and services from third
parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites.
You bear all risks associated with the use of such content. If you choose to purchase any products or services
from a third party, the relationship is directly between you and the third party. Oracle is not responsible for:
(a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the
third party, including delivery of products or services and warranty obligations related to purchased
products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from
dealing with any third party.
Contents

Preface ................................................................................................................................................................. v
Audience....................................................................................................................................................... v
Typographic Conventions.......................................................................................................................... v
Command Syntax ........................................................................................................................................ v
Documentation Accessibility ..................................................................................................................... vi

1 Prerequisites

2 Overview and Setup


2.1 Requesting Access to the CMA for Refresh Runs .................................................................. 2-2
2.2 Requesting Access to the CMA for Patching Runs ................................................................ 2-2
2.2.1 Requesting a Cloud Services CMA User Account .......................................................... 2-2
2.2.2 Requesting a Cloud Services CMA Privileges................................................................. 2-3
2.3 Setting Up Preferred Credentials.............................................................................................. 2-4
2.4 Troubleshooting Login Errors................................................................................................... 2-5

3 Viewing Dashboard Information


3.1 Logging In to CMA..................................................................................................................... 3-1
3.2 Viewing Settings ......................................................................................................................... 3-1
3.3 Viewing Outage Notifications................................................................................................... 3-2
3.4 Searching for a Change Execution............................................................................................ 3-2
3.5 Switching Between Patch and Refresh Queues ...................................................................... 3-3
3.6 Viewing Details ........................................................................................................................... 3-3
3.6.1 Viewing or Adding Communications .............................................................................. 3-3
3.6.2 Viewing, Adding, and Editing Exceptions ...................................................................... 3-4
3.6.3 View EM Status .................................................................................................................... 3-5
3.6.4 Reassign the Engineer ......................................................................................................... 3-5
3.6.5 Stopping, Suspending, Resuming, Resubmitting, or Deleting an Execution ............. 3-5
3.6.6 Retrying, Updating and Retrying, or Ignoring a Change Execution Step................... 3-6
3.6.7 Confirming a Manual Change Execution Step ................................................................ 3-7
3.7 Working with Scheduled Refreshes ........................................................................................ 3-7
3.8 Reviewing Executions that Require Attention ....................................................................... 3-8
3.9 Reviewing Running Change Executions ................................................................................. 3-8
3.10 Reviewing Completed Change Executions............................................................................. 3-8

iii
4 Initiating a Patching Run
4.1 Patch Type Overview ................................................................................................................. 4-1
4.2 Specify the RFC ID...................................................................................................................... 4-1
4.3 Change Target System Information ......................................................................................... 4-2
4.4 Specify Patch Options................................................................................................................. 4-4
4.4.1 Prerequisite Patches............................................................................................................. 4-5
4.4.2 Patching Procedure Options .............................................................................................. 4-5
4.4.3 AutoPatch Options (Application-Tier Only) ................................................................ 4-11
4.4.4 OPatch Options (Database-Tier Only) ........................................................................... 4-12
4.4.5 AD Administration Options (Application-Tier and CPU Patching Only)............... 4-12
4.4.6 HR Global Options .......................................................................................................... 4-13
4.4.7 Reviewing the Patch List Table....................................................................................... 4-13
4.5 Specifying Hosted Servers Password.................................................................................... 4-15
4.6 Review Patching Run Information ........................................................................................ 4-15
4.6.1 Reviewing the Patch Readme File .................................................................................. 4-15
4.6.2 Changing the Patch Application Order......................................................................... 4-16
4.6.3 Reapplying and Pausing a Previously Applied Patch ................................................ 4-16
4.6.4 Selecting Preinstall Mode ............................................................................................... 4-17
4.6.5 Deleting a Patch ................................................................................................................ 4-17
4.6.6 Recovering a Deleted Patch............................................................................................. 4-17
4.6.7 Specify Operating System Password ............................................................................. 4-17
4.6.8 Change, Cancel, or Submit a Patching Run Request ................................................... 4-18

5 Initiating a Refresh Run


5.1 Specifying the RFC ID or Customer Name ............................................................................. 5-1
5.2 Specifying Refresh Type ............................................................................................................ 5-2
5.3 Specifying Customer, Target, and Source Instances.............................................................. 5-3
5.4 Specifying Hosted Servers Password and PowerBroker Role.............................................. 5-4
5.5 Specifying Backup Options and Advanced Settings ............................................................. 5-5
5.6 Changing, Cancelling, or Submitting a Refresh Run............................................................. 5-7
5.7 Retrying Failed Steps.................................................................................................................. 5-8

A Bugs and Enhancements

B Troubleshooting
n Initializing the Enterprise Manager Command Line Interface Client Manually ............. B-1
5. Review Log Files ........................................................................................................................ B-2
5. Create XML Files from Runtime Parameters ......................................................................... B-3

C Refresh Procedure Step Details

D Conditional Patching Procedure Behavior


D Database Tier Patching Procedure .......................................................................................... D-1

iv
Preface

This guide provides instructions for configuring and using Oracle Enterprise Manager
and the Change Management Application to request patching and refresh runs.

Audience
This guide is intended for Oracle On Demand Operations engineers who maintain On
Demand customer systems.

Typographic Conventions
The following typographic conventions are used in this guide:

Convention Meaning
boldface Boldface type indicates graphical user interface elements associated
with an action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for
which you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code
in examples, text that appears on the screen, or text that you enter.
UPPERCASE Uppercase case letters indicate Structured Query Language (SQL)
reserved words, initialization parameters, and environment variables.
<cr> Indicates a line break.

Command Syntax
UNIX and Linux command syntax appears in monospace font and assumes the use of
the Bourne shell. The "$" character at the beginning of UNIX or Linux command
examples should not be entered at the prompt. Because UNIX and Linux is
case-sensitive, conventions used in this document may differ from those used in other
Oracle documentation.

Convention Meaning
Backslash \ A backslash indicates a command that is too long to fit on a single line.
Enter the line as printed (with a backslash) or enter it as a single line
without a backslash:
dd if=/dev/rdsk/c0t1d0s6 of=/dev/rst0 bs=10b \
count=10000

v
Convention Meaning
Braces {} Braces indicate required items: DEFINE {macro1}
Brackets [] Brackets indicate optional items: cvtcrt termname [outfile]
Note that brackets have a different meaning when used in regular text.
ellipses.... Ellipses indicate an arbitrary number of similar items:
CHKVAL fieldname value1 value2 ... valueN
Italics Italic type indicates a variable. Substitute a value for the variable.
library_name
Vertical line A vertical line indicates a choice within braces or brackets:
SIZE filesize [K|M]

Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of assistive
technology. This documentation is available in HTML format, and contains markup to
facilitate access by the disabled community. Accessibility standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading
technology vendors to address technical obstacles so that our documentation can be
accessible to all of our customers. For more information, visit the Oracle Accessibility
Program Web site at
http://www.oracle.com/accessibility/

Accessibility of Code Examples in Documentation


Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an
otherwise empty line; however, some screen readers may not always read a line of text
that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation


This documentation may contain links to Web sites of other companies or
organizations that Oracle does not own or control. Oracle neither evaluates nor makes
any representations regarding the accessibility of these Web sites.

TTY Access to Oracle Support Services


Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services
within the United States of America 24 hours a day, seven days a week. For TTY
support, call 800.446.2398.

vi
1
Prerequisites

Ensure that you meet the following prerequisites before using this guide:
You have an Oracle Single Sign-On (SSO) account.
You have a basic understanding of Oracle Enterprise Manager Grid Control 10g
Release 4 (EM Grid Control 10g R4) concepts, including logging in to the console,
basic navigation, and accessing the online help. For information about these
concepts, see the Oracle Enterprise Manager Grid Control Installation and Basic
Configuration guide, available at the following URL:
http://www.oracle.com/technology/products/oem/deployments/b12012_
03.pdf

Oracle Applications Patching and Refresh Procedures have been successfully


installed in your EM Grid Control console and you have a valid account with the
appropriate role for that console.
Currently, the URL for the EM Grid Control console for patching runs is
http://odem1.oracle.com/em/.
Currently, the URL for the EM Grid Control console for refresh runs is
https://sacoms.oracle.com/em/.
You have a thorough understanding of the Orion RFC system, available through
the Oracle Internal Support Portal at the following URL:
http:/support.us.oracle.com
If you intend to request a patching run:
You have a valid account on the
adcinf-ebso-upgrd-set2-03.oracle.com node.
The OHSDBA PowerBroker role has been assigned to you, and you have login
access to every node of each system that you will be patching.
You have a basic understanding of the Oracle Application Management Pack
for Oracle E-Business Suite, including using the EM Grid Control 10g R4 pages
to manage Oracle E-Business Suite. For information about Oracle Application
Management Pack for Oracle E-Business Suite, see the Oracle Application
Management Pack for Oracle E-Business Suite User's Guide, available at the
following URL:
https://metalink.oracle.com/cgi-bin/cr/getfile.cgi?p_
attid=394448.1:2

You have a thorough understanding of AutoPatch and other Applications DBA


(AD) concepts and utilities, including AutoConfig, AD Administration, AD

Prerequisites 1-1
maintenance mode, and AD Merge Patch. These concepts and utilities are
explained in the following documents:
Release 11i:
Oracle Applications Maintenance Procedures, Release 11i (11.5.10.2), available at
the following URL:
http://download.oracle.com/docs/cd/B25516_
18/current/acrobat/11iadproc.pdf

Oracle Applications Maintenance Utilities, Release 11i (11.5.10.2), available at the


following URL:
http://download.oracle.com/docs/cd/B25516_
18/current/acrobat/11iadutil.pdf

Release 12:
Oracle Applications Patching Procedures, Release 12, available at the following
URL:
http://download.oracle.com/docs/cd/B40089_09/current/acrobat/oa_
patching_r12.pdf

Oracle Applications Maintenance Procedures, Release 12, available at the following


URL:
http://download.oracle.com/docs/cd/B40089_
09/current/acrobat/r12adproc.pdf

Oracle Applications Maintenance Utilities, Release 12, available at the following


URL:
http://download.oracle.com/docs/cd/B40089_
09/current/acrobat/r12adutil.pdf

You have a thorough understanding of OPatch and how it is used to apply


patches to the database tier of Oracle E-Business Suite (EBS) customer systems.
For information about Opatch, see the Oracle Universal Installer and OPatch
User's Guide, available at the following URL:
http://download.oracle.com/docs/cd/B19306_01/em.102/b16227.pdf

If you intend to request a refresh run:


You have a valid account on the
adcinf-ebso-upgrd-set2-02.oracle.com node.
The SA PowerBroker role has been assigned to you.
You have a thorough understanding of SMART Clone / eZ-Clone utility,
which is used in On Demand to refresh customer instances, and of the Rapid
Clone utility, which is used to clone Oracle Applications instances in general.
Rapid Clone is described in the following documents:
* Cloning Oracle Applications Release 11i with Rapid Clone, available at the
following URL:
https://metalink.oracle.com/metalink/plsql/ml2_
documents.showDocument?p_database_id=NOT&p_id=230672.1

* Cloning Oracle Applications Release 12 with Rapid Clone, available at the


following URL:

1-2 Oracle Change Management Application User's Guide


https://metalink.oracle.com/metalink/plsql/ml2_
documents.showDocument?p_database_id=NOT&p_id=406982.1

Prerequisites 1-3
1-4 Oracle Change Management Application User's Guide
2
Overview and Setup

Change Management Application (CMA) automates most of the tasks involved in


managing changes to Oracle E-Business Suite (EBS) customer systems which involve
applying patches and refreshing instances. The CMA was designed to simplify and
streamline the change management processes for users who manage changes to EBS
customer systems, especially in a multisystem, grid-based, data-center type of
environment. Examples of change management tasks that are automated by the CMA
include:
Running Service Health Checks to verify the integrity of the Applications system
Shutting down and restarting all of the application-tier and database-tier services
Making a backup of the Applications system
Applying patches with either AutoPatch or Opatch
Refreshing instances
Performing various post-patch and post-refresh tasks
To do this, the CMA leverages the grid control power of Oracle Enterprise Manager
(EM) Grid Control 10g Release 3, along Oracle Application Management Pack Release
2.0 for EBS. The CMA adds a Web-based user interface and predefined deployment
procedures to this framework.
These predefined deployment procedures are the heart of the automated patching
process. For more information about deployment procedures in general, refer to the
following EM Online Help page:
Contents >Top Level >Management Operations >Managing Deployment Procedures
>About Deployment Procedure Manager
You can also access this help page by clicking Help in the Deployment Procedure
Manager page, and then clicking the About Deployment Procedure Manager link.
The user interacts with the CMA as follows:
1. The CMA user interface gathers information from the user about the change to be
made.
2. The deployment procedures use this information to make the change.
3. The user uses the CMA to monitor the change progress.
Currently, the CMA is available on two different systems, depending on whether you
want to request a patching run or a refresh run:
For patching runs, log in to the following node:
https://cmportal.oracle.com/cmportal/

Overview and Setup 2-1


Requesting Access to the CMA for Refresh Runs

For refresh runs, log in to the following node:


https://refresh-cmportal.oraclecorp.com/cmportal/

Complete the steps in the following sections before using the CMA.

2.1 Requesting Access to the CMA for Refresh Runs


To request access to the CMA for refresh runs, send a request for a user account on the
https://refresh-cmportal.oraclecorp.com/cmportal// environment to
one of the following email addresses:
dipti.joshi@oracle.com
cristiana.ion@oracle.com
jayanta.pal@oracle.com

2.2 Requesting Access to the CMA for Patching Runs


The CMA for patching runs uses the Oracle Access Provisioning System (APS) to
manage user accounts and role assignments. Before you can access the CMA, you must
use the APS to request a user account and role.

Note: At the time of this publication, the CMA environment for


patching runs is https://cmportal.oracle.com/cmportal/.
The examples in the following sections assume you are requesting an
account for this environment.

2.2.1 Requesting a Cloud Services CMA User Account


This section describes how to request a Cloud Services CMA User account.
To request a Cloud Services CMA User account:
1. Use your Oracle Single Sign-On credentials to log in to the APS at the following
URL:
https://aps.oraclecorp.com/

2. Click the Access & Mailing List Request tab.


The Access & Mailing List Request page appears.
3. Select the following values, then click Next Step:
Category - Select Oracle Applications.
Action - Select Create Account.
Who - Select For Myself.
The Identify System(s) page appears.
4. From the list of systems, select Cloud Services CMA, then click Next Step.
The Justification page appears.
5. On the Justification page, in the Justification field, enter a justification for the
CMA account. Include the group you work for and what you will be using the
CMA for, then click Submit Request.

2-2 Oracle Change Management Application User's Guide


Requesting Access to the CMA for Patching Runs

The Confirmation page appears, showing that the request has entered the
approval process.
Your manager receives an automated notification from APS and must then
approve the request.
You can monitor the request in the Recent Requests section of the APS Home
page. When the request has been approved, the status will change to Successfully
Processed.
Complete the steps in the following section to request a role.

Note: You will not be able to request a role until your user account
request is approved, and you will not be able to log in to the CMA
until your role request is approved.

2.2.2 Requesting a Cloud Services CMA Privileges


This section describes how to request Cloud Services CMA privileges. You must have
a Cloud Services CMA account before requesting these privileges. To request the
account, see Requesting a Cloud Services CMA User Account.
To request Cloud Services CMA privileges:
1. Use your Oracle Sign-On credentials to log in to the APS at the following URL:
https://aps.oraclecorp.com/

2. Click the Access & Mailing List Request tab.


The Access & Mailing List Request page appears.
3. Select the following values, then click Next Step:
Category - Select Oracle Applications.
Action - Select Add Privileges.
Who - Select For Myself.
The Identify System(s) page appears.
4. From the list of systems, select Cloud Services CMA, then click Next Step.
The Identify Privileges page appears.

Note: If Cloud Services CMA does not appear in the systems list,
you do not have a Cloud Services CMA account. Follow the
instructions in Requesting a Cloud Services CMA User Account to
create the account, then begin this procedure again.

5. Select the following privileges by moving them from the Available Privileges area
to the Selected Privileges area, then click Next Step:
Change Execution Engineer - This privilege provides access to CMA Patch,
Bounce, and PSFT Refresh on https://cmportal.oracle.com.
Change Execution Planner - This privilege provides access to CMA-PPA on
https://cmportal.oracle.com.
The Justification page appears.

Overview and Setup 2-3


Setting Up Preferred Credentials

6. On the Justification page, in the Justification field, enter a justification for the
CMA account. Include the group you work for and what you will be using the
CMA for, then click Submit Request.
The Confirmation page appears, showing that the request has entered the
approval process.
Your manager receives an automated notification from APS and must then
approve the request.
You can monitor the request in the Recent Requests section of the APS Home
page. When the request has been approved, the status will change to Successfully
Processed.

Note: Note: You will not be able to request a role until your user
account request is approved, and you will not be able to log in to the
CMA until your role request is approved.

2.3 Setting Up Preferred Credentials


You can specify preferred host credentials that the patching procedures can use to
connect to the nodes being patched. Specify preferred host credentials to eliminate the
requirement to enter usernames and passwords for each node that will be patch. You
should define preferred host credentials for all application tier and database tier nodes
of all the customer systems under your control before using the patching procedures.
Complete the following steps to specify preferred host credentials:
1. Log in to the EM Grid Control console.
Currently, the URL for the EM Grid Control console for patching runs is
http://odem1.oracle.com/em/.
Currently, the URL for the EM Grid Control console for refresh runs is
https://sacoms.oracle.com/em.
2. Click Preferences in the top right corner of the page.
The General page appears.
3. Click Preferred Credentials in the left frame of the page.
The Host Preferred Credential page appears.
4. Click the icon in the Set Credentials column of the host target type.
The Host Preferred Credentials page appears.
5. Enter your PowerBroker username and password in the Normal Username and
Normal Password boxes of the Default Credentials section.
The patching procedures are compatible with PowerBroker and require the use of
preferred credentials. You must define preferred credentials using your
PowerBroker username and password for the patching procedures to succeed.
6. In the Target Credentials area, enter values in the Normal Username and Normal
Password boxes for individual application-tier or database-tier nodes, if necessary.
You should enter these values if:
You are unwilling or unable to define default credentials.

2-4 Oracle Change Management Application User's Guide


Troubleshooting Login Errors

There are certain application-tier or database-tier nodes that require special


login credentials that are separate from your PowerBroker username and
password.
If you enter values in these boxes, they override the default Normal Username
and Normal Password values.

Note: The Privileged Username and Privileged Password are not


used by the CMA.

7. Click the Test button on the row of each target for which you entered credentials to
test the login credentials.

2.4 Troubleshooting Login Errors


CMA supports four account types:
CMA Account
OS Account
EMCLI Account
EM Host Level Preferred Credentials Account

Invalid CMA Account


If you do not have a valid CMA account, you will see the following error upon signing
into CMA using the corporate SSO login:
You are not authorized to use this application. Please refer to the "Requesting
Access" section of the user guide for instructions on requesting a user account
and role for this application.

Invalid OS Account
If you do not have a valid OS account, you will see the following error when your OS
credentials are validated during the Credentials step:
Error: Invalid Credentials Supplied. Invalid password supplied for user <username>
on Change Management Application Server (<CMA_server_name>). You will not be able
to submit the request until we validate your credentials.

Invalid EM Account
The EMCLI account is created based on the EM account. If you not have a valid EM
account, you will see the following error when attempting to (re)create the EMCLI
account during the Credentials step:
Invalid credential supplied for user <username> on Enterprise Manager Grid Control
(url:<EM_server_name>).You may click the Next button to continue with the
submission of this change execution request, and complete the emcli setup later;
but if you do not complete the emcli setup before the change execution is run by
the CMA, it will fail.

Overview and Setup 2-5


Troubleshooting Login Errors

Invalid EM Host Level Preferred Credentials Account


If you do not have a valid EM Host Level Preferred Credentials account, you will see
the following error when your EM Host Level Preferred Credentials account is
validated during the Credentials step:
Invalid EM Host Level Preferred Credentials. Please use <EM_server_name> to
correct your credentials. Click the "re-validate" link to proceed with the
submission.
Note: The change execution may fail if you do not have valid EM Default Host Level
Preferred Credentials.CMA

2-6 Oracle Change Management Application User's Guide


3
Viewing Dashboard Information

This chapter describes how to log into the Change Management Application (CMA)
and view information on the Dashboard page. It includes the following sections:
Logging In to CMA
Viewing Settings
Switching Between Patch and Refresh Queues
Viewing Details
Working with Scheduled Refreshes
Reviewing Executions that Require Attention
Reviewing Running Change Executions
Reviewing Completed Change Executions

3.1 Logging In to CMA


To log in to CMA:
1. Enter one on of the following URLs in a browser:
For patches, enter:
https://cmportal.oracle.com/cmportal/

For refreshes, enter:


https://refresh-cmportal.oraclecorp.com/cmportal//

2. When prompted, enter your Single Sign On (SSO).


The CMA Dashboard appears.

Note: If you have manager privileges, you will see the Dashboard
and Changes Executions tabs.

3.2 Viewing Settings


Click the Settings link at the top of any page to view information about your CMA
account.

Viewing Dashboard Information 3-1


Viewing Outage Notifications

3.3 Viewing Outage Notifications


All outages are notified in advance. Warning messages appear on the menu bars of all
CMA pages. During outages, read-only actions are permitted. All other actions are not
allowed.
Additionally, CMA provides the following notifications to remind users of these
outages:
Stage 1 - When CMA detects an upcoming outage, warning messages are
displayed on the menu bars on all CMA pages. You can click More... to find out
more details about the outage.
Stage 2 - Once the outage begins, a new page appears, displaying details of the
outage. At this time, actions to initiate, update, suspend, submit, resume, stop, or
delete, ignore, retry, update & retry, or confirm a change execution are not
permitted and the Submit button is inactive. All other CMA actions are permitted.
Click OK to confirm.

Note: If you log in to CMA during Stage 1 & 2, you will also see the
outage notifications described here.

Once the outage is complete, the warning messages disappear and restricted actions
are enabled again.

3.4 Searching for a Change Execution


You can search for a change execution using the RFC ID, target instance, or customer
name.
To search for a change execution:
1. On the Change Executions Home page, click Actions > Search.
The Search page appears.
2. Select the appropriate criterion:
RFC ID
Target Instance
Customer Name
Then click Search
All results matching these criteria are displayed.
3. Click the View Execution Details icon for the relevant run/change execution. The
View Procedure Status page appears.
4. The View Procedure Status page provides the following options:
To view details of the RFC, click the hyperlinked RFC ID in the Change
Request Information area.]]
To reassign the RFC, click Reassign in the Change Request Region, select the
user name from the User list, then click Submit.
To add a communication, in the Communications area, click Actions > Add
Communication. For more information, see Viewing or Adding
Communications.

3-2 Oracle Change Management Application User's Guide


Viewing Details

To add an exception, in the Run Exceptions area, click Actions > Add
Exception. Follow the instructions in Viewing, Adding, and Editing
Exceptions.
To stop, suspend, resume, submit, or delete one of the refresh steps, click the
relevant link in the Execution Status Detail area. Only completed refresh steps
are listed.
Note that you can also view details of the EM status of the instance by clicking
the hyperlink in this area.

3.5 Switching Between Patch and Refresh Queues


If you have manager privileges, you can use the Queue menu to switch between the
Refresh and Patch queues.

3.6 Viewing Details


In any of the areas on the dashboard, click the icon in the Details column to view
information about a patch or refresh.
Refresh
To refresh the information on the View Procedure Status page, select Manual Refresh
from the refresh menu. Last update X Minutes Ago displays the last time that the data
was refreshed. To set the data refresh to automatically refresh at specific intervals,
select one of the following options:
30 Second Refresh
1 Minute Refresh
5 Minute Refresh

Note: The refresh feature is not available in the wizards.

Parameter Information
To view parameter information, click the plus sign next to Runtime Metadata.

Note: If the change type is unknown the Runtime Metadata section


is empty and a message appears under the Change Request
Information heading.

The Execution Status Detail area displays information about the patch or refresh run.
Select an item to view details about that item. Click the arrow next to an item to
expand the tree.

3.6.1 Viewing or Adding Communications


The Communications area lists comments made by users about the patch or refresh.
View Communications
To view a communication:
1. Expand the Communications region on the Details page.

Viewing Dashboard Information 3-3


Viewing Details

2. Select a communication.
3. Select View Communication from the Actions menu.
The communication appears in a window.
4. Click Back and Next to view other communications.
Communications are listed in chronological order.
5. Click Done to close the window.
Add Communications
To add a communication:
1. Select Add Communication from the Actions menu.
2. Enter a subject and a comment, then click Submit.

3.6.2 Viewing, Adding, and Editing Exceptions


The Run Exceptions area lists exceptions to the refresh.
To view an exception:
1. Select an exception, then select View Exception from the Actions menu.
The View Exception box appears, displaying the following information:
Step Name: Displays the step name at which the exception occurred.
Hostname: Displays the hostname of the target instance.
Action: Displays details of the action that resulted in an exception.
Error: Displays details of the error resulting from the exception.
Summary: Displays the exception category.
Problem: Displays a description of the problem.
Solution: Displays a proposed solution for the problem.
RFC created for this issue: Shows whether an RFC has been created.
Bug created for this issue: Shows whether a bug has been created.
2. Select Next or Back to view the next or previous exception.
3. Click Done to return t the Details page.
To edit an exception:
1. Select an exception, then select Edit Exception from the Actions menu.
The Edit Exception box appears.
2. Make the required changes, then click Done:
Step Name: Click the Choose step name icon, then select the step from the list
displayed. Click Select.
Hostname: Enter the hostname of the target instance.
Action: Enter details of the action that resulted in an exception.
Error: Enter details of the error resulting from the exception.
Summary: Select the relevant category from the list.
Problem: Enter a description of the problem.
Solution: Enter a proposed solution for the problem.

3-4 Oracle Change Management Application User's Guide


Viewing Details

RFC created for this issue: If an RFC has been created, check this checkbox.
Bug created for this issue: If a bug has been created, check this checkbox.
To add an exception:
1. Select Add Exception from the Actions menu.
The Add Exception box appears.
2. Enter the exception information, then click Add Exception.
You must complete fields marked with an asterisk.
Step Name: Click the Choose step name icon, then select the step from the list
displayed. Click Select.
Hostname: Enter the hostname of the target instance.
Action: Enter details of the action that resulted in an exception.
Error: Enter details of the error resulting from the exception.
Summary: Select the relevant category from the list.
Problem: Enter a description of the problem.
Solution: Enter a proposed solution for the problem.
RFC created for this issue: If an RFC has been created, check this checkbox.
Bug created for this issue: If a bug has been created, check this checkbox.

3.6.3 View EM Status


Click View EM Status to open the Oracle Enterprise Manager console and monitor
Oracle Enterprise Manager activity.

3.6.4 Reassign the Engineer


You can reassign the engineer which will grant ownership of the run to another
engineer. You should do this when an engineer is going off shift. To reassign the
engineer associated with a patch or refresh:
1. In the Execution Status Summary region, select Reassign, next to the engineers
name.
The Reassign Change Execution dialog box appears.
2. Select a new user to assign to the patch or refresh, then click Submit.

3.6.5 Stopping, Suspending, Resuming, Resubmitting, or Deleting an Execution


You can stop, suspend, or resume a suspended execution. You should delete old runs
to remove them from view. However, users cannot get to the execution information
after it has been deleted so use Delete with caution.
You can resubmit a change execution that fails with CMA errors. Click Resubmit, then
enter your operating system credentials in the dialog box.
To stop, suspend, or resume a suspended execution, click Stop, Suspend, or Resume.
Click Stop to terminate the execution. Stopped executions cannot be resumed.
However, stopped refresh runs can be resubmitted. To resubmit a stopped execution,
click Resubmit, then enter your operating system credentials in the dialog box.
Click Suspend to pause an execution.

Viewing Dashboard Information 3-5


Viewing Details

Click Resume to restart a paused execution.


Delete a Patch or Refresh Run
You can delete a patch or refresh run that has not completed:
If the run has not yet reached Oracle Enterprise Manager:
1. Click Delete in the Execution Status Detail table.
2. When prompted, enter your user name and password.
If the run has reached Oracle Enterprise Manager, but has not yet completed:
1. Click Stop in the Execution Status Detail table.
2. When prompted, enter your username and password.
3. Click Delete in the Execution Status Detail table.
4. When prompted, enter your user name and password.

3.6.6 Retrying, Updating and Retrying, or Ignoring a Change Execution Step


If a change execution step fails, you can retry, update and retry, or ignore the step.

Note: You can only retry, update and retry, ignore, or confirm job
steps.

To retry or ignore a failed job step:


1. Select the failed job step from the Execution Status Detail tree.
2. Select either Retry or Ignore from the Actions column.
Select Retry to retry the failed step.
Select Ignore to continue the execution without retrying the failed step.
3. When prompted, enter your host credentials.
4. Complete the Issue Information section.
You must enter a description of the error and select a category.
5. Click Submit.
The patch or refresh will resume.
To update and retry a failed job step:
1. Select the failed job step from the Execution Status Detail tree.
2. Select Update&Retry from the Actions column.
Update&Retry enables you to update parameters associated with the execution
before retrying the step.
3. When prompted, enter your host credentials, then click Yes.
Oracle Enterprise Manager attempts to verify that the host contains the required
credentials. If this verification fails, you are prompted to enter your Oracle
Enterprise Manager credentials manually.
4. In the dialog box that appears, update the parameters as required, then click
Submit.
The Details page reappears and the execution has the status of running.

3-6 Oracle Change Management Application User's Guide


Working with Scheduled Refreshes

3.6.7 Confirming a Manual Change Execution Step


A manual step is a step that requires intervention before continuing. The patch or
refresh execution pauses at manual steps. To continue the execution after you have
perform the required manual action:.
1. Select the manual job step from the Execution Status Detail tree.
2. Select Confirm from the Actions column.
3. When prompted, enter your host credentials, then click Submit.
The patch or refresh will resume.

3.6.7.1 Start and End Times


The Start Time and End Time columns list the times that the execution started and
ended. Executions are listed chronologically.

3.6.7.2 Viewing Logs


If a step in the Execution Status Detail area has log information, an icon appears in the
Logs column. Click the icon to view output and error logs. Not all steps have logs, or
have both output and error logs.

3.6.7.3 Update Status


After you complete a refresh or patch run, update the status of the RFC in the
execution log:
1. Click Actions on the Details page, then select Update Status.
The Update Status area appears.
2. Select a sub-status type from the list, then click Update RFC.

3.7 Working with Scheduled Refreshes


If you logged in using the refresh URL, refreshes schedule within the next 21 days are
listed in the Upcoming Refreshes in ITAS.
You can perform the following tasks in the Upcoming Refreshes in ITAS area:

Changing the Date Range


To change the date range for the scheduled refreshes displayed:
1. Edit the dates in the Scheduled Date Between box or click the calendar icons to
select new date ranges.
2. Click the Search icon.
All refreshes scheduled between the specified dates appear in the table.

View Test Refresh Run Status


Test refresh runs can be scheduled to run 24 hours before a scheduled production run.
The Upcoming Refreshes in ITAS area lists the last test run. For text runs, click the icon
in the Test DP column to view the test details.

Initiating a Scheduled Refresh


To initiate a scheduled refresh:

Viewing Dashboard Information 3-7


Reviewing Executions that Require Attention

Note: You can only initiate a refresh with the status Awaiting
Implementation.

1. Select the icon in the Initiate column for the refresh that you want to edit.
The Initiate a New Refresh Run wizard starts with the RFC populated.
2. Edit the refresh as required.

See Also: For information about using the Initiate a New Refresh
wizard, see Chapter 5.

3.8 Reviewing Executions that Require Attention


The Attention Required area lists refresh or patch requests that require attention to
proceed, depending on how you logged into the CMA.
To view execution details, click the icon in the Details column.
To view an RFC, click an RFC in the RFC column.
For Refreshes, the Run Type column indicates whether the refresh is a test (Test) or full
run (PROD). If the icon is greyed out, the refresh is a test run.
The Status column lists the status of the refresh or patch.

Note: By default, the Attention Required area does not list stopped
refresh or patch requests. To include stopped requests, click the Edit
icon, deselect the Exclude Stopped Execution check box, then click
Save. This option is not available on the Dashboard tab for the
manager role.

To refresh the Attention Required area, click Manual Refresh in the upper right corner
of the page.
The Elapsed Time column lists the amount of time that an execution has been running.
This time is also listed on the Details page.

3.9 Reviewing Running Change Executions


The Running Change Executions area lists refresh requests or patch requests that are
currently running, depending on how you logged into the CMA.
To view execution details, click the icon in the Details column.
To view an RFC, click an RFC in the RFC column.
To refresh the Running Change Executions table, click Manual Refresh in the upper
right corner of the page.

3.10 Reviewing Completed Change Executions


The Completed Change Executions area lists completed refresh requests or patch
requests, depending on how you logged into the CMA.
To change the date range for the completed refreshes or patches:

3-8 Oracle Change Management Application User's Guide


Reviewing Completed Change Executions

1. Edit the dates in the Completion Date Between boxes or click the calendar icons to
select new date ranges.
2. Click the Search icon.
All refreshes or patches completed between the specified dates appear in the table.
To view execution details, click the icon in the Details column.
To view an RFC, click an RFC in the RFC column.
To refresh the Completed Change Executions table, click Manual Refresh in the upper
right corner of the page.

Viewing Dashboard Information 3-9


Reviewing Completed Change Executions

3-10 Oracle Change Management Application User's Guide


4
Initiating a Patching Run

This chapter describes how to use the CMA to initiate a patching run. It includes the
following sections:
Patch Type Overview
Specify the RFC ID
Change Target System Information
Specify Patch Options
Specifying Hosted Servers Password
Review Patching Run Information

4.1 Patch Type Overview


The CMA supports the patch types listed in the following table. A Request For Change
(RFC) is associated with one of these patch types:

Patch Type Description


APPS_PATCH Used to patch an Oracle Applications instance.
DB_PATCH Used to patch an Oracle Database instance
DB_PATCH Used to patch an Oracle Database instance
CEMLI Used to patch CEMLI for a specific customer instance. A CEMLI patch
has 10 digits. It has the same options as an application patch.
VERTEX A one to many CPU used to apply patches to more than one instance.
If you enter a VERTEX RFC, the Target Instances table appears in the
RFC Information area. This table lists the instances contained in the
RFC. The patch will be applied to all of the listed instances.
DB_EBSO_UPGRADE Used to upgrade Oracle Database instances. This patch type has two
subsets, DB Upgrade and DB Patchset Upgrade.
DB Upgrade patches upgrade Oracle Database to a major release, for
example, from release 10.3 to 11.
DB Patchset Upgrade is used to upgrade Oracle Database to a minor
release, for example, from release 10.3 to 10.4.

4.2 Specify the RFC ID


To specify the RFC request ID:
1. Log in to the CMA at the following URL:

Initiating a Patching Run 4-1


Change Target System Information

https://cmportal.oracle.com/cmportal/

2. Click the Actions menu, then click Initiate Patch.


3. In the Search area, select RFC ID, enter the RFC ID in the box, then click Search.
A list of previously scheduled change executions for the specified RFC ID may
appear. Scheduled, to OD, means something scheduled in the future. This pop up
indicates the change execution runs that are associated with the particular RFC ID.
It also indicates the status of these runs. You should review the status before
proceeding. Click Yes to proceed with the patch run request.
The Search area reappears with the RFC Information section populated with the
patching information about the RFC ID entered, including the patch type.

Note: You cannot created a refresh before the scheduled start time in
the RCF. If you try, an error message appears and you cannot
continue.

Note: 1.earch by Customer Name to display a list of customers that match


your search criteria.
2. Select a customer from the Customer List, then select a target instance
from the Target Instance list.
3. Enter the RFC ID.
A list of previously scheduled change executions for the specified RFC ID
may appear.
4. Click Yes to proceed with the patch run request.
The CMA validates the RFC ID with the selected customer and target. If
the RFC ID does not pass validation a warning or an error message
appears. Warning messages are red and error messages are blue. If you
receive an error message, you cannot proceed with the selected RFC ID. If
you receive a warning message, you may proceed with the patch

4. If the RFC was created with an incorrect subtype, you may override the subtype
by clicking Change, then selecting the appropriate subtype. Doing this enables
CMA to ask the appropriate interview questions for this RFC.

Note: Doing this does not update the RFC's subtype.

5. Click Next.
The Target System Information page appears.

4.3 Change Target System Information


The Target System Information page displays information about the customer system
to be patched. To change the target system information:

Note: If you receive an error message on this page, follow the instructions
in the message.

4-2 Oracle Change Management Application User's Guide


Change Target System Information

1. If the status of the selected application system is Unavailable, click the


Application System link to go to the Oracle Enterprise Manager (EM) monitoring
page for that system.
On the EM monitoring page, you can determine why the system is unavailable
and if necessary take appropriate actions, for example restart listeners or agents.

Note: If the Status for Patching is System in Blackout and you click Next,
you will receive the following prompt:

The following instances: instance_names appear to


be in blackout. Do you want to proceed.
If you select Yes, the wizard proceeds to the next screen. If you select
No, the wizard remains on the Target System Information page.

2. For application-tier patch run requests, specify the number of AD workers that
you want AutoPatch and AD Administration to use during the patching run in the
Workers box.
This box cannot be empty and must be set between 1 and 25. By default, this field
is set to twice the number of processors in use by the primary database node of the
customer system, which is the same default number of workers that AutoPatch
and AD Administration normally present to the user.
3. For application-tier patch run requests, in the NLS box, click the short name of
each NLS language for which you want the translated version of each translatable
patch applied.

Note: NLS languages installed in the customer system are selected


in the NLS box by default.
Hold down the Control key while you click to select or deselect
additional languages, or hold down the Shift key to select all
languages between the first and second mouse clicks.

For application-tier patch run requests, the NLS box contains the short names of
any NLS languages that are installed in the customer system, along with None.
None specifies American English, which is the base language of every On Demand
customer system. If no NLS languages are installed in the customer system, the
NLS box contain only None.
4. For Database upgrade patch types, select the Oracle Database release number that
you want to upgrade to.
If you select 11.1.0.7, you will perform a Database Upgrade. If you select 10.2.0.4,
you will perform a Database Patchset Upgrade.

Note: To upgrade to Oracle Database 11.1.0.7 your instance must


have Oracle Database release 10.2.0.x and Applications release
11.5.10.2 or 12.0.4.
To upgrade to Oracle Database release 10.2.0.4, your system must
have Oracle Database release 10.2.0.1, 10.2.0.2, or 10.2.0.3 and
Applications release 11.5.9, 11.5.10.2, or 12.0.4.

Initiating a Patching Run 4-3


Specify Patch Options

4.4 Specify Patch Options


To specify patch list options:
1. On the Target System Information page, click Next.
The Patch List Options page appears.
2. In the Patch Number List box, enter the patch number of each patch to be applied
to the customer system during the patching run, separated by a comma, in the
order that the patches should be applied.

Note: If you are creating an application-tier patching run request and


you plan to use the Merge Patches option to merge the patches before
they are applied, the order in which you list the patches is not
important.

3. In the Patch Directory Location box, enter the full path of the location of each
patch ZIP file for the patches listed in the Patch Number List box.
The default value for this field is %appl_top%/ patches for an application-tier
patching run request and %oracle_home%/patches for a database-tier patching
run request, but you can use any location that grants read and write permissions
to the owner of the application-tier file system (for an application tier patching run
request) or the owner of the database-tier file system (for a database tier patching
run request) of the customer system to be patched. The variable %appl_top% may
be used with an application-tier patching run request to represent the instantiated
value of the $APPL_TOP environment variable, and the variable %oracle_home%
may be used with a database-tier patching run request to represent the
instantiated value of the $ORACLE_HOME environment variable.
If one or more of the patch ZIP files for the patches listed in the Patch Number
List box are not available in the location entered in the Patch Directory Location
box, and they are available to the general public from OracleMetaLink, the
patching procedure will download them to this location. If the patches have a
distribution status of By MetaLink and are not classified either Internal or
Controlled in ARU, they are available to the general public. If the patches do not
meet these criteria, you must manually copy them to the location specified in the
Patch Directory Location box.
When defining an application-tier patching run request, if you plan to apply
NLS-translated versions in addition to the base language version of any patch
during the patching run, the patch ZIP file for each desired NLS-translated version
of each patch must also be located in the directory listed in the Patch Number List
box.
4. In the Stage Directory Location box, enter the full path of the location of the patch
stage area, which is where each patch ZIP file will be unzipped and from where
each patch will be applied using AutoPatch (by the application tier patching
procedure) or OPatch (by the database tier patching procedure).
The default value for this box is %appl_top%/patch_stage for an
application-tier patching run request and %oracle_home%/patch_stage for a
database-tier patching run request, but you can use any location that grants read
and write permissions to the owner of the application-tier file system (for an
application tier patching run request) or the owner of the database-tier file system
(for a database tier patching run request) of the customer system to be patched.
The variable %appl_top% may be used with an application tier patching run

4-4 Oracle Change Management Application User's Guide


Specify Patch Options

request to represent the instantiated value of the $APPL_TOP environment


variable, and the variable %oracle_home% may be used with a database tier
patching run request to represent the instantiated value of the $ORACLE_HOME
environment variable.
5. For database-tier patching and database upgrade run requests, enter the full path
of the location of the oraInst.loc Central Inventory file in the Central
Inventory Pointer File Location box.
This file contains the location of the Oracle Central Inventory directory, which
both the Oracle Universal Installer (OUI) and OPatch use to keep track of and
manage the maintenance of the products installed in each Oracle home on a any
node. The default value for this field is %oracle_home%/oraInst.loc, but you
must ensure that it is set to the actual location of the oraInst.loc file in use by
each database server node of the customer system to be patched. The variable
%oracle_home% may be used to represent the instantiated value of the
$ORACLE_HOME environment variable.
6. For DB Upgrade and DB Patchset Upgrade patches, the Database Base directory is
the base directory of the database version that you are upgrading to.
7. For DB Upgrade and DB Patchset Upgrade patches, the Database Patch Set
directory is the location of the patch set files that will be applied.
8. For DB Upgrade patches, the Target Oracle Home location is the Oracle home
location for the new installation. This value must be %new_oracle_home%.
9. For DB Patchset Upgrade patches, the Database Companion directory is the
location of the Companion CD files.
10. Select a pre and post patch backup method.

11. Select desired options from the Patching Procedure Options box, then click Next.

If the patch numbers entered the Patch Number List box are valid patches, the
Patch List page appears.

Note: For CPU patches, select the month and year of the CPU patch.
Select Apply E-Business Suite for applications patching and select
RDBMS for DB patching. To reapply a DB patch, select Force RDBMS
Patch.
If you select a date in the future, you will receive the following
validation error message:
The CPU date should be between Oct 2008 and the
current date.

4.4.1 Prerequisite Patches


The Patch List page lists the patches that will be applied. The CMA automatically adds
patches that are prerequisites and are missing from the target systems. These patches
are marked with an asterisks. If you believe that any of these patches are not need, you
can remove them by clicking the icon in the Delete column.

4.4.2 Patching Procedure Options


This section describes the patching procedure options.

Initiating a Patching Run 4-5


Specify Patch Options

4.4.2.1 Backup Options


The following backup options are available to both database-tier, application-tier, and
CPU patch run requests:
No Target Backup: No backup is performed.
Cold Target Backup: Systems are shut down before the backup is performed.
Hot Target Backup: Systems are not shut down before the backup is performed.

4.4.2.2 Application-Tier and CEMLI Patch Options


The patching procedure options listed in this section are specific to application-tier
and CEMLI patching run requests.
Merge Patches: This option is only applicable if you are applying multiple patches
in a single patching run (or a single entered patch, if that patch has one or more
NLS-translated versions to be applied during the same patching run). It controls
whether the patching procedure uses AD Merge Patch to merge multiple patches
together before applying them all in a single AutoPatch session. Otherwise, the
patching procedure will apply multiple patches one at a time, in separate
AutoPatch sessions, in the order that the patches are listed in the Patch Number
List field. (You will also have a chance to change the order, if necessary, in the
Patching Procedure Patch List page.) By default, this option is disabled, meaning
that multiple patches will not be merged. If you enable this option for a patching
run of only a single patch, and there are no NLS-translated versions of that patch
to be applied, the patching procedure will ignore the enabled option.
Enable HotPatch Mode: Controls whether the patching procedure operates in
HotPatch mode, whereby the customer system experiences no service interruption
during the patching run. When HotPatch mode is enabled, the following
service-interrupting actions that are normally performed by the patching
procedure will not be performed:
Before any patches have been applied:
Shutdown of the application tier services
AD Maintenance mode enabled
Shutdown of the database instance and listener
Pre-patching application tier and database tier file system backups performed
(normally performed if the Create Target Backup Before Patching option is
selected)
Archive mode disabled (normally performed if the Disable Archive Mode
option is selected)
Startup of the database instance and listener
After all patches have been applied:
Shutdown of the database instance and listener
Archive mode enabled (normally performed if the Disable Archive Mode
option is selected)
Shutdown of the database instance and listener
Post-patching application tier and database tier file system backups performed
(normally performed if the Create Target Backup After Patching option is
selected)

4-6 Oracle Change Management Application User's Guide


Specify Patch Options

Startup of the database instance and listener


AD Maintenance mode disabled
Startup of the application tier services
By default, this option is disabled, meaning that the patching procedure will not
operate in HotPatch mode, and all the aforementioned actions will be performed
as described.
You cannot enable HotPatch mode if a Cold Target Backup was requested before
or after patching, because cold backups require that all customer system services
to be shut down. If one or both of the Create Target Backups options are enabled,
the Enable HotPatch Mode option will be grayed out and unselectable. Both of the
Create Target Backup options must be disabled in order for the Enable HotPatch
Mode option to be selectable.
Pause Before AutoPatch Steps: Controls whether the patching procedure pauses
indefinitely after it has prepared the customer system for patching, but just before
it starts to use AutoPatch to apply the first patch in the patching run. This can be
useful for performing manual tasks that certain patches require before the patch
has been applied, or for performing maintenance on the customer system that
needs to take place immediately before patches are applied. Once the manual tasks
have been performed (or whatever necessitated the pause has been accomplished),
the patching run can be continued at the point it left off. By default, this option is
disabled, meaning that the patching procedure will not pause before it applies the
first patch in the patching run.
This is how the pause works: the "Pre-AutoPatch Manual Step" of the patching
procedure (which comes just before the "(Copy and Database Portions) Apply
Oracle Applications Product Patches" step) will return an "Action Required"
status, and the patching procedure will pause until action is taken and confirmed.
You will see the 'Action Required' status on the dashboard. Navigate to the Run
Detail page. The offending step will be displayed with the Action Required status
in the step tree. Click on the step to view its information in the detail pane. When
you are ready for the patching run to continue, select the applicable target and
click the Confirm link. You will be prompted for your username and password.
Click Submit and the patching procedure will continue.
Pause After AutoPatch Steps: Controls whether the patching procedure pauses
indefinitely just after it has used AutoPatch to apply the last patch in the patching
run, but before it (optionally) runs AD Administration or AutoConfig, or performs
any other post-patching tasks. This can be useful for performing manual tasks that
certain patches require after the patch has been applied, or for performing
maintenance on the customer system that needs to take place immediately after
patches are applied. Once the manual tasks have been performed (or whatever
necessitated the pause has been accomplished), the patching run can be continued
at the point it left off. By default, this option is disabled, meaning that the patching
procedure will not pause after it applies the last patch in the patching run.
This is how the pause works: the "Post-AutoPatch Manual Step" of the patching
procedure (which comes just after the "(Generate Portions) Apply Oracle
Applications Product Patches" step) will return an "Action Required" status, and
the patching procedure will pause until action is taken and confirmed. You will see
the 'Action Required' status on the dashboard. Navigate to the Run Detail page.
The offending step will be displayed with the Action Required status in the step
tree. Click on the step to view its information in the detail pane. When you are
ready for the patching run to continue, select the applicable target and click the

Initiating a Patching Run 4-7


Specify Patch Options

Confirm link. You will be prompted for your username and password. Click
Submit and the patching procedure will continue.
Create appsutil.zip: The appsutil.zip file is created when the AutoConfig
application is installed or patched. This file contains all of the AutoConfig files
that are needed on the database tier. After AutoConfig is installed or patched, the
appsutil.zip file contains the new or modified AutoConfig files for the database
tier. You can copy this zip file to each database server node and unzips it to install
or modify AutoConfig on the database server node.
Run AutoConfig on the Application Tier: Controls whether the patching
procedure runs AutoConfig on each application tier node after all patches have
been applied and any optional AD Administration tasks have been performed.
When the patching procedure runs AutoConfig, it does so first in test mode, and
then in normal mode immediately afterwards. Test mode generates a
configuration report that shows what configuration changes AutoConfig would
have made, without actually performing any of the changes; normal mode
performs all the changes. By default, this option is disabled, meaning that
AutoConfig will not be run.
Run AutoConfig on the Database Tier: Controls whether the patching procedure
runs AutoConfig on each database-tier node after all patches have been applied
and any optional AD Administration tasks have been performed. When the
patching procedure runs AutoConfig, it does so first in test mode, and then in
normal mode immediately afterwards. Test mode generates a configuration report
that shows what configuration changes AutoConfig would have made, without
actually performing any of the changes; normal mode performs all the changes. By
default, this option is disabled, meaning that AutoConfig will not be run.

Note: You cannot select this option unless you also select Run
AutoConfig on the Database Tier.

Disable Archive Mode: Controls whether the patching procedure disables


Archive mode in the database instance before patches are applied. For large
patches that have a lot of database jobs, disabling Archive mode usually increases
the performance of the AD workers used by AutoPatch and AD Administration,
causing such patches to be applied faster. By default, this option's checkbox is not
selected, meaning that the patching procedure will not disable Archive mode in
the database instance.
Disabling Archive mode requires the database instance to be bounced; therefore,
you cannot disable Archive mode if the Enable HotPatch Mode option is selected,
because HotPatch mode requires that the database instance remain up in order to
avoid service interruption of the customer system. If one of these two options is
selected, the other one will be grayed out and unselectable. You must deselect one
first before you can select the other one.
Pause After AutoConfig Test Mode Step: This option is only selectable if at lease
one of the Run AutoConfig options is enabled. In addition, this option is greyed
out and disabled if you select either of the Hot backup options. It controls whether
the patching procedure pauses indefinitely after it has run AutoConfig in test
mode to generate a configuration report, but just before it runs AutoConfig in
normal mode to perform all configuration changes. This can be useful for
reviewing the configuration report to understand the configuration changes that
AutoConfig will make when it runs in normal mode. Once the configuration
report has been reviewed (or whatever necessitated the pause has been

4-8 Oracle Change Management Application User's Guide


Specify Patch Options

accomplished), the patching run can be continued at the point it left off. By
default, this option is neither selectable nor enabled, meaning that if the Run
AutoConfig option is enabled, the patching procedure will not pause between
running AutoConfig in test mode and normal mode.
This is how the pause works: the "Validate AutoConfig Test Mode Output" step of
the patching procedure (which comes just after the "Run AutoConfig in Test
Mode" step) will return an "Action Required" status, and the patching procedure
will pause until action is taken and confirmed. You will see the 'Action Required'
status on the dashboard. Navigate to the Run Detail page. The offending step will
be displayed with the Action Required status in the step tree. Click on the step to
view its information in the detail pane. When you are ready for the patching run to
continue, select the applicable target and click the Confirm link. You will be
prompted for your username and password. Click Submit and the patching
procedure will continue.

4.4.2.3 CPU Patching Option


The Pause Before CPU Steps option controls whether the patching procedure pauses
indefinitely after it has prepared the customer system for patching, but just before it
starts to use CPU patch to apply the first patch in the patching run. This can be useful
for performing manual tasks that certain patches require before the patch has been
applied, or for performing maintenance on the customer system that needs to take
place immediately before patches are applied. Once the manual tasks have been
performed (or whatever necessitated the pause has been accomplished), the patching
run can be continued at the point it left off. By default, this option is disabled, meaning
that the patching procedure will not pause before it applies the first patch in the
patching run.

4.4.2.4 Database-Tier Patching Procedure Options


The following patching procedure options are specific to database-tier patching run
requests only:
Compile Invalid Objects: Controls whether the patching procedure attempts to
compile all invalid objects in the database instance once all patches have been
applied. By default, this option is disabled, meaning that any invalid objects will
not be compiled.
Pause Before OPatch Steps: Controls whether the patching procedure pauses
indefinitely after it has prepared the customer system for patching, but just before
it starts to use OPatch to apply the first patch in the patching run. This can be
useful for performing manual tasks that certain patches require before the patch
has been applied, or for performing maintenance on the customer system that
needs to take place immediately before patches are applied. Once the manual tasks
have been performed (or whatever necessitated the pause has been accomplished),
the patching run can be continued at the point it left off. By default, this option is
disabled, meaning that the patching procedure will not pause before it applies the
first patch in the patching run.
This is how the pause works: the "Pre-Database Patch Step" of the patching
procedure (which comes just before the "Apply Oracle Applications Database Tier
Patches" step) will return an "Action Required" status, and the patching procedure
will pause until action is taken and confirmed. You will see the "Action Required"
status of the step in the Steps tab of the Status Detail page of the EM Grid Control
console. You will see the 'Action Required' status on the dashboard. Navigate to
the Run Detail page. The offending step will be displayed with the Action
Required status in the step tree. Click on the step to view its information in the

Initiating a Patching Run 4-9


Specify Patch Options

detail pane. When you are ready for the patching run to continue, select the
applicable target and click the Confirm link. You will be prompted for your
username and password. Click Submit and the patching procedure will continue.
Pause After OPatch Steps: Controls whether the patching procedure pauses
indefinitely just after it has used OPatch to apply the last patch in the patching
run, but before it performs any post-patching tasks. This can be useful for
performing manual tasks that certain patches require after the patch has been
applied, or for performing maintenance on the customer system that needs to take
place immediately after patches are applied. Once the manual tasks have been
performed (or whatever necessitated the pause has been accomplished), the
patching run can be continued at the point it left off. By default, this option is
disabled, meaning that the patching procedure will not pause after it applies the
last patch in the patching run.
This is how the pause works: the "Post-Database Patch Step" of the patching
procedure (which comes just after the "Relink All RDBMS Binaries" step) will
return an "Action Required" status, and the patching procedure will pause until
action is taken and confirmed. You will see the "Action Required" status of the step
in the Steps tab of the Status Detail page of the EM Grid Control console. You will
see the 'Action Required' status on the dashboard. Navigate to the Run Detail
page. The offending step will be displayed with the Action Required status in the
step tree. Click on the step to view its information in the detail pane. When you are
ready for the patching run to continue, select the applicable target and click the
Confirm link. You will be prompted for your username and password. Click
Submit and the patching procedure will continue.
Relink All Executables After Patching: This option is only selectable if the Relink
Updated Executables option in the OPatch Options section of the accordion
control is disabled. It controls whether the patching procedure attempts to relink
all binary executables in the Oracle home once all patches have been applied. (The
Relink Updated Executables option, which is described later in this section of the
document, controls whether OPatch relinks any binary executables that were
updated by the patching run once all patches have been applied.)
There is no need for OPatch to relink just the binary executables updated by the
patching run if the patching procedure is going to attempt to relink all binary
executables in the Oracle home anyway. Therefore, if one of the Relink All
Executables After Patching or Relink Updated Executables options are selected,
the other one will be grayed out and unselectable; you must unselect one first
before you can select the other one. By default, the Relink All Executables After
Patching option is neither selectable nor enabled, meaning that the patching
procedure will not attempt to relink all binary executables in the Oracle home once
all patches have been applied, but OPatch will relink any binary executables that
were updated by the patching run once all patches have been applied.

4.4.2.5 Database Upgrade Patching Procedure Options


The following patching procedure options are specific to database upgrade patching
run requests only:
Pause Before Database (Patch Set) Upgrade: Controls whether the patching
procedure pauses indefinitely after it has prepared the customer system for
patching, but just before it starts to upgrade or apply the first patch in the patching
run. Unselected by default.
Pause After Database (Patch Set) Upgrade: Controls whether the patching
procedure pauses indefinitely just after it has completed the upgrade but before it
performs any post-patching tasks. This can be useful for performing manual tasks

4-10 Oracle Change Management Application User's Guide


Specify Patch Options

that certain patches require after the patch has been applied, or for performing
maintenance on the customer system that needs to take place immediately after
patches are applied. Once the manual tasks have been performed (or whatever
necessitated the pause has been accomplished), the patching run can be continued
at the point it left off. By default, this option is disabled, meaning that the patching
procedure will not pause after it applies the last patch in the patching run.

4.4.3 AutoPatch Options (Application-Tier Only)


This section describes the AutoPatch options available for application-tier patch run
requests:
Enable Prerequisite Checking: Controls whether AutoPatch verifies that any
prerequisite patches have been applied prior to running patch driver files that
contain file copy actions. By default, this option's checkbox is not selected, which
means that AutoPatch will not verify that any prerequisite patches have been
applied.
Disable JSP Compilation: Controls whether AutoPatch attempts to compile
out-of-date JSP files, which only occurs if a patch contains copy actions for at least
one JSP file. By default, this option's checkbox is not selected, which means that
AutoPatch will attempt to compile out-of-date JSP files when necessary.
Disable Invalid Objects Compilation: Controls whether AutoPatch attempts to
compile invalid database objects after running patch driver files that contain
database actions. By default, this option's checkbox is not selected, which means
that AutoPatch will attempt to compile invalid database objects when necessary.
Disable File Generation: Controls whether AutoPatch performs any file
generation actions that may exist in each patch driver file. By default, this option's
checkbox is not selected, which means that AutoPatch will perform any file
generation actions that exist in each patch driver file.
Disable Package Revision Cache: Controls whether AutoPatch loads the package
revision cache, which only occurs when package commands without checkfile
syntax are present in the patch driver file. By default, this option's checkbox is not
selected, which means that AutoPatch will load the package revision cache when
necessary.
Disable Maintain MRC: Controls whether AutoPatch maintains the Multiple
Reporting Currencies (MRC) schema after performing database actions, if the
MRC feature is enabled in the customer system. By default, this option's checkbox
is not selected, which means that AutoPatch will maintain the MRC schema when
necessary.
Disable Schema Validation: Controls whether AutoPatch attempts to connect to
all registered EBS schemas in the customer system prior to running the patch
driver file. By default, this option's checkbox is not selected, which means that
AutoPatch will attempt to connect to all registered EBS schemas prior to running
the patch driver file.
Disable Checkfile: The Disable Checkfile option controls whether AutoPatch
records the execution of EXEC, EXECTIER, and SQL commands. If these
commands are recorded, when AutoPatch runs it does not run these commands
again. Doing this significantly improves the performance of database actions. By
default, this option is not selected, which means that AutoPatch will perform these
performance-improving actions.

Initiating a Patching Run 4-11


Specify Patch Options

4.4.4 OPatch Options (Database-Tier Only)


The following OPatch options are available for database-tier patching run requests:
Relink Updated Executables: This option is only selectable if the Relink All
Executables After Patching option in the Patching Procedure Options section is
disabled. It controls whether OPatch relinks any binary executables that were
updated by the patching run once all patches have been applied. The Relink All
Executables After Patching option controls whether the patching procedure
attempts to relink all binary executables in the Oracle home once all patches have
been applied.
There is no need for OPatch to relink just the binary executables updated by the
patching run if the patching procedure is going to attempt to relink all binary
executables in the Oracle home anyway. Therefore, if one of the Relink All
Executables After Patching or Relink Updated Executables options is selected, the
other one will be grayed out and unselectable; you must unselect one first before
you can select the other one. By default, the Relink Updated Executables option is
enabled, meaning that the patching procedure will not attempt to relink all binary
executables in the Oracle home once all patches have been applied, but OPatch
will relink any binary executables that were updated by the patching run once all
patches have been applied.
Force Apply Patch: Controls what OPatch does if it discovers a conflict between
one or more patches that have already been applied to the database tier, and one
or more patches to be applied during the patching run. OPatch can either forcibly
resolve the conflict by removing each existing conflicting patch from the database
tier and then proceeding to apply each patch selected for the patching run, or
passively report the conflict in the log file and return failure without removing or
applying any patches. By default, this option is disabled, meaning that OPatch will
passively report the conflict in the log file and return failure without removing or
applying any patches.
Verbose Output: Controls whether OPatch displays additional information in its
log file. By default, this option is enabled, meaning that OPatch will display
additional information in its log file.

4.4.5 AD Administration Options (Application-Tier and CPU Patching Only)


The following options correspond to AD Administration tasks that are commonly
performed after applying certain patches. If one or more of these options are selected,
the patching procedure will run AD Administration after all patches in the patching
run have been applied by AutoPatch, and instruct it to perform the corresponding
tasks. By default, none of the following options are selected:
Generate Message Files: Generates the binary message files for all products,
based on message data stored in the database instance.
Compile Menu Information: Compiles menu data structures in the database
instance.
Re-create Grants and Synonyms for APPS Schema: Re-creates required grants
and synonyms for the public APPLSYSPUB schema, re-creates required grants on
certain packages from the SYSTEM schema to the APPS schema, and re-creates
required grants and synonyms linking sequences and tables in the base schemas to
the APPS schema.
Compile APPS Schema: Attempts to compile every invalid database object owned
by the APPS schema.

4-12 Oracle Change Management Application User's Guide


Specify Patch Options

Compile Flexfields: Compiles flexfield data structures in the database instance.

4.4.6 HR Global Options


The HR Global Options are used to upgrade human resource (HR) policies on systems
running Oracle E-Business Suite (Apps and CPU only).
To upgrade HR policies:
1. Select Run HR Global Driver.

Note: You must run DataInstall before applying the hrglobal.drv


driver.

2. Select the type of data installation to perform:


Automatically install global and United States localization data only
Automatically install global, United States, and other installed localization
data
Pause to allow user to run DataInstall manually

Note: If you choose to run DataInstall manually, the patching run


will pause at the Manual DataInstall step to enable you to run
DataInstall. You must resume the patching run after DataInstall has
successfully completed so that the patching run will apply the
hrglobal.drv driver. If you choose this option but do not run
DataInstall before resuming the patching run, the HRGlobal step will
fail.

3. If desired, select Install United States College Data and Install JIT/Geocode
Data.

Note: If you select Pause to allow user to run DataInstall manually,


the Install United States College Data and Install JIT/Geocode Data
options are disabled.

4.4.7 Reviewing the Patch List Table


On the Patch List page, review the information in the following columns of the Patch
List table:

Note: For CPU patches, the Patch List page is disabled.

Patch: Lists each patch number that was entered in the Patch Number List box of
the Patch List Options page.
Product: Displays the Oracle product name to which each patch belongs. If there is
a problem validating the patch with OracleMetaLink, then this column is empty.
Abstract: Displays the abstract of the bug on which each patch is based. If there is
a problem validating the patch with OracleMetaLink, then this column display
NOT FOUND.

Initiating a Patching Run 4-13


Specify Patch Options

Platform: Displays one of the following messages about the patch:


Generic Platform if the patch exists and is not specific to an operating
system.
The name of the operating system, for example Linux x86, if the patch is
specific to that operating system.
No Patches Found if the patch is not available for target systems operating
system, or if the patch number is not a valid Oracle product patch. In this
situation, the patching procedure will not automatically download the patch
ZIP file from OracleMetaLink. In this case, you must manually copy the patch
ZIP file to the location specified in the Patch Directory Location box on the
Patch List Options page before the patching run begins.
Languages (Application-tier patching run request only): Displays the availability
status of translated versions of the patch for each NLS language that was selected
on the Patch List Options page. The short name of each NLS language is
displayed, followed by one of the following statuses:

Note: US followed by one of the listed statuses is always displayed


at the end of the list, indicating that the base American English
version of each patch will be applied if it is available. If no NLS
languages were selected in the Patch List Options page, then this
column displays only US followed by the availability status.

Available if the patch is available for download to the general public in that
language
Obsoleted if the patch has been obsoleted and replaced by another patch
Not found if the patch is not available for download to the general public in
that language, is not a valid EBSO application tier product patch, or if there is
a problem validating the patch with MetaLink.

Note: The Product, Abstract, Platform, Password, Languages, and


Readme columns are entirely dependent on information from
OracleMetaLink. If the CMA is unable to establish a connection with
OracleMetaLink, these columns will not display useful information.
However, the information on this page is for review purposes only
and is not required to successfully define a patching run request or for
the patching procedure to successfully apply patches.

Readme: Click the hyperlinked Readme file name to open the Readme file.
Password: If the patch is password protected and you want CMA to download the
patch, enter the correct password for the product and code version running on the
target instance. You will also see an alert that the patch may be password
protected. Passwords are entered in clear text.
Patch Application Order: You can change the patch application order by entering
the new order in this box. This capability is not available if you have chosen to
merge patches.
Reapply, Pause, or Preinstall Patch: Check the patch checkbox to specify
reapplication of the patch, a pause after the patch, and preinstall mode.
Delete Patch: Click the Delete icon to delete the patch.

4-14 Oracle Change Management Application User's Guide


Review Patching Run Information

4.5 Specifying Hosted Servers Password


To specify the hosted servers password role:
1. On the Credentials and Assignment page in the Password box, enter your
operating system password.
This is the password that will be used to submit the patching procedure. Your
Oracle global user ID is automatically populated in the Username box. When you
click Next, a dialog box appears given you the option to validate your password.

Note: If you do not enter the correct password, the patching run will
fail.

2. Click Yes to validate your password or click Skip this Step to continue without
validation.
3. If the validation fails, you click the link to the EM Console to correct your
credentials.

Note: You cannot proceed unless you select this box.

4. For Database upgrade patch types, select the Oracle Database release number that
you want to upgrade to.
If you select 11.1.0.7, you will perform and Database Upgrade. If you select
10.2.0.4, you will perform a Database Patchset Upgrade.

Note: To upgrade to Oracle Database 11.1.0.7 your instance must


have Oracle Database release 10.2.0.x and Applications release
11.5.10.2 or 12.0.4.
To upgrade to Oracle Database release 10.2.0.4, your system must
have Oracle Database release 10.2.0.1, 10.2.0.2, or 10.2.0.3 and
Applications release 11.5.9, 11.5.10.2, or 12.0.4.

5. Click Next.
The Review page appears.

4.6 Review Patching Run Information


The following sections describe how to review the patching run information.

4.6.1 Reviewing the Patch Readme File


The Readme column displays a page icon for each patch number that is a valid Oracle
product patch and is available for download to the general public from
OracleMetaLink. Click the icon to open the patch readme file in a separate browser
window.

Initiating a Patching Run 4-15


Review Patching Run Information

Note: This column is empty if OracleMetaLink was unable to validate


the patch, if the patch has been obsoleted, or if the patch is not
available to the general public.

4.6.2 Changing the Patch Application Order


The Patch Application Order column lists the order that the patching procedure will
apply the patches. The default order of the patches is determined by the order that the
patches were listed in the Patch Number List box on the Patch List Options page.

Note: this column does not appear in the table if the request is for an
application-tier patching run and you enabled the Merge Patches
option on the Patch List Options page.

To change the patch application order, review the following rules then edit the
numbers in the Patch Application Order column:
The field cannot be empty.
Any positive or negative integer, or zero, can be used.
Negative integers take precedence over zero and positive integers, just like the
concept of a number line in mathematics being read from left to right. For
example, -8 takes precedence over -4, which takes precedence over 0, which takes
precedence over 4, which takes precedence over 8, and so on.
The values do not have to be sequential. For example, you could use the values
-14, 0, and 8 to determine the application order of three patches.
Values may be duplicated. When two or more patches share the same Patch
Application Order value, those patches will be applied in a random order relative
to each other.
Duplicated values may be grouped. For example, if there are eight patches to be
applied, and their Patch Application Order values are 1, 2, 2, 2, 3, 3, 4, and 5, then
the patch with the value 1 will be applied first, followed by the three patches with
the value 2 applied in a random order, followed by the two patches with the value
3 applied in a random order, followed by the patch with the value 4, finally
followed by the patch with the value 5.
If you navigate back to the Patch List Options page, change the order in which the
patches are listed in the Patch Number List box, and then navigate to the Patch List
page, the order change will be reflected in the Patch Application Order column.

4.6.3 Reapplying and Pausing a Previously Applied Patch

Note: This section does not apply to DB_EBSO_Upgrade Apps


patches.

Select the box in the Okay To Reapply column to apply a patch that has already been
applied to the customer system. Doing this can be useful if you suspect that an applied
patch may not have been completely and successfully applied.

4-16 Oracle Change Management Application User's Guide


Review Patching Run Information

If the box in the Okay to Reapply column is not selected and the patch has already
been applied, the patching procedure will not re-apply the patch and the run will fail.
To pause the patch application after either AutoPatch (Apps run) or OPatch (DB run)
has performed the file copy and database actions of the patch, select the box in the
Pause After Applying column.
Pausing a patch application will enable you to perform manual tasks. These tasks may
be tasks required by the patch after a patch has been applied or system maintenance
tasks required immediately after certain patches are applied.
After the manual tasks have been performed, the patching run can be continued at the
point it left off.

Note: If a patch has been previously applied to the selected instance,


the OK To Reapply box is checked and cannot be unchecked. You can
click Delete to remove the patch from the list.

4.6.4 Selecting Preinstall Mode

Note: This section does not apply to DB_EBSO_Upgrade or DBMS


patches.

Preinstall Mode is an AdPatch option. Select Preinstall Mode to apply the patch before
running AutoInstall if the patch includes files for AutoInstall or another utility called
by AutoInstall.

4.6.5 Deleting a Patch


To remove the patch from the list of patches to be applied during the patching run,
click the Trash icon in the Delete column.

Note: Deleting a patch from the patching run does not delete
anything about the patch from the file system, for example, the patch
ZIP file.

4.6.6 Recovering a Deleted Patch


To recover a deleted patch before the patching run request has been submitted and
before you have left the Patch List page, do one of the following:
Click Back to return to the Patch List Options page:
The patch once again appears on this page
Click Cancel to cancel the patching run request.

4.6.7 Specify Operating System Password


To specify your operating system password:
1. On the Patch List Page, click Next.
The View & Assignment page appears and your Oracle global user ID is
automatically populated in the Username box.

Initiating a Patching Run 4-17


Review Patching Run Information

2. In the Password box, enter your operating system password.


This is the password that will be used to submit the patching procedure.
3. Click Next.
The Review page appears.

4.6.8 Change, Cancel, or Submit a Patching Run Request


To change, cancel, or submit a patching run request, review the patching run request
information on the Review page, then do one of the following:
To make a change to the patching run request, click Back.
To cancel the patching run request, click Cancel or click the Dashboard
breadcrumb in the top left corner. The patching run request is cancelled and the
Dashboard page appears.
To submit the patching run request, click Submit. A list of previously scheduled
change executions for the specified RFC ID may appear. To proceed with the
submission, click Yes. If you click No, the patch is not submitted.

Note: If the CMA cannot confirm the host login password, you
cannot submit the patch run. In this case, a red circle appears next to
the Credentials page in the summary on the left of the screen.

4-18 Oracle Change Management Application User's Guide


5
Initiating a Refresh Run

This chapter describes how to use the Change Management Application (CMA) to
imitate a refresh run. It includes the following sections:
Specifying the RFC ID or Customer Name
Specifying Refresh Type
Specifying Customer, Target, and Source Instances
Specifying Hosted Servers Password and PowerBroker Role
Specifying Backup Options and Advanced Settings
Changing, Cancelling, or Submitting a Refresh Run
Retrying Failed Steps

5.1 Specifying the RFC ID or Customer Name


To specify the Request for Change (RFC) or customer name for this refresh run:
1. Log in to the CMA at the following URL:
https://refresh-cmportal.oraclecorp.com/cmportal//

2. Click the Actions menu, then click Initiate Refresh.


3. On the Identifying the Refresh page:
a. Click the RFC ID menu, then select either RFC ID or Customer Name to
specify the search type.
b. Enter the appropriate value in the Search box.
If you selected RFC ID, enter the complete, valid RFC ID number of the RFC
that is associated with the refresh run request.
If you selected Customer Name, enter the name of the company or entity that
owns the customer system to be refreshed.
You may enter any part of the customer name, including multiple strings
separated by the % wildcard character, and the portal will search for all
customer names that include each string that you entered. If you omit the %
character between two or more strings and just use a space to separate them,
the portal will insert the % character into each space. The case of the values
you enter is not important.

Initiating a Refresh Run 5-1


Specifying Refresh Type

Note:
1. Search by Customer Name to display a list of customers that
match your search criteria.
2. Select a customer from the Customer List, then select a target
instance from the Target Instance list.
3. Enter the RFC ID.
A list of previously scheduled change executions for the specified
RFC ID may appear.
4. Click Yes to proceed with the refresh run request.
The CMA validates the RFC ID with the selected customer and target. If
the RFC ID does not pass validation a warning or an error message
appears. Warning messages are red and error messages are blue. If you
receive an error message, you cannot proceed with the selected RFC ID. If
you receive a warning message, you may proceed with the refresh

c. Click Search. All refresh requests meeting these criteria are displayed.

Note: CMA validates the RFC during this search.


A list of previously initiated change executions for the specified RFC
ID or Customer Name is displayed.
If the RFC ID is for a production target instance or if you selected a
production target instance from the Target Instance list, you will see a
warning. Click OK to confirm that you want to refresh the selected
production instance.

d. When prompted if you want to proceed, click Yes.


e. Click Next. The Configuration page appears.
4. On the Configuration page, click Yes to proceed with the refresh run request.
If you searched by customer name, a list of customers that match the search
criteria appears in the Customer List section.
5. If desired, click Collect New Snapshot Data to trigger a snapshot of your system,
then click Next.
6. On the Instance Configuration page, review the information on the page if desired,
then click Next.

Note: The information on Instance Configuration page comes from


the configuration file for that target. Verify that the Configuration File
Name and Configuration File Checksum are the same files listed by
the file system.

5.2 Specifying Refresh Type


Select Test DP from the Refresh Type menu to test the deployment procedure without
actually performing the refresh. Select Full DP to perform the refresh. Test DP is
selected by default. This applies if the search is done by customer name. This is not
available for the RFC ID search method.

5-2 Oracle Change Management Application User's Guide


Specifying Customer, Target, and Source Instances

5.3 Specifying Customer, Target, and Source Instances


Note: Only complete the tasks in this section if you searched by
customer name in the previous section.

When you search by customer name, a list of matching customer names appears in the
Customer List box:
1. Select a customer name in the Customer List box.
The CMA populates the Target Instances box with the target instances for the
selected customer.

Note: Only target instances that have at least one valid


corresponding source instance defined appear in the list.Target and
corresponding source instance names come from the eZ-Clone refresh
configuration files. This data is parsed and loaded into the VDB
database.

2. Select a target instance for the refresh run.


The CMA populates the Source Instance box with every valid corresponding
source instance that is defined for that target instance.

Note: The values in the Source Instance box change when a


different instance is selected in the Target Instance box.

3. Select an instance in the Source Instance box.


Oracle Enterprise Manager verifies the source and target mapping and displays
the results in the Source and Target Mapping area.
4. If necessary, in the RFC ID box, enter the complete, valid RFC ID of the RFC that is
associated with the refresh run request. A list of previously scheduled change
executions for the specified RFC ID appears. Click Yes to proceed with the refresh
run request.

Note: The CMA will not initiate the refresh run request without a
valid RFC ID. If there are issues with the Orion connection, the CMA
will allow the user to proceed if the user has used the customer search.

5. On the same page, confirm the following information:


R&R Customer:
Yes - for Restore & Refresh refreshes.
No for other refreshes.

Note: If this value is incorrect, click Change, then select the correct
value.

Initiating a Refresh Run 5-3


Specifying Hosted Servers Password and PowerBroker Role

Source and Target Mapping: Successfully verified in EM grid control.


Configuration Files: Configuration files validated.
Latest Backup Date: Displays the latest backup date for the source instance
specified earlier.
For regular refreshes: To collect new information about existing snapshots, click
Collect new backup data. You will be redirected to an external system to
initiate snapshot collection. Follow the prompts.
For R&R refreshes: To request a new backup of the source instance, click Collect
new backup data. When prompted, enter email addresses to be notified when
the backup is completed, then click Submit. You will receive an email
confirming that the backup is complete.
Click Next.
The Configuration page appears.
6. On the Configuration page, review the information if desired, then click Next.

Note: The information on Instance Configuration page comes from


the configuration file for that target. Verify that the Configuration File
Name and Configuration File Checksum are the same files listed by
the file system.

The Credentials and Assignment page appears.

5.4 Specifying Hosted Servers Password and PowerBroker Role


To specify the hosted servers password and PowerBroker role:
1. On the Credentials & Assignment page in the Password box in the Credentials
area, enter your operating system password.
This is the password that will be used to submit the patching procedure. Your
Oracle global user ID is automatically populated in the Username box.

Note: If you do not enter the correct password, you will not be able
to submit the refresh run.

2. From the Role list, select one of the following PowerBroker roles to be used during
the refresh run:

Note: The default role is SA.

OHSDBA
OHSCC
PRODSUPP
Click Next.

5-4 Oracle Change Management Application User's Guide


Specifying Backup Options and Advanced Settings

3. If the password you entered is valid, you will be prompted to validate your EM
Host Level Credentials. Click Yes.
4. If the following message is selected on the page, click the link displayed in the
message, then enter your EM user name and password to initialize the EMCLI
Client:
Invalid EM Host Level Preferred Credentials...

Note: If you choose to initialize the EMCLI client manually, complete


the steps in the "Initializing the Enterprise Manager Command Line
Interface Client Manually" section on page B-1:

Then click Re-validate.


5. Confirm that the Change Execution Assignment area displays assignment to the
username from the Credentials area.
Click Next.
The Settings page appears.

5.5 Specifying Backup Options and Advanced Settings


On the Backup Options page, select the appropriate type of backup:
Snapshot Backup or RMAN Backup, for regular refreshes, described in Backup
Options for Regular Refreshes.
Replicas, for Restore & Refresh (R&R) refreshes, described in Backup Options for
Refresh and Restore Refreshes.

Backup Options for Regular Refreshes


If you select Snapshot Backup:
1. Select a snapshot date.
When you select a snapshot date, a list of the On Demand snapshot-related
parameters appears. Each parameter represents the filesystem snapshot that will
be used for refresh for both the tech stack and database files.'
2. Click the edit icon next to each parameter to edit the snapshot parameters as
required:
If desired, select Non-Standard to display a list of snapshots that do not
conform to the standard naming convention.

Note: A standard snapshot contains the creation date in the file name
in the format YYYYMMDD. Snapshots that do contain the creation
date in this format are non-standard snapshots.

Click Reset to Default to reset to the default snapshot.


3. If your RFC ID is for a RAC instance, select a snapshot for each mount point in the
Oradata file.

Initiating a Refresh Run 5-5


Specifying Backup Options and Advanced Settings

Note: The CMA now supports RAC instances. If your RFC ID is for a
RAC instance, the RAC mount points are listed for the Oradata file.
Each mount point can have more than one snapshot. Select the
snapshot that you want to refresh.

4. Specify whether to use a cold database backup.


5. Select the Powerbroker policy.
6. Click the Advanced Settings link.
7. Change the following settings, as required:
Target database log_archive_dest directory
Temporary directory for refresh scripts
Target init.ora file
Clone type: ondemand_at_oracle or rapid_clone
Blackout Target Instance on Production OMS
Perform a split after flexclone

Note: This option is only enabled if the Copy files from source
oradata volumes to target oradata option is set to Yes in the Setting
tab.
Specify whether a split should be performed after the target database
volumes are copied from the source system using the NetApp
Flexclone feature. This option applies only if it is possible to perform a
Flexclone copy.

Target Port Pool


To use a password other than the default Workflow Mailer password, enter the
preferred password in the Post-refresh Steps area. This step is optional.
If you select RMAN Backup:
1. Specify the database backup directory.
2. Indicate whether or not the CMA should perform the database backup and copy
in parallel.
3. Click the Advanced Settings link.
4. Change the following settings, as required:
Target database log_archive_dest directory
Temporary directory for refresh scripts
Target init.ora file
Clone type: ondemand_at_oracle or rapid_clone
Blackout Target Instance on Production OMS
Perform a split after flexclone

5-6 Oracle Change Management Application User's Guide


Changing, Cancelling, or Submitting a Refresh Run

Note: This option is only enabled if the Copy files from source
oradata volumes to target oradata option is set to Yes in the Setting
tab.
Specify whether a split should be performed after the target database
volumes are copied from the source system using the NetApp
Flexclone feature. This option applies only if it is possible to perform a
Flexclone copy.

Target Port Pool


To use a password other than the default Workflow Mailer password, enter the
preferred password in the Post-refresh Steps area. This step is optional.
When you have completed setting selections, click Next.

Backup Options for Refresh and Restore Refreshes


If you want to run an R&R refresh:
1. Click Please select..., then select a replica for the source instance.
To request a new backup of the source instance, click Collect new backup data.
When prompted, enter email addresses to be notified when the backup is
completed, then click Submit. You will receive an email confirming that the
backup is complete.
2. In the Additional Replica Settings area, configure these settings as required:
Cold Database Backup
PowerBroker Policy - select the username for this policy.
Create new volumes for target oradata mount points?
Copy files from source oradata volumes to target oradata volumes?
3. Click the Advanced Settings link.
4. Change the following Refresh settings, as required:
Target database log_archive_dest directory
Temporary directory for refresh scripts
Target init.ora file
Clone type: ondemand_at_oracle or rapid_clone
Blackout Target Instance on Production OMS
Target Port Pool
To use a password other than the default Workflow Mailer password, enter the
preferred password in the Post-refresh Steps area. This step is optional.
5. As described, click the Save Advanced Settings icon to save these settings and
display the full Backup Options page.
When you have completed setting selections, click Next.

5.6 Changing, Cancelling, or Submitting a Refresh Run


To change, cancel, or submit a refresh run request:

Initiating a Refresh Run 5-7


Retrying Failed Steps

1. When you have reviewed the refresh information on the Review and Submit page,
click Next.
The Refresh Request page appears.
2. Review the refresh run request information, then do one of the following:
To cancel the refresh run request, click Cancel. The refresh run request is
cancelled and the Dashboard page appears.
To make a change to the refresh run request, click Back.
To submit the refresh run request, click Submit. A list of previously scheduled
change executions for the specified RFC ID appears. To proceed with the
submission, click Yes. If you click No, the refresh is not submitted.

Note: If there are errors in the previous steps, the Submit button is
not available. A list of errors appears on the page as well as the step in
which the error occurred.

3. The Dashboard page appears and a message indicating the status of the refresh
run submission is displayed.
Most of the refresh procedure steps can be retried within the EM 10g Grid Control
console once the problem that caused the failure has been fixed. (Refer to
Appendix A and Appendix B of this document for troubleshooting information.)
The only exceptions are:

5.7 Retrying Failed Steps


You can retry most of the failed refresh procedure steps after the problem that caused
the failure has been fixed, with the following exceptions:
Initialize
Initialize Clone Runtime Data
Hot Clone: Back Up and Copy Database Parallel Method
If the refresh procedure fails in one of these steps, you must resubmit the refresh run.

5-8 Oracle Change Management Application User's Guide


A
Bugs and Enhancements

All bugs and enhancements related to the CMA and the Oracle Applications Patching
and Refresh Procedures must be logged against product ID 4319, SE EM Initiative.
The Bug/Enhancement Filing FAQ for Change Management's EM Initiative contains
information about the following topics:
Components to be selected
Subcomponents, where applicable, to be selected
Filing and closing templates
Subject formatting
Status handling
Formatted bug reports
This FAQ is available at the following URL:
https://sac.us.oracle.com/change-em/process/bug_enhancement_filing_faq.html

Bugs and Enhancements A-1


A-2 Oracle Change Management Application User's Guide
B
Troubleshooting

This appendix contains the following information about troubleshooting procedures:


Initializing the Enterprise Manager Command Line Interface Client Manually
Review Log Files
Create XML Files from Runtime Parameters

Initializing the Enterprise Manager Command Line Interface Client


Manually
The CMA uses the Enterprise Manager Command Line Interface (EM CLI) Client to
communicate with the EM Grid Control console which is where the EM Grid Control
deployment procedures that process the patching run requests are located. These
specific deployment procedures are known as the Oracle Applications Patching
Procedures. Before you can initiate a patching run request, you must provide the EM
CLI Client with the location of the EM Grid Control console as well as your EM Grid
Control which authorizes the CMA to submit patching run requests to the patching
procedures in the EM Grid Control console under your name. You only need to
perform the following tasks once:
1. Log in to one of the following CMA environment with your personal credentials.
For patching runs, log in to the following nodes:
adcinf-ebso-upgrd-set2-03.oracle.com

For refresh runs, log in to the following node:


adcinf-ebso-upgrd-set2-02.oracle.com

2. Change directory to the EM Grid Control console home directory:


For patching runs, the EM Grid Control console home directory is
/posa3o/em/oms10g.
For refresh runs, the EM Grid Control console home directory is
/tosa3o/em/oms10g.
3. Enter the following to set the EM Grid Control console environment:
$ . ./oms.env
4. To check if the EM CLI Client has already been initialized, run the EM CLI utility:
$ emcli setup

You must complete the remaining steps if the output of this command displays:

Troubleshooting B-1
Review Log Files

The statement No current OMS.


An EM Grid Control console other than the EM Grid Control console you
want to use.
Currently, the URL for the EM Grid Control console for patching runs is
http://odem1.oracle.com/em/.
Currently, the URL for the EM Grid Control console for refresh runs is
https://sacoms.oracle.com/em/.
If the EM CLI Client has already been initialized with the EM Grid Control
console and your credentials, the preceding command should display the
following:
Oracle Enterprise Manager 10g Release 10.2.0.0.0.
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.

OS User Name : /home/{username}/.emcli


OMS : {EM Grid Control console URL}
EM USER : {username}
TRUST ALL : false.

Otherwise, the EM CLI Client has already been initialized with the EM Grid
Control console and your credentials, and you can stop here.
5. If the EM CLI has not been initialized, use the EM CLI utility to initialize the EM
CLI Client with the EM Grid Control console location and your EM Grid Control
credentials. The following example shows how to initialize the current EM Grid
Control console, where CONSOLE_URL is either the patching run or refresh runs
EM Grid Control console, username is your EM Grid Control username and
password is your EM Grid Control password:
$ emcli setup -url="CONSOLE_URL" -
username="username" -password="password"

For example:
To run the EM CLI utility for patching runs:
$ emcli setup -url="http://odem1.oracle.com/em/" -
username="jeff.lunn" -password="welcome"

To run the EM CLI utility for refresh runs:


$ emcli setup -url="https://emsac.oracle.com:1159/em" -
username="jeff.lunn" -password="welcome"

Review Log Files


The log files that are generated by the refresh procedure steps during a refresh run
contain useful information about refresh fails. Review these files in the following
directory on the OMS node:
OMS home/sysman/log/pafLogs

The files have the following format:


Refresh run name truncated to 14 characters_instance GUID.log
For example, if the refresh run name is QTESTI_to_TTESTI, the step log file names
are similar to the following:

B-2 Oracle Change Management Application User's Guide


Create XML Files from Runtime Parameters

QTESTI_to_TTES_4DED2ABD1AB1354AE040940AE32F20E5.log
QTESTI_to_TTES_4DED2ABD1AC2354AE040940AE32F20E5.log
QTESTI_to_TTES_4DED2ABD1AD3354AE040940AE32F20E5.log

Create XML Files from Runtime Parameters


The Enterprise Manager Command Line Interface (EM CLI) and the Provisioning
Advisor Framework (PAF) can be used on the OMS node to create XML files that list
every runtime parameter and corresponding value that were used during a given
refresh run, including information that can be difficult or impossible to determine
from the configuration file or runtime XML file.
For example:
The V_CUST_TGT_DB_PARAM_FILES parameter is set to the location of the
backed-up database initialization parameter (initSID.ora) file that is used to start
the target database instance. You can create an XML file to find out if the target
database instance failed to start after the refresh.
To create the XML files:
1. In the EM 10g Grid Control console, navigate to the Procedure Completion Status
tab of the Deployment Procedure Manager page, and in the Run column, click the
name of the refresh run you wish to analyze.
The Status page appears.
2. On the Status page, copy the instanceGUID of this refresh run from the very end of
the URL in the URL field of your browser. The instanceGUID is e a long series of
alphanumeric characters immediately following the phrase "instanceGUID=". The
following URL is an example, with the instanceGUID value that you need to copy
in bold:
http://appslab121.us.oracle.com:4889/em/console/paf/procedureStatus?instanceGUI
D=50E9189CB94A2C7EE040940AD32F43A0

3. Log in to the OMS node as the owner of the OMS file system.
4. Change directories to the OMS home, for example:
$ cd /emsac/EM10203/oms10g

5. Set the OMS environment as follows:


$ ./oms.env

6. Change directories to the directory where you want to create the XML files.
7. Enter the following command to use the EM CLI utility to create a temporary
output text file consisting of a single, huge, unformatted line:
$ emcli get_instance_data_xml -instance="instanceGUID" > "temporary output
file"

For example:
$ emcli get_instance_data_xml -instance="50E9189CB94A2C7EE040940AD32F43A0" >
"QTESTI_to_TTESTI_dump.tmp"

Troubleshooting B-3
Create XML Files from Runtime Parameters

8. Use the pafUtil.sh utility to create the second XML file:


$ $ORACLE_HOME/refresh/2.8/bin/pafUtil.sh -getRuntimeData fully_qualified_OMR_
host_name OMR_db _listener_port OMR_SID sysman SYSMAN_schema_password
instanceGUID

For example:
$ $ORACLE_HOME/refresh/2.8/bin/pafUtil.sh -getRuntimeData emsac.oracle.com 1521
emrep sysman oracle 50E9189CB94A2C7EE040940AD32F43A0

This second XML file is created in the current directory, with the name
RuntimeDatarandom_number.xml. For example:
RuntimeData6747.xml

9. Rename the RuntimeDatarandom_number.xml file to be consistent with the


first XML file that you created. For example:
$ mv RuntimeData6747.xml RuntimeData_QTESTI_to_TTESTI.xml

10. Review the two XML files with a text editor to see all the runtime parameter
values used during the refresh run.

APPS Password Example


To determine the unencrypted APPS schema password of the target database instance
from the RuntimeData XML file:
1. Look for the following line in the RuntimeData XML file:
<scalar value="encrypted_password"
classname="oracle.sysman.pp.paf.impl.EncryptedString" name="V_TGT_APPS_DB_
PWD"/>

For example:
<scalar value="643D60B75FC6AF9EE040558C0EAD57E0"
classname="oracle.sysman.pp.paf.impl.EncryptedString" name="V_TGT_APPS_DB_
PWD"/>

2. Copy the encrypted password value into a buffer.


3. Use SQL*Plus to connect to the OMR as the SYSMAN schema, as follows:
$ sqlplus sysman/SYSMAN_schema_password

4. Perform the following query:


SQL> select decrypt(encrypted)
2 from mgmt_paf_encrypted_strings
3 where str_guid=('<encrypted password>');

DECRYPT(ENCRYPTED)
----------------------------------------------------------------------------
apps

B-4 Oracle Change Management Application User's Guide


C
Refresh Procedure Step Details

For a list of each step in the refresh procedure, including a brief description of the step,
the file names that are relevant to the step, the technical details of what the step does,
and useful troubleshooting information about the step, see the EM Refresh Job Steps
page on the SAC Wiki:
http://sacwiki.us.oracle.com/wiki/index.php/EM_Refresh_Job_
Steps#Initialize_.28Computational_Step.29

Refresh Procedure Step Details C-1


C-2 Oracle Change Management Application User's Guide
D
Conditional Patching Procedure Behavior

The patching procedures require additional user interaction in certain situations,


described in this section.

Database Tier Patching Procedure


When the database tier patching procedure is used to patch an Oracle Real
Applications Cluster (RAC) instance, it pauses on each database server node before
applying any patches, to enable you to manually shut down the Cluster Manager
(oracm) processes on each node. This must be done before patches can be applied to
the Oracle home. The patching procedure will then pause again on each database
server node before starting up the database instance to enable you to manually restart
the Cluster Manager processes on each node. This must be done before the database
instance can be restarted.
The Stop the oracm Processes pause process works as follows:
1. When the Stop the oracm Processes step of the patching procedure (which comes
just before the Upgrade Opatch step) returns an Action Required status, the
patching procedure pauses until action is taken and confirmed and the status
changes to Action Required on Steps tab of the Status Detail page.
2. In the Step Status page for that step, the Instruction field displays a message
instructing you manually shut down the Cluster Manager processes on that node
and the Elapsed Time field keeps a running count of how long the patching run
has been paused.
3. If desired, enter information about the Cluster Manager shutdown in the Note
field.
4. After you have shut down the Cluster Manager processes on each database server
node and you have entered any notes that you want recorded, select each
applicable target then click Confirm.
The patching procedure continues where it left off and upgrades OPatch to the
latest available version, if necessary.
The Start the oracm Processes pause process works as follows:
1. The Start the oracm Processes step of the patching procedure (which comes just
before the Start Up Database and Listener Services step) returns an Action
Required" status, the patching procedure pauses until action is taken and
confirmed and the status changes to Action Required on Steps tab of the Status
Detail page.
2. In the Step Status page for that step, the Instruction field displays a message
instructing you manually shut down the Cluster Manager processes on that node

Conditional Patching Procedure Behavior D-1


Database Tier Patching Procedure

and the Elapsed Time field keeps a running count of how long the patching run
has been paused.
3. If desired, enter information about the Cluster Manager shutdown in the Note
field.
4. After you restart the Cluster Manager processes on each database server node and
you have entered any notes that you want recorded, select each applicable target
the click Confirm. The patching procedure continues where it left off, starting up
the database instance and listener.

D-2 Oracle Change Management Application User's Guide