| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.3) Part Number E16602-14 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.3) Part Number E16602-14 |
|
|
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 sometimes 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.
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. 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 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 completes 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.5.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 button 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 location, such as Oracle Fusion Middleware home and Oracle Fusion Applications Oracle home. After the file copy is completed, RUP Installer performs the Policy Store Analysis, as described in Table 5-4. 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. Depending on the contents of the RUP, not all tasks run.
If any tasks fail during the installation phase, refer to Section 5.5.2, "Troubleshooting Failures During the Installation Phase".
All mandatory configuration tasks must complete successfully before proceeding to the next configuration task. For more information, see Section 5.5.3, "General Troubleshooting During the Configuration Phase".
Table 5-1 provides a complete list of possible configuration tasks. The Retry Behavior column describes what RUP Installer does after a configuration task fails and you use 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.3.0.0) RUP Installer
| 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.5.6, "Error During Bootstrapping Patch Manager". |
|
Verify Middleware PSA Schema Credentials |
Yes |
Verifies users and logins for schema. |
Starts from the beginning of the task. |
|
Apply Middleware Patch Sets |
Yes |
Applies Oracle Fusion Middleware patch sets, which include schema changes and installers. |
Starts from the beginning of the task. See Section 5.5.8, "Failure During Applying Middleware Patch Sets". |
|
Apply Pre-PSA Middleware Patches |
Yes |
Applies WebLogic Server Smart Update patches and Opatch based patches. See Section 5.1.4.1, "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.5.7, "Troubleshooting Applying Middleware Patches". |
|
Upgrade Middleware Schemas |
Yes |
Runs Oracle Fusion Middleware patch sets assistants. |
Starts from the beginning of the task. |
|
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. Section 5.5.7, "Troubleshooting Applying Middleware Patches". |
|
Offline Preverification |
Yes |
Performs the following validation checks while all servers are shutdown:
|
Runs failed steps Section 5.5.11, "LdapServerCheck Failure". |
|
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.5.10, "Troubleshooting Loading Database Components". |
|
Upgrade OPSS |
Yes |
Upgrades the OPSS DIT and schema in the security store. Upgrades the configuration on each domain. Adds Delegated Administration policies to the policies in the security store. |
Starts from the beginning of the task. See Section 5.5.11, "LdapServerCheck Failure". |
|
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.5.12, "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 ESS Connections File |
Yes |
Generates |
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 required configuration file for supporting new flexfields, new flexfield usages, and flexfield view links added by Oracle Fusion Application products. |
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 |
Deploy Copies captions and deploys Webcat to the Oracle Business Intelligence repository using Catalog Manager. |
Starts from the beginning of the task. See Section 5.5.15, "Failure During Deployment of BI Publisher Artifacts". |
|
Import Oracle Data Integrator Repository |
Yes |
Imports ODI related changes to the ODI repository. |
Imports failed data. |
|
Apply Offline Setting Changes |
Yes |
Applies Oracle Fusion Applications environment configuration setting changes during the offline phase. |
Starts from the beginning of the task. |
|
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, and should fail because you manually shut these processes down prior to starting RUP Installer. You must manually start both the Node Manager for all domains and the OPMN control process at this time. You must not exit out of RUP Installer during this task. |
Runs failed steps. |
|
Start all servers |
No |
Starts all servers in all domains, including the BI servers. |
Restarts failed servers. See Section 5.5.16, "Failures During Starting All Servers" |
|
Online Preverification |
Yes |
For more information, see Section 5.1.4.3, "Validation Steps Performed During Online Preverification Task". |
Runs failed steps. See Section 5.5.9, "EditTimedOutException Error During Online Preverification" and Section 5.5.18, "Merging SOA Composite JDeveloper Customizations While Installing a RUP". |
|
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. You must manually modify the related properties file in order for this task to be successful. For more information, see Section 5.2.12, "Update Oracle Fusion Middleware Schema Credentials". |
Starts from the beginning of the task. See Section 5.5.13, "Failure during Applying OAM Configuration". |
|
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 only failed IPM artifacts. See Section 5.5.17, "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 |
No |
Deploys SOA shared repository artifacts to SOA servers available in the environment. |
Deploys failed SOA shared repository artifacts. |
|
Deploy SOA Composites |
No |
Deploys SOA composites to the corresponding SOA servers and performs server management steps. |
Deploys failed SOA composites. See Section 5.5.19, "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. |
|
Applying Online Setting Changes |
No |
Applies Oracle Fusion Applications environment configuration setting changes during the online phase. |
Starts from the failed task. |
|
Apply BI Metadata Updates |
Yes |
Applies Oracle Business Intelligence Metadata Updates. |
Applies failed patches.Section 5.5.20, "Failure During Applying BI Metadata Updates". |
The following installers are installed by the Pre-PSA Middleware Patches configuration task:
Oracle Business Intelligence
Oracle Common
Oracle Data Integrator (ODI)
Oracle Database Client
Oracle Enterprise Content Management
Oracle HTTP Server (OHS) - Note that this is the embedded OHS. OHS may also be installed in the DMZ. Patching OHS in the DMZ is a manual process not supported by RUP Installer.
Oracle 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.2, "Apply Mandatory Prerequisite Patches".
Patching your Oracle Identity Management Server. For more information, refer to "Oracle Identity Management Patches for Oracle Fusion Applications" in Oracle Fusion Applications release notes.
The following validation steps are performed during this task:
Taxonomy URL
Flexfield: Checks if the flexfield deployed Managed Server is up
OAM Configuration
SOA Shared Repository: Verifies the taxonomy, checks if the Administration Server is up, and if the SOA platform is ready
SOA Resource Bundle: Verifies the taxonomy, checks if the Administration Server is up, and if the SOA platform is ready
SOA Composite: Performs the following validation steps:
Verifies the taxonomy
Checks if the Administration Server is up
Checks if the SOA platform is ready
Checks if the base composite is deployed
Checks if the default revision is deployed
Checks if the new revision is not deployed
Checks whether the SOA composites that will be affected by the patch have JDeveloper customizations. For more information, see Section 5.5.18, "Merging SOA Composite JDeveloper Customizations While Installing a RUP".
Image Routing (IPM): Checks if the IPM server is up
B2B Metadata: Checks if the Common Domain SOA Managed Server and the LDAP Server are up
SPE Inline Service: Checks if the Oracle CRM Performance application is deployed. If it is, the OracleRTD application must be deployed and at least one BI server must be running where the OracleRTD application is deployed.
Data Role (RGX) Template: Checks if the Administration Server for the Common Domain is up
Group Space Template: Checks if the following Managed Servers are up: WC_Spaces, WC_Collaboration, ucm_server1
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 RUP1 (11.1.2.0.0)
Add -d64 Option to JRE_MEMORY_OPTIONS (Solaris X64 and Solaris Sparc)
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
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 RUP1 and followed all post installation tasks in the RUP2 documentation and in the "Applying Patches" section of Oracle Fusion Applications Release Notes. For more information, see Oracle Fusion Applications Release Notes, 11g Release 1, Update 1 (11.1.2.0.0) Document 1382781.1.
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 RAM on the 64-bit domains to be up during the installation. RUP installer also requires at least 6GB of free RAM on the 64-bit primordial host that the installer is launched from, for the duration of the RUP installation. This 6GB of free memory requirement is in addition to the memory requirement for all servers, including the Administration Servers on the primordial host that is already up and running. Oracle also recommends at least 1GB of additional free memory on the primordial host during the RUP installation as a safety net.
For example, if the BI domain is provisioned on the primordial host, then RUP Installer requires this 64-bit primordial host to have a minimum of 12GB of RAM. If you have two 64-bit hosts with the BI domain provisioned on a different host from the primordial host, then one host runs the Administration Server and the BI servers, while the other host runs RUP Installer, which requires a connection to the Administration Server that is running. If you run RUP installer and the Administration Server on the same primordial host with insufficient memory, then the Administration Server and Managed Servers may fail.
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.
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)
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 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.
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. This script updates the rup2-preupg-parameters.property properties file.
Unzip the script and properties file.
The script and properties file are located in the companionCD.zip, located under REPOSITORY_LOCATION/installers/companionCD.zip. These two files must be unzipped to APPLICATIONS_BASE/fusionapps/applications/admin/preupg, as shown in the following command.
unzip -j companionCD.zip -d APPLICATIONS_BASE/fusionapps/applications/admin/preupg
Enable write permission on the rup2-preupg-parameters.property file.
chmod u+w APPLICATIONS_BASE/fusionapps/applications/admin/preupg/rup2-preupg-parameters.properties
Ensure that the Administration Server on the Common Domain and a WLS server are running, and 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. Note that you must accept the default values for the Oracle Access Manager domain name and Oracle Access Manager authorization parameters.
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
Oracle Access Manager Administrator user name and password.
Oracle Access Manager Resource Webgate Administrator user name and password.
Oracle Access Manager Administration Server host name.
Oracle Access Manager Administration Server port number.
Oracle Access Manager administrator user name.
Oracle Access Manager mode, valid values are open, simple, and cert. There is no default value. Your OAM administrator should know this value.
Oracle Access Manager domain name, you must accept the default value of OraFusionApp.
Oracle Access Manager primary server name, the default value is oam_server1.
Oracle Access Manager version number, the default value is 11.
Oracle Access Manager authorization scheme, you must accept the default value of FAAuthScheme.
Presence of a load balancer, valid values are true and false. The default value is false.
Oracle HTTP Server host name.
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. 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 during the RUP Installation, after the Online Verification configuration task fails. For more information, see Section 5.5.18, "Merging SOA Composite JDeveloper Customizations While Installing 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 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.
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 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.
This section describes the following preparation steps for installing a RUP, all of which must be performed during your system down time.
Perform the following steps to upgrade your Identity Management environment to the RUP2 level.
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. If you want to use the fastartstop utility to do this, see "Starting and Stopping the Oracle Fusion Applications Middle Tier Using the fastartstop Utility" in the Oracle Fusion Applications System Administrator's Guide. 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 Server 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, specifically the "Managed Server for an application" row, in the Oracle Fusion Applications Administrator's Guide.
Refer to Document ID 1435333.1 on My Oracle Support and follow the remaining mandatory Identity Management upgrade steps.
Perform the following steps to apply mandatory prerequisite patches before installing the RUP.
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. If you want to use the fastartstop utility to do this, see "Starting and Stopping the Oracle Fusion Applications Middle Tier Using the fastartstop Utility" in the Oracle Fusion Applications System Administrator's Guide. Also confirm that the BI presentation servers are shut down. For Windows, see Section 5.3.2.1, "Stop Services on Windows Before Applying Mandatory Patches".
Apply mandatory Oracle Database patches mentioned in the "Oracle Database" section of Oracle Fusion Applications release notes.
Apply any additional 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.
If additional ODI components, such as ODI SDK or ODI Studio are installed, you must run ODI Installer in UI mode to upgrade ODI to 11.1.1.6.0 before running RUP Installer. To determine if these additional ODI components are installed you can either use OPatch or you can look at the directories included under the ODI_HOME.
To use OPatch, run ODI_HOME\OPatch\opatch lsinventory to get a list of installed products.
Alternatively, you can look for the following directories under ODI_HOME:
ODI_HOME\oracledi\client will be present if ODI Studio was installed
ODI_HOME\oracledi.sdk will be present if ODI SDK was installed
Note:
You must follow the steps described in "Starting the Installer" and "Following the Installation Instructions for the 'Developer' Installations" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator. You must install and upgrade your ODI Studio in an Oracle home other than Oracle Fusion Middleware Oracle homes and Oracle Fusion Applications Oracle home.
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.
This section contains steps to follow for all platforms. For Windows platforms, also follow the steps in Section 5.3.3.10, "Steps for Windows Platforms".
To prevent locks on patched objects and other data issues during patching of database artifacts, review and perform the following checklist before installing the RUP.
Perform the following steps related to Oracle Secure Enterprise Search (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.3.10, "Steps for Windows Platforms".) Note that you must start the Node Manager for all domains and the OPMN control process during the Verifying Node Manager and OPMN Status configuration task, before proceeding to the next step in the RUP installation.
For more information, see "Stopping Node Manager" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
Use the following procedure to stop the OPMN control processes for 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\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 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.5.11, "LdapServerCheck Failure".
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.
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. For additional back up steps that are specific to Windows, refer to Section 5.3.4.5, "Back Up Steps for Windows Platforms". You should also back up your central inventory.
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 applications and system policies for each stripe supported by Oracle Fusion Applications. System policies are global and not by stripe. Applications policies are stored by stripe and must be backed up and restored by stripe. If you do not back up the policies by stripe, you cannot restore the policies from your backup. Oracle Fusion Applications supports the following stripes:
fscm_system-jazn-data.xml: FSCM stripe
crm_system-jazn-data.xml: CRM stripe
hcm_system-jazn-data.xml: HCM stripe
bip_jazn-data.xml: OBI stripe
The following steps explain how to back up the system policies and the four application stripes from an Oracle Internet Directory (OID) OPSS security store to individual XML files. These steps must be performed on the Common Domain.
Copy the existing jps-config-jse.xml file (that has configured the policystore.ldap service) to a new file, myFile-migrate-jps-config.xml. This is the jps-config-jse.xml file that is referenced in the FUSION_env.properties file.
Open myFile-migrate-jps-config.xml for editing and add the following jpsContexts:
<jpsContext name="MyOIDSecurityStore"> <serviceInstanceRef ref="policystore.ldap"/> </jpsContext> <jpsContext name="MyDestinationContextFscm"> <serviceInstanceRef ref="my.fscm.backup"/> </jpsContext> <jpsContext name="MyDestinationContextCrm"> <serviceInstanceRef ref="my.crm.backup"/> </jpsContext> <jpsContext name="MyDestinationContextHcm"> <serviceInstanceRef ref="my.hcm.backup"/> </jpsContext> <jpsContext name="MyDestinationContextObi"> <serviceInstanceRef ref="my.obi.backup"/> </jpsContext> <jpsContext name="MyDestinationContextGlobal"> <serviceInstanceRef ref="my.global.backup"/> </jpsContext>
Add the following service instances to myFile-migrate-jps-config.xml. You must create a backup_directory to hold the exported policy XML files before following this step.
<serviceInstance location="backup_directory/fscm-policies.xml" name="my.fscm.backup" provider="policystore.xml.provider"> <property name="createNew" value="true"/> </serviceInstance> <serviceInstance location="backup_directory/crm-policies.xml" name="my.crm.backup" provider="policystore.xml.provider"> <property name="createNew" value="true"/> </serviceInstance> <serviceInstance location="backup_directory/hcm-policies.xml" name="my.hcm.backup" provider="policystore.xml.provider"> <property name="createNew" value="true"/> </serviceInstance> <serviceInstance location="backup_directory/obi-policies.xml" name="my.obi.backup" provider="policystore.xml.provider"> <property name="createNew" value="true"/> </serviceInstance> <serviceInstance location="backup_directory/global-policies.xml" name="my.global.backup" provider="policystore.xml.provider"> <property name="createNew" value="true"/> </serviceInstance>
Remove or comment out the entry <serviceInstanceRef ref="idstore.ldap"/> which exists in <jpsContext name="default">...</jpsContext>.
Create five XML files, fscm-policies.xml, crm-policies.xml, hcm-policies.xml, obi-policies.xml (one for each application stripe), and global-policies.xml (for system policies), each containing the following framework:
<?xml version="1.0" encoding='utf-8' ?>
<jazn-data>
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
</realm>
</jazn-realm>
<policy-store>
<applications>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>
Use the migrateSecurityStore OPSS WLST command to backup each application stripe:
migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="MyOIDSecurityStore", dst="dstJpsContext", srcApp="srcAppName")
Where:
jpsConfigFileLocation is the location of the file, myFile-migrate-jps-config.xml.
srcAppName is the stripe being backed up, such as fscm.
dstJpsContext is the name of the context that refers to the XML store, such as, MyDestinationContextFscm.
Use the OPSS WLST command migrateSecurityStore to backup system policies. Run the following command from ORACLE_COMMON_HOME, which is defined in the FUSION_env.properties file:
ORACLE_COMMON_HOME/common/bin/wlst.sh
migrateSecurityStore(type="globalPolicies",
configFile="jpsConfigFileLocation", src="srcJpsContext",
dst="dstJpsContext")
Where:
jpsConfigFileLocation is the location of the file myFile-migrate-jps-config.xml.
srcJpsContext is the name of the context that refers to the OID security store, such as, MySourceContext.
dstJpsContext is the name of the context that refers to the XML policy store, such as MyDestinationContextGlobal.
For more information, see "Migrating with the Script migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
If you made customizations to the content of the Oracle Business Intelligence Repository (Oracle BI RPD), perform the following steps:
Ensure that you have a backup of the original version of the Oracle Fusion Applications 11g Oracle BI RPD. If you do not have a backup created before making customizations, then use a version of the RPD in the following instance directory after provisioning:
APPLICATIONS_BASE/instance/BIInstance/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository/OracleBIApps_BI0002.rpd
Back up your existing customized version of the Oracle Fusion Applications 11g Oracle BI RPD by copying the file from your runtime location to a safe place of your choosing for later use. To find out what the current, custom Oracle BI RPD file is called, use Oracle Fusion Middleware Control and locate the file in the following directory:
APPLICATIONS_BASE/instance/BIInstance/bifoundation/OracleBIServerComponent/coreapplication_obis1/repository/
For information about how to resolve conflicts related to your customizations after RUP installation, see Section 5.5.20, "Failure During Applying BI Metadata Updates".
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.
This section contains the steps to install a RUP with RUP Installer. It contains the following topics:
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 Downtime" are successfully completed before installing the RUP.
Note:
If you encounter errors during the RUP installation, refer to Section 5.5, "Troubleshoot RUP Installer Sessions" before clicking any buttons in the RUP Installer User Interface.
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 results in a zero byte file. This causes failure during the copy phase when oracle_common patches are applied. For more information, see Section 5.5.2.3, "Inventory Pointer File is Empty".
Start RUP Installer.
(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/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/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 -Xmx1024m -XX:MaxPermSize=1024m" (Windows)REPOSITORY_LOCATION\installers\fusionapps\Disk1\setup.exe -jreLoc JAVA_HOME_LOCATION [-Dworkers=number_of_workers][-DlogLevel=level] [logfile=log_file_name] [-debug yes]
Table 5-3 shows valid options that can be used when running RUP Installer.
Table 5-3 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". |
|
( |
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 |
|
|
Retrieves the debug information from RUP Installer. |
No. |
Example:
(Unix) REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk6 -invPtrLoc FA_ORACLE_HOME/oraInst.loc (Windows) REPOSITORY_LOCATION\installers\fusionapps\Disk1\setup.exe -jreLoc APPLICATIONS_BASE\fusionapps\jdk6
Example when FA_ORACLE_HOME is registered with a /net path:
REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk6 -invPtrLoc /net/FA_ORACLE_HOME/oraInst.loc
Table 5-4 illustrates the tasks that RUP installer runs. For information about troubleshooting RUP Installer sessions, see Section 5.5, "Troubleshoot RUP Installer Sessions". For information about log files generated during RUP installation, see Section 5.5.1, "RUP Installer Log File Directories".
Table 5-4 RUP Installer Screen Sequence
| 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 from the RUP 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 configuration phase are described in Section 5.1.4, "RUP Installer Configuration Tasks". Before the Starting All Servers task, the Verifying Node Manager and OPMN Status configuration task checks for access to the Node Manager and the OPMN control process. This should fail because you manually shut down these processes prior to starting RUP Installer. Do not cancel and exit out of RUP Installer in response to this task. |
|
Configuration Progress (continued) |
After this task fails, follow these steps:
No additional user action is required in the Configuration Progress screen unless a failure occurs. For more information, see Section 5.5.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. |
Perform the following required manual steps after RUP Installer completes successfully:
Copy the generated OHS configuration <location> elements. If your OHS is scaled out, then the following steps must be repeated for each additional OHS server.
The generated OHS configuration snippets are under FA_ORACLE_HOME/admin/OHS/patched_moduleconf. For each product family file under that directory, identify all <location> elements. Copy and paste these elements to the corresponding file under APPLICATIONS_BASE/instance/CommonDomain_webtier/config/OHS/ohs1/moduleconf.
Further customization of the generated OHS configuration <location> is needed if any of your Oracle Fusion Applications domains are scaled out. For more information, see "Oracle HTTP Server Configuration" in the Oracle Fusion Applications Enterprise Deployment Guide. The generated OHS configuration snippet only contains one server. If there are additional servers in the cluster, you must add the additional server host and port. For example, the following example shows one server.
<Location /icCnSetupCreditRulesPublicService > SetHandler weblogic-handler WebLogicCluster server_name_1:9809 </Location>
The following example has been updated for two servers.
<Location /icCnSetupCreditRulesPublicService > SetHandler weblogic-handler WebLogicCluster server_name_1:9809,server_name_2:9804 </Location>
Stop and start the OHS server.
Verify that the new context roots are accessible through an internet browser. The context roots in the location elements indicate that requests are rerouted to the host and port specified in the location element. The URL that can be used to verify the context root depends on the application that hosts the context root. No standard pattern can be followed.
Follow these steps to manually deploy sca_UpdateSOAMDS_rev1.0.jar SOA composite to every domain:
Access the WLST shell.
(UNIX) SOA_ORACLE_HOME/common/bin/wlst.sh (Windows) SOA_ORACLE_HOME\common\bin\wlst.cmd
Deploy the composite using the sca_deployComposite WLST command to the SOA server of each domain. This composite is located under APPLICATIONS_BASE/fusionapps/atgpf/pcbpel/composite/sca_UpdateSOAMDS_rev1.0.jar.
sca_deployComposite(serverURL, sarLocation, overwrite=true)
Where:
serverURL is the URL of the server that hosts the SOA Infrastructure application (for example, http://hostname:8001).
sarLocation is the absolute path of the SAR file or the ZIP file that bundles multiple SAR files, MAR files, or both. Since the installer copies the UpdateSOAMDS composite to APPLICATIONS_BASE/fusionapps/atgpf/pcbpel/composite/ in the target system, the sarLocation argument should be set to the absolute path of the composite at that location, as shown in the example.
overwrite specifies whether to overwrite a currently deployed SOA composite.
Example:
sca_deployComposite('http://abc10:8001', 'APPLICATIONS_BASE/fusionapps/atgpf/pcbpel/composite/sca_UpdateSOAMDS_rev1.0.jar', overwrite=true)
You must run UpdateSOAMDS composite if you made any flexfield changes. For more information, see "Task: Synchronizing Customized Flexfields in the SOA MDS Repository" in the Oracle Fusion Applications Extensibility Guide.
Update the essbase.cfg file by performing the following steps:
Back up essbase.cfg to essbase.cfg.copy.
Shut down the agent essbaseserver1 using the following commands:
./opmnctl stopproc ias-component=essbaseserver1 ./opmnctl status
Add the line JAVAMAXOUTLINES 128 to essbase.cfg.
Go to this directory to FA_MW_HOME/localdomain/BIInstance/Essbase/essbaseserver1/bin
Edit essbase.cfg to add a line that contains JAVAMAXOUTLINES 128.
Start the agent essbaseserver1 using the following commands:.
./opmnctl startproc ias-component=essbaseserver1 ./opmnctl status
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.
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.5, "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.5.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 b 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 Analyze report for potential conflicts and deletions that are not patched automatically by RUP Installer.
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
If the RUP contains ODI artifacts, you must manually drop the work tables from the schema, FUSION_ODI_STAGE.
Connect to the Oracle Fusion Applications database with the correct privilege.
Drop all tables that begin with E$ from the FUSION_ODI_STAGE schema.
Apply all mandatory post installation patches and follow any post installation steps mentioned in the "Applying Patches" section of Oracle Fusion Applications release notes.
Run the script enable_partition_attr_val.sql to improve the query and crawl performance. This step is optional.
The script enable_partition_attr_val.sql may take several hours to complete, depending on the number of documents that have been previously indexed, and the number of custom attributes. This script can be run ONLINE.
Follow these steps to run the script enable_partition_attr_val.sql:
Start SQL*Plus and connect as the SYS user.
Run the following script:
SES_ORACLE_HOME/search/admin/scripts/enable_partition_attr_val.sql
Activate the schedules by running the following commands.
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 SES_ORACLE_HOME/bin/searchadmin -c http://sesHost:sesPort/search/api/admin/AdminService -p ses_Admin_Password activate indexOptimizer
The variables, ses_Admin_Host and ses_Admin_Port, refer to the host and port of the search_server1 Managed Server or SES cluster
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.
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
Stop 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).
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 a through f for each Oracle Virtual Directory instance, changing the values in the property file as necessary.
In Oracle Fusion Applications 11.1.3.0.0, Oracle moved some tables and indexes from the FUSION schema into different tablespaces. Starting with 11.1.3.0.0, those tables that are seeded with rows by Oracle reside in the FUSION_TS_SEED tablespace and those that are not seeded with rows do not reside in the FUSION_TS_SEED tablespace. This was done to leverage the Transportable Tablespace database feature.
Run the following script to move these objects into new tablespaces so that the tablespace assignment of FUSION objects in your database matches those of a freshly installed RUP2 database.
From the operating system, run the following command:
sqlplus FUSION_schema/FUSION_password APPLICATIONS_BASE/com/acr/db/sql/acr_tablespace_move.sql
If you have not customized the FUSION tablespaces, you must run this script as it is delivered by Oracle. If you customized the tablespaces in which the FUSION-owned objects reside, then you may edit this script before running it to match the customizations that you implemented regarding tablespace assignment for FUSION objects.
Oracle recommends that you save the output of the script and review it for any errors. For example, you may run out of space in one or more tablespaces, in which case you must refer to the Oracle Database Administrators Guide, rectify the situation, and rerun the script.
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".
This section provides information to assist you in troubleshooting RUP Installer sessions. It contains the following topics:
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-5 contains a list of log directories for RUP Installer activities.
Table 5-5 Log Directories for RUP Installer Activities
| Log directory name | Generated from... |
|---|---|
|
|
Installation phase |
|
|
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.3.0.0 for RUP2.
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.3.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, "Perform the Installation". After canceling the previous installation and starting again, you must choose to continue with the previous failed installation by clicking Yes on the Checkpoint Dialog. If the error is not recoverable, you can restore and restart from 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/directory_path/oraInst.loc.
Restore from a backup copy of your oraInst.loc file in case the original file is damaged.
You can recover from this error by creating a new oraInst.loc. See the "Creating the oraInst.loc File" section in the relevant Oracle Database installation guide, for example, Oracle Database Installation Guide, 11g Release 2 (11.2) for Linux.
Then click Retry.
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, 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, "Perform the Installation".
A pop up dialog displays, asking if you want to continue the previous incomplete installation. Select Yes to continue 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 on 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.5.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.
On the Configuration Progress page of RUP Installer, a java.lang.RuntimeException:: error in finding weblogic.Home error may occur. The Oracle WebLogic Server class path may be corrupted.
Follow these steps to resolve this issue:
On the Configuration Progress page of RUP Installer, click Cancel.
Set the WEBLOGIC_HOME in the CLASSPATH parameter explicitly. For example:
CLASSPATH=WLS_HOME/server/lib/weblogic.jar:$CLASSPATH
Restart RUP Installer. All failed configuration actions or steps rerun upon restart.
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.3.0.0/ApplyPrePSAMiddlewarePatchestimestamp.log
FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.3.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.
Perform the following steps if the following error occurs during Applying Middleware Patch Sets:
Jobs failed during Applying Middleware Patchsets: [[{ Job ID 8 (seq[12]
OUIINSTALLER:odi):
Confirm that you have followed the instructions in Section 5.3.2, "Apply Mandatory Prerequisite Patches", Step 6.
If you are installing the RUP in an Oracle VM environment, ensure that ODI Standalone Agent is installed. If this is not installed, refer to "Installing Oracle Data Integrator (ODI) Standalone Agent for a Successful RUP Installation" in Oracle Fusion Applications release notes, 11g Release 1, Update 2 (11.1.3.0.0).
If you receive the following error during preverification, you may have to manually release the edit session. For more information, see Section 11.3.8, "Resolving an EditTimedOutException Error".
weblogic.management.mbeanservers.edit.EditTimedOutException
This section contains information about troubleshooting issues that can 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.3.0.0/PatchManager_DBPatch/
FAPatchManager_apply_timestamp.log
adpatch_apply_timestamp.log
adpatch_apply_timestamp_workerum.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 configuration 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. For more information, see
Select Tell worker to restart a failed job and enter All for all workers.
Select Cancel to stop the session and 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 OPSS Security Store is not running before RUP Installer starts, the related configuration task will fail. Even if you start this server after you notice the failure, the configuration task fails again, with the following error:
Retry of step "oracle.as.install.fapatchconfig.plugin.impl.LdapServerCheck" failed.
Follow these steps to recover:
Abort the failed configuration task.
Select Cancel to end the RUP Installer session.
Start the OPSS Security Store. For more information, see "Starting and Stopping Oracle Internet Directory" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
Start a new RUP Installer session. The installer resumes with the remaining tasks because you selected Cancel, which saves the session.
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.3.0.0/fapatch_timestamp.log
When a failure occurs during Deploying Application Policies, you must restore only the stripe or system policy that 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 following log files are located under the main log directory, FA_ORACLE_HOME/admin/FUSION/log/fapatch/fapatch_11.1.3.0.0/timestamp:
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.
After the deployment of Applications Policies, a version check is performed, to ensure that the version of each stripe was updated successfully in OID. If the version of a stripe is incorrect, an error about a version mismatch is reported.
To resolve this issue, you may need a fix from Oracle Support to retry the deployment after you restore your policy store. Use the OPSS migrateSecurityStore command with the appropriate source and destination arguments. Do not restore a stripe that has not failed.
For more information, see "Migrating with the Script migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
If the IDM Server goes down during the deployment of applications 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.
Read only permission on a .tmp file could result in a failure during JAZN policy stripe validation. This file is created by the Oracle Enterprise Agent, with a file name such as, /tmp/pki_data1967998276.lck.tmp. The file is owned by emcadm, so the policy version validation fails. Because the policy upload completes before version validation starts, you can click Continue to proceed to the next task.
While running the WLST command migrateSecurityStore to backup applications and system policies, the command fails with the following error:
Command FAILED, Reason: JPS-00056: Failed to create identity store service instance idstore.ldap.provider:idstore.ldap. Reason: java.lang.ClassNotFoundException: oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider.
To resolve this error, remove the entry, <serviceInstanceRef ref="idstore.ldap"/>, as described in Step 4 in Section 5.3.4.3, "Back Up Applications and System Policies".
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 this workaround to run 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>
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.
If the deployment of BI Publisher artifacts fails, follow these steps to restore the BI Publisher web catalog and retry the deployment.
Click Cancel to exit RUP Installer.
Caution:
Do not click Abort.
Restore the web catalog from the backup created by RUP Installer. The log file includes a message that provides the location of the backup, for example:
Successfully backed up "/u01/APPLTOP/instance/BIShared/OracleBIPresentationServicesComponent/coreapplication_obips1/catalog/OracleBIApps" to "/u01/APPLTOP/fusionapps/applications/admin/BIP/11.1.3.0.0/en_US/webcat.zip
Restart RUP Installer.
A failure during the Starting All Servers configuration task typically happens when one of the servers times out and fails to restart 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.3.0.0/StartStop/fastartstop_timestamp.log, indicates which server failed to start.
An example of messages for a server that timed out follow.
Time out while performing Start for domain SCMDomain. Waited for 2160 seconds [2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [UTIL] [oracle.apps.startstop.util.MbeanUtil: runSSCommandOnDomain.868] [tid:37] Start operation is completed for domain SCMDomain. Please see SCMDomain.log for details. [2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [UTIL] [oracle.apps.startstop.invoke.StartStopTask: call.221] [tid:37] StartStopTask over for domain SCMDomain [2011-10-21T03:57:52.052--8:00] [fastartstop] [NOTIFICATION:1] [SST] [oracle.apps.startstop.invoke.StartStopTask: call.223] [tid:37] Finished the task for the Domain SCMDomain
Review the log files at the domain level to see a summary of the server status for the domain in the previous step: 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 move 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 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". Then run the following command:
importIPMApplication() & importIPMInput() WLST commands have not run successfully
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.3.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.3.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 file 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.
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.3.0.0/soalogs
Log files for the failed domain:
APPLICATIONS_CONFIG/domains/hostname/domain name/servers/server name/logs/soa_server1.log
APPLICATIONS_CONFIG/domains/hostname/domain name/servers/server name/logs/soa_server1.out
APPLICATIONS_CONFIG/domains/hostname/domain name/servers/server name/logs/soa_server1-diagnostic.log
APPLICATIONS_CONFIG/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.3.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.3.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.
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 Release 2 Update 1 (11.1.3.0.0), should be 11.1.3.0.0 by default.
Example:
wls:/mydomain/ServerConfig> sca_undeployComposite
("http://myhost10:7001",
" ContractsDeliverablePurchaseAgrmntFlowComposite ", "11.1.3.0.0")
You are prompted for 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.3.0.0 as shown in this example:
ContractsDeliverablePurchaseAgrmntFlowComposite [11.1.3.0.0]
Right click on the composite and select SOA deployment > Undeploy.
You may receive the following error during the 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 Metadata Updates 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 Enterprise Manager 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 and
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.
Follow the steps below 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" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition). Also see "Upgrading Oracle Fusion Applications Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition) for background information.
If the attachHome script hangs, when following the steps in Section 5.2.11, "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.11, "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 |
|