Installing Release Update Patches - 11g Release 1 (11.1.2) (2024)

This chapter describes how to install release update patches in Oracle Fusion Applications.

5.1 Introduction to Oracle Fusion Applications Release Update Patches

This section provides an introduction to the following concepts related to release update patches:

Release Update Patches
RUP Installer
Oracle Fusion Applications Artifacts Supported by RUP Installer
RUP Installer Configuration Tasks

5.1.1 Release Update Patches

A release update patch (RUP) contains a large number of merged patches, changes the version of the product it is applied to, can sometimes introduce new functionality, and should be applied when suitable. A RUP is a set of cumulative patches and changes for the entire Oracle Fusion Applications Suite for a base release. You install RUPs with Release Update Patch (RUP) Installer.

5.1.2 RUP Installer

RUP Installer is a Java-based installer that enables you to install a group of patches across all product families, delivered as a RUP. When you install a RUP, you are essentially upgrading the version of Oracle Fusion Applications. RUP Installer can patch existing content and can also copy and deploy new artifacts, depending on the contents of the RUP. You run RUP Installer in interactive mode and proceed through the installation by providing information in the user interface when prompted.

RUP Installer provides the following features:

Prerequisite validation
Installation and copying of artifacts
Policy store analysis
Configuration and automated deployment of most artifacts
Ability to cancel and restart tasks
Logging

5.1.3 Oracle Fusion Applications Artifacts Supported by RUP Installer

RUP Installer supports the installation and automated deployment of most middleware and database artifacts used by Oracle Fusion Applications. Depending on the type of artifact included in the RUP, the artifact deployment may require manual actions. For more information about manual deployment of these artifacts, see Chapter 4, "Patching Oracle Fusion Applications Artifacts".

Table 5-1 provides a quick reference that depicts how RUP Installer supports the Oracle Fusion Applications artifacts that could be included in a RUP.

An explanation of the information presented in this table follows:

Automated Actions Performed by RUP Installer
RUP Installer always copies the artifacts from the RUP to the appropriate location on your system. This column describes additional actions that are performed automatically for each artifact.
Actions to Be Performed Manually
This column displays the actions you must perform when the RUP includes the specified artifact.

After you apply a RUP, review the Diagnostics report to find out which manual steps are required for the artifacts included in the RUP and where the artifacts were copied in FA_ORACLE_HOME. For more information, see Section 3.5.5, "Diagnostics Report". For more detailed information about manual actions for each artifact, refer to the relevant sections in Chapter 4, "Patching Oracle Fusion Applications Artifacts".

Table 5-1 Artifacts Supported by RUP Installer

Artifact Type	Automated Actions Performed by RUP Installer	Actions to Be Performed Manually
Applications Policies (`system-jazn-data.xml`)	Deploy changes	Back up the policy store before installation and choose the deployment method during configuration
Applications Database schema changes (SXML files)	Update database objects such as tables, triggers, views, sequences, synonyms, queues, queue tables, policies, and context	None
Applications Seed Data (XML,XLIFF files)	Upload seed data into your database	None
B2B Metadata	None	Deploy agreements to Common domain, see Section 4.3.1, "Manually Deploying Trading Partner Agreements"
Oracle Business Intelligence Publisher (Reports and Captions)	Deploy to the Business Intelligence repository using Catalog Manager, and start the BI Presentation server after patching	None
Oracle Business Process Management (Oracle BPM) Template	Publish template to the Oracle Metadata Service (MDS) repository	None
C Artifact	None	None
Common Resource (Activity Strings)	None	None
Data Security	Run the `DSDataMigrator` utility to reconcile GUID in LDAP	None
Flexfields	Deploy flexfields	None
Group Space Template	Deploy template	None
Java EE	Stop and start the relevant servers that host the Java EE application	None
Image Routing (IPM)	Deploy to IPM servers	None
Oracle Data Integrator (ODI	Import changes to the ODI repository	Drop work tables from FUSION_ODI_STAGE schema, see Section 4.14.1, "Dropping Work Tables After Patching in Online Mode"
Oracle Fusion Applications Help Content	None	Start the crawl after patching, see Section 5.3.3, "Completing the Post Installation Tasks"
Data Role (RGX) Template	Deploy the template to the Common domain	None
PL/SQL objects (pkh, pkb files)	Update package headers and bodies	None
SOA Composite	Deploy composite to SOA-INFRA Managed Servers	Preserve JDeveloper customizations, see Section 4.18.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch"
SOAEXTENSION	None	None
SOA Resource Bundle	Deploy resource bundle and restart all SOA-INFRA Managed Servers	Reset SOA-INFRA MBean property if resource bundle contains human task-mapped attribute labels and standard view names, see Section 4.20, "Patching SOA Resource Bundles"
SOA Shared Repository	Deploy to SOA-INFRA Managed Servers	None
SPE Inline Service	Deploy SPE files	None
SQL scripts	Update or create scripts that update the database	None

5.1.4 RUP Installer Configuration Tasks

During the installation phase, RUP Installer copies all of the files from the RUP to the appropriate location, such as Oracle Fusion Applications Oracle home. After the file copy is completed, RUP Installer starts the Policy Store Analysis, as described in Table 5-4. Then RUP Installer calls Configuration Assistant to perform the remaining tasks required to update and deploy the artifacts included in the RUP. Depending on the contents of the RUP, not all tasks are required by every RUP. If any tasks fail during the configuration phase, you can abort or retry the task. The options available for managing failed tasks and steps depends on whether the task is a mandatory task. For more information, see Section 5.4.3, "Error During the Configuration Phase".

A complete list of possible configuration tasks, including steps within the task, follows.

Configure Patch Manager (Mandatory task)
Bootstrap Patch Manager (Mandatory task)
Updates the data model for Oracle Fusion Applications Patch Manager by running the fapmgr bootstrap command.
Apply Middleware Patches (Mandatory task)
Applies patches that update Oracle Fusion Middleware objects. If one of the Middleware patches fails to apply, the Apply Middleware Patches task starts from the point of failure when you restart RUP Installer.
The following patches are supported by this configuration task:
- Applications Core objects, including those that must be applied by OPatch in addition to those that must be applied by Oracle Fusion Applications AutoPatch.
- Oracle Business Intelligence
- Oracle Common
- Oracle Data Integrator (ODI)
- Oracle Database Client
- Oracle Enterprise Content Management
- Oracle HTTP Server (OHS) - Note that this is the embedded OHS. OHS may also be installed in the DMZ. Patching OHS in the DMZ is a manual process not supported by RUP Installer.
- Oracle Secure Enterprise Search (SES)
- Oracle SOA Suite
- Oracle WebCenter Suite
- Oracle WebLogic Server
The following patches are not supported by this configuration task:
- Integrated Development Environment (IDE)
- OHS installed in the DMZ. For more information, refer to Oracle Fusion Applications release notes for information about mandatory OHS patches.
- Patching your Database Server. For more information, see Step 1 in Section 5.2.2, "Prerequisites".
- Patching your Oracle Identity Management Server. For more information, refer to Oracle Fusion Applications release notes for information about mandatory IDM patches.
Offline Preverification (Mandatory task)
Performs validation checks while all servers are shutdown. The following validation steps are performed during this task:
- Policy Store
- Database Content Upload
- Business Process Management (BPM) Template
- Oracle Data Integrator
Load Database Components (Mandatory task)
Deploy Applications Policies (jazn-data.xml) (Mandatory task)
Performs the deployment of the updated applications policies, based on your selections during the Policy Store Analysis task.
Deploy Data Security Grants (Mandatory task)
Deploy BPM Templates (Mandatory task)
Deploy BI Publisher Artifacts (Mandatory task)
The following steps occur during this task:
- Copy captions
- Deploy Webcat
Import Oracle Data Integrator Repository (Mandatory task)
Verify Node Manager and OPMN Status (Mandatory task)
This task checks for access to the Node Manager and the Oracle Process Manager and Notification Server (OPMN) control process, and should fail because you manually shut these processes down prior to starting RUP Installer. You must manually start both the Node Manager for all domains and the OPMN control process at this time. You must not exit out of RUP Installer during this task.
Start all servers
Starts all servers in all domains, including the BI servers.
Online Preverification (Mandatory task)
The following validation steps are performed during this task:
- Taxonomy URL
- Flexfield: Flexfield deployed managed server must be up
- LDAP Data (LDIF): Validates the policy store
- SOA Shared Repository: Verifies the taxonomy, checks if the Administration Server is up, and if the SOA platform is ready
- SOA Resource Bundle: Verifies the taxonomy, checks if the Administration Server is up, and if the SOA platform is ready
- SOA Composite: Performs the following validation steps:
  - Verifies the taxonomy
  - Checks if the Administration Server is up
  - Checks if the SOA platform is ready
  - Checks if the base composite is deployed
  - Checks if the default revision is deployed
  - Checks if the new revision is not deployed
  - Checks whether the SOA composites that will be affected by the patch have JDeveloper customizations. For more information, see Section 5.4.11, "JDeveloper Customizations Performed on SOA Composite".
- Image Routing (IPM): Checks if the IPM server is up
- B2B Metadata: Checks if the Common Domain SOA Managed Server and the LDAP Server are up
- SPE Inline Service: Checks if the Oracle CRM Performance application is deployed. If it is, the OracleRTD application must be deployed and at least one BI server must be running where the OracleRTD application is deployed.
- Data Role (RGX) Template: Checks if the Administration Server for the Common domain is up
- Group Space Template: Checks if the following Managed Servers are up: WC_Spaces, WC_Collaboration, ucm_server1
Apply BI Metadata Patches (Mandatory task)
Deploy Flexfields
Import Image Routing (IPM) Artifacts
Deploy B2B Metadata
Deploy SPE Inline Service Artifacts
Deploy Data Role (RGX) Templates
Import Group Space Templates
Deploy SOA Shared Repository Artifacts
Deploy SOA Composites
Deploy SOA Resource Bundles (Mandatory task)
See Also
E-Business Suite - Oracle FAQ Oracle ERP Cloud vs. Oracle EBS: Which is best?Oracle Phone Interview Questions How to Check the Version of Oracle E-Business Suite - orahow
Restart All SOA Servers

5.2 Preparing to Install a Release Update Patch

This section describes the following preparation steps for installing a RUP.

Downloading the RUP Repository
Prerequisites

5.2.1 Downloading the RUP Repository

The RUP repository contains RUP installer and Oracle Fusion Middleware patches that are required to install a release update patch in an existing Oracle Fusion Applications environment. You download the repository from the Oracle Fusion Applications Product Media Package to a location of your choice. This directory is referred to as REPOSITORY_LOCATION.

5.2.1.1 Obtaining the Software

Oracle groups its software releases by product area. A Product Media Pack refers to those groupings. Each media pack may also include a zipped file containing electronic documentation files or "Quick Install" files, which facilitate the initial installation of the software.

Once you have completed the software licensing agreements, you can obtain the Oracle Fusion Applications software using one of these two methods:

Oracle Software Delivery Cloud Portal: Provides you with a readme document that helps you to determine which media you need to fulfill the license you have purchased. You download only the media you need. This is the default delivery method.
Oracle Store: Provides a complete set of the software in DVD format. You use only the DVDs covered by your software licensing agreement.

Using either method, you can obtain the Oracle Fusion Applications RUP repository and gain access to the Oracle Fusion Applications documentation library.

5.2.1.2 Downloading from the Oracle Software Delivery Cloud Portal

Go to http://edelivery.oracle.com/ and follow these instructions:

Complete the Export Validation process by entering basic identification information using the online form.
On the Media Pack Search page, specify the product pack and platform to identify the media pack you want to download. If you do not know the name of the product pack, you can search for it using the license list.
Choose the appropriate media pack from the search results and download the Release Update Patch repository (in zipped format). You can download the repository to a location of your choice.
Extract the contents of all zipped files to the same target directory. The directory must be on a networked drive or shared disk so that it will be accessible to all the hosts in your new environment. The installers are normally located in the installers subdirectory under REPOSITORY_LOCATION.

Note:

You should avoid creating the repository in a deeply nested directory on Windows. The Windows PATH variable has a limited size, and long directory names may cause it to overflow. For example, c:\work\my_repository is a better choice than c:\Work\WorkInProgress\FusionApps\FusionAppsv1\Nov2011\tempfiles\my_repository.

5.2.1.3 Release Update Patch Installers

Table 5-2 lists the installers in the RUP repository.

Table 5-2 RUP Installers

Media Label Name Staging Destination

Media Label Name	Staging Destination
RUP Installer	(Unix) `REPOSITORY_LOCATION`/installers/fusionapps/`Disk1/runInstaller` (Windows) `REPOSITORY_LOCATION`\installers\fusionapps`\Disk1\setup.exe`

RUP Installer

(Unix) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller

(Windows) REPOSITORY_LOCATION\installers\fusionapps\Disk1\setup.exe

5.2.2 Prerequisites

Complete the following prerequisite steps before you install the RUP.

Back up your entire Oracle Fusion Applications environment by following the steps in "Backing Up and Recovering Oracle Fusion Applications" in the Oracle Fusion Applications Administrator's Guide. For additional back up steps that are specific to Windows, refer to Section 5.2.2.1, "Back Up Steps for Windows Platforms".
Refer to Oracle Fusion Applications release notes for mandatory prerequisite steps, including the application of all mandatory Oracle Database, Oracle Identity Management, and OHS in DMZ patches.
If you have Oracle Business Intelligence Applications installed and configured, refer to Oracle Fusion Applications release notes for information about mandatory patches that need to be applied before installing the RUP. For additional information about patching Oracle Business Intelligence Applications, see “Oracle BI Applications Patching” in the Oracle Fusion Middleware Reference Guide for Oracle Business Intelligence Applications.
Refer to Oracle Fusion Applications release notes for information about database tuning parameters, to avoid time out conditions during the installation.
Confirm that the open file limit is set properly.
RUP Installer uses multiple workers for uploading database content. The number of workers used dictates the open file limit setting for the machine where you run the RUP Installer. To understand how the number of the workers are calculated and the open file limit setting that is required for the workers, see Section 3.1.2, "Patching Database Artifacts".
Confirm that the SQL*Net Timeout Configuration is set properly.
RUP Installer is tested with a SQL*Net timeout value of 500 to avoid connection timeout issues during uploading of database content. The exact setting in your environment depends on your network configuration and machine resources. To determine the parameters that need to be set, see Section 11.5.8, "Resolving the Error, "Unable to start universal connection pool"".
Confirm registration of the network location of FA_ORACLE_HOME.
If Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), which is located under the APPLICATIONS_BASE/fusionapps directory, is registered in inventory with a /net path then provide the oraInst.loc location including /net while starting the RUP Installer.
Confirm that hardware and memory requirements are met on the primordial host that the RUP installer is launched from. The primordial host is where the Administration Server for the Common domain runs.
Running RUP installer is an administrative activity that requires all of the Administration Servers for the provisioned Oracle Fusion Applications domains to be up during the RUP installation. RUP Installer requires at least 6GB of free RAM on the 64-bit domains to be up during the installation. RUP installer also requires at least 6GB of free RAM on the 64-bit primordial host that the installer is launched from, for the duration of the RUP installation. This 6GB of free memory requirement is in addition to the memory requirement for all servers, including the Administration Servers on the primordial host that is already up and running. Oracle also recommends at least 1GB of additional free memory on the primordial host during the RUP installation as a safety net.
For example, if the BI domain is provisioned on the primordial host, then RUP Installer requires this 64-bit primordial host to have a minimum of 12GB of RAM. If you have two 64-bit hosts with the BI domain provisioned on a different host from the primordial host, then one host runs the Administration Server and the BI servers, while the other host runs RUP Installer, which requires a connection to the Administration Server that is running. If you run RUP installer and the Administration Server on the same primordial host with insufficient memory, then the Administration Server and Managed Servers may fail.

5.2.2.1 Back Up Steps for Windows Platforms

Back up the Oracle Fusion Applications environment, including APPLICATIONS_BASE, inventory, registry entries, Oracle Identity Management, the database and the System environment PATH variable of the Oracle Fusion Applications host machine.

APPLICATIONS_BASE has many files whose path is more than 256 characters. The Microsoft Windows Copy function is limited to copying only those files with a path of less than 256 characters. Therefore, many files fail to copy.
Use Robust File Copy (Robocopy), which is available as part of the Windows Resource Kit, to copy the APPLICATIONS_BASE. Use the following command:
```
robocopy <source> <destination> /MIR > <file>
```
Sample output from the robocopy command:
Total Copied Skipped Mismatch FAILED Extras
Dirs:
112640
112640
Files:
787114
787114
Bytes:
63.822 g
63.822 g
Times:
2:22:20
2:19:00
0:00:00
0:03:19
Back up inventory.
Back up the inventory location referenced in the registry HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\inst_loc.
Back up the registry.
Use Regedit.exe to back up the following registries related to Oracle Fusion Applications.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
webtier service
BI Service
Nodemanager service
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Oblix

	Total	Copied	FAILED	Extras
Dirs:	112640	112640
Files:	787114	787114
Bytes:	63.822 g	63.822 g
Times:	2:22:20	2:19:00	0:00:00	0:03:19

Save the system PATH variable. An example of the PATH variable for an Oracle Fusion Applications host follows.

PATH=C:\AT\dbclient\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\MKSNT;c:\Program Files\Winzip;C:\ADE\BIN;C:\ADE\packages\ntreskit;C:\AT\webtier_mwhome\webtier\bin;C:\AT\webtier_mwhome\webtier\opmn\bin;C:\AT\webtier_mwhome\webtier\opmn\lib;C:\AT\webtier_mwhome\webtier\perl\bin;C:\AT\fusionapps\bi\products\Essbase\EssbaseServer\bin;C:\AT\fusionapps\bi\bin;C:\AT\fusionapps\bi\opmn\bin;C:\AT\fusionapps\bi\opmn\lib;C:\AT\fusionapps\bi\perl\bin

5.3 Installing a Release Update Patch

This section contains the steps you perform to install a RUP with RUP Installer. It contains the following topics:

Before You Begin
Performing the Installation
Completing the Post Installation Tasks

5.3.1 Before You Begin

Ensure that the steps in Section 5.2, "Preparing to Install a Release Update Patch" are successfully completed before following the steps in this section. Then perform the steps in this section.

5.3.1.1 Steps for All Platforms

This section contains steps to follow for all platforms. For Windows platforms, also follow the steps in Section 5.3.1.2, "Steps for Windows Platforms".

To prevent locks on patched objects and other data issues during patching of database artifacts, review and perform the following checklist before installing the RUP:

Stop all servers and processes, except the OPSS Security Store and the database, before starting the installation. If you want to use the fastartstop utility to do this, see "Starting and Stopping the Oracle Fusion Applications Middle Tier Using the fastartstop Utility" in the Oracle Fusion Applications System Administrator's Guide. Confirm that the BI presentation servers are shut down before starting RUP Installer.
The manual shutdown of the Oracle Enterprise Scheduler Service (ESS) server includes the following steps:
1. Stop the ESS request processor and dispatcher to prevent new requests from being processed. See "Starting and Stopping a Request Processor or Dispatcher" in the Oracle Fusion Applications Administrator's Guide for more information.
2. Cancel any in-progress requests. See "Cancelling Oracle Enterprise Scheduler Job Requests" in the Oracle Fusion Applications Administrator's Guide for more information.
3. Shutdown the ESS WebLogic Server Managed server. See the "Starting and Stopping" table, specifically the "Managed Server for an application" row, in the Oracle Fusion Applications Administrator's Guide for more information.
Stop the Node Manager and the OPMN control process. (On Windows, stop the Node Manager and OPMN services and follow steps1 and 2 in Section 5.3.1.2, "Steps for Windows Platforms".) Note that you must bring up the Node Manager for all domains and the OPMN control process during the Verifying Node Manager and OPMN Status configuration task, before proceeding to the next step in the installation.
For more information, see "Stopping Node Manager" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
Use the following procedure to stop the OPMN control processes for BI, GOP, and webtier (OHS). This procedure also stops all BI server processes, all GOP processes, and the OHS process.
Note:
There should be no webtier processes on this installation if you are running OHS from a separate installation (DMZ or otherwise). In this case, you do not need to stop the webtier processes.
1. Set ORACLE_INSTANCE to the location of the target Oracle instance directory.
2. Go to the bin directory under the target Oracle instance directory.
3. Run the opmnctl program from the current directory with the stopall command.
Example for BI:
```
INSTANCE_HOME=APPLICATIONS_BASE/instance/BIInstance; export INSTANCE_HOMEcd $ORACLE_INSTANCE/bin./opmnctl stopall
```
Example for GOP:
```
ORACLE_INSTANCE=APPLICATIONS_BASE/instance/gop_1; export ORACLE_INSTANCEcd $ORACLE_INSTANCE/bin./opmnctl stopall
```
Example for webtier:
```
INSTANCE_HOME=APPLICATIONS_BASE/instance/CommonDomain_webtier; export INSTANCE_HOMEcd $ORACLE_INSTANCE/bin./opmnctl stopall
```
For more information about the location of APPLICATIONS_BASE, see Section 2.1.2, "Oracle Fusion Applications Oracle Home".
Start the OPSS Security Store if it is not already running. For more information, see "Starting and Stopping Oracle Internet Directory" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition). If this server is not running prior to starting the installation, the related configuration tasks will fail. For more information, see Section 5.4.5, "LdapServerCheck Failure".
Back up applications and system policies for each stripe supported by Oracle Fusion Applications. System policies are global and not by stripe. Application policies are by stripe and need to be backed up and restored by stripe. If you do not back up the policies by stripe, you cannot restore the policies from your backup. Oracle Fusion Applications supports the following stripes:
- fscm_system-jazn-data.xml: FSCM stripe
- crm_system-jazn-data.xml: CRM stripe
- hcm_system-jazn-data.xml: HCM stripe
- bip_jazn-data.xml: OBI stripe
The following steps explain how to back up the system policies and the four application stripes from an OID OPSS security store to individual XML files. These steps must be performed on the Common domain.
1. Create five XML files, fscm-policies.xml, crm-policies.xml, hcm-policies.xml, obi-policies.xml (one for each application stripe), and global-policies.xml (for system policies), each containing the following skeleton:
```
<?xml version="1.0" ?> <jazn-data> <jazn-realm default="jazn.com"> </jazn-realm> <policy-store> <applications> </applications> </policy-store> <jazn-policy> </jazn-policy> </jazn-data>
```
2. Copy an existing jps-config.xml file (that has configured the policystore.ldap service) to a new file, myFile-migrate-jps-config.xml.
3. Open myFile-migrate-jps-config.xml for editing and add the following jpsContexts:
```
<jpsContext name="<MyOIDSecurityStore">> <serviceInstanceRef ref="policystore.ldap"/></jpsContext><jpsContext name="MyDestinationContextFscm"> <serviceInstanceRef ref="my.fscm.backup"/></jpsContext><jpsContext name="MyDestinationContextCrm"> <serviceInstanceRef ref="my.crm.backup"/></jpsContext><jpsContext name="MyDestinationContextHcm" <serviceInstanceRef ref="my.hcm.backup"/></jpsContext><jpsContext name="MyDestinationContextObi"> <serviceInstanceRef ref="my.obi.backup"/></jpsContext><jpsContext name="MyDestinationContextGlobal"> <serviceInstanceRef ref="my.global.backup"/></jpsContext>
```
4. Add the following service instances to myFile-migrate-jps-config.xml:
```
<serviceInstance location="<back-up directory>/fscm-policies.xml" name="my.fscm.backup" provider="policystore.xml.provider"/><serviceInstance location="<back-up directory >/crm-policies.xml" name="my.crm.backup" provider="policystore.xml.provider"/><serviceInstance location="<back-up directory> /hcm-policies.xml" name="my.hcm.backup" provider="policystore.xml.provider"/><serviceInstance location="<back-up directory> /obi-policies.xml" name="my.obi.backup" provider="policystore.xml.provider"/><serviceInstance location="<back-up directory >/global-policies.xml" name="my.global.backup" provider="policystore.xml.provider"/>
```
5. Use the OPSS script migrateSecurityStore to backup each application stripe:
```
migrateSecurityStore(type="appPolicies",configFile="jpsConfigFileLocation", src="srcJpsContext",dst="dstJpsContext", srcApp="srcAppName")
```
  Where:
  jpsConfigFileLocation is the location of the file myFile-migrate-jps-config.xml.
  srcAppName is the stripe being backed up, such as fscm.
  srcJpsContext is the name of the context that refers to the OID security store, such as, fscm.
  dstJpsContext is the name of the context that refers to the XML store, such as, MyDestinationContextFscm.
  See Also
  The Future of Oracle EBS
6. Use the OPSS script migrateSecurityStore to backup system policies:
```
migrateSecurityStore(type="globalPolicies",configFile="jpsConfigFileLocation", src="srcJpsContext",dst="dstJpsContext")
```
  Where:
  jpsConfigFileLocation is the location of the file myFile-migrate-jps-config.xml.
  srcJpsContext is the name of the context that refers to the OID security store, such as, MySourceContext.
  dstJpsContext is the name of the context that refers to the XML policy store, such as MyDestinationContextGlobal.
For more information, see "Migrating with the Script migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
Ensure that you have your own versions of any customized BI Publisher reports. If a RUP includes an update to a catalog object that was delivered with an Oracle Fusion application, the patch will overwrite any customizations applied to the original report. For more information, see "Before You Begin Customizing Reports" in the Oracle Fusion Applications Extensibility Guide.

Oracle Provisioning records information about the Business Intelligence (BI), Global Order Promising (GOP), the Webtier Oracle home, and Webtier Common Oracle home installation information separately from information about other products. Patching expects information about all products to be recorded in the same place. To transfer information about the BI, GOP, and Webtier installations to the same location as information about other products, perform the following steps:

Verify that the default Inventory Pointer file (/etc/oraInst.loc for Unix, C:\Program Files\Oracle\Inventory for Windows) points to the correct location of the central OUI inventory directory that was created by Oracle Provisioning.

Run attachHome from the BI Oracle home.

(Unix) BI_HOME/oui/bin/attachHome.sh -jreLoc JAVA_HOME_LOCATION(Windows) BI_HOME\oui\bin\attachHome.cmd -jreLoc JAVA_HOME_LOCATION

Run attachHome from the GOP Oracle home.

(Unix) GOP_HOME/oui/bin/attachHome.sh -jreLoc JAVA_HOME_LOCATION(Windows) GOP_HOME\oui\bin\attachHome.cmd -jreLoc JAVA_HOME_LOCATION

Run attachHome from the Webtier Oracle home.

(Unix) WEBTIER_HOME/oui/bin/attachHome.sh -jreLoc JAVA_HOME_LOCATION(Windows) WEBTIER_HOME\oui\bin\attachHome.cmd -jreLoc JAVA_HOME_LOCATION

Run attachHome from the Webtier Common Oracle home.

(Unix) WEBTIER_COMMON_HOME/oui/bin/attachHome.sh -jreLoc JAVA_HOME_LOCATION(Windows) WEBTIER_COMMON_HOME\oui\bin\attachHome.cmd -jreLoc JAVA_HOME_LOCATION

Run Oracle Universal Installer with the -updateHomeDeps option and pass a dependency list. The syntax for the dependency list is:

HOME_DEPENDENCY_LIST={ORACLE_HOME:DEPENDENT_ORACLE_HOME}

Example for Business Intelligence:

(Unix) oui/bin/runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST={/u01/APPTOP/fusionapps/bi:/u01/APPTOP/fusionapps/oracle_common}"-jreLoc JAVA_HOME_LOCATION(Windows) oui\bin\runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST={\u01\APPTOP\fusionapps\bi:\u01\APPTOP\fusionapps\oracle_common}"-jreLoc JAVA_HOME_LOCATION

(Unix) oui/bin/runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST={/u01/APPTOP/webtier_mwhome/oracle_common:/u01/APPTOP/webtier_mwhome/oracle_common}"-jreLoc JAVA_HOME_LOCATION(Windows) oui\bin\runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST={\u01\APPTOP\webtier_mwhome\oracle_common:\u01\APPTOP\webtier_mwhome\oracle_common}"-jreLoc JAVA_HOME_LOCATION

Verify that the central inventory now contains the correct GOP, BI, and webtier information. Open the inventory.xml file from the ContentsXML subdirectory in your central inventory directory using a text editor. You can find your central inventory directory by looking in the default Oracle Inventory pointer file mentioned in Step a. Verify that there are entries for GOP and for BI, and that the BI entry lists the Oracle Common dependency you specified in Step f. Do the same for webtier information. Ensure that you do not modify inventory.xml in any way, as this may corrupt your system.
Example entries in inventory.xml:
```
<HOME NAME="OH1109401105" LOC="/u01/APPTOP/fusionapps/gop" TYPE="O" IDX="11"><HOME NAME="OH198367808" LOC="/u01/APPTOP/fusionapps/bi" TYPE="O" IDX="12"> <DEPHOMELIST> <DEPHOME LOC="/u01/APPTOP/fusionapps/oracle_common"/> </DEPHOMELIST></HOME><HOME NAME="OH987588708" LOC="/u01/APPTOP/webtier_mwhome/webtier" TYPE="O" IDX="13"> <DEPHOMELIST> <DEPHOME LOC="/u01/APPTOP/webtier_mwhome/oracle_common"/> </DEPHOMELIST></HOME><HOME NAME="OH1271096710" LOC="/u01/APPTOP/webtier_mwhome/oracle_common" TYPE="O" IDX="14"> <REFHOMELIST> <REFHOME LOC="/u01/APPTOP/webtier_mwhome/webtier"/> </REFHOMELIST></HOME>
```

Back up the Oracle Business Intelligence Publisher web catalog prior to starting RUP Installer. The web catalog is the folder named catalog under FA_ORACLE_HOME/instance/BIShared/OracleBIPresentationServicesComponent/coreapplication_obips1.
Confirm that the database is running and in an idle state.
Confirm that there are no active jobs or processes running against the database.
Stop all background jobs, including jobs in the database and active processes.
Ensure that all Oracle Fusion Applications Patch Manager processes are complete. From your operating system, check for processes that are running fapmgr, javaworker, adpatch, adadmin, and adworker. If a session was interrupted, you may need to forcefail and abandon the session as follows:
1. Use the fapmgr forcefail command to update the patching tables.
```
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh forcefail [-logfile log file name] [-loglevel level](Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd forcefail [-logfile log file name] [-loglevel level]
```
2. Use the fapmgr abort command to abandon the session:
```
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh abort [-logfile log file name] [-loglevel level](Windows) FA_ORACLE_HOME/lcm\ad\bin\fapmgr.cmd abort [-logfile log file name] [-loglevel level]
```

Ensure that all Oracle Fusion Applications AutoPatch processes are complete. If a session is running, you must abandon the session as follows:

From FA_ORACLE_HOME:

(Unix) lcm/ad/bin/adpatch.sh abandon=y interactive=n defaultsfile=FA_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Windows) lcm\ad\bin\adpatch.cmd abandon=y interactive=n defaultsfile=FA_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt

From ATGPF_ORACLE_HOME:

(Unix) lcm/ad/bin/adpatch.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Windows) lcm\ad\bin\adpatch.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt

Ensure that all AD Administration sessions are complete. If one is running, you must abandon the session as follows:.

From FA_ORACLE_HOME:

(Unix) lcm/ad/bin/adadmin.sh abandon=y interactive=n defaultsfile=FA_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Windows) lcm\ad\bin\adadmin.cmd abandon=y interactive=n defaultsfile=FA_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt

From ATGPF_ORACLE_HOME

(Unix) lcm/ad/bin/adadmin.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Windows) lcm\ad\bin\adadmin.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt

Proceed to the RUP Installation, Section 5.3.2, "Performing the Installation".

5.3.1.2 Steps for Windows Platforms

Follow these steps before you install a RUP on Windows platforms.

Change the service type from Automatic to Manual for the following services: Nodemanager, webtier, GOP, and BI. Restore the service type back to Automatic after RUP installation completes.
Stop the following services: Nodemanager, webtier, GOP, and BI.
Reboot the Oracle Fusion Applications host.
Release Java Archive File Handles on System Process ID (PID) 4
On the Windows Weblogic Server, the node manager runs as a service. Since, the APPLICATIONS_BASE of Oracle Fusion Applications is in a symbolic folder, some of the jar file handles are loaded by Microsoft Windows System Process ID (PID) 4. The loaded file handles eventually cause Middleware patch application to fail when running the RUP Installer. Before starting the RUP Installer, make sure the Windows System Process ID (PID) 4 does not have handles to Oracle Fusion Applications jar files.
Check for file handles using the Windows utility Process Explorer. If file handles exist, make sure the node manager service is not running. If the file handles remain even after shutting down the node manager service, switch the node manager service from Automatic to Manual and reboot the machine to release the file handles.
Ensure that the Server service is up and running.
Set the PATH to include FA_ORACLE_HOME\fusionapps\jdk6\bin so that Java is available in the PATH.

5.3.2 Performing the Installation

Ensure that the steps in Section 5.2, "Preparing to Install a Release Update Patch" and Section 5.3.1, "Before You Begin" are successfully completed before installing the RUP.

5.3.2.1 Start RUP Installer

You start RUP Installer from the command line, using specific options to further define the necessary actions. You must run RUP Installer from the primordial host.

(UNIX) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLocJAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \-J-Dworkers number_of_workers][-J-DlogLevel level] [-debug yes](Windows)REPOSITORY_LOCATION\installers\fusionapps\Disk1\setup.exe -jreLocJAVA_HOME_LOCATION

Table 5-3 shows valid options that can be used when running RUP Installer.

Table 5-3 RUP Installer command options

Argument	Description	Mandatory
`jreLoc`	Path where the Java Runtime Environment is installed. This option does not support relative paths, so you must specify the absolute path.	Yes.
`invPtrLoc`	The location of an overriding inventory pointer file. If Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), located under the `APPLICATIONS_BASE/fusionapps` directory, is registered in inventory with a `/net` path, then provide the `oraInst.loc` with `/net`.	Recommended, use to override the default location of the inventory pointer file, located in `/etc/oraInst.loc.` This option can be used only on Unix platforms.
`J-Dworkers`	The number of workers to use for uploading database content. If you provide a value for the number of workers that is outside the calculated range, you are prompted to provide a value that is within the optimal range. If you do not use this option, a calculated optimal value is used.	No, overrides the default number of workers calculated by RUP Installer. See "Worker Calculation" in Section 3.1.2, "Patching Database Artifacts".
`debug`	Retrieves the debug information from RUP Installer.	No.
`J-DlogLevel`	Records messages in the log file at the level you specify. Enter a value to override the default log level of `INFO`. See Section 11.1, "Oracle Fusion Applications Patch Manager Logging".	No, default value is `INFO`.

Example:

(Unix) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc /server01/appmgr/APPTOP/fusionapps/jdk6 -invPtrLoc FA_ORACLE_HOME/oraInst.loc(Windows) REPOSITORY_LOCATION\installers\fusionapps\Disk1\ssetup.exe -jreLoc \server01\appmgr\APPTOP\fusionapps\jdk6

Example when FA_ORACLE_HOME is registered with a /net path:

REPOSITORY_LOCATION/installers/fusionapps/Disk1//runInstaller -jreLoc/server01/appmgr/APPTOP/fusionapps/jdk6 -invPtrLoc /net/APPLICATIONS_BASE/fusionapps/applications/oraInst.loc

5.3.2.2 Install the RUP

Table 5-4 illustrates the tasks that RUP installer runs. For information about log files generated during RUP installation, see Section 5.4.1, "RUP Installer Log Files".

Table 5-4 RUP Installer Screen Sequence

Screen	Description and Action Required
Welcome	Appears each time you start RUP Installer. The standard Welcome screen is read-only. It contains a navigation pane on the left-hand side that summarizes the tasks the installer will take. Each item in the pane represents an installer screen, which contains prompts for the necessary information. No action is required. Click Next to continue.
Installation Location	Specify the location of the existing Oracle Fusion Applications home (`FA_ORACLE_HOME)` where you want to install the RUP. Click Next to continue.
Installation Summary	Summarizes the selections you made during this installation session. It includes the Oracle home, required and available disk space, and the version of the RUP to be installed. Review the information displayed to ensure that the installation details are what you intend. To make changes before installing, click Back to return to previous screens in the interview. Click Install to accept this configuration and start the installation.
Installation Progress	Displays a progress indicator that shows the percentage of the installation that is complete and indicates the location of the installation log file. The installation task consists of copying files from the RUP to the Oracle home. The configuration process starts when the installation progress indicator shows 100 percent. Click Next to continue.
Policy Store Analysis	Select the stripes to be analyzed and then click Run Analysis to identify any conflicts or deletions. Only the stripes that are included in the RUP are enabled for analysis and the analysis could run for several minutes. After the analysis runs, review the results of the analysis and decide which deployment method you want RUP Installer to use for policy store changes to each stripe. If you decide to resolve the conflicts or deletions before the actual JAZN upload from RUP installer, you should run the Policy Store Analysis step again to get the most accurate analysis report. The choices for deployment method are: Apply safe changes only Apply all changes and overwrite customizations Append additive changes Manually resolve conflicts and upload changes using Authorization Policy Manager If you choose Apply safe changes only or Append additive changes, then you must review the results of the analysis to manually upload any changes not applied by RUP installer with the choice you selected, after the installation is complete. If you choose Apply all changes and overwrite customizations, then you may need to reapply the customizations that are overwritten after the installation is complete. If you choose one of these options, click Next after you make your selection. If you choose Manually resolve conflicts and upload changes using Authorization Policy Manager (APM), you must bring up the APM application and pause the installation while you go to APM. When you complete this task in APM, shut down the APM application, return to RUP Installer, and click Next.
Configuration Progress	Displays a progress indicator that shows the percentage of the configuration phase that is complete. It displays each task, including steps within tasks, in the message pane as it is performed. Tasks that could be included in the configuration phase are described in Section 5.1.4, "RUP Installer Configuration Tasks". Before the Starting All Servers task, the Verifying Node Manager and OPMN Status configuration task checks for access to the Node Manager and the OPMN control process. This should fail because you manually shut down these processes prior to starting RUP Installer. Do not cancel and exit out of RUP Installer in response to this task. When this task fails, follow these steps: Start the Node Manager on all hosts that are part of the Oracle Fusion Applications provisioned system. For more information, see "Start Node Manager" in Oracle Fusion Applications Administrator's Guide. Restart the OPMN server for BI and GOP, and the OPMN server plus managed processes for webtier. This is similar to the `stop` steps described in Step 2, Section 5.3.1, "Before You Begin", except that for BI and GOP, you must start only the OPMN server itself, while for webtier, you should start OPMN and all processes that it manages. If you run the webtier (OHS) installed with the Oracle Fusion Applications middle tier, you can start it using the following steps. If you run the webtier on a separate machine, you may be able to run the steps below on the other machine. In either case, ensure that webtier (OHS) is up at this point. Example for BI: (note the usage of `start` instead of `startall`) INSTANCE_HOME=APPLICATIONS_BASE/instance/BIInstance; export INSTANCE_HOMEcd $ORACLE_INSTANCE/bin./opmnctl start Example for GOP: (note the usage of `start` instead of `startall`) ORACLE_INSTANCE=APPLICATIONS_BASE/instance/gop_1; export ORACLE_INSTANCEcd $ORACLE_INSTANCE/bin./opmnctl start Example for webtier: INSTANCE_HOME=APPLICATIONS_BASE/instance/CommonDomain_webtier; export INSTANCE_HOMEcd $ORACLE_INSTANCE/bin./opmnctl startall For more information about the location of `APPLICATIONS_BASE`, see Section 2.1.2, "Oracle Fusion Applications Oracle Home". The BI processes managed by OPMN are started by RUP installer in a later configuration task. The GOP processes managed by OPMN can be started by an administrative user from the GOP home page in Oracle Enterprise Manager after RUP installer completes. Fix any other environment issues before retrying the session. If RUP Installer exits for any reason, make sure that all node managers and OPMN processes are running. Contact Oracle Support Services to proceed out of this step. After you start these services, click Retry to move to the Starting All Servers task. If starting of servers times out, see Section 5.4.9, "Failure During Starting All Servers". No additional user action is required in the Configuration Progress screen unless a failure occurs. For more information, see Section 5.4.3, "Error During the Configuration Phase".
Installation Complete	Summarizes the installation just completed. If you want to save this configuration to a response file, click Save. For more information, see "How Response Files Work" in the Oracle Database Installation Guide 11g Release 2 (11.2) for Linux.To complete a successful installation, click Finish. If you want to rerun this session to resolve failed configuration tasks, click Cancel.

5.3.3 Completing the Post Installation Tasks

The following steps may be required after RUP Installer successfully installs the RUP.

Confirm that all deployments were successful by reviewing the Diagnostics report and log files. For more information, see Section 3.5.5, "Diagnostics Report".
Confirm there are no unresolved errors or exceptions in the log files. For information about resolving errors, see Section 5.4, "Troubleshooting RUP Installer Sessions".
Confirm that all relevant Managed Servers have a RUNNING status.
Verify that all deployed applications are up and running. You can check this from Oracle Enterprise Manager Fusion Applications Control, or by reviewing the server side log files.
Review the JAZN Analyze report for potential conflicts and deletions that are not patched automatically by RUP Installer.
Ensure that you applied all mandatory post installation patches and followed any post installation steps mentioned in Oracle Fusion Applications release notes.

5.4 Troubleshooting RUP Installer Sessions

This section provides information to assist you in troubleshooting RUP Installer sessions. It contains the following topics:

RUP Installer Log Files
Error During the Installation Phase
Error During the Configuration Phase
Invalid Oracle Home
LdapServerCheck Failure
Error While Loading Database Tasks
Database Failure While Loading Database Components
AutoPatch Validation Fails
Failure During Starting All Servers
Resolving a Failure During IPM Import
JDeveloper Customizations Performed on SOA Composite
EditTimedOutException Error
Webcat Patch File Creation Failure
Error in Writing to File, Text File Busy
Inventory Pointer File is Empty
Error During Bootstrapping Patch Manager
How to Find the Cause of an Error During Applying Middleware Patches
Failure During Deployment of Applications Policies
Failure During Deployment of BI Publisher Artifacts

For additional information about troubleshooting Oracle Fusion Applications Patch Manager sessions, see Chapter 11, "Monitoring and Troubleshooting Patches".

5.4.1 RUP Installer Log Files

Table 5-5 contains a list of log directories for RUP Installer activities.

Table 5-5 Log Directories for RUP Installer Activities

Log directory name	Generated from...
`oracle_inventory`/logs/install_timestamp.log	Installation phase
`FA_ORACLE_HOME`/admin/FUSION/log/fapatch/fapatch_11.1.2.0.0/PatchManager_DBPatch	Configuration phase
`FA_ORACLE_HOME`/admin/FUSION/log/fapatch/fapatch_11.1.2.0.0/StartStop	StartStop utility
`FA_ORACLE_HOME`/admin/FUSION/log/fapatch/fapatch_11.1.2.0.0/soalogs	Processing SOA artifacts

During the execution of configuration tasks, log files are created under the FA_ORACLE_HOME/admin/FUSION/log directory. Upon completion or failure, the log files move to the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_releasenumber directory. The current releasenumber is 11.1.2.0.0.

5.4.2 Error During the Installation Phase

RUP Installer backs up the contents of the FA_ORACLE_HOME/patchsettop directory after it completes the installation phase. The backup directory is FA_ORACLE_HOME/patchsettop/backup/patchsettop_timestamp. When RUP Installer restarts after a failure, it ensures that the contents in the FA_ORACLE_HOME/patchsettop directory are relevant for the current session. When RUP Installer exits the installation phase, it deletes any existing content in the FA_ORACLE_HOME/patchsettop directory.

Follow these steps when an error occurs during the installation phase:

Click Cancel to exit RUP Installer.
Review the log files to determine the cause of the failure. For more information, see Section 5.4.1, "RUP Installer Log Files". Resolve the cause of the failure.
Start RUP Installer using the same command syntax that you used for the previous incomplete installation. For more information, see Section 5.3.2, "Performing the Installation".
Click Next to navigate through the Welcome, Specify Installation Location, and Installation Summary screens. When the Installation Progress screen displays, click Install to start the installation again.

5.4.3 Error During the Configuration Phase

If a configuration task fails, you have the option to abort the task or retry the task after resolving the cause of the failure. Using this feature allows you to restart RUP Installer and continue from the point of failure. If a failure occurs during a step within a configuration task, you have to option to abort the step, retry the step after you resolve the cause of the failure, or continue with the next step.

When a configuration task or step fails, the Configuration Progress screen displays the location of the log file and the exception that caused the failure. You can also view the log files that appear at the bottom of the screen to obtain detailed information to assist in diagnosing the cause of the failure.

Additional related information is described in the following topics:

Configuration Task Failures
Configuration Step Failures
Restart RUP Installer After a Failure During Configuration

5.4.3.1 Configuration Task Failures

A configuration task failure causes the Abort and Retry buttons to be enabled. All mandatory configuration tasks must complete successfully before proceeding to the next configuration task. For a complete list of configuration tasks, see Section 5.1.4, "RUP Installer Configuration Tasks".

The usage of these buttons follows:

Abort: Skips the failed task and records the failure so it can be rerun when you restart the installation. For mandatory tasks, after you abort the task, only the Cancel button is enabled. You must then resolve the cause of the failure and start RUP Installer from this failure point. For non-mandatory tasks, RUP Installer proceeds to the next configuration task.
Retry: Attempts to run the failed configuration task again. Use Retry when you know the cause of the failure and can resolve the issue during the current RUP Installer session. For example, when a server is down, you can restart it and proceed with the RUP installation by using Retry.

After a configuration task fails and you select Abort, RUP Installer reports that the RUP installation succeeded but the Configuration failed. If you want to rerun this installation session from the point of failure, you must select Cancel or Close to end the session, so RUP Installer saves the session information for a subsequent restart.

If you select Cancel before the end of the RUP Installer session, RUP Installer waits for the completion of the task that is currently running. At that time, whatever is saved so far in the session preserved. You can then restart the same RUP Installer session from the point of failure. Oracle recommends that you use the Cancel button only after a failure.

5.4.3.2 Configuration Step Failures

Certain configuration tasks run multiple steps to complete the task. A configuration step failure causes the Abort, Retry, Cancel, and Continue buttons to be enabled. For mandatory tasks, all steps must complete successfully before RUP Installer can proceed to the next task.

The usage of these buttons follows:

Abort: Skips the failed step and records the failure so it can be rerun when you restart the installation. Then RUP Installer marks the failed step as red. If the step is part of a mandatory configuration task, RUP Installer fails the task and marks the failed task red. RUP Installer does not proceed. You must click Cancel to stop the session, then resolve the failures so you can restart RUP Installer.
If the configuration task is not mandatory, RUP Installer proceeds to run the next task.
Retry: Attempts to run the failed configuration step again. Use Retry when you know the cause of the failure and can resolve the issue during the current RUP Installer session.
Continue: Skips the failed step, within the task, and records the failure. RUP Installer proceeds with the next step. If you rerun this RUP Installer session, this step is attempted again.

5.4.3.3 Restart RUP Installer After a Failure During Configuration

RUP Installer can be restarted to rerun all failed configuration tasks as well as those tasks that were not started from the previous session.

Follow these steps to rerun RUP Installer from the point of failure.

Start RUP Installer using the same command syntax that you used for the previous incomplete installation. For more information, see Section 5.3.2, "Performing the Installation".
A pop up dialog displays, asking if you want to continue the previous incomplete installation. Select Yes to rerun the previous session. If you select No, RUP Installer starts from the beginning and it will fail, indicating that a RUP cannot be installed again in the same environment. You would then need to restore from your backup and restart the RUP installation.
The Configuration Progress screen displays only the failed configuration tasks.
Assuming all configuration tasks complete successfully, click Next to go to the Installation Complete screen and then click Finish to end the session. If a configuration task fails again and you want to attempt to run the session again, click Cancel to save the session.

5.4.4 Invalid Oracle Home

In the Installation Location page, you receive a message about entering an invalid Oracle home, even though the location displayed on the page is correct. RUP Installer reads /etc/oraInst.loc to determine the location of the central inventory. Review the following settings:

Ensure that the /etc/oraInst.loc file on the machine where you are running RUP Installer is pointing to the correct central inventory location.
Ensure that the FA_ORACLE_HOME matches the values provided during provisioning. If a /net/location was provided as the Oracle home location during provisioning, the same /net/location that corresponds to FA_ORACLE_HOME should be provided during the RUP Installation.

5.4.5 LdapServerCheck Failure

If the OPSS Security Store is not running before RUP Installer starts, the related configuration task will fail. Even if you start this server after you notice the failure, the configuration task fails again, with the following error:

Retry of step"oracle.as.install.fapatchconfig.plugin.impl.LdapServerCheck" failed.

Follow these steps to recover:

Abort the failed configuration task.
Select Cancel to end the RUP Installer session.
Start the OPSS Security Store. For more information, see "Starting and Stopping Oracle Internet Directory" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
Start a new RUP Installer session. The installer resumes with the remaining tasks because you selected Cancel, which saves the session.

5.4.6 Error While Loading Database Tasks

When RUP Installer notifies you that one or more database workers failed during the configuration task called Loading Database Tasks, you must start AD Controller to manage the failed workers. For more information, see Section 11.5, "Troubleshooting Patching Sessions for Database Content". After you resolve the issue that caused the workers to fail and you restart the failed worker, click OK in the dialog box and RUP Installer continues processing.

5.4.7 Database Failure While Loading Database Components

If your database goes down while RUP Installer is running the task called Loading Database Components, the options to Abort or Continue display. If you simply bring the database up and then click Continue, you may encounter the following error:

Failed to connect to the database as fusion with error: No more data to read from socket

Perform the following steps to recover from this error:

Force the database patching session to fail.

(Unix) ...lcm/ad/bin/fapmgr.sh -forcefail (Windows) ...lcm\ad\bin\fapmgr.cmd -forcefail

Start AD Controller.
```
(UNIX) ...lcm/ad/bin/adctrl.sh(Windows) ...lcm\ad\bin\adctrl.cmd
```
For more information, see Section 11.5.1, "Starting AD Controller".
Follow this sequence of steps in AD Controller to manage the workers:
1. Select Tell manager that a worker failed its job and enter All for all workers.
2. Select Tell worker to quit and enter All for all workers.
3. Select Tell manager that a worker acknowledges quit and enter All for all workers.
4. From your operating system, check for processes that are running fapmgr, javaworker, adpatch, adadmin, sqlplus, and adworker. If any exist, terminate them from your operation system.
5. Select Tell worker to restart a failed job and enter All for all workers.
Go back to the RUP Installer screen and select Retry.

5.4.8 AutoPatch Validation Fails

When AutoPatch validation fails, you receive this message:

An active adpatch or adadmin session was found. Complete or terminate the active session to allow fapmgr to proceed.

Follow these steps to resolve this error:

Run the fapmgr abort command from FA_ORACLE_HOME to find out if an Oracle Fusion Applications Patch Manager must be cleaned up.
```
(UNIX) ...lcm/ad/bin/fapmgr.sh abort [-logfile log file name] [-J-DlogLevel level](Windows) ...lcm\ad\bin\fapmgr.cmd abort [-logfile log file name] [-J-DlogLevel level]
```
If this command finds no failed session, proceed to Step 2.

Run the following commands from ATGPF_ORACLE_HOME to abandon any Applications Core patching sessions or AD Administration sessions that may be running:

(Unix) ...lcm/ad/bin/adpatch.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Unix) ...lcm/ad/bin/admin.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt(Windows) ...lcm/ad/bin/adpatch.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt(Windows) ...lcm/ad/bin/adadmin.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt

5.4.9 Failure During Starting All Servers

A failure during the Starting All Servers configuration task typically happens when one of the servers times out and fails to start due to resource issues or application specific issues. Various platforms and environment configurations can impact how long it will take all servers to actually start during the Starting All Servers configuration task. Although RUP Installer waits an average amount of time for this task to complete before it is marked as Failed, different platforms may require more time. It is not unusual to receive timeout errors in the log files if the starting of all servers for your environment requires more time than RUP Installer allows. If this task fails, follow these steps:

Monitor the status of the servers by reviewing the messages in the server log files or on the console. The log file,FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.2.0.0/StartStop/fastartstop_timestamp.log, indicates which server failed to start.

An example of messages for a server that timed out follow.

Time out while performing Start for domain SCMDomain. Waited for 2160 seconds[2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [UTIL] [oracle.apps.startstop.util.MbeanUtil: runSSCommandOnDomain.868] [tid:37] Start operation is completed for domain SCMDomain. Please see SCMDomain.log for details.[2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [UTIL] [oracle.apps.startstop.invoke.StartStopTask: call.221] [tid:37] StartStopTask over for domain SCMDomain[2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [SST] [oracle.apps.startstop.invoke.StartStopTask: call.223] [tid:37] Finished the task for the Domain SCMDomain

If a server fails to restart due to an issue other than timing out, review the corresponding server log, located in the FA_ORACLE_HOME/instance/domains directory, to determine and resolve the cause of the failure.
When all servers are up and running, including those that exceeded the timeout limit, click Retry in RUP Installer to move to the next configuration task.

5.4.10 Resolving a Failure During IPM Import

If the configuration task for importing IPM artifacts fails with the following error, follow the instructions in Step 7 in Section 4.12.1, "Prerequisites for the Deployment of IPM Artifacts".

importIPMApplication() & importIPMInput() WLST commands have not run successfully

5.4.11 JDeveloper Customizations Performed on SOA Composite

If you receive the following error during the Online Prevalidation configuration task, the Abort, Retry, and Continue buttons are enabled.

JDev Customizations were performed on the current active revision: "revision_number" of the composite "Composite_name". Hence, it cannot be imported.JDev customizations are required to be manually imported from the currentrevision into the new revision of the composite.Action : Please check location "full_path_of_composite.jar_file" which is used bythe installer and merge the customization at this location.

To proceed with the installation of the RUP, you must preserve your JDeveloper customizations. Follow the steps in Section 4.18.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch". After you complete these steps, select Retry. RUP Installer then performs the validation checks again and the checks for JDeveloper customizations passes with the message, No Jdev Customizations need to be manually imported.

At this point all composites are ready to be deployed and all prerequisite checks have passed. During the deployment of SOA Composites, all prerequisites are checked again and the composite is deployed.

5.4.12 EditTimedOutException Error

If you receive the following error during pre-validation,

weblogic.management.mbeanservers.edit.EditTimedOutException

you may have to manually release the edit session. For more information, see Section 11.3.8, "Resolving an EditTimedOutException Error".

5.4.13 Webcat Patch File Creation Failure

If you apply a RUP that contains BI Publisher artifacts, the BI Presentation servers should not be running. The following error occurs if the BI Presentation servers are running during the deployment of BI Publisher artifacts:

java.lang.RuntimeException: Webcat patch file creation failed!

To resolve this issue, shut down the BI Presentation servers to release locks on the Oracle BI Presentation Catalog.

5.4.14 Error in Writing to File, Text File Busy

During the installation phase of RUP Installer, you receive the following message on a Unix platform.

Error in writing to file'/server01/APPTOP/fusionapps/applications/lcm/ad/bin/adctrl'(Text file busy)

To resolve this issue, perform the following steps.

Run the lsof command using the full directory path of the file that is busy.
```
/usr/bin/lsof full_path_to_file
```
You should receive a list of process ids that are using the file. Kill each process using the appropriate command for your operating system.
After all processes are no longer running, click Continue in RUP Installer.

5.4.15 Inventory Pointer File is Empty

After running RUP Installer, the contents of oraInst.loc were removed.

RUP Installer always tries to copy the inventory pointer file specified by the -invPtrLoc option to the Oracle home on which the RUP is to be installed. If you specify an incorrect path for the -invPtrLoc file, the inventory pointer file could result in being an empty file. There are three possible solutions to this issue:

For best results, if you are using the -invPtrLoc option, use it with this value: FA_ORACLE_HOME/oraInst.loc. This avoids a situation where you may inadvertently exclude part of the directory path to the file, as in the case of using a mapped drive. For example, if Oracle home is registered in inventory with a /net path, such as /net/home/oraInst.loc, and you provide /home/oraInst.loc to the invPtrLoc option, the installer interprets the two paths as different. The end result is an empty inventory pointer file.
If FA_ORACLE_HOME is registered in central inventory with a /net path, then you must include /net when specifying the location of the inventory pointer file with the -invPtrLoc option, for example, -invPtrLoc /net/directory_path/oraInst.loc.
Restore from a backup copy of your oraInst.loc file in case the original file is damaged.
You can recover from this error by creating a new oraInst.loc. See the "Creating the oraInst.loc File" section in the relevant Oracle Database installation guide, for example, Oracle Database Installation Guide, 11g Release 2 (11.2) for Linux.
Then click Retry.

5.4.16 Error During Bootstrapping Patch Manager

An error during the configuration task called Bootstrapping Patch Manager normally occurs only when the database is down. Ensure that the database is up and running.

5.4.17 How to Find the Cause of an Error During Applying Middleware Patches

If an error occurs during the configuration step called Applying Middleware Patches, review the log file in this location:

FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.2.0.0/FAPatchManager_ApplyMWPatches_timestamp.log

For specific OPatch failures, go to each of the individual Oracle home directories to find the details of the OPatch errors. For example, for a SOA failure, go to FA_ORACLE_HOME/fusionapps/soa/cfgtoollogs/opatch.

5.4.18 Failure During Deployment of Applications Policies

When a failure occurs during the deployment of applications policies, you must restore only the stripe or system policy that has failed from your backup. Use the OPSS migrateSecurityStore command with the appropriate source and destination arguments. Do not restore a stripe that has not failed. Then restart RUP Installer by either selecting Retry in the same session or by exiting RUP Installer and restarting it.

For more information, see "Migrating with the Script migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

5.4.19 Failure During Deployment of BI Publisher Artifacts

If the deployment of BI Publisher artifacts fails, follow these steps to restore the BI Publisher web catalog and retry the deployment.

Click Cancel to exit RUP Installer.
Caution:
Do not click Abort.
Restore the web catalog from the backup you created in step 7 in Section 5.3.1, "Before You Begin".
Restart RUP Installer.