| Oracle® Fusion Applications Upgrade Guide 11g Release 7 (11.1.7) Part Number E35833-18 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Upgrade Guide 11g Release 7 (11.1.7) Part Number E35833-18 |
|
|
PDF · Mobi · ePub |
This chapter provides an introduction to the process of upgrading Oracle Fusion Applications to 11g Release 7 (11.1.7).
This chapter contains the following topics:
Upgrading to Oracle Fusion Applications 11g Release 7 (11.1.7) requires that you run Oracle Fusion Applications Upgrade Orchestrator (Upgrade Orchestrator) on an Oracle Fusion Applications environment. If you are upgrading to Release 7 from Release 5 (11.1.5), Upgrade Orchestrator manages this chained upgrade in two hops. The first hop is the upgrade from Release 5 to Release 6 (11.1.6). The second hop of the upgrade is from Release 6 to Release 7. Note that releases of Oracle Fusion Applications are referred to as Release 5, Release 6, and Release 7 for the remainder of this Upgrade Guide.
The upgrade process flow varies, depending on whether you are running Oracle Fusion Applications on an Oracle VM environment. The following diagram depicts the upgrade process flow for non-Oracle VM environments.
The following diagram depicts the upgrade process flow for Oracle VM environments.
For more information about the tools and utilities called by Upgrade Orchestrator, see Appendix A, "Additional Information About Upgrade Orchestrator".
You must complete all pre-upgrade tasks before you start Upgrade Orchestrator. For more information, see Chapter 2, "Preparing to Perform the Release 7 Upgrade". You must also update your database during a separate downtime window prior to the upgrade. For more information, see Chapter 3, "Updating the Oracle Fusion Applications and Oracle Identity Management Databases." After you upgrade by following the steps in Chapter 4, "Upgrading to Oracle Fusion Applications Release 7," you must complete the post-upgrade tasks. For more information, see Chapter 5, "Post-Upgrade Tasks for Oracle Fusion Applications".
Familiarize yourself with the information in this section before proceeding with the upgrade.
The Release 7 upgrade must be performed on the following host types:
Primordial host: The location of the Common domain (specifically the Administration Server of the Common domain). Only one primordial host exists in each environment.
IDM host: A combination of hosts which hosts OID, OIM, OAM,IDM OHS, and IDM Database services.
OHS host: The host where the Oracle HTTP Server (OHS) software is installed and configured.
DB host: The host where the Oracle Fusion Applications database is installed and configured.
Midtier hosts:
Primary host: The host on which the Administration Server of a domain runs. Only one primary host exists in a domain.
Secondary host: The location where the Managed Servers for any application reside when they are not on the same host as the Administration Server of the same domain. The term, secondary host, is meaningful when a domain spans across more than one physical server. The server(s) that does (do) not have the administration server is (are) called secondary host(s).
BI host: The host where the Oracle Business Intelligence (Oracle BI) software is installed and configured.
Note that all of these host types can be scaled out to multiple hosts, and Upgrade Orchestrator must be run on each scaled out host for all host types, with the exception of DB hosts. For more information, see "Scaling Out Oracle HTTP Server" in the Oracle Fusion Applications Enterprise Deployment Guide for Customer Relationship Management.
The following directories and files are referenced in this guide and are required by Upgrade Orchestrator:
SHARED_LOCATION: You create this directory in a shared location, which is accessible to all hosts in the environment, including scaled out hosts. For more information, see Section 2.3.2, "Create Directories in a Shared Location".
ORCHESTRATION_CHECKPOINT_LOCATION and ORCHESTRATION_CHECKPOINT_ARCHIVE_LOCATION: You create these directories in the SHARED_LOCATION, where orchestration checkpoint related files are saved. For more information, see Section 2.3.3.1, "Orchestration Checkpoint Locations". These directory locations are stored as properties in the pod.properties file. For more information, see Table B-1, "pod.properties".
SHARED_UPGRADE_LOCATION: You create this temporary directory to copy files and perform write operations. For more information, see Section 2.3.3.2, "Shared Upgrade Location".
ORCH_LOCATION: This directory is created when you unzip orchestration.zip and is referred to as the orchestration directory. For more information, see Section 2.3.7, "Unzip Orchestration.zip".
POD_NAME: You can create this directory under ORCH_LOCATION. The name of the directory created is referred to as POD_NAME throughout this guide.
Manifest files: These files are .xml type distribution files that are required by both Health Checker and Upgrade Orchestrator. They are used throughout this guide to define specific tasks performed during the upgrade process.
Upgrade Orchestrator includes the following features:
You run Upgrade Orchestrator on all host types except for the DB host. The upgrade is performed in phases, during which sets of tasks run. Upgrade Orchestrator waits to ensure that the current set of tasks run to successful completion on all hosts before proceeding to the next set of tasks. If there is a participating host which is not reporting its status, an email alert is sent with corrective action.
Upgrade Orchestrator performs the upgrade in two primary phases:
Pre-Down Time: Upgrade Orchestrator provides the option to run pre-down time steps using the command line option, -phase PreDowntime, allowing you run some steps before your down time. This phase can be run at any time prior to your upgrade maintenance window and can be run any number of times, until all validations and health checks are successful. Issues reported by the tools during this phase can be fixed ahead of time, before entering the maintenance window.
For more information on the steps that are included in the PreDowntime phase and how to run this phase of the upgrade, see Section 4.1.1, "Run Upgrade Orchestrator in Pre-Down Time Mode".
Down Time: This phase is executed during the maintenance window. Upgrade Orchestrator exits and pauses during this phase to allow you to perform required tasks outside of orchestration, after which you must relaunch orchestration on one or more hosts to resume the upgrade.
Upgrade Orchestrator pauses when it reaches a task that must be performed outside of orchestration. You perform the required steps and then direct Upgrade Orchestrator to continue with the upgrade. If multiple environments are sharing the orchestration software location, a pause point that is created on a host type is common across all environments for that host type.
Default pause points are predefined by Upgrade Orchestrator to allow you to perform the following actions:
Perform required backups
Upgrade the Oracle Identity Management domain
Run RUP Lite for OVM in pre- and post-root modes
Start external servers
You cannot edit or remove default pause points. For more information, see Section 4.4, "Pause Point Steps".
Orchestration uses the properties defined in five properties files: pod.properties, PRIMORDIAL.properties, OHS.properties, MIDTIER.properties, and IDM.properties. The properties are set to specific values as part of your preparation to begin the upgrade. For more information, see Appendix B, "Upgrade Orchestrator Properties Files".
The Oracle Fusion Applications Upgrade Orchestrator report is generated for each pod and its location is defined in the mandatory ORCH_REPORT_LOCATION property in the pod.properties file. When you run the report, you can override the default value for the location, if needed. In the event of a failure during the upgrade, this report is generated and emailed to the user who is running the upgrade. The report name is FAOrchestrationUpgradeReport_release_hosttype_hostname_timestamp.html. Reports are archived at ORCH_LOCATION/ARCHIVE/release/hosttype/hostname/timestamp for troubleshooting purposes after the failure or completion of each task.
The report displays the task that failed, including the phase and host type. This report also displays the following information:
Upgrade from Release: The starting release on the pod, which is either release 11.1.5.0.0 or release 11.1.6.0.0.
Upgrade to Release: The ending release, which in this case is "FA version 11.1.7.0.0".
Upgrade Status: The cumulative status of the upgrade. The following states are possible:
Success: All tasks were successful.
Error: One or more tasks failed.
Running: At least one task is still running and there are no failures.
NotApplicable: The task is not applicable on the host.
Pending: A task is waiting for a dependent task to complete.
PausePoint: A task must be performed manually. Orchestrator needs to be restarted after the manual process completion.
Report Time: The time stamp in the format of yyyy-MM-dd HH:mm:ss.SSS.
Status Table: Contains the following columns:
Task: Tasks are listed in the order of execution.
Phase: Phase during which the task runs.
Host type: Host type on which the task runs.
HostNames: All scaled out hosts for the host type.
Status: Status of the task for each host, including scaled out hosts.
Start Time: The start time for the task on a specific host.
End Time: The end time for the task on a specific host.
Duration: The duration of the task on a specific host.
More details: The path and file name for the HTML report that is generated on each host.
Upgrade Orchestrator runs the Health Checker utility to run system checks before, during, and after the upgrade to ensure that the environment meets recommended standards. For more information, see Section A.2.2, "Health Checker Utility."
If you previously installed any languages in addition to US English, Upgrade Orchestrator performs the upgrade of each installed language. For information about installing a new language, see "Installing and Maintaining Oracle Fusion Applications Languages" in the Oracle Fusion Applications Administrator's Guide.
Orchestration allows you to skip one or more installed language pack upgrades by using a property called SKIP_UPGRADE_FOR_LANGUAGE in the PRIMORDIAL.properties file. If you choose to skip any languages, you upgrade them manually after the completion of Upgrade Orchestration. For more information, see "Installing and Maintaining Oracle Fusion Applications Languages" in the Oracle Fusion Applications Administrator's Guide.
Before you start the upgrade process, you should have a clear understanding of the backup requirements, as there are multiple components involved in an Oracle Fusion Applications environment. An effective and accurate backup strategy helps to restore from the point of failure without having to restart from the beginning.
Note that backups are manual steps and can be automated outside of Upgrade Orchestrator based on your IT requirements and processes. For detailed information about required backups, see Section 4.4.1, "Back Up the OPSS Security Store" and Section 4.4.2, "Back Up Oracle Fusion Applications".
The following components must be backed up:
Oracle Fusion Applications, including:
Oracle Fusion Applications database
APPLICATIONS_BASE, as defined in Section 1.6.3, "Relationship of Home Directories"
APPLICATIONS_CONFIG, as defined in Section 1.6.3, "Relationship of Home Directories"
Oracle Identity Management database
Upgrade Orchestration directories
OHS and /etc/hosts files
Central Inventory
OPSS Security Store
You must back up your Oracle Fusion Applications upgrade at multiple stages during the upgrade process. It is recommended to back up your entire Oracle Fusion Applications environment, including your databases, at the following points:
Before the upgrade
Between the two hops, if you are performing a multi-hop upgrade
After the upgrade
Before the language pack upgrade starts, if you have languages installed
For additional backup steps that are specific to Windows, refer to Section 4.4.3, "Back Up Oracle Fusion Applications on a Windows Platform".
Upgrade Orchestrator provides default pause points to perform these backup steps, depending on your upgrade path. For more information, see Section 4.1.6, "Pause Point 2 - Back Up Oracle Fusion Applications".
Consider the following suggestions when planning your down time for the upgrade:
Perform pre-down time steps ahead of time. For more information, see Chapter 2, "Preparing to Perform the Release 7 Upgrade".
Perform your database patching in a separate maintenance window. For more information, see Chapter 3, "Updating the Oracle Fusion Applications and Oracle Identity Management Databases".
Run Upgrade Orchestrator in pre-down time mode after all prerequisites are met. For more information, see Section 4.1.1, "Run Upgrade Orchestrator in Pre-Down Time Mode".
Upgrade Orchestrator references and uses the following directories:
The following diagram shows the directory structure that is created when the Orchestration.zip file is unzipped and is referred to as ORCH_LOCATION. For more information, see Section 2.3.7, "Unzip Orchestration.zip".
The following diagram shows the directory structure that you create during the preparation of your environment for the upgrade. There are specific files that must be downloaded into each of these directories. For more information, see Section 2.3.2, "Create Directories in a Shared Location".
The following home directories are referenced during the upgrade steps:
APPLICATIONS_CONFIG: The top-level directory for the Oracle Fusion Applications configuration files.
APPLICATIONS_BASE: The top-level directory for the Oracle Fusion Applications binaries.
FA_ORACLE_HOME: The directory named applications, located under the Oracle Fusion Applications Middleware home fusionapps directory.
The following figure shows the relationship of the home directories using the Oracle Fusion Financials product family on a UNIX environment as an example. This figure does not show all subdirectories under APPLICATIONS_BASE and APPLICATIONS_CONFIG. For example, the APPLICATIONS_CONFIG directory contains several more directories for component-specific configuration files. Also, Oracle Database and Oracle Identity Management are not represented in this figure, as they are installed separately. For more information, see "Provisioned Oracle Fusion Applications Home Directories" in the Oracle Fusion Applications Administrator's Guide.
|
 Copyright © 2011, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
