| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.4) Part Number E16602-15 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.4) Part Number E16602-15 |
|
|
PDF · Mobi · ePub |
This chapter describes how to install release update patches in Oracle Fusion Applications.
This chapter contains the following topics:
This section provides an introduction to the following concepts related to release update patches:
A RUP is a set of cumulative patches and changes for the entire Oracle Fusion Applications Suite, for a base release. A RUP can introduce new functionality, and should be applied when suitable. You install RUPs with Oracle Fusion Applications RUP Installer. To install a certain version of a RUP you must have successfully installed the previous version. For example, in order to install RUP3, you must have successfully installed RUP2.
RUP Installer is a Java-based installer that enables you to install a group of patches across all product families, to upgrade Oracle Fusion Applications to the next release. RUP Installer can patch existing content and can also copy and deploy new artifacts, depending on the contents of the RUP. RUP Installer is comprised of two installers that are chained together. The first installer manages updates to Oracle Fusion Applications Patch Manager and Oracle Fusion Middleware. The second installer manages updates to Oracle Fusion Applications. When the first installer completes its tasks successfully, RUP Installer automatically calls the second installer. You run RUP Installer in interactive mode and proceed through the installation by providing information in the user interface when prompted.
RUP Installer provides a graphical user interface which allows you to control the behavior of the installer by the use of buttons, in cases where it encounters a failure. Note that the behavior of these buttons may vary, depending on whether it is a task, or a step within a task, that fails. The behavior also depends on whether a task is mandatory. All mandatory configuration tasks must complete successfully before proceeding to the next configuration task. For information about which tasks are mandatory, see Section 5.1.4, "RUP Installer Configuration Tasks".
You can exit out of RUP Installer in the event of a failure and restart from the point of failure. If a non-mandatory task fails, and you continue to the next task, you must restart RUP Installer after it finishes with incomplete tasks. When you restart, RUP Installer retries all failed configuration tasks and steps. For more information about what to do when a configuration action fails, see Section 5.6.3, "General Troubleshooting During the Configuration Phase".
An explanation of the usage of each button follows.
The Abort button allows you to skip a failed task or step within a task, and records the failure so it can be rerun when you restart the installation. For mandatory tasks, after you abort the task, RUP Installer does not proceed and 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 after you abort the task. This button is enabled only after a failure.
The Cancel button allows you to stop a RUP Installer session after a failure. This button is enabled only after a failure.
The Windows Close button allows you to stop a RUP Installer session after a failure. This is enabled only after a failure.
The Continue button allows you to skip a failed step within a task that is not mandatory, or a non-mandatory task, and records the failure. RUP Installer then proceeds with the next step. When you rerun this RUP Installer session, the failed configuration actions are attempted again.
Note that this button is enabled only for configuration tasks that contain steps and is not enabled in the case of failure for configuration tasks that do not contain steps.
The Next button allows you to proceed to the next screen. This button is enabled only when all tasks complete successfully in the current screen.
During the installation phase, RUP Installer copies all files from the RUP to the appropriate locations, such as Oracle Fusion Middleware home and Oracle Fusion Applications Oracle home. After the file copy completes, RUP Installer calls its first installer to update Oracle Fusion Applications Patch Manager and apply Oracle Fusion Middleware patches. When the first installer completes successfully, RUP Installer calls the second installer, which performs the Policy Store Analysis, as described in Table 5-7. Upon successful completion of the Policy Store Analysis, RUP Installer calls Configuration Assistants to perform the remaining tasks required to update and deploy the artifacts included in the RUP to Oracle Fusion Applications. Depending on the contents of the RUP, not all tasks run.
If any tasks fail during the installation phase, refer to Section 5.6.2, "Troubleshooting Failures During the Installation Phase" for more information.
All mandatory configuration tasks must complete successfully before proceeding to the next configuration task. For more information, see Section 5.6.3, "General Troubleshooting During the Configuration Phase".
Table 5-1 provides a list of configuration tasks that the first installer runs. The Retry Behavior column describes what RUP Installer does after a configuration task fails and you select the Retry button. If available, links are provided to the relevant troubleshooting sections.
Table 5-1 Configuration Tasks Run by Oracle Fusion Applications 11g Release 1 (11.1.4.0.0) RUP Installer Part 1 of 2
| Name | Mandatory | Description | Retry Behavior and Troubleshooting |
|---|---|---|---|
|
Configure Patch Manager |
Yes |
Configures Oracle Fusion Applications Patch Manager. |
Starts from the beginning of the task. |
|
Bootstrap Patch Manager |
Yes |
Updates the data model for Oracle Fusion Applications Patch Manager by running the fapmgr |
Starts from the beginning of the task. See Section 5.6.5, "Troubleshooting Bootstrapping Patch Manager". |
|
Verify Middleware PSA Schema Credentials |
Yes |
Verifies users and logins for schemas. |
Starts from the beginning of the task. |
|
Apply Middleware Patch Sets |
Yes |
Applies Oracle Fusion Middleware patch sets, which include schema changes and installers. |
Installs failed patch sets. |
|
Apply Pre-PSA Middleware Patches |
Yes |
Applies WebLogic Server Smart Update patches and OPatch-based patches. See Section 5.1.4.1, "Middleware Installers Invoked by the Apply Pre-PSA Middleware Patches Tasks" and Section 5.1.4.2, "Patches Not Supported by the Apply Pre- and Post-PSA Middleware Patches Tasks". |
Applies the failed patches. See Section 5.6.6, "Troubleshooting Applying Middleware Patches". |
|
Patch Middleware Schemas |
Yes |
Runs Oracle Fusion Middleware patch set assistants (PSA). |
Runs failed tasks. See Section 5.6.7, "Troubleshooting Upgrading Middleware Schema". |
|
Apply Post-PSA Middleware Patches |
Yes |
Applies patches that update Oracle Fusion Middleware Extensions for Applications objects. See Section 5.1.4.2, "Patches Not Supported by the Apply Pre- and Post-PSA Middleware Patches Tasks". |
Applies the failed patches. See Section 5.6.6, "Troubleshooting Applying Middleware Patches". |
Table 5-2 provides a list of configuration tasks that the second installer runs. The Retry Behavior column describes what RUP Installer does after a configuration task fails and you select the Retry button. If available, links are provided to the relevant troubleshooting sections.
Table 5-2 Configuration Tasks Run by Oracle Fusion Applications 11g Release 1 (11.1.4.0.0) RUP Installer Part 2 of 2
| Name | Mandatory | Description | Retry Behavior |
|---|---|---|---|
|
Configure Patch Manager |
Yes |
Configures Oracle Fusion Applications Patch Manager. |
Starts from the beginning of the task. |
|
Bootstrap Patch Manager |
Yes |
Updates the data model for Oracle Fusion Applications Patch Manager by running the fapmgr |
Starts from the beginning of the task. See Section 5.6.5, "Troubleshooting Bootstrapping Patch Manager". |
|
Offline Preverification |
Yes |
Performs the following validation checks while all servers are shutdown:
|
Runs failed steps. See Section 5.6.8, "LdapServerCheck Failure During Offline Preverification". |
|
Load Database Components |
Yes |
Uploads the database content packaged in the RUP to the database, such as database objects, seed data, and package headers and bodies. |
Runs failed database commands. See Section 5.6.9, "Troubleshooting Loading Database Components". |
|
Prepare for WebGate Upgrade |
Yes |
Performs steps to prepare for the upgrade of WebGate to 11g. |
In case of a failure, see Section 5.6.10, "Failure During Preparing For WebGate Upgrade Configuration Task." |
|
Deploy Applications Policies (jazn-data.xml) |
Yes |
Performs the deployment of the updated applications policies, based on your selections during the Policy Store Analysis task. This task does not run if you installed a Language Pack and chose to override the base English strings in the policy store by using the |
Deploys the failed stripes. See Section 5.6.11, "Troubleshooting Deployment of Applications Policies". |
|
Deploy Data Security Grants |
Yes |
Performs GUID reconciliation in LDAP. |
Starts from the beginning of the task. |
|
Generate ADF Domain Configuration Plan |
Yes |
Generates Oracle ADF domain configuration in Metadata Service (MDS) to be used by Expression Language (EL) expressions in |
Starts from the beginning of the task. |
|
Generate SOA Configuration Plan |
Yes |
Generates the configuration plan to be used for deploying SOA composites. |
Starts from the beginning of the task. |
|
Update Flexfield Configuration |
Yes |
Updates the |
Starts from the beginning of the task. |
|
Deploy BPM Templates |
Yes |
Deploys BPM Templates to the MDS repository. |
Deploys failed templates. |
|
Deploy BI Publisher Artifacts |
Yes |
Copies captions and deploys Webcat to the Oracle Business Intelligence repository using Catalog Manager. |
Starts from the beginning of the task. See Section 5.6.14, "Webcat Patch File Creation Failure During Deployment of BI Publisher Artifacts". |
|
Import Oracle Data Integrator Repository |
Yes |
Imports ODI related changes to the ODI Master and Work repository. Drops ODI error tables. |
Imports failed data. See Section 5.6.15, "Importing ODI Repositories Task Shows 100% Complete". |
|
Deploy Middleware Shared Libraries |
Yes |
Deploys templates for Oracle Fusion Middleware shared libraries. |
Runs failed steps. |
|
Apply Offline Setting Changes |
Yes |
Applies Oracle Fusion Applications environment configuration setting changes during the offline phase. |
Retries failed domains. |
|
Verify Node Manager and OPMN Status |
Yes |
Checks for access to the Node Manager and the Oracle Process Manager and Notification Server (OPMN) control process. You must not exit out of RUP Installer during this task. |
Runs failed steps. See Section 5.6.16, "Troubleshooting Failure During Verifying Node Manager and OPMN Status". |
|
Start All Admin Servers |
No |
Starts all Administration Servers. |
Restarts failed Administration Servers. See Section 5.6.18, "Troubleshooting Server Start and Stop Failures". |
|
Upgrade ODI Agent Application |
Yes |
Upgrades ODI Agent applications. |
Retries failed domains. See Section 5.6.17, "Error During Upgrading ODI Agent". |
|
Start All Servers |
No |
Starts all servers in all domains, including the BI servers. |
Restarts failed servers. See Section 5.6.18, "Troubleshooting Server Start and Stop Failures". |
|
Upgrade ADF Connections |
Yes |
Runs a WLST script on the provisioned domains to upgrade the ADF connections in that domain. |
Retries script on failed domains. |
|
Restart All Servers |
No |
Restarts all servers. |
Restarts failed servers. |
|
Online Preverification |
Yes |
Performs steps described in Section 5.1.4.3, "Validation Steps Performed During Online Preverification Task". |
Runs failed steps. See Section 5.6.19, "EditTimedOutException Error During Online Preverification" and Section 5.6.20, "Merging SOA Composite JDeveloper Customizations While Applying a RUP". |
|
Upgrade WebGate |
No |
Generates policies and files that are required to upgrade WebGate to 11g. The generated policies and files are packaged into RUP Lite for OHS. |
Starts from the beginning of the task. |
|
Generate OHS Reference Configuration File |
No |
Generates Oracle HTTP Server (OHS) configuration files for installed product families in this directory: |
Starts from the beginning of the task. |
|
Apply OAM Configuration |
No |
Applies changes to the Oracle Access Manager configuration. |
Starts from the beginning of the task. See Section 5.6.21, "Location of GRC Policies in the OAM Applications Domain". |
|
Apply OWSM Configuration |
No |
Upgrades Oracle Web Services Manager (Oracle WSM) policies after backing up the policies. |
Restores the backup of the policies and starts from the beginning of the task. |
|
Apply SES Configuration Changes |
No |
Updates additional configuration updates to SES running on the Common Domain. |
Starts from the beginning of the task. |
|
Deploy Flexfields |
No |
Deploys flexfields to the domain that hosts the |
Starts from the beginning of the task. |
|
Import Image Routing (IPM) Artifacts |
No |
Deploys IPM artifacts to the IPM server. |
Retries failed IPM artifacts. See Section 5.6.22, "Failure During IPM Import". |
|
Deploy B2B Metadata |
No |
Deploys B2B Metadata. |
Deploys failed B2B artifacts. |
|
Deploy SPE Inline Service Artifacts |
No |
Deploys SPE Inline Service Artifacts. |
Retries the deployment. |
|
Deploy Data Role (RGX) Templates |
No |
Deploys RGX Template artifacts to the Common Domain. |
Deploys failed templates. |
|
Import Group Space Templates |
No |
Imports Group Space Templates. |
Deploys failed templates. |
|
Deploy SOA Shared Repository Artifacts |
Yes |
Deploys SOA shared repository artifacts to the various SOA servers available in the environment. |
Deploys failed SOA shared repository artifacts. |
|
Deploy UpdateSOAMDS Composite |
No |
Deploys the |
Deploys composite on domains that failed. |
|
Deploy SOA Composites |
No |
Deploys SOA composites to the corresponding SOA servers and performs server management steps. |
Deploys failed SOA composites. See Section 5.6.23, "Troubleshooting SOA Composite Deployment Failures". |
|
Deploy SOA Resource Bundles |
Yes |
Deploys SOA Resource Bundles to the corresponding SOA servers. |
Deploys failed SOA resource bundles. |
|
Restart All SOA Servers |
No |
Restarts all SOA servers in the environment. |
Starts at the beginning of the task. |
|
Apply Online Setting Changes |
No |
Applies Oracle Fusion Applications environment configuration setting changes during the online phase. |
Starts from the failed task. |
|
Generate RUP Lite for OHS |
No |
Generates the zip file that contains all files needed by RUP Lite for OHS for upgrading OHS. |
Starts at the beginning of the task. |
|
Apply BI Metadata Updates |
Yes |
Applies Oracle Business Intelligence Metadata updates. |
Applies failed patches. See Section 5.6.24, "Failure During Applying BI Metadata Updates". |
|
Post Configuration |
No |
Reactivates the ESS Server from inactive or quiescent mode. |
Retries failed domains. See Section 5.6.25, "Failure During Post Configuration". |
The following installers are invoked by this configuration task:
Oracle Business Intelligence
Oracle Common
Oracle Data Integrator (ODI)
Oracle Database Client
Oracle Enterprise Content Management
Oracle HTTP Server (OHS) - OHS may be installed either beside the rest of the Oracle Fusion Middleware in the Oracle Fusion Applications middle tier or on a separate DMZ machine. For either case, patching OHS requires extra steps after running the RUP installer. You must patch OHS using RUP Lite for OHS as described in Section 5.5.2, "Complete the WebGate Upgrade Using RUP Lite for OHS".
Oracle Fusion Middleware Extensions for Applications
Oracle Global Order Promising
Oracle Secure Enterprise Search (SES)
Oracle SOA Suite
Oracle WebCenter Suite
Oracle WebLogic Server
Oracle Web Tier
The following patches are not supported by these configuration tasks:
Patching Integrated Development Environment (IDE)
Patching 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 Section 5.3.4, "Apply Mandatory Prerequisite Patches".
Patching your Oracle Identity Management Server. For more information, refer to Oracle Fusion Applications release notes for information about mandatory IDM patches.
The following validation steps are performed during this task:
Taxonomy URL
Database validation
Flexfield: Checks for the HelpPortal Managed Server in the Common Domain and for the successful deployment of the FndSetup application
OAM Configuration
SOA Shared Repository: Verifies the taxonomy, checks if the Administration Server is up, and if the SOA platform is ready
UpdateSOAMDS SOA Composite: 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.6.20, "Merging SOA Composite JDeveloper Customizations While Applying a RUP".
Image Routing (IPM): Checks if the IPM server is up
SES Administration Server URL
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
This section describes the following preparation steps for installing a RUP, all of which can be performed before your scheduled down time.
Confirm Installation of Oracle Fusion Applications 11g Release 1 (11.1.3.0.0)
Confirm All Oracle Homes Are Registered in the Central Inventory
Verify Credentials in Oracle Directory Services Manager (ODSM)
Before you begin the upgrade, you should have access to the following documentation:
RUP Installer documentation from the previous release
Oracle Fusion Applications release notes from the previous release
Oracle Fusion Applications release notes from the release you are upgrading to
You should also have a clear understanding of the following host and directories:
Primordial host: The primordial host is where the Administration Server for the Common Domain runs
APPLICATIONS_CONFIG: The top-level directory for the Oracle Fusion Applications configuration files
Note that the APPLICATIONS_CONFIG value can be obtained from the APPLICATIONS_BASE/fusionapps/faInst.loc file.
APPLICATIONS_BASE: The top-level directory for the Oracle Fusion Applications binaries
FA_ORACLE_HOME: Directory named applications, located under the fusionapps Oracle Fusion Applications Middleware home
For more information, see "Provisioned Oracle Fusion Applications Home Directories" in the Oracle Fusion Applications Administrator's Guide.
Ensure that you have successfully installed RUP2 and followed all post installation tasks in the RUP2 documentation and in the "Applying Patches" section of RUP2 Release notes. For more information about release notes, see Oracle Fusion Applications Release Notes, 11g Release 1, Update 2 (11.1.3.0.0).
The RUP repository contains RUP Installer and Oracle Fusion Middleware patches that are required to install a RUP 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.
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.
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.
Confirm that DBMS_STATS has recently been run on the MDS schema in the Oracle Fusion Applications database. This step optimizes the performance of starting servers. For more information, see "Collecting Optimizer Statistics" in the Oracle Fusion Applications Administrator's Guide..
Then follow the steps in "Configuring Oracle Metadata Services" in the Oracle Fusion Applications Post-Installation Guide.
Follow this step only if you have updated OPatch in the FA_ORACLE_HOME outside of what Oracle Provisioning and RUP Installer installs.
Oracle Fusion Applications is compatible with a specific version of OPatch instead of the generic version of OPatch. If an incompatible version of OPatch exists in FA_ORACLE_HOME, errors can occur while applying patches and running RUP Installer. The compatible version of OPatch is available on My Oracle Support under patch 14044793.
If the file, FA_ORACLE_HOME/OPatch/ocm/lib/emocmclnt.jar exists, then you have an incompatible version of OPatch, and you must contact Oracle Support to fix this issue. On Windows, look for FA_ORACLE_HOME\OPatch\ocm\lib\emocmclnt.jar.
Confirm that 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.
RUP Installer requires at least 6GB of free memory on the 64-bit domains to be up during the installation. RUP Installer also requires at least 6GB of free memory on the 64-bit primordial host that the installer is launched from, for the duration of the RUP installation. This requirement of 6GB of free memory 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.
For Unix platforms, confirm that the host names are correctly formatted in the /etc/hosts file, and that this file contains entries for all hosts used by Oracle Fusion Applications to ensure that all hosts are visible from the primordial host. The /etc/hosts file is a network configuration file that associates IP addresses with host names and host alias names, if used. Every hosts file in Unix platforms should have an entry for the IP address 127.0.0.1, with the name localhost following it. For more information, see "Edit Host Names (Linux)" in the Oracle Fusion Applications Installation Guide.
Check the local port range value in /proc/sys/net/ipv4/ip_local_port_range before starting the installation. The recommended value is 32768 61000. If the range is set to any value below 32768, a system process could potentially use a port that was assigned to one of the Managed Servers. Since RUP Installer requires all domains to be down, those ports are available for the system to use.
To set the correct local port range, log in as the root user and run the following command:
echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range
Perform the following steps to confirm that your database settings are optimized for the RUP installation:
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 workers are calculated and the requirement for the open file limit setting for the workers, see Section 3.1.2, "Patching Database Artifacts". For more information, see "Increase the Open Files Limit" in the Oracle Fusion Applications Installation Guide
Confirm that the SQL*Net Timeout Configuration is set properly.
The exact setting in your environment depends on your network configuration and machine resources. Refer to "SQLNET.EXPIRE_TIME Parameter" and "INBOUND_CONNECT_TIMEOUT Parameter" in the Oracle Fusion Applications Performance and Tuning Guide to determine the parameters that need to be set.
Note:
If you are upgrading from a previous release, Oracle homes are likely to be already registered properly, so you can skip this step now.
Oracle Provisioning records information about the following Oracle homes separately from information about other products: Oracle Business Intelligence (Oracle BI), Oracle Global Order Promising (GOP), Web Tier, and Web Tier Common Oracle home installation information. RUP Installer expects information about all products to be recorded in the same place. To transfer information about the Oracle BI, GOP, and Web Tier installations to the same location as information about other products, perform the following steps. For more information about home directories, see "Provisioned Oracle Fusion Applications Home Directories" in the Oracle Fusion Applications Administrator's Guide.
Verify that the default Inventory Pointer file points to the central inventory on the primordial host on which RUP Installer runs. The default Inventory Pointer is in the following locations:
Unix: /etc/oraInst.loc
Solaris: /var/opt/oracle/oraInst.loc
Windows: located in the registry key, \\HKEY_LOCAL_MACHINE\\Software\Oracle\inst_loc
Run attachHome from the BI Oracle home, for example, APPLICATIONS_BASE/fusionapps/bi.
(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, for example, APPLICATIONS_BASE/fusionapps/gop.
(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 Web Tier Oracle home, for example, APPLICATIONS_BASE/webtier_mwhome/webtier.
(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 Web Tier Common Oracle home, for example, APPLICATIONS_BASE/webtier_mwhome/oracle_common.
(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 attachHome from the Oracle Common Oracle home.
(Unix) APPLICATIONS_BASE/fusionapps/oracle_common/oui/bin/attachHome.sh -jreLoc JAVA_HOME_LOCATION (Windows) APPLICATIONS_BASE\fusionapps\oracle_common\oui\bin\attachHome.cmd -jreLoc JAVA_HOME_LOCATION
Register the dependency between the BI Oracle home and Oracle Common Oracle home.
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) BI_HOME/oui/bin/runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST=
{APPLICATIONS_BASE/fusionapps/bi:APPLICATIONS_BASE/fusionapps/oracle_common}"
-jreLoc JAVA_HOME_LOCATION
(Windows) BI_HOME\oui\bin\setup.exe -updateHomeDeps "HOME_DEPENDENCY_LIST=
{APPLICATIONS_BASE\fusionapps\bi:APPLICATIONS_BASE\fusionapps\oracle_common}"
-jreLoc JAVA_HOME_LOCATION
Register the dependency between Web Tier Oracle home and Web Tier Common Oracle home.
(Unix) WEBTIER_HOME/oui/bin/runInstaller -updateHomeDeps "HOME_DEPENDENCY_LIST=
{APPLICATIONS_BASE/webtier_mwhome/webtier:APPLICATIONS_BASE/webtier_mwhome/oracle_common}"
-jreLoc JAVA_HOME_LOCATION
(Windows) WEBTIER_HOME\oui\bin\setup.exe -updateHomeDeps "HOME_DEPENDENCY_LIST=
{APPLICATIONS_BASE\webtier_mwhome\webtier:APPLICATIONS_BASE\webtier_mwhome\oracle_common}"
-jreLoc JAVA_HOME_LOCATION
Verify that the central inventory now contains the correct GOP, BI, and Web Tier 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 1. Verify that there are entries for GOP and for BI, and that the BI entry lists the Oracle Common dependency you specified in Step 6. Do the same for Web Tier 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="APPLICATIONS_BASE/fusionapps/gop" TYPE="O" IDX="11"> <HOME NAME="OH198367808" LOC="APPLICATIONS_BASE/fusionapps/bi" TYPE="O" IDX="12"> <DEPHOMELIST> <DEPHOME LOC="APPLICATIONS_BASE/fusionapps/oracle_common"/> </DEPHOMELIST> </HOME> <HOME NAME="OH987588708" LOC="APPLICATIONS_BASE/webtier_mwhome/webtier" TYPE="O" IDX="13"> <DEPHOMELIST> <DEPHOME LOC="APPLICATIONS_BASE/webtier_mwhome/oracle_common"/> </DEPHOMELIST> </HOME> <HOME NAME="OH1271096710" LOC="APPLICATIONS_BASE/webtier_mwhome/oracle_common" TYPE="O" IDX="14"> <REFHOMELIST> <REFHOME LOC="APPLICATIONS_BASE/webtier_mwhome/webtier"/> </REFHOMELIST> </HOME>
Note:
Rerunning the ATTACH_HOME command does not cause any issues.
Run the preRupSeeding.py script to perform updates to seed several Oracle Fusion Middleware schema credentials for the schema upgrade.
Unzip the script.
The script is located in REPOSITORY_LOCATION/installers/companionCD.zip. Unzip the script to APPLICATIONS_BASE/fusionapps/applications/admin/preupg, as shown in the following command.
unzip -j companionCD.zip -d APPLICATIONS_BASE/fusionapps/applications/admin/preupg
Ensure that the Common Domain is running, and then run the following command.
APPLICATIONS_BASE/fusionapps/oracle_common/common/bin/wlst.sh APPLICATIONS_BASE/fusionapps/applications/admin/preupg/preRupSeeding.py
This script connects to the Administration Server and prompts you for the following values. You can press Enter to accept default values.
WLST credentials, including the user name, password and server URL for the CommonDomain Administration server.
Oracle Fusion Applications database credentials, including the Oracle Database host name, port number, and sid or service. These values can be found in the DB_CONNECT_STRING row of FA_ORACLE_HOME/admin FUSION_env.properties.
SYSDBA user name and password.
Various schema credentials including:
CRM_FUSION_MDS_SOA Schema Owner
CRM_FUSION_SOAINFRA Schema Owner
FIN_FUSION_MDS_SOA Schema Owner
FIN_FUSION_SOAINFRA Schema Owner
FUSION_ACTIVITIES Schema Owner
FUSION_APM Schema Owner
FUSION_BIPLATFORM Schema Owner
FUSION_OCSERVER11G Schema Owner
FUSION_ORA_ESS Schema Owner
FUSION_WEBCENTER Schema Owner
HCM_FUSION_MDS_SOA Schema Owner
HCM_FUSION_SOAINFRA Schema Owner
OIC_FUSION_MDS_SOA Schema Owner
OIC_FUSION_SOAINFRA Schema Owner
PRC_FUSION_MDS_SOA Schema Owner
PRC_FUSION_SOAINFRA Schema Owner
PRJ_FUSION_MDS_SOA Schema Owner
PRJ_FUSION_SOAINFRA Schema Owner
SCM_FUSION_MDS_SOA Schema Owner
SCM_FUSION_SOAINFRA Schema Owner
SEARCHSYS Schema Owner
SETUP_FUSION_SOAINFRA Schema Owner
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.
If you performed JDeveloper customizations to a SOA composite and then you deployed the composite to the SOA runtime, you must perform manual steps to merge your customizations during the RUP installation. To ensure that your customizations can be merged successfully, review the recommendations in "Merging Runtime Customizations from a Previously Deployed Revision into a New Revision" in the Oracle Fusion Applications Extensibility Guide before you start RUP Installer.
You will merge your customizations after the Online Verification configuration task fails during the RUP installation. For more information, see Section 5.6.20, "Merging SOA Composite JDeveloper Customizations While Applying a RUP".
Verify that the following credentials are present in ODSM by performing the following steps:
Log in to Oracle Internet Directory using ODSM: http://ldap_host:port/odsm, for example, http://IDM_HOST:7005/odsm. (Note that you cannot do this using jexplorer.)
Connect to a directory. Use the OID-OID connection, for example, where the User name is cn=orcladmin and the Password is password.
Go to the Data Browser tab. Go to the cn=oracle internet directory and within the cn=oracle internet directory, go to cn=DirectoryAdminGroup.
Verify that this user entry is present in the Members section:
cn=PolicyRWUser,cn=users,dc=us,dc=oracle,dc=com
If the entry is not present, click the add [+] button in the Members section and add the entry. Then apply the changes.
Perform the following steps to move the userpref_currencies.xml file.
Review the following file:
APPLICATIONS_BASE/instance/BIInstance/config/OracleBIPresentationServicesComponent/coreapplication_obips1/instanceconfig.xml
Check if the file contains the following element:
<UserprefCurrenciesConfigFile>[BI InstanceHome] /config/OracleBIPresentationServicesComponent/coreapplication_obips1/ userpref_currencies_OTBI.xml</UserprefCurrenciesConfigFile>
If this element is not available, perform the following steps in this section. If this element is available, no further action is required.
Back up the file, APPLICATIONS_BASE/instance/BIInstance/config/OracleBIPresentationServicesComponent/coreapplication_obips1/userpref_currencies.xml to userpref_currencies.xml.backup.
Copy the file, BI_ORACLE_HOME/bifoundation/admin/config/OracleBIPresentationServicesComponent to BI_INSTANCE_HOME/config/OracleBIPresentationServicesComponent/coreapplication_obips1/userpref_currencies.xml.
For example, copy from:
/u01/APPTOP/fusionapps/bi/bifoundation/admin/config/OracleBIPresentationServicesComponent/userpref_currencies_OTBI.xml
to:
/u01/APPTOP/instance/BIInstance/config/OracleBIPresentationServicesComponent/coreapplication_obips1/userpref_currencies.xml.
If you are using local domains, replace APPTOP with the local domain directory.
Bounce the coreapplication_obis1 server.
RUP Installer expects the default realm name to be myrealm for the Common Domain. Verify that you have not changed this value to any other name, because changing the name to anything other than myrealm causes RUP Installer to fail. Log in to the WLS Console for the Common Domain and click Security Realms on the domain structure pane. A list of realms displays, where you can verify that there is an entry for myrealm and that it is the default realm.
RUP Installer makes WebLogic configuration changes using Oracle WebLogic Scripting Tool (WLST), which may overwrite any unsaved changes. Ensure that any pending WebLogic configuration changes are either activated or discarded. For more information, see "Configuring Existing WebLogic Domains" in Oracle Fusion Middleware Oracle WebLogic Scripting Tool.
The following steps must be performed for non-Linux platforms:
Add the -d64 option to JRE_MEMORY_OPTIONS in the following file:
APPLICATIONS_BASE/fusionapps/applications/oui/oraparam.ini
Adding this option prevents OPatch from failing with this error:
APPLICATIONS_BASE/fusionapps/applications/oui/lib/intelsolaris/liboraInstaller.so:
wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
On Oracle Solaris on x86-64 (64-bit) systems, change the permission of the oraInst.loc file to Read-only mode before starting RUP Installer. This will prevent a failure during the Database Content Upload step of the Offline Preverification configuration task.
On IBM AIX on POWER Systems (64-bit), set the value for the SKIP_ROOTPRE environment variable as follows:
SKIP_ROOTPRE=TRUE
This prevents an Oracle Web Tier installation failure.
This section describes the following preparation steps for installing a RUP, all of which must be performed during your system down time.
Upgrade Identity Management Domain to 11g Release 1 Update 3 (11.1.4)
Install Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)
Ensure that you have followed the steps described in Oracle Fusion Applications release notes, in the section titled "Upgrading Security Application Policies for Oracle Business Intelligence Applications and Oracle Fusion Transactional Business Intelligence". Not doing so will cause RUP Installer to fail during the Applying BI Metadata Updates configuration task.
Note:
This prerequisite step is applicable only if you are upgrading from Oracle Fusion Applications Release 1, Update 1 (11.1.2.0.0) to Release 1, Update 2 (11.1.3.0.0) to Release 1, Update 3 (11.1.4.0.0). It does not apply if you installed Release 1, Update 2 (11.1.3.0.0) as a new installation and are upgrading to Release 1, Update 3 (11.1.4.0.0).
Perform the following steps to confirm the upgrade was completed:
Log in to Authorization Policy Manager (APM).
Expand Applications.
Expand obi.
Right click Role Catalog and select Open.
Verify the following information about roles in your obi stripe:
Role FBI_SUPPLIER_MASTER_DATA_TRANSACTION_ANALYSIS_DUTY is present
Role OBIA_PARTNER_ANALYSIS_DUTY is present and it has the following members:
ZPM_PARTNER_SALES_MANAGER_JOB
ZPM_PARTNER_SALES_REPRESENTATIVE_JOB
Role OBIA_PARTNER_ANALYSIS_DUTY is a member of the following roles:
OBIA_PARTNER_CURRENCY_PREFERENCES
OBIA_RESOURCE_HIERARCHY_DATA_SECURITY
OBIA_TERRITORY_HIERARCHY_DATA_SECURITY
Role OBIA_PARTNER_ORG_ANALYSIS_DUTY has no members
Perform the following steps to upgrade your Identity Management environment to 11g Release 1 Update 3 (11.1.4):
Stop all servers and processes in the Oracle Fusion Applications domain, except the OPSS Security Store and the database, before starting the Identity Management upgrade. For more information, see "Starting and Stopping" in the Oracle Fusion Applications System Administrator's Guide. Also confirm that the BI presentation servers are shut down.
Shut down the Oracle Enterprise Scheduler Service (ESS) server by performing the following steps:
Stop the ESS request processor and dispatcher to prevent new requests from being processed. For more information, see "Starting and Stopping Oracle Enterprise Scheduler Service Components" in the Oracle Fusion Applications Administrator's Guide.
Cancel any in-progress requests. For more information, see "Cancelling Oracle Enterprise Scheduling Service Job Requests" in the Oracle Fusion Middleware Administrator's Guide for Oracle Enterprise Scheduling Service.
Shutdown the ESS WebLogic Server Managed server. For more information, see the "Starting and Stopping" table in the Oracle Fusion Applications Administrator's Guide.
Refer to Document ID 1441704.1 on My Oracle Support and follow the remaining mandatory Identity Management upgrade steps.
Follow the steps in "Installing Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management to obtain GCC libraries for Linux 64-bit or Solaris 64-bit SPARC. Copy both GCC libraries into the following directory: REPOSITORY_LOCATION/installers/webgate.
Perform the following steps to apply mandatory prerequisite patches.
After you complete the Identity Management upgrade, confirm that all servers and processes in the Oracle Fusion Applications domain, except the OPSS Security Store and the database, are down before applying the prerequisite patches. For more information, see "Starting and Stopping" in the Oracle Fusion Applications System Administrator's Guide. Also confirm that the BI presentation servers are shut down. For Windows, see Section 5.3.4.1, "Stop Services on Windows Before Applying Mandatory Patches".
Ensure you have upgraded your database to 11.2.0.3. Apply mandatory Oracle Database patches mentioned in the "Oracle Database" section of Oracle Fusion Applications release notes.
Apply all prerequisite patches mentioned in the "Oracle Fusion Middleware" section of Oracle Fusion Applications release notes.
Apply all prerequisite patches mentioned in the "Applying Patches" section of Oracle Fusion Applications release notes.
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.
For a Windows platform, the following services must be stopped:
OracleOraDb11g_home1TNSListenerLISTENER_<SID>
OracleOraDb11g_home1ClrAgent
OracleDBConsole<SID>
OracleJobScheduler<SID>
OracleService<SID>
OracleMTSRecoveryService
Windows Management Instrumentation
Distributed Transaction Coordinator
Oracle <SID> VSS Writer Service
From the Control Panel, select Administrative Tools, then Services. Right click on each service and choose the Stop option.
There are patches that are required to be applied to your database server installation as prerequisites for applying Oracle Fusion Applications RUP3. Because the database server is normally installed on a separate machine, these patches are not applied by the RUP Installer. Instead, you must apply these patches manually.
To verify that all required database server patches have been applied, you must create a zip file that contains the patch validation tool and the database server patches, copy the zip file to your database server box, and then run the included patch validation tool. If you have installed the database server on multiple machines, for a RAC install, you must copy the zip file to each machine and run the included patch validation tool on each machine.
Perform the following steps to create the database server patch validation zip file:
Get the CreateTPBundle utility files.
Unzip TPBundler.zip in a temporary directory. You can find the TPBundler.zip file in the REPOSITORY_LOCATION/installers/patch_bundler directory. The TPBundler.zip file contains files used by the CreateTPBundle utility to create the database server patch validation zip file.
Run the CreateTPBundle utility to create the database server patch validation zip file, which contains database server patches and the patch validation tool.
Go to the directory where you unzipped TPBundler.zip.
Use the createTPBundle command to create the database server patch validation zip file using the following command syntax:
sh createTPBundle.sh -target DB -shiphomelocation REPOSITORY_LOCATION -tempdir any_temporary_directory -zipfile database_server_patch_validation_zip_file_name -release standalone [-logfile log_file_location] [-loglevel log_level]
If you receive the following message about missing patches, you can disregard it:
<missing_patches>
<patch_id>13257247</patch_id>
<patch_id>13004894</patch_id>
<patch_id>13454210</patch_id>
</missing_patches>
Table 5-4 provides a list of arguments for the CreateTPBundle command.
Table 5-4 Description of CreateTPBundle Arguments
| Name | Description | Mandatory |
|---|---|---|
|
|
The utility identifies the patches to include in the patch bundle using a combination of the |
Yes. |
|
|
Top level directory of the RUP repository. The patch_bundler directory should be under |
Yes. |
|
|
Complete path of any temporary directory which has read and write permissions. This directory is used to stage the database server patch validation zip file contents and must exist before you run this command. |
Yes. |
|
|
Name of the database server patch validation zip file. The default value is target.zip in the |
No, depends on the target value. |
|
|
The utility identifies the patches to include in the patch bundle using a combination of the |
Yes. |
|
|
Full path to the log file. |
No, default value is |
|
|
Log level for the utility. Valid values are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. |
No, default value is INFO. |
|
|
Displays usage message and exits with success. |
No. |
The techpatch utility uses OPatch utilities to check whether a patch has been applied, so you must verify that the OPatch version in the database server Oracle home is at least version 11.2.0.3.0.
OPatch depends on Oracle Universal Installer (OUI), and does not work correctly if the OPatch and OUI versions are not compatible. For example, you cannot use OPatch version 11.1 with OUI version 11.2, or vice-versa. Most software installations used by Oracle Fusion Applications Release 1, Update 3 (11.1.4.0.0) (RUP3) include OUI and OPatch version 11.1. For these software installations, the minimum required OPatch version for patch validation to work correctly is 11.1.0.9.5 (or a higher 11.1 version) of OPatch. The database server software for Oracle Fusion Applications RUP3 includes OUI and OPatch version 11.2. Specifically for the database server installation, the minimum required OPatch version for patch validation to work correctly is 11.2.0.3.0 (or a higher 11.2 version) of OPatch. Be careful not to install OPatch 11.1.0.9.5 (or a higher 11.1 version) in the database server Oracle home, and be careful not to install OPatch 11.2.0.3.0 (or a higher 11.2 version) in any Oracle Fusion Middleware, OHS, or IDM Oracle home, as neither of these combinations will work correctly.
Go to the OPatch directory under your database server Oracle home and run the following command:
opatch version
The output is similar to the following:
OPatch Version: 11.2.0.3.0 OPatch succeeded.
If the OPatch version is less than 11.2.0.3.0, you must upgrade your OPatch version. To upgrade your OPatch version, download and install the required version of OPatch from My Oracle Support. Installation instructions are in the Readme file of the patch zip file. In general, installing a new version of OPatch consists of unzipping the zip file from the downloaded patch directly under the Oracle home directory.
Perform the following steps to validate that all database server prerequisite patches have been applied:
Copy the database server patch validation zip file that you created in Section 5.3.5.1, "Create the Database Server Patch Validation Zip File" to the database server machine.
Unzip this file in a temporary directory.
Edit patch validation utility configuration files.
The utility that validates the database server patches is called TechPatch. It is located in the techpatch subdirectory under the top-level directory in the zip file. You must edit the TechPatch configuration file techpatchutil.properties before running the TechPatch utility.
For RAC installations with local Oracle homes, you must edit this file separately and run the patch validation utility separately on each machine. For non-RAC installations and for RAC installations with shared Oracle homes, you only need to edit this file and run the patch validation utility on one machine.
To edit the techpatchutil.properties file, open it with a text editor and specify values for the following properties:
db_home: The Oracle home under which the database server is installed, for example, db_home=/u01/dbhome.
db_host: The host name where the database instance is present, for example, db_host=xyz.domain.com.
Go to the db_server_bundle/techpatch subdirectory under the temporary directory where you unzipped the patch validation zip file and run techpatch.sh. using the following command syntax:
./techpatch.sh -target DB -jobsxmlpath ./jobs.xml -patchbaseloc ../db_server
-jreloc JAVA_HOME/jdk6 -validate true
Table 5-5 provides a description of the arguments for the techpatch command.
Table 5-5 Description of techpatch Arguments
| Name | Description | Mandatory |
|---|---|---|
|
|
Target environment against which the patches will be validated. The value must be |
Yes. |
|
|
Full path of the jobs XML file which describes how to validate or apply patches. The value is |
Yes. |
|
|
Top level directory that contains all patches to be applied. The value is .. |
Yes. |
|
|
Top level directory that contains installed Oracle Fusion Applications and Tech Stack components. The directory path may require |
Required for FAMW target. Not used by IDM target. |
|
|
Location of your JAVA_HOME. Make sure you have a jdk6 installation on the database host. |
Yes. |
|
|
If set to true, tells |
No, by default, techpatch applies patches listed in the jobs XML file instead of checking to see if they have already been applied. |
|
|
Full path of the properties file used for applying patches. |
No, default value is |
|
|
Full path of the |
No, default value is |
|
|
Log level for the utility. Valid values are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST. |
No, default value is INFO. |
To prevent issues during the Bootstrapping Patch Manager configuration task, run the following script as SYS user on all database instances before you start RUP Installer:
ORACLE_HOME/rdbms/admin/catmetx.sql
This section contains steps to follow for all platforms. For Windows platforms, also follow the steps in Section 5.3.7.12, "Steps for Windows Platforms".
To prevent locks on patched objects and other data issues during patching, review and perform the following tasks 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 "Understand the Starting and Stopping with the fastartstop Utility" in the Oracle Fusion Applications System Administrator's Guide. Confirm that BI presentation servers are shut down before starting RUP Installer.
If you successfully completed the steps in Section 5.3.7.1, "Stop All Servers" and all servers were cleanly shut down, then you can skip this step.
If servers were not cleanly shut down, update the CrashRecoveryEnabled property in nodemanager.properties to "false" for all hosts. The nodemanager.properties file exists in the following location:
APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/nodemanager/host/nodemanager.properties
Note that there may be an extra nodemanager.properties file in the APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/nodemanager/nodemanager.properties directory. This file is not used and can be ignored.
Perform the following steps related to Oracle Secure Enterprise Search (Oracle SES).
Stop all running schedules.
Get a list of running schedules by running the following command. The schedules with a status of EXECUTING are the running schedules.
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService getAllStates schedule
Stop a running schedule by running the following command:
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService stop schedule -n schedule_Name
Note:
To get a list of all schedules defined in Oracle SES, execute the following command:
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService getAllObjectKeys schedule
Deactivate the schedules that may start running during the RUP installation.
The schedules that may start running during the RUP installation, such as daily schedules, must be deactivated. Execute the following command to deactivate such schedules:
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService deactivate schedule -n schedule_Name
Stop the Index Optimizer.
Run the following command to stop the Index Optimizer:
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService stop indexOptimizer
Deactivate the Index Optimizer if it may start running during the RUP installation.
If the time at which the Index Optimizer is scheduled to run overlaps with the time period of the RUP installation, then the Index Optimizer must be deactivated before starting the RUP installation. Run the following command to deactivate the Index Optimizer:
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService deactivate indexOptimizer
Stop the Node Manager and the OPMN control process. All OHS and Web Tier processes, including the Apache processes, must also be stopped if you are not running OHS from a separate installation (DMZ or otherwise). (On Windows, stop the Node Manager and OPMN services and follow steps 1 and 2 in Section 5.3.7.12, "Steps for Windows Platforms".) Note that you must start the Node Manager for all domains and the OPMN control process after the first installer completes successfully and before proceeding to the second installer.
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 Oracle Business Intelligence, GOP, and Web Tier (OHS). This procedure also stops all BI server processes, all GOP processes, and the OHS process.
Note:
There should be no Web Tier 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 Web Tier processes.
Set ORACLE_INSTANCE to the location of the target Oracle instance directory.
Go to the bin directory under the target Oracle instance directory.
Run the opmnctl program from the current directory with the stopall command.
The following example is for Oracle Business Intelligence, where BIInstance is the location of BIInstance. Depending on whether Local Applications Config is enabled for your setup, BIInstance is located under either the Applications Config directory or the Local Applications Config directory of the BI host.
(Unix)INSTANCE_HOME=APPLICATIONS_CONFIG/BIInstance; export INSTANCE_HOME cd $ORACLE_INSTANCE/bin ./opmnctl stopall (Windows) set INSTANCE_HOME=APPLICATIONS_CONFIG\instance\BIInstance cd $ORACLE_INSTANCE\bin .\opmnctl stopall
Example for GOP:
(Unix)ORACLE_INSTANCE=APPLICATIONS_CONFIG/gop_1; export ORACLE_INSTANCE cd $ORACLE_INSTANCE/bin ./opmnctl stopall (Windows) set INSTANCE_HOME=APPLICATIONS_CONFIG\gop_1 cd $ORACLE_INSTANCE\bin .\opmnctl stopall
Example for Web Tier (OHS):
(Unix) INSTANCE_HOME=APPLICATIONS_CONFIG/CommonDomain_webtier; export INSTANCE_HOME cd $ORACLE_INSTANCE/bin ./opmnctl stopall (Windows) set INSTANCE_HOME=APPLICATIONS_CONFIG\CommonDomain_webtier cd $ORACLE_INSTANCE\bin .\opmnctl stopall
For more information about the location of APPLICATIONS_CONFIG, see Section 5.2.1, "Before You Begin".
For more information about concepts related to ORACLE_HOME and ORACLE_INSTANCE, refer to the "Understanding Oracle Fusion Middleware Concepts" chapter in the Oracle Fusion Middleware Administrator's Guide.
Start the OPSS Security Store if it is not already running. The OPSS Security Store used here is an Oracle Internet Directory LDAP server instance. Before proceeding with the RUP installation, the designated Oracle Internet Directory server instance must be up and running. If this server is not running prior to starting the installation, the related configuration tasks will fail. For more information, see Section 5.6.8, "LdapServerCheck Failure During Offline Preverification".
For more information about starting, see "Starting and Stopping Oracle Internet Directory" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
If you are running on a RAC database, ensure that the first node (host and port) in the TNS descriptor is up and running prior to running RUP Installer. If this is not running, the Upgrading Middleware Schemas configuration task will fail.
If you added any servers, you must start the new servers at least once before you run RUP Installer. This step is not required for a server that has previously been started at least once since you initially installed Oracle Fusion Applications.
Confirm there are no active jobs or processes running against the database. If you stop all servers, including ESS servers, most Oracle Fusion Applications processes are shut down. However, some database jobs could still be running or scheduled to start. These processes must be stopped so that they do not start while patching is in progress. Stop all background jobs, including jobs in the database and active processes.
To confirm if the database is running in idle mode, you can follow the steps below:
Start SQL*Plus and connect as the SYS user and run the following SQL*Plus queries.
To retrieve a list of active SQL processes:
select a.sid, a.serial#, b.sql_text
from v$session a, v$sqlarea b
where a.sql_address=b.address
and a.username in ('FUSION', 'FUSION_RUNTIME')
and a.sid <> sys_context('USERENV', 'SID');
To retrieve a list of scheduler jobs that are currently running:
select owner, job_name from dba_scheduler_running_jobs;
To retrieve a list of scheduled jobs for the next 24 hours:
select owner, job_name from dba_scheduler_jobs where state = 'SCHEDULED' and next_run_date between sysdate and sysdate+1;
If all the queries return no rows, that indicates the database is in Idle mode for the next 24 hours and you can safely proceed with the upgrade.
From your operating system, check for processes that are running fapmgr, javaworker, adpatch, adadmin, and adworker. If an fapmgr session was interrupted, you may need to forcefail and abandon the session as follows:
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]
If the forcefail command returns "There are no active Oracle Fusion Applications Patch Manager sessions which can be forcibly failed", then skip the next step.
Use the fapmgr abort command to abandon the session, only if a session is active.
(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]
If an Oracle Fusion Applications AutoPatch session is running, you must abandon the session as follows.
Run the following command from ATGPF_ORACLE_HOME: (This is the directory under MW_HOME that contains the Applications Core code. For more information, see Section 7.1.2, "Running Oracle Fusion Applications AutoPatch".)
(Unix) lcm/ad/bin/adpatch.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt logfile=logfile_name.log (Windows) lcm\ad\bin\adpatch.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\LOCAL\defaults.txt logfile=logfile_name.log
The TWO_TASK value can be obtained from the ATGPF_env.properties file.
The LOCAL value can be obtained from the FUSION_env.properties file.
If an AD Administration session 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.txt logfile=log_file_name (Windows) lcm\ad\bin\adadmin.cmd abandon=y interactive=n defaultsfile=FA_ORACLE_HOME\admin\LOCAL\defaults.txt logfile=log_file_name
The TWO_TASK and LOCAL values can be obtained from the FUSION_env.properties file.
From ATGPF_ORACLE_HOME
(Unix) lcm/ad/bin/adadmin.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults.txt logfile=log_file_name (Windows) lcm\ad\bin\adadmin.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\LOCAL\defaults.txt logfile=log_file_name
The TWO_TASK and LOCAL values can be obtained from the ATGPF_env.properties file.
Follow these steps before you install a RUP on A Windows platform.
Change the service type from Automatic to Manual for the following services: Node Manager, Web Tier, GOP, and BI. Restore the service type back to Automatic after RUP installation completes.
Stop the following services: Node Manager, Web Tier, 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.
Increase the shared_pool_size in the init.ora file. If it seems large enough then improve segmentation in the shared pool by reserving part of the shared pool for large objects using the SHARED_POOL_RESERVED_SIZE parameter. The recommended value to start tuning is one third of the shared pool size. You can allow for large objects by using the SHARED_POOL_RESERVED_MIN_ALLOC parameter.
To ensure that the Java parameters in fusionapps_start_params.properties are set for the servers in all the domains in the RUP Installer environment, and to prevent OutOfMemory exceptions from the servers, perform the following steps:
Shutdown all WebLogic Servers.
Rename the FA_ORACLE_HOME\instance\domains\HOST_NAME\DOMAIN_NAME\bin\setFusionAppsDomainEnv.cmd as setFusionAppsDomainEnv_orig.cmd for all domains.
Copy repo\provpatches\Bug13568823\setFusionAppsDomainEnv.cmd to FA_ORACLE_HOME\instance\domains\HOST_NAME\DOMAIN_NAME\bin folder for all domains.
The following backups must be performed before you install a 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. You should also back up your central inventory.
For additional back up steps that are specific to Windows, refer to Section 5.3.8.3, "Back Up Steps for Windows Platforms".
RUP Installer upgrades all WLS domains to the 11gR1 PS5 MLR1 (11.1.1.6.1) level so you must perform the following backups. Make sure you perform your backups in directories that you can restore from. You can use any directory to back up the data, as long as you know where to restore the backup from.
OPSS Security Store
Back up all data under the root node of the OPSS Security Store. To identify the root node in the Oracle Internet Directory hosting the OPSS Security store, use Fusion Applications Control and look at the Root Node Details pane under the Security Provider information. For more information, see "Reassociating with Fusion Middleware Control" in the Oracle Fusion Middleware Application Security Guide.
In case of an upgrade failure, restore this node entirely. The ldifwrite and bulkload operations that follow must be performed on the system where the Oracle Internet Directory hosting the OPSS Security store resides.
Set the following environment variables.
setenv ORACLE_HOME OID_ORACLE_HOME setenv ORACLE_INSTANCE OID_INSTANCE_HOME
Example:
setenv ORACLE_HOME /u01/oid/oid_home setenv ORACLE_INSTANCE /u01/oid/oid_inst
Follow this step to create the backup.
In the system where the Oracle Internet Directory is located, produce an LDIF file by running ldifwrite as illustrated in the following line:
OID_HOME/ldap/bin/ldifwrite connect="srcOidDbConnectStr" basedn="cn=FAPolicies", c=us" ldiffile="srcOid.ldif"
Example:
/u01/oid/oid_home/ldif/bin/ldifwrite connect="oidddb" basedn="cn=FAPolicies" ldiffile="srcOid.ldif"
This command writes all entries under the node cn=FAPolicies to the file srcOid.ldif. Once generated, move this file to the directory that was identified earlier, to hold all backup data.
Follow these steps to restore the backup.
In the Oracle Internet Directory system, verify that there are no schema errors or bad entries by running bulkload as illustrated in the following line:
OID_HOME/ldap/bin/bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
If duplicate DNs (common entries between the source and destination directories) are detected, review them to prevent unexpected results.
Load data into the Oracle Internet Directory by running bulkload as illustrated in the following line:
OID_HOME/ldap/bin/bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
For more information about the bulkload command, see "Performing Bulk Operations" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
For more information about migrating Oracle Internet Directory, see "Migrating Large Volume Policy and Credential Stores" in the Oracle Fusion Middleware Application Security Guide.
Bootstrap Wallet
Back up the cwallet.sso file in the DOMAIN_HOME/config/fmwconfig/bootstrap directory for each WLS domain in an Oracle Fusion Applications installation. You must take backups of each cwallet.sso file for each domain and when you restore, you must be careful to restore the correct file. For example, if you back up cwallet.sso from the Common Domain, then you must restore it in the Common Domain upon failure. If you back up cwallet.sso from the BI domain, you must restore it in the BI Domain upon failure.
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 |
0 |
0 |
0 |
|
|
Files: |
787114 |
787114 |
0 |
0 |
0 |
|
|
Bytes: |
63.822 g |
63.822 g |
0 |
0 |
0 |
|
|
Times: |
2:22:20 |
2:19:00 |
0:00:00 |
0:03:19 |
Back up the 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
Web Tier service
BI Service
Node Manager service
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Oblix
Ensure that the System PATH has the following values:
C:\<APPLICATIONS_BASE>\dbclient\bin C:\<APPLICATIONS_BASE>\webtier_mwhome\webtier\bin C:\<APPLICATIONS_BASE>\webtier_mwhome\webtier\opmn\bin C:\<APPLICATIONS_BASE>\webtier_mwhome\webtier\opmn\lib C:\<APPLICATIONS_BASE>\webtier_mwhome\webtier\perl\bin C:\<APPLICATIONS_BASE>\fusionapps\bi\products\Essbase\EssbaseServer\bin C:\<APPLICATIONS_BASE>\fusionapps\bi\bin C:\<APPLICATIONS_BASE>\fusionapps\bi\opmn\bin C:\<APPLICATIONS_BASE>\fusionapps\bi\opmn\lib C:\<APPLICATIONS_BASE>\fusionapps\bi\perl\bin
Add any of the previous values that are missing to the system PATH. Missing values cause failures in launching the Oracle Process Manager and Notification Server (OPMN) services and Oracle Business Intelligence Presentation Services Web Catalog (Webcat) deployment tasks in RUP Installer.
Save the system PATH variable.
RUP Installer must run during down time. Oracle recommends that you run RUP Installer from a machine that is co-located in the same subnetwork as the database server to maximize performance. You must run RUP Installer from the primordial host.
Ensure that the steps in Section 5.2, "Prepare to Install a RUP - Pre-Down Time" and Section 5.3, "Prepare to Install a RUP - During Down time" are successfully completed before installing the RUP.
Note:
If you encounter errors during the RUP installation, refer to Section 5.6, "Troubleshoot RUP Installer Sessions" before clicking any buttons in the RUP Installer User Interface.
Perform the following steps to 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.
Set the JAVA_HOME environment variable as follows:
(Unix) export JAVA_HOME=APPLICATIONS_BASE/fusionapps/jdk6 (Windows) set JAVA_HOME=APPLICATIONS_BASE\fusionapps\jdk6
Confirm the registration of the network location of FA_ORACLE_HOME.
If the Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), which is APPLICATIONS_BASE/fusionapps/applications, is registered in the central inventory with a /net path, then provide the oraInst.loc location including /net when starting RUP Installer. An example follows:
REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk6/ -invPtrLoc /net/APPLICATIONS_BASE/fusionapps/applications/oraInst.loc
If not triggered with /net path, RUP Installer copies the -invPtrLoc file to FA_ORACLE_HOME. In the example, this results in a copy of the file to itself, which then becomes an empty or zero byte file. As a result, the copy phase will fail when oracle_common patches are applied. For more information, see Section 5.6.2.3, "Inventory Pointer File is Empty".
Start RUP Installer.
(UNIX) REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [-J-DserverStartTimeout=timeout_period_for_server_in_seconds] [logfile=log_file_name][-debug yes] (IBM AIX on POWER Systems (64-bit) REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [-J-DserverStartTimeout=timeout_period_for_server_in_seconds] [logfile=log_file_name][-debug yes] JVM_OPTIONS="-Xms1024m -Xmx1536m" (Solaris X64 and Solaris Sparc) REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [-J-DserverStartTimeout=timeout_period_for_server_in_seconds] [logfile=log_file_name][-debug yes] JVM_OPTIONS="-d64 -Xms512m -XX:MaxPermSize=756m -Xmx2048m" (Windows)REPOSITORY_LOCATION\installers\farup\Disk1\setup.exe -jreLoc JAVA_HOME_LOCATION [-Dworkers=number_of_workers][-DlogLevel=level] [-DserverStartTimeout=timeout_period_for_server_in_seconds] [logfile=log_file_name] [-debug yes]
Table 5-6 shows valid options that can be used when running RUP Installer.
Table 5-6 RUP Installer command options
| Argument | Description | Mandatory |
|---|---|---|
|
|
Path where the Java Runtime Environment is installed. This option does not support relative paths, so you must specify the absolute path. |
Yes. |
|
|
The location of an overriding inventory pointer file. If Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), located under the |
Recommended, use to override the default location of the inventory pointer file, located in |
|
(- |
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". |
|
|
Retrieves the debug information from RUP Installer. |
No. |
|
(- |
Records messages in the log file at the level you specify. Enter a value to override the default log level of |
No, default value is |
|
|
Configures the timeout value for server in seconds. |
No, overrides the default value for server timeout. |
Example:
(Unix) REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk6 -invPtrLoc FA_ORACLE_HOME/oraInst.loc (Windows) REPOSITORY_LOCATION\installers\farup\Disk1\setup.exe -jreLoc APPLICATIONS_BASE\fusionapps\jdk6
Example when FA_ORACLE_HOME is registered with a /net path:
REPOSITORY_LOCATION/installers/farup/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk6 -invPtrLoc /net/FA_ORACLE_HOME/oraInst.loc
Table 5-7 and Table 5-8 illustrate the tasks that RUP Installer runs. For information about troubleshooting, see Section 5.6, "Troubleshoot RUP Installer Sessions". For information about log files generated during RUP installation, see Section 5.6.1, "RUP Installer Log File Directories".
Table 5-7 RUP Installer Screen Sequence for the First Installer
| Screen | Description and Action Required |
|---|---|
|
Welcome |
Appears when you start RUP Installer. This screen does not appear if you restart RUP Installer after a failure. 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. Click Next to continue. |
|
Installation Location |
Specify the location of the existing Oracle Fusion Applications home ( 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 related to configuration tasks run during the first installer to the appropriate Oracle homes. The configuration process starts when the installation progress indicator shows 100 percent. Click Next to continue. |
|
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 first installer's configuration phase are described in Table 5-1. No additional user action is required in the Configuration Progress screen unless a failure occurs. For more information, see Section 5.6.3, "General Troubleshooting 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. The Finish button is activated only if all mandatory configuration tasks completed successfully. If you want to rerun this session to resolve failed configuration tasks, click Cancel. |
Table 5-8 RUP Installer Screen Sequence for the Second Installer
| Screen | Description and Action Required |
|---|---|
|
Welcome |
Appears when the second installer starts. You must perform the following steps to start the Node Manager and OPMN server before proceeding to the next screen.
Click Next to continue. |
|
Installation Location |
Specify the location of the existing Oracle Fusion Applications home ( 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 second installer. |
|
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 related to configuration tasks run during the second installer to the appropriate Oracle homes. The configuration process starts when the installation progress indicator shows 100 percent. Click Next to continue. |
|
Policy Store Analysis (Note that if you installed a Language Pack and chose to override the base English strings in the policy store, then this screen no longer displays during RUP installation.) |
Analysis is available for the following policy store stripes: hcm, crm, fscm, and obi. Select the stripes to be analyzed and then click Run Analysis to identify any conflicts or deletions. Only the stripes that will be updated are enabled for analysis and the analysis could run for several minutes. After the analysis runs, review the results of the analysis to determine which deployment method RUP Installer will use for policy store changes to each stripe. Oracle recommends that you select Apply safe changes only. This is the safest method unless you have read and totally understood the consequences of the other three options. 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:
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 pause the upgrade while you bring up the APM application and upload the changes. For more information, see the "Upgrading Oracle Fusion Applications Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition). Note the location of the following files:
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 second installer's configuration phase are described in Table 5-2. 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 may fail if you did not start the Node Manager and OPMN processes after the completion of the first installer. Do not cancel and exit out of RUP Installer in response to this task. For more information, see Section 5.6.16, "Troubleshooting Failure During Verifying Node Manager and OPMN Status". No additional user action is required in the Configuration Progress screen unless a failure occurs. For more information, see Section 5.6.3, "General Troubleshooting During the Configuration Phase". Links to specific task failures are available in Table 5-2. |
|
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. The Finish button is activated only if all mandatory configuration tasks completed successfully. If you want to rerun this session to resolve failed configuration tasks, click Cancel. |
Perform the following required manual steps after RUP Installer completes successfully:
Review the fapatch_timestamp.log file under the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0 directory to ensure your Oracle Web Services Manager (Oracle WSM) upgrade was successful. You must manually import each of the web service policies listed in the log file if you see the following message in the log file:
The following documents have changed since the last installed version of the product. Please import the latest version of the files using Oracle Enterprise Manager.
Perform the following steps to import web service policies using Fusion Applications Control.
Extract FA_ORACLE_HOME/oracle_common/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar into any directory using the following command:
jar -xf FA_ORACLE_HOME/oracle_common/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar
Import policies from the META-INF/policies/oracle directory using Fusion Applications Control. There are two policies which are read-only and cannot be imported or deleted. Skip the importing of the following policies:
oracle/wsaddr_policy
oracle/wsmtom_policy
Access Fusion Applications Control for the Common Domain and go to WebLogic Domain > CommonDomain > Web Services > Policies.
Search for the policy name. The search criteria for Category and Applies To can be set to All.
Select the policy and click Delete. Click OK to confirm the policy deletion.
Click Import from File and import the policy from the directory where you extracted wsm-seed-policies.jar in step 1. You can find the policies using the policy name (without the oracle/ part) under the extracted folder at folder_name/META-INF/policies/oracle.
Repeat steps 4 through 6 for all policies that were listed after the following message in the fapatch_timestamp.log file under the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0 directory:
The following documents have changed since the last installed version of the product. Please import the latest version of the files using Oracle Enterprise Manager.
RUP Lite for OHS manages the steps required to upgrade 10g WebGate to 11g WebGate. The following steps are performed by RUP Lite for OHS to accomplish this upgrade:
Stop the OHS instance.
Upgrade the OHS installation.
Remove WebGate 10g entries.
Install WebGate 11g.
Apply OPatches to WebGate, OHS, and ORACLE_COMMON.
Configure WebGate 11g.
Update the httpd.conf file.
Copy 11g WebGate artifacts.
Update the OHS configuration files.
Update OHS settings.
Start the OHS instance.
Perform the following steps to complete the WebGate upgrade using RUP Lite for OHS. Note that you must run RUP Lite for OHS from the OHS host.
If you are running Web tier on a DMZ, you must roll back patch 12947325 in the ORACLE_COMMON and Web tier Oracle Homes. The syntax for the rollback option follows:
ORACLE_HOME/OPatch/opatch rollback -id 12947325
-oh ORACLE_HOME
-invPtrLoc ORACLE_HOME/oraInst.loc
Verify that he following configuration tasks were successful during the RUP installation:
Preparing for WebGate Upgrade
Upgrading WebGate
Generating RupLite for OHS
Copy webgate_installer.zip, which was generated by the Generate RUP Lite for OHS configuration task, to the webtier server, for example:
cp FA_ORACLE_HOME/admin/webgate_installer.zip /scratch/ruplite_repo
Note that if the webtier is on a separate host, then copying the zip file may not work. In this case, you may need to ftp the zip file to the OHS host instead.
Unzip webgate_installer.zip into the folder /scratch/ruplite_repo, which is referred to as the RUP Lite for OHS repository, or RUPLITE_REPO, in the remaining steps.
Set the following environment variables. You can refer to the README.txt file in the unzipped location for more information on these environment variables.
setenv JAVA_HOME APPLICATIONS_BASE/fusionapps/jdk6
Then run the which java command. If the location you just set in the preceding command does not display, then you must also set the JAVA_HOME in PATH by running the following command:
setenv PATH $JAVA_HOME/bin:$PATH
setenv MIDDLEWARE_HOME APPLICATIONS_BASE/webtier_mwhome
Note that this is the Middleware home of the webtier.
setenv OHS_ORACLE_HOME APPLICATIONS_BASE/webtier_mwhome/webtier/
setenv OHS_INSTANCE_HOME APPLICATIONS_BASE/instance/CommonDomain_webtier/
Note that in an Oracle VM environment, this directory is located in /u02/instance/CommonDomain_webtier_local and /u02 is not APPLICATIONS_BASE.
setenv OHS_INSTANCE_ID ohs1
If for some reason you did not perform the step described in Section 5.3.3, "Install Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)", you must obtain GCC libraries for Linux 64-bit or Solaris 64-bit SPARC now, before running RUP Lite for OHS. Follow the steps in "Installing Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management to obtain the GCC libraries. Copy both GCC libraries into the following directory: RUPLITE_REPO/webgate/installers/webgate.
Run the ruplite utility from the OHS host.
cd RUPLITE_REPO bin/ruplite.sh
If this utility completes with errors or warnings, you must resolve the issue, and then run the utility again. When you restart the ruplite utility, all failed steps run again.
The following error message may occur during the "Reassociating OHS Instance With Common Domain" step:
Unregistering instance Command failed: Exception while unregistering the instance
This error can be ignored because it means that the RUP Lite for OHS Installer was unable to unregister the instance because there is no instance registered.
To verify that RUP Lite for OHS was successful, review the results in the following files:
RUPLITE_REPO/ohs_bundle/techpatch/ohs/patch_validate_results.xml RUPLITE_REPO/ohs_bundle/techpatch/ohs_manual_download/patch_validate_results.xml
Note:
If you have multiple instances of OHS, repeat the steps in this section for each OHS instance. Ensure that you set the correct environment variable value for OHS_INSTANCE_ID before running the ruplite utility.
RUP Lite for OHS automatically verifies that all required OHS patches have been applied. If you want to verify this again after the RUP Lite for OHS has completed, review the following log files to confirm that all patches were applied successfully:
$RUPLITE_REPO/ohs_bundle/techpatch/ohs_apply.log
$RUPLITE_REPO/ohs_bundle/techpatch/ohs_validate.log
$RUPLITE_REPO/ohs_bundle/techpatch/patch_validate_results.xml
You can also run the following steps to confirm the patches were applied:
After RUP Lite for OHS has completed successfully, you will have three OHS-related Oracle homes under a common root directory. The following list describes these directories and provides the name often used to refer to the directories.
Common root directory: webtier_mwhome
OHS Oracle home: webtier
Oracle Common Oracle home: oracle_common
WebGate 11g Oracle home: webgate
The techpatch utility uses OPatch utilities to check whether a patch has been applied, so you must verify that the OPatch version in these three OHS-related Oracle homes is at least version 11.1.0.9.5.
OPatch depends on Oracle Universal Installer (OUI), and does not work correctly if the OPatch and OUI versions are not compatible. For example, you cannot use OPatch version 11.1 with OUI version 11.2, or vice-versa. Most software installations used by Oracle Fusion Applications RUP3 come with OUI and OPatch version 11.1. For these software installations, the minimum required OPatch version for patch validation to work correctly is 11.1.0.9.5 (or a higher 11.1 version) of OPatch. The database server software for Oracle Fusion Applications RUP3 comes with OUI and OPatch version 11.2. Specifically for the database server installation, the minimum required OPatch version for patch validation to work correctly is 11.2.0.3.0 (or a higher 11.2 version) of OPatch. Be careful not to install OPatch 11.1.0.9.5 (or a higher 11.1 version) in the database server Oracle home, and be careful not to install OPatch 11.2.0.3.0 (or a higher 11.2 version) in any FMW, OHS, or IDM Oracle home, as neither of these combinations will work correctly.
For each of the OHS-related Oracle homes, go to the OPatch directory under Oracle home and run the following command:
opatch version
You should get output like the following:
OPatch Version: 11.1.0.9.0 OPatch succeeded.
If the OPatch version is less than 11.1.0.9.5 in any of the OHS-related Oracle homes, you need to upgrade your OPatch version in that Oracle home. To upgrade your OPatch version, download and install the required version of OPatch from My Oracle Support. Installation instructions are in the Readme file of the patch zip file. In general, installing a new version of OPatch consists of unzipping the zip file from the downloaded patch directly under the Oracle home directory.
The utility that validates the standalone OHS patches is called TechPatch. It is located in the techpatch subdirectory in the RUP Lite for OHS repository, $RUPLITE_REPO/ohs_bundle.
The RUP Lite for OHS repository contains all files required to validate that the required OHS-related patches have been applied. In addition, RUP Lite for OHS updates the techpatch configuration files when it runs, so you do not need to manually update the techpatchutil.properties file.
Perform the following steps to validate that all OHS prerequisite patches have been applied:
Go to the techpatch subdirectory under the RUP Lite for OHS repository.
Run techpatch.sh using the following command syntax:
./techpatch.sh -target OHS -jobsxmlpath ./jobs.xml -patchbaseloc ../ohs -jreloc JAVA_HOME/jdk6 -validate true
For a description of the techpatch arguments, see Table 5-5.
Note:
If the techpatch utility reports an error in the techpatchoutput.xml file about the GOP home missing, and you are running the utility in a CRM or HCM environment, you can ignore this error.
Use the techpatch command with the validate argument to verify that all Oracle Fusion Middleware patches were applied. The techpatch utility generates an XML report that contains the list of applied and missing patches for each Oracle home that is included in the jobs.xml file. You must run techpatch twice to validate that all patches were applied. The first run validates patches applied during the Applying Pre-PSA Middleware Patches configuration task. The second run validates patches applied during the Applying Post-PSA Middleware Patches configuration task. You can review the XML report after each techpatch run to see the list of applied patches, as well as any missing patches.
Techpatch requires a minimum OPatch version of 11.1.0.9.5 to validate that all Fusion Middleware patches were applied successfully. RUP3 ships with this version (or a higher 11.1 version) of OPatch, so there should be no issues with the OPatch version.
Perform the following steps to validate that all Pre-PSA Middleware patches were applied:
Go to a temporary directory of your choosing. Note that this directory cannot be directly under the root directory, such as /tmp, /scratch.
Run techpatch.sh using the following command syntax:
FA_ORACLE_HOME/lcm/tp/bin/techpatch.sh -validate true -jobsxmlpath FA_ORACLE_HOME/lcm/tp/config/RUP/FMW/pre-psa-jobs.xml -patchbaseloc REPOSITORY_LOCATION -appbase APPLICATIONS_BASE
For a description of the techpatch arguments, see Table 5-5.
Perform the following steps to validate that all Post-PSA Middleware patches were applied:
Go to a temporary directory of your choosing. Note that this directory cannot be directly under the root directory, such as /tmp, /scratch.
Run techpatch.sh using the following command syntax:
APPLICATIONS_BASE/fusionapps/applications/lcm/tp/bin/techpatch.sh -validate true -jobsxmlpath APPLICATIONS_BASE/ fusionapps/applications/lcm/tp/config/RUP/FMW/post-psa-jobs.xml -patchbaseloc REPOSITORY_LOCATION -appbase APPLICATIONS_BASE
If the output from this command indicates that patch 13506932 was not applied, you can ignore this error.
For a description of the techpatch arguments, see Table 5-5.
Note:
If the techpatch utility reports an error in the techpatchoutput.xml file about the GOP home missing, and you are running the utility in a CRM or HCM environment, you can ignore this error.
You must run the UpdateSOAMDS SOA composite on every domain if you made any flexfield changes, by following the steps described in "Task: Synchronizing Customized Flexfields in the MDS Repository for SOA" in the Oracle Fusion Applications Extensibility Guide.
Perform the following steps to update the wsm-pm application targeting.
Log in to the WebLogic Console.
Click Deployments to list the Application Deployments.
Click wsm-pm application to retrieve the details for the wsm-pm application.
Click the Targets tab to display all the Servers/clusters to which the wsm-pm application is deployed.
Click Lock & Edit under Change Center.
Select wsm-pm and click Change Targets.
Un-target or remove the wsm-pm application from all servers and clusters except for the Administration Server and the cluster to which it was originally targeted before the upgrade. The following list of servers and clusters must be updated under Domain Cluster Mapping:
HCMDomain - CoreSetupCluster
ProjectsDomain - ProjectsFinancialsCluster
SCMDomain - SCMCommonCluster
CRMDomain - CRMCommonCluster
CommonDomain - FunctionalSetupCluster
FinancialDomain - FinancialCommonCluster
Procurement Domain - ProcurementCluster
ICDomain - IncentiveCompensationCluster
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.6, "Troubleshoot 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 Fusion Applications Control, or by reviewing the server side log files. For more information, see "Starting Fusion Applications Control" in the Oracle Fusion Applications Administrator's Guide or Section 5.6.1, "RUP Installer Log File Directories".
Perform the following steps to start or stop the GOP processes. Note that the opmnctl process for gop_1 should only be started on the host machine which contains the AdvancedPlanning Managed server. Do not start it on the primordial host.
Proceed to Step 2 if your GOP processes have been previously configured and have run before.
If you are starting GOP processes for the first time, confirm that a datasource exists, in the form of XML files, under the APPLICATIONS_BASE/instance/gop_1/GOP/GlobalOrderPromisingServer1/datasource directory. Then run the RefreshOpDatastore ESS job.
Log in to Fusion Applications Control. For more information, see "Starting Fusion Applications Control" in the Oracle Fusion Applications Administrator's Guide.
Access GOP by navigating to Oracle Fusion Supply Chain Management, then Global Order Promising, then GlobalOrderPromisingServer1.
Click GlobalOrderPromisingServer1 to open the GlobalOrderPromisingServer1 page.
Select Control from the menu, then Start Up.
Follow this step if you have customized BI Publisher reports.
Reload custom templates for BI Publisher reports on Oracle-delivered BI Publisher reports by following the steps in "Task: Upload the Template File to the Report Definition" in the Oracle Fusion Applications Extensibility Guide.
Review the JAZN Analysis reports for potential conflicts and deletions that are not patched automatically by RUP Installer. The reports are located in this directory:
FA_ORACLE_HOME/admin/JAZN/stripe/delta/report.txt
The stripe is crm, fscm, hcm, or obi.
Review the Modification section of the report to see the roles that RUP Installer did not update. For each conflict that displays in this report, you must evaluate and manually patch the role by using APM. For more information, see "Upgrading Oracle Fusion Applications Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
The following example shows a typical Application Role conflict that has been modified by both the patch and production, therefore it is not applied by RUP Installer.
MODIFICATION CONFLICTS Artifact type: Application Role Artifact Name: OBIA_PARTNER_CHANNEL_ADMINISTRATIVE_ANALYSIS_DUTY Description: This artifact is modified at attribute level in patch version and also in production.
Note the location of the following files for reference when using APM:
Location of baseline files, where stripe is crm, fscm, hcm, or obi:
FA_ORACLE_HOME/admin/JAZN/stripe/baseline
Location of patch files for fscm, crm, and hcm stripes:
FA_ORACLE_HOME/stripe/deploy/system-jazn-data.xml
Location of patch files for the obi stripe:
FA_ORACLE_HOME/com/acr/security/jazn/bip_jazn-data.xml
Activate the SES schedules.
SES_ORACLE_HOME/bin/searchadmin -p ses_Admin_Password -c http://ses_Admin_Host:ses_Admin_Port/search/api/admin/AdminService activate schedule -n schedule_Name
The variables, ses_Admin_Host and ses_Admin_Port, refer to the host and port of the search_server1 Managed Server or SES cluster.
Activate the Index Optimizer.
SES_ORACLE_HOME/bin/searchadmin -c http://sesHost:sesPort/search/api/admin/AdminService -p ses_Admin_Password activate indexOptimizer
The variable, ses_Admin_Password, is the SEARCHSYS database schema password, which is the same as the SES Admin screen.
The -p on the command line is optional. If you do not use it, you will be prompted for it.
Perform the following steps to confirm that the ESS Request Processor is running:
In Fusion Applications Control, select Scheduling Services, ESSAPP (ESSCluster), and ESSAPP (ess_server).
View the status of the Request Processer in the Scheduler Components tab as depicted in the following diagram.
For security, you must perform the following tasks in the IDM domain:
Disable anonymous binds to Oracle Virtual Directory's LDAP ports
Disable Oracle Virtual Directory ACLs
You perform both tasks at the same time by running the idmConfigTool with the -disableOVDAccessConfig option. Proceed as follows:
Set the environment variables MW_HOME, IAM_HOME,JAVA_HOME, and ORACLE_HOME as shown in the following examples:
setenv MW_HOME /u01/oid setenv IAM_ORACLE_HOME /u01/oim/oim_home setenv JAVA_HOME /u01/oim/jrockit-jdk1.6.0_24 setenv ORACLE_HOME /u01/oim/oim_home
Create a properties file called disableOVDAcces.prop, with the following contents:
ovd.host:ovdhost1.mycompany.com
ovd.port:1234
ovd.binddn:cn=orcladmin
ovd.password:password
ovd.ssl:true
Where:
ovd.host is the name of the host that the Oracle Virtual Directory server runs on.
ovd.port is the Oracle Virtual Directory https port.
ovd.binddn is the name of the Oracle Virtual Directory administrative user.
ovd.ssl indicates that you are communicating with Oracle Virtual Directory using the https protocol.
Disable Oracle Virtual Directory ACLs and anonymous binds to Oracle Virtual Directory LDAP ports using the command idmConfigTool which is located in the IAM_ORACLE_HOME/idmtools/bin directory.
Note:
When you run the idmConfigTool, it creates or appends to the file idmDomainConfig.param. This file is generated in the same directory that the idmConfigTool is run from. To ensure that the same file is appended to each time the tool is run, always run the idmConfigTool from the IAM_ORACLE_HOME/idmtools/bin directory.
(Unix) idmConfigTool.sh -disableOVDAccessConfig input_file=properties_file
(Windows) idmConfigTool.bat -disableOVDAccessConfig input_file=properties_file
For example:
idmConfigTool.sh -disableOVDAccessConfig input_file=disableOVDAcces.prop
Check the log file for any errors or warnings and correct them. Output is saved in a file named automation.log, which is created in the directory where you run the tool.
Restart Oracle Virtual Directory as described in "Starting and Stopping Oracle Identity Management Components" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
Repeat Steps 1 through 5 for each Oracle Virtual Directory instance, changing the values in the property file as necessary.
Apply all mandatory post installation patches and follow any post installation steps mentioned in the "Applying Patches" section of Oracle Fusion Applications release notes.
If you are deploying Oracle Business Intelligence Applications, then you must perform the post-installation or upgrade steps specified in "Roadmap for Installing, Upgrading, and Setting Up Oracle BI Applications" in Oracle Fusion Middleware Installation and Configuration Guide for Oracle Business Intelligence Applications.
If you have installed any languages in addition to US English, you must upgrade each installed language using Language Pack Installer. For more information, see Chapter 6, "Maintaining Oracle Fusion Applications Languages".
You can skip this step unless you performed the step in Section 5.3.7.2, "Update "CrashRecoveryEnabled" Property to False". If you did perform this step, you must now set the CrashRecoveryEnabled property to "true" in the nodemanager.properties file for all domains in the following location:
APPLICATIONS_CONFIG/nodemanager/host
This section provides information to assist you in troubleshooting RUP Installer sessions. It contains the following topics:
Failure During Preparing For WebGate Upgrade Configuration Task
Updating Webcat to Resolve a Failure During Deploying BI Publisher Artifacts
Webcat Patch File Creation Failure During Deployment of BI Publisher Artifacts
Troubleshooting Failure During Verifying Node Manager and OPMN Status
Merging SOA Composite JDeveloper Customizations While Applying a RUP
RUP Installer calls Oracle Fusion Applications Patch Manager during the Load Database Components task. For additional information about troubleshooting Oracle Fusion Applications Patch Manager sessions, see Chapter 11, "Monitoring and Troubleshooting Patches".
Table 5-9 contains a list of log directories for RUP Installer activities.
Table 5-9 Log Directories for RUP Installer Activities
| Log directory name | Generated from... |
|---|---|
|
|
Installation phase and Oracle Fusion Middleware patch set installation. |
|
|
Top level log directory which contains the main RUP Installer log file. |
|
|
Top level log directory where log files are moved when you retry the RUP installation session. |
|
|
Database upload configuration task after failure or completion. |
|
|
StartStop utility. Note that server logs are located under respective domains. For example, the AdminServer log for CommonDomain is under |
|
|
Processing SOA artifacts. Note that SOA server logs are located under respective domains. For example, the SOA server logs for CommonDomain are under |
During the execution of configuration tasks, log files are created under the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_releasenumber directory. During the execution of the database upload configuration task, log files are created under FA_ORACLE_HOME/admin/FUSION/log. Upon completion or failure of the database upload, the log files move to the FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_releasenumber/PatchManager_DBPatch directory. The current releasenumber is 11.1.4.0.0 for RUP3.
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/version/language/timestamp. For RUP3, the directory is FA_ORACLE_HOME/patchsettop/backup/11.1.4.0.0/en_US/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. The log files reside in oracle_inventory/logs/installtimestamp.log.
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.4.1, "Start RUP Installer". After canceling the previous installation and starting again, you must choose to continue with the previously failed installation by clicking Yes on the Checkpoint Dialog. If the error is not recoverable, you can restore and restart from from your backup.
If you choose to continue with the failed installation, RUP Installer opens at the screen where it was canceled. When canceled during the copy action, it relaunches in the Installation Summary screen. Click Next to navigate through the Installation Summary screen. When the Installation Progress screen displays, click Install to start the installation again.
Troubleshooting steps are described for the following specific failures that may occur during the installation phase:
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.
During the installation phase of RUP Installer, you receive the following message on a Unix platform.
Error in writing to file'/server01/APPLICATIONS_BASE/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.
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/diirectory_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.
RUP Installer can be restarted to rerun all failed configuration tasks as well as those tasks that were not started from the previous session. 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 content of the log files that appear at the bottom of the screen to obtain detailed information to assist in diagnosing the cause of the failure.
If one or more failures occur during the configuration phase of the first installer, the following message displays after the final configuration task is complete:
Configuration is completed with errors, exit the installer by clicking the 'Cancel' button and retry the failed configurations.
Perform the following steps to rerun RUP Installer and retry the failed configuration tasks:
Click Cancel to exit RUP Installer.
Resolve the issues that caused the failure.
Start RUP Installer using the same command syntax that you used for the previous incomplete installation. For more information, see Section 5.4.1, "Start RUP Installer".
A pop up dialog displays, asking if you want to continue the previous incomplete installation. Select Yes to continue running 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 and remaining configuration tasks, and then runs these 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. If all the configuration tasks were successful, the second installer is launched automatically.
If one or more failures occur during the configuration phase of the second installer, the following message displays after the final configuration task is complete:
Configuration is completed with errors, exit the installer by clicking the 'Cancel' button and retry the failed configurations.
Perform the following steps to rerun RUP Installer and retry the failed configuration tasks:
Click Cancel to exit RUP Installer.
Resolve the issues that caused the failure.
Start the second installer using the same set of command options used in starting the first installer, but run the second installer directly by replacing farup with fusionapps, using the following command syntax:
(UNIX) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [logfile=log_file_name][-debug yes] (IBM AIX on POWER Systems (64-bit) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [logfile=log_file_name][-debug yes] JVM_OPTIONS="-Xms512m -Xmx1024m" (Solaris X64 and Solaris Sparc) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc JAVA_HOME_LOCATION [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] \ [-J-Dworkers=number_of_workers][-J-DlogLevel=level] [logfile=log_file_name][-debug yes] JVM_OPTIONS="-d64 -Xms512m -XX:MaxPermSize=756m -Xmx2048m" (Windows)REPOSITORY_LOCATION\installers\fusionapps\Disk1\setup.exe -jreLoc JAVA_HOME_LOCATION [-Dworkers=number_of_workers][-DlogLevel=level] [logfile=log_file_name] [-debug yes]
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 and remaining configuration tasks, and then runs these 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.
On the Configuration Progress page of RUP Installer, the Next button is enabled only when all configuration tasks are successful.
If you see that all your configurations are complete, and the Next button is not enabled, you encountered a configuration failure and continued to the next configuration. In this case, you must retry the failed configurations by following these steps:
On the Configuration Progress page of the RUP Installer, click Cancel.
Restart RUP Installer. All failed configuration actions or steps are re-executed upon restart. For more information, see Section 5.6.3, "General Troubleshooting During the Configuration Phase".
As long as a configuration task is not successful, the Next button remains disabled. It may be necessary to repeat the cancel and restart procedure until all configuration tasks are successful.
An error during the Bootstrapping Patch Manager configuration task normally occurs only when the database is down. Ensure that the database is up and running. You can review the related log files in this location:
FA_ORACLE_HOME/admin/FUSION/log/FAPatchManager_bootstrap_timestamp.log
If an error occurs during the Applying Pre-PSA Middleware Patches or Applying Post-PSA Middleware Patches configuration tasks, review the log file in the relevant location:
FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/ApplyPrePSAMiddlewarePatchestimestamp.log
FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/ApplyPostPSAMiddlewarePatchestimestamp.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 APPLICATIONS_BASE/fusionapps/soa/cfgtoollogs/opatch.
If an error occurs during the Upgrading Middleware Schema configuration task, review the log file in this location:
fusionapps/oracle_common/upgrade/logs/psatimestamp.log
If the OPSS Security Store is not running before RUP Installer starts, the Offline Preverification configuration task fails. Even if you start the OPSS Security Store 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.
This section contains information about troubleshooting issues that may occur during the Loading Database Components configuration task. Depending on the type of failure, you may need to review one or more of the log files in the following locations:
FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/PatchManager_DBPatch/
FAPatchManager_apply_timestamp.log
adpatch_apply_timestamp.log
adpatch_apply_timestamp_workernum.log
ATGPF_HOME/admin/FUSION/log
When RUP Installer notifies you that one or more database workers failed during the Loading Database Components configuration task, 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.
If your database goes down while RUP Installer is running the Loading Database Components task, the options to Abort or Retry display. If you simply bring the database up and then click Retry, 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) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh -forcefail (Windows) FA_ORACLE_HOME\lcm\ad\bin\fapmgr.cmd -forcefail
Start AD Controller.
(UNIX) FA_ORACLE_HOME/lcm/ad/bin/adctrl.sh (Windows) FA_ORACLE_HOME\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:
Select Tell manager that a worker failed its job and enter All for all workers.
Select Tell worker to quit and enter All for all workers. Note that this does not kill the workers. It sends a command to the worker to shutdown after it completes the current task.
Wait for all workers to complete their tasks and shut down normally.
If there are still some worker processes that do not shut down, kill those processes manually by selecting Tell manager that a worker failed its job. Then select Tell manager that a worker acknowledges quit and enter All for all workers.
From your operating system, check for processes that are running fapmgr, javaworker, adpatch, adadmin, sqlplus, and adworker. If any exist, terminate them from your operating system.
Select Tell worker to restart a failed job and enter All for all workers.
Select Cancel to stop the session and then restart RUP Installer.
If 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 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]
Run the fapmgr abort command from FA_ORACLE_HOME to find out if an Oracle Fusion Applications Patch Manager must be cleaned up.
(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]
If this command finds no failed session, proceed to Step 3.
Run the following commands from ATGPF_ORACLE_HOME to abandon any Applications Core patching sessions or AD Administration sessions that may be running:
(Unix) ATGPF_ORACLE_HOME/lcm/ad/bin/adpatch.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt (Unix) ATGPF_ORACLE_HOME/lcm/ad/bin/adadmin.sh abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME/admin/TWO_TASK/defaults_file_name.txt (Windows) ATGPF_ORACLE_HOME/lcm/ad/bin/adpatch.exe abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt (Windows) ATGPF_ORACLE_HOME\lcm/ad/bin/adadmin.cmd abandon=y interactive=n defaultsfile=ATGPF_ORACLE_HOME\admin\TWO_TASK\defaults_file_name.txt
If the Prepare for WebGate Upgrade configuration task fails, the Cancel and Next buttons are enabled. When this happens, you must click Cancel, fix the error, and restart RUP Installer from the point of failure. The errors are reported in the RUP Installer log file, FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/fapatch_timestamp.log.
Note:
Do not click the Next button in this situation, as this causes RUP Installer to exit the session without saving its progress. In this case, you would not be able to restart the session from the point of failure.
The following types of failures could occur during the Prepare for WebGate Upgrade configuration task:
Classpath errors, such as a java.lang.NoClassDefFoundError exception in the log file.
No Read/Write access to the config.xml and jps-config.xml files under each domain directory. In this case, the log file reports a java.security.AccessControlException error.
Upgrade failure while restoring the config.xml and jps-config.xml files. In this case, the log reports a java.io.FileNotFoundException error.
This section contains information about troubleshooting issues that may occur during the Deploying Application Policies configuration task. Log files for this task may be found in this location:
FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/fapatch_timestamp.log
When a failure occurs during Deploying Application 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 to perform the restore. Do not restore a stripe that has not failed. Review the log file to determine the cause of the failure. If needed, you can also review the log file that is specifically generated by each stripe. These log files are located under the main log directory, FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.5.0.0/timestamp and are named as follows:
fapatch_CRMJaznAnalysis_timestamp.log
fapatch_FSCMJaznAnalysis_timestamp.log
fapatch_HCMJaznAnalysis_timestamp.log
fapatch_OBIJaznAnalysis_timestamp.log
After you resolve the issue, 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.
If you see the following warning during Deploying Application Policies, you can safely ignore it.
WARNING: Failed to validate the xml content. cvc-complex-type.2.4.a: Invalid
content was found starting with element 'property'. One of
'{"http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd":propertySetRef,
"http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd":extendedProperty,
"http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd":extendedPropertySetRef,
"http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd":serviceInstanceRef}'
is expected. Location: line 165 column 96.
WLS ManagedService is not up running. Fall back to use system properties for
configuration.
If you see the following warning during Deploying Application Policies, you can safely ignore it.
FINE: Application policies already exists for application: fscm
oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException:
Cannot create application policy context "fscm".
at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.unsync_createApp
licationPolicy(LdapPolicyStore.java:833)
at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.createApplicatio
nPolicy(LdapPolicyStore.java:753)
at
oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy.c
lone(JpsDstPolicy.java:805)
If the IDM Server goes down during Deploying Application Policies, the deployment fails. Even if the Retry button is enabled, RUP Installer does not allow a retry after this type of failure. You must instead click Cancel and restart RUP Installer.
If the Applying OAM Configuration task fails with the following error:
[ecid: 0000JVgds_DAtHc5ljO5yZ1Fq^T6000004,0] Cannot find applications matching name [ webcenter* ].[[ oracle.apps.ad.common.exception.ADException: Cannot find applications matching name [ webcenter* ]. at oracle.apps.ad.common.taxonomy.WLSUtil.getApplicationsStartingWith(WLSUtil.java:925) at oracle.apps.ad.fapmgr.sdk.FAPManagerSDK.getServerDetailsForWebcenterApp(FAPManagerSDK.java:2977)
Perform the following workaround to run the oamcfgtool.jar manually from the command line. Note that the parameters in brackets <> must be replaced with valid values first.
setenv APPTOP <Apptop location>
$ cd ${APPTOP}/fusionapps/oracle_common/modules/oracle.oamprovider_11.1.1
$ java -jar oamcfgtool.jar app_domain=fs web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/atf/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=crm web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/crm/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=fin web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/fin/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=fndsetp web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/atgpf/atgpf/applications/exploded/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=fs web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/grc/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=hcm web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/hcm/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=ic web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/ic/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=prc web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/prc/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=prj web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/prj/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
$ java -jar oamcfgtool.jar app_domain=scm web_domain=OraFusionApp uris_file=${APPTOP}/fusionapps/applications/scm/security/oam.conf oam_aaa_mode=<'open' or 'simple'>
primary_oam_servers=oam_server1 oam_admin_server=http://<OAM ADMINSERVER HOST>:<OAM ADMINSERVER PORT> oam_version=11 default_authn_scheme=FAAuthScheme
oam_admin_username=<OAM Admin username (the username for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> oam_admin_password=<OAM Admin password
(the password for the FUSION_APPS_PATCH_OAM_ADMIN-KEY credential in credstore)> app_agent_password=<the password for the FUSION_APPS_PATCH_OAM_RWG-KEY credential in credstore>
Follow these steps if you need to update the runtime instance webcat to fix the cause of a failure during the Deploying BI Publisher Artifacts configuration task.
RUP Installer restores the backed up webcat before you retry RUP Installer. The backup is stored in FA_ORACLE_HOME/admin/BIP/11.1.5.0.0/en_US/webcat.zip.
If you update the runtime instance webcat only, this does not resolve the issue, because before you retry the failed step, RUP Installer will restore the previously backed up webcat again. If you update the runtime webcat directly, you must also update the backup webcat. Perform the following steps if you plan to update the runtime webcat:
Restore the runtime webcat from the backed up version at FA_ORACLE_HOME/admin/BIP/11.1.5.0.0/en_US/webcat.zip.
Make your updates to the runtime webcat.
Take a backup of FA_ORACLE_HOME/admin/BIP/11.1.5.0.0/en_US/webcat.zip.
Zip the runtime webcat again, to FA_ORACLE_HOME/admin/BIP/11.1.5.0.0/en_US/webcat.zip
Click Retry to restart RUP Installer.
If you apply a RUP that contains BI Publisher artifacts, the BI Presentation servers must 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. For more information, see "fastartstop Syntax" in the Oracle Fusion Applications Administrator's Guide.
During the Importing ODI Repositories configuration task, the percent complete displays 100% but the task failed. This is a known issue and is resolved in the next version of RUP Installer.
If the Verifying Node Manager and OPMS Status configuration task fails, do not cancel and exit out of RUP Installer in response to this task. Perform the following steps to recover:
Review the node manager log files to determine the cause of the failure:
APPLICATIONS_CONFIG/nodemanager/host_name
Note that the APPLICATIONS_CONFIG value can be obtained from the APPLICATIONS_BASE/fusionapps/faInst.loc file.
After you resolve the issue that caused the failure, start the Node Manager on all hosts that are part of the Oracle Fusion Applications provisioned system. For more information, see "Task 3: 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 Web Tier. This is similar to the stop steps described in Section 5.3.7.4, "Stop the Node Manager and the OPMN Control Process", except that for BI and GOP, you must start only the OPMN server itself, while for Web Tier, you should start OPMN and all processes that it manages. If you run the Web Tier (OHS) installed with the Oracle Fusion Applications middle tier, you can start it using the following steps. If you run the Web Tier on a separate machine, you may be able to run the steps below on the other machine. In either case, ensure that Web Tier (OHS) is up at this point.
Example for BI: (note the usage of start instead of startall)
cd APPLICATIONS_CONFIG/BIInstance/bin
./opmnctl start
Example for GOP: (note the usage of start instead of startall)
cd APPLICATIONS_CONFIG/gop_1/bin
./opmnctl start
Example for Web Tier:
cd APPLICATIONS_CONFIG/CommonDomain_webtier/bin
./opmnctl startall
For more information about the location of APPLICATIONS_BASE and APPLICATIONS_CONFIG, see Section 5.2.1, "Before You Begin".
The BI processes managed by OPMN are started by RUP Installer in the Starting All Servers configuration task. The GOP processes managed by OPMN can be started by an administrative user from the GOP home page in Fusion Applications Control 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 if you have unresolved environment issues.
After you start the services, click Retry to proceed to the Starting All Servers task. If the starting of servers times out, see Section 5.6.18, "Troubleshooting Server Start and Stop Failures".
Note:
If GOP is not installed, the user interface reports "Success" for GOP OPMN status, but the log file reports: GOP is not provisioned. Skipping check for OPMN status.
After the Upgrading ODI Agent configuration task is run, the RUP Installer log file may report the following error message:
Deployment Message : [Deployer:149034]An exception occurred for task
This message can be ignored.
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.4.0.0/StartStop/fastartstop_timestamp.log, indicates which server started and failed to start.
An example of messages for a server that timed out follows.
Time out while performing Start for domain SCMDomain. Waited for 2400 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
Review the log files at the domain level to see a summary of the server status for that domain: FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/StartStop/domain name_timestamp.log.
Review the corresponding server logs for the failed servers under the following directory: APPLICATIONS_CONFIG/domains/hostname/domain name/servers/server_name/logs.
After you determine and resolve the cause of the failure, return to RUP Installer and click Retry.
When all servers are up and running, including those that exceeded the timeout limit, click Abort in RUP Installer to proceed to the next configuration task.
The following exception during the Starting all Servers configuration action indicates a failure in starting the BIServer:
Start all servers fails to start Start operation on the component :coreapplication_obips1:, for the instance :BIInstance: - FAILED
The coreapplication_obips1 server log file reports the following error:
ecid:]] [2012-04-10T00:22:20.000-07:00] [OBIPS] [ERROR:16] [] [saw.security.odbcuserpopulationimpl.initialize] [ecid: ] [tid: ] Unable to create a system user connection to BI Server during start up. Trying again.[[ File:odbcuserpoploaderimpl.cpp Line:325 Location: saw.security.odbcuserpopulationimpl.initialize saw.catalog.local.loadCatalog saw.subsystems.catalogbootstrapper.loadcatalog saw.webextensionbase.init saw.sawserver ecid:]] [2012-04-10T00:22:25.000-07:00] [OBIPS] [NOTIFICATION:1] [] [saw.sawserver] [ecid: ] [tid: ] Oracle BI Presentation Services are shutting down.[[ File:sawserver.cpp Line:706 Location: saw.sawserver ecid:
Perform the following steps to work around this issue:
Select Retry, which shuts down and starts bi_server1.
Monitor the fastartstop log files and the state of bi_server1(BIDomain).
As soon as bi_server1 restarts, as indicated by a RUNNING status, start the component coreapplication_obiccs1 or all the components of type OracleBIClusterControllerComponent using opmnctl.
Example syntax follows:
*/BIInstance/bin/opmnctl startproc ias-component=coreapplication_obiccs1
If you receive the following error during preverification, you may have to manually release the edit session.
weblogic.management.mbeanservers.edit.EditTimedOutException
For more information, see Section 11.3.8, "Resolving an EditTimedOutException Error".
If you performed JDeveloper customizations to a SOA composite and you deployed the composite to the SOA runtime, RUP Installer reports an error during Online Preverification, which instructs you to take the newer version of the composite that is in the RUP. You must then merge your customizations by performing the following steps:
If any customizations are detected, the Online Preverification results display the SOA composite name, its location in the FA_ORACLE_HOME/stripe/deploy directory, and the requirement for you to merge JDeveloper customizations into the sca_*.jar file in FA_ORACLE_HOME before proceeding with RUP Installer. The stripe in the directory path refers to crm, hcm, fscm, and so on.
Open the custom SOA workspace and the customized version of the Fusion Applications SOA composite in JDeveloper using "Oracle Fusion Applications Developer". For more information, see "Customizing SOA Composites with JDeveloper" in the Oracle Fusion Applications Web User Interface Developer's Guide for Oracle Application Development Framework.
Import the composite sca_*.jar file from FA_ORACLE_HOME/stripe/deploy into the project, for example revision 11.1.4.0.0, in JDeveloper. Make note of this revision number in the deployment window because you will need it in Step 8.
Restart JDeveloper in the Oracle Fusion Applications Administrator Customization role.
Verify that there are no errors in JDeveloper.
Verify that the changes introduced in both the customized version and the patched version are present.
Right-click the composite project in the Application Navigator, select Deploy, select the composite, click Deploy to SAR, and click Next.
Manually change the value in New Revision ID to the revision from Step 3, for example, 11.1.4.0.0, and click Finish.
If the deployment folder is set to a location different from that of the FA_ORACLE_HOME/stripe/deploy directory, copy and replace the JAR in the location mentioned in the error message of this SOA Composite. If your file name is different, rename it to the original name. You must copy the jar in the correct format to FA_ORACLE_HOME/stripe/deploy. For example if you have sca_ContractsDeliverablePurchaseDocAttrReadComposite_rev11.1.2.0.0.jar in JDeveloper, then you must copy it back to FA_ORACLE_HOME/stripe/deploy as sca_ContractsDeliverablePurchaseDocAttrReadComposite.jar.
To proceed with the installation of the RUP, select Retry.
For more information about customizing SOA composites, see "Customizing and Extending SOA Components" in the Oracle Fusion Applications Extensibility Guide.
The location of your Governance, Risk, and Compliance (GRC) policies varies, depending on your upgrade path to RUP3. GRC polices are location in the grc OAM application domain if your Oracle Fusion Applications environment was originally provisioned with either version 11.1.1.5 or 11.1.2, then upgraded to version 11.1.3 (RUP2), and then upgraded to version 11.1.4 (RUP3). If your environment was originally provisioned with version 11.1.3 (RUP2) and upgraded to version 11.1.4 (RUP3), your GRC policies are located in the fs OAM application domain.
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
This section describes how to recover from out-of-memory errors during the Deploying SOA Composites configuration task. The following topics are described:
The following log files are generated by the deployment of SOA composites:
Client side log files where individual domain logs reside: FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.4.0.0/soalogs
Log files for the failed domain:
APPLICATIONS_CONFIG/instance/domains/hostname/domain name/servers/server_name/logs/soa_server1.log
APPLICATIONS_CONFIG/instance/domains/hostname/domain name/servers/server_name/logs/soa_server1.out
APPLICATIONS_CONFIG/instance/domains/hostname/domain name/servers/server_name/logs/soa_server1-diagnostic.log
APPLICATIONS_CONFIG/instance/domains/hostname/domain name/servers/server_name/logs/AdminServer.log
Normally, a failed SOA composite is undeployed by RUP Installer. However, if the failure of the deployment is due to SOA servers running out of memory, then RUP Installer cannot recover. As a result, a failure message such as CFGEX-00062: Composite revision "default/composite name!11.1.4.0.0" is already deployed may occur.
An example of a complete error message follows:
[2011-12-30T04:24:38.613-08:00] [apps]
[ERROR] [] [oracle.apps.CRMDomain] [tid: 58]
[ecid: 0000JIEvTHGEGR9ZvdYBV11EzMvF00000c,0]
CFGEX-00073 : SOA composite "/u01/APPLICATIONS_BASE/fusionapps/applications/crm/deploy/sca_ContractsTermLibTemplatesComposite.jar"
deployment failed for Domain "CRMDomain".[[
Action : See logs for details. oracle.as.install.
fapatchconfig.exception.PatchsetConfigException:
CFGEX-00073 : SOA composite "/u01/APPLICATIONS_BASE/fusionapps/applications/
crm/deploy/sca_ContractsTermLibTemplatesComposite.jar" deployment failed for Domain "CRMDomain".
….
Caused by: oracle.as.install.fapatchconfig.exception.PatchsetConfigException: CFGEX-00062 : Composite revision "default/
ContractsTermLibTemplatesComposite!11.1.4.0.0" is already deployed.
To resolve this issue, you must manually undeploy the composite.
Note:
Ensure that you undeploy only the revision deployed by RUP Installer. Do not undeploy the previous version.
To undeploy, use WebLogic Server Tool (WLST) commands or the Fusion Applications Control console. For more information see Section 5.6.23.2.1, "Undeploy SOA Composites Using WLST Commands" and Section 5.6.23.2.2, "Undeploy SOA Composites Using Fusion Applications Control Console".
Then return to RUP Installer and select Retry.
Follow these steps to undeploy the composite using WLST commands:
Start WLST:
(Unix) APPLICATIONS_BASE/soa/common/bin/wlst.sh (Windows) APPLICATIONS_BASE\soa\common\bin\wlst.cmd
Run the sca_undeployComposite command using the following syntax:
sca_undeployComposite(serverURL, compositeName, revision, [user], [password], [partition])
where the variables have values as follows:
serverURL contains the host and port of the SOA cluster Managed Server of the domain that the SOA composite failed to deploy
compositeName is the name of the composite to be undeployed
revision, in the case of the RUP3 (11.1.4.0.0), this should be 11.1.4.0.0 by default.
Example:
wls:/mydomain/ServerConfig> sca_undeployComposite
("http://myhost10:7001",
" ContractsDeliverablePurchaseAgrmntFlowComposite ", "11.1.4.0.0")
You are prompted for the user name and password to execute the command.
For more information, see "Oracle SOA Suite Custom WLST Commands" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Follow these steps to undeploy the composite using the Fusion Applications Control console:
In the Fusion Applications Control console, connect to the domain where the SOA composite failed to deploy.
Navigate to Farm_Domain->soa-infra->default.
Locate the composite and revision, such as 11.1.4.0.0 as shown in this example:
ContractsDeliverablePurchaseAgrmntFlowComposite [11.1.4.0.0]
Right click on the composite and select SOA deployment > Undeploy.
You may receive the following error during deployment of a SOA composite. For this example, the HcmEmploymentProcessesChngWkHrsComposite composite is shown:
Step FIND_BASE_COMPOSITE:Find the base composite for patch. It will be current default composite of the series ==> failed: Error in getting default composite:default/HcmEmploymentProcessesChngWkHrsComposite, The configuration file, deployed-composites.xml, does not contain the default/HcmEmploymentProcessesChngWkHrsComposite composite-series element.
To resolve this issue, manually deploy the missing composite by executing the following commands on a Windows platform:
SET JAVA_HOME=REPOSITORY_LOCATION\jdk6 REPOSITORY_LOCATION\provisioning\ant\bin\ant -f APPLICATIONS_BASE/fusionapps/soa/bin/ant-sca-deploy.xml -DsarLocation APPLICATIONS_BASE/fusionapps/applications\hcm/deploy\sca_HcmEmploymentProcessesChngWkHrsComposite.jar -DserverURL http://my_host:9420 -Duser FUSION_APPS_PROV_PATCH_APPID -Dstdinpassword true -Doverwrite true -DfailOnError true deploy
If a failure occurs during the Apply BI Apps Metadata Updates configuration task due to conflicts, you must resolve the conflicts before the task can proceed. You must resolve the conflicts as soon as the task fails and then select Retry to allow RUP Installer to proceed.
To get information about conflicts, review the related report at this location:
FA_ORACLE_HOME/fusionapps/bi/.biapps_patch_storage/update/timestamp/update-report-timestamp.txt
Refer to the following types of conflicts for information about how to resolve them.
To resolve Oracle BI RPD conflicts, use the decision file located at FA_ORACLE_HOME/fusionapps/bi/.biapps_patch_storage/update/timestamp/patchrpd_decision_file.csv. The decision file lists the decisions that would have been displayed in the Define Merge Strategy screen of the Merge Wizard if the merge had been performed in the Oracle BI Administration Tool. The decision file provides a record of all items that can be affected by user input.
Use the Load Decision File button in the Define Merge Strategy screen of the Merge Wizard to load the merge decisions, and then change the decisions if needed. In the decision window, ensure you select Current, as those are Oracle's changes. You can then complete the merge in the Oracle BI Administration Tool.
Use Fusion Middleware Control to upload the merged RPD. For more information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Return to RUP Installer and select Retry.
For more information, see "Resolving Conflicts for Oracle BI Repository (RPD) Updates"' in the Oracle Fusion Middleware Reference Guide for Oracle Business Intelligence Applications.
If you made customizations to the content of the Oracle BI Presentation Catalog, conflicts may arise when the Oracle BI Presentation Catalog is updated by RUP Installer. You must resolve these conflicts and then run the BI Metadata Update Tool (MUT) which was run by RUP Installer. The patch log file lists the conflicts and the location of the runtime and Oracle home Presentation Catalogs.
Perform the following steps to resolve Oracle BI Presentation Catalog conflicts:
Back up the runtime Oracle BI Presentation Catalog. This is the customized Oracle BI Presentation Catalog you were using before running RUP Installer.
Start the Catalog Manager and open the runtime Oracle BI Presentation Catalog in offline mode.
Start another instance of the Catalog Manager, and open the Oracle home Oracle BI Presentation Catalog in offline mode. This Oracle BI Presentation Catalog contains the content last delivered by Oracle.
Review the list of conflicts in the patch log file.
Archive the runtime Oracle BI Presentation Catalog. For instructions on archiving a Oracle BI Presentation Catalog, see "Archiving and Unarchiving Using Catalog Manager" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
For each object with a conflict, copy the object in the Oracle home Presentation Catalog and paste it into the runtime Presentation Catalog, using the Force paste option. For instructions on copying and pasting objects, see "Copying and Pasting Objects" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Rerun the BI Metadata Update Tool (MUT). RUP Installer runs the MUT and the last part of the MUT generates a log file that contains the exact command to use for rerunning MUT.
For more information, see "Resolving Conflicts for Oracle BI Presentation Catalog Updates" in the Oracle Fusion Middleware Reference Guide for Oracle Business Intelligence Applications.
To resolve JAZN policy store conflicts, see "Resolving Patch Differences" and "Upgrading Oracle Fusion Applications Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
The following error is reported in the log file when there is no ESS server configured for a domain:
Failed to restart ESS servers from quiescent mode for the Domain <domain name>
You can ignore this error and exit RUP Installer by clicking Cancel. If this is the only configuration task that failed, your RUP Installation can be considered to be successful. If you try to relaunch RUP Installer, this failed task reruns and will fail again.
Review this section if you encounter the following error when running RUP Lite for OHS:
Re-registering OHS Instance.. Traceback (innermost last): File "/rupliteohs/scripts/ruplite.py", line 1219, in ? File "/rupliteohs/scripts/ruplite.py", line 188, in reAssociateOHSInstWithCommonDomain at oracle.security.pki.OracleWallet.open(Unknown Source) at oracle.as.install.faruplite.WalletReader.getPassword(WalletReader.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25 at java.lang.reflect.Method.invoke(Method.java:597) java.io.IOException: java.io.IOException: PKI-02002: Unable to open the wallet. Check password.
Perform the following steps to resolve this failure:
Create an ADMIN_PASSWORD_FILE such as pw.txt, that contains the admin password to the Common Domain Administration Server. Then run the next three commands, replacing the values in brackets { } with the appropriate values, to re-register OHS with the Administration Server manually.
Redeploy the OHS instance:
${OHS_INSTANCE_HOME}/bin/opmnctl redeploy -adminHost {ADMIN_HOST} -adminPort
{ADMIN_PORT} -adminUsername {ADMIN_USERNAME} -adminPasswordFile
{ADMIN_PASSWORD_FILEPATH}
Unregister the OHS instance:
${OHS_INSTANCE_HOME}/bin/opmnctl unregisterinstance -oracleInstance
${OHS_INSTANCE_HOME} -instanceName CommonDomain_webtier -adminHost
{ADMIN_HOST} -adminPort {ADMIN_PORT} -adminUsername {ADMIN_USERNAME}
-adminPasswordFile {ADMIN_PASSWORD_FILEPATH}
Register the OHS instance:
${OHS_INSTANCE_HOME}/bin/opmnctl registerinstance -adminHost {ADMIN_HOST}
-adminPort {ADMIN_PORT} -adminUsername {ADMIN_USERNAME} -adminPasswordFile
{ADMIN_PASSWORD_FILEPATH}
Open the RUPLITE_ROOT/scripts/ruplite.py file. Comment out the line that contains "reAssociateOHSInstWithCommonDomain()" by placing a '#' character in the beginning of the line. This ensures that this command is skipped because you manually performed it using the preceding three commands.
Rerun RUP Lite for OHS:
cd RUPLITE_REPO bin/ruplite.sh
If the attachHome script hangs, when following the steps in Section 5.2.10, "Confirm All Oracle Homes Are Registered in the Central Inventory", run attachHome with the following additional arguments: -waitforcompletion -nowait.
If the runInstaller -updateHomeDeps command hangs, when following the steps in Section 5.2.10, "Confirm All Oracle Homes Are Registered in the Central Inventory", run this command with the following additional arguments: -waitforcompletion -nowait.
Perform the steps in "Verifying Installation" in the Oracle Fusion Applications Post-Installation Guide.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|