Oracle® Fusion Applications Upgrade Guide 11g Release 6 (11.1.6) Part Number E35833-07 |
|
|
PDF · Mobi · ePub |
This chapter describes tasks you must perform before you start the upgrade.
This chapter contains the following topics:
This section describes the following preparation steps for upgrading to Release 6, all of which can be performed before your scheduled down time.
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, 11g Release 5 (11.1.5) for the previous release
Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6) for the release you are upgrading to
You should also have a clear understanding of the following hosts 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: The directory named applications
, located under the Oracle Fusion Applications Middleware home fusionapps
directory
Figure 2-1 shows the relationship of the home directories using the Oracle Fusion Financials product family on a UNIX environment as an example. This figure does not show all subdirectories under APPLICATIONS_BASE and APPLICATIONS_CONFIG. For example, the APPLICATIONS_CONFIG directory contains several more directories for component-specific configuration files. Also, Oracle Database and Oracle Identity Management are not represented in this figure, as they are installed separately. For more information, see "Provisioned Oracle Fusion Applications Home Directories" in the Oracle Fusion Applications Administrator's Guide.
The release repository contains RUP Installer and Oracle Fusion Middleware patches that are required to upgrade to the next release 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 Release 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 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:
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
.
Create a directory named 11.1.6.0.0_post_repo_patches
in the parent directory of your APPLICATIONS_BASE
directory. For example, if APPLICATIONS_BASE
is /u01/APPTOP
, the patch directory is /u01/11.1.6.0.0_post_repo_patches
. For more information about the APPLICATIONS_BASE
directory, see Section 2.1.1, "Before You Begin".
Note:
Oracle recommends you use this exact directory name and location because upgrade-related utilities will find it automatically. See Section 3.1, "Run RUP Installer" for more information. Downloading a patch to the incorrect directory could result in failure.
RUP Installer can apply mandatory post-installation patches that are required by Oracle Fusion Applications if you download the patches from My Oracle Support before you start the upgrade. Note that this feature relates only to patches that are documented in Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6) and that are specifically required for Release 6 (11.1.6).
Note:
If there are no post-installation patches in Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6) when you run RUP Installer, there is no action required for this step.
Perform the following steps to download the patches:
Download patch 16065661 from My Oracle Support and unzip this patch to any directory. After unzipping, the patch directory contains two files, PostRepoPatchDirs.zip
and postRepoPatchDirsREADME.txt
.
Unzip PostRepoPatchDirs.zip
in the 11.1.6.0.0_post_repo_patches
directory to create the directory structure for the patches you download.
Review the README file that was created when you unzipped PostRepoPatchDirs.zip,
to learn how the subdirectories under the 11.1.6.0.0_post_repo_patches
directory map to the corresponding components, such as Oracle Fusion Middleware, database client, and database server components.
Refer to the Section titled "Upgrade Known Issues, Pre-Upgrade Known Issues, Mandatory Patches to be Downloaded" in Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6) to find any additional patches to be downloaded from My Oracle Support.
Table 2-2 describes the types of patches that you download and where to find the list of patches in Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6).
Table 2-2 Mandatory Patches to be Downloaded
Type of Patches | Location in Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6) | Configuration Assistant or Utility That Applies Patches |
---|---|---|
Oracle Database |
Upgrade Known Issues, Pre-Upgrade Known Issues, Mandatory Patches to be Downloaded, Oracle Database |
RUP Lite for RDBMS |
Oracle Fusion Middleware |
Upgrade Known Issues, Pre-Upgrade Known Issues, Mandatory Patches to be Downloaded, Oracle Fusion Middleware |
Apply Pre-PSA Middleware Patches and Apply Post-PSA Middleware Patches |
Oracle HTTP Server (OHS) |
Upgrade Known Issues, Pre-Upgrade Known Issues, Mandatory Patches to be Downloaded, Oracle HTTP Server (OHS) |
RUP Lite for OHS |
Oracle Fusion Applications |
Upgrade Known Issues, Pre-Upgrade Known Issues, Mandatory Patches to be Downloaded, Oracle Fusion Applications |
Apply Downloaded Patches |
Download and unzip the patches listed in the Release Notes for Oracle Fusion Applications 11g Release 6 (11.1.6), into the appropriate subdirectory under the 11.1.6.0.0_post_repo_patches
directory, based on the mapping information in the README file described in Step 3. Downloading a patch to the incorrect directory could result in failure. Note that when you download the Oracle Fusion Applications patches, you must use the Patch Plan feature in My Oracle Support. If you cannot create a patch plan because you do not have Oracle Configuration Manager (OCM) configured, you can create the patch plan by running the script in Step 6.
An excerpt from a sample My Oracle Support patch plan follows:
<results> <generated_date in_epoch_ms="..."></generated_date> <plan> <name>patchplan</name> <type>patch</type> <description/> <last_analyzed></last_analyzed> <oracle_home></oracle_home> <host_name></host_name> <org_id></org_id> <conflict_free_list> <patch> <id>6530099</id> <name>6530099</name> <abstract>db</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> <patch> <id>16021106</id> <name>16021106</name> <abstract>db</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> <patch> <id>6712</id> <name>6712</name> <abstract>soa</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> <patch> <id>731301</id> <name>731301</name> <abstract>db</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> <patch> <id>9912345</id> <name>9912345</name> <abstract>soa</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> <patch> <id>11112</id> <name>11112</name> <abstract>db</abstract> <status></status> <platform></platform> <release></release> <language></language> <install_step></install_step> </patch> </conflictfree_list> </plan> </results>
Run this step if you cannot create a My Oracle Support patch plan for the Oracle Fusion Applications patches. This step assumes that you have downloaded the patches as described in Step 5 without using the Patch Plan feature.
The Perl script, adCreateMosPlan.pl,
reads the patch metadata from the downloaded Oracle Fusion Applications patches to generate the patch plan file, mosdownload.xml
. To run this script, use the Perl executable from APPLICATIONS_BASE
/dbclient/perl/bin
for Unix platforms and APPLICATIONS_BASE
\dbclient\perl\5.8.3\bin\MSWin32-x64-multi-thread
for Windows.
Use the following command syntax to create the patch plan file:
(Unix) setenv PERL5LIB APPLICATIONS_BASE/dbclient/perl/lib/5.8.3:APPLICATIONS_BASE/dbclient/perl/lib/site_perl/5.8.3/: APPLICATIONS_BASE/dbclient/perl/lib/site_perl $APPLICATIONS_BASE/dbclient/perl/bin/perl $REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/bin/adCreateMosPlan.pl download_location_for_Oracle Fusion Applications_patches_only (Windows) SET PERL5LIB=APPLICATIONS_BASE\dbclient\perl\5.8.3;APPLICATIONS_BASE\dbclient\perl\site\5.8.3\;APPLICATIONS_BASE\dbclient\perl\site %APPLICATIONS_BASE%\dbclient\perl\5.8.3\bin\MSWin32-x64-multi-thread\perl %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\bin\adCreateMosPlan.pl download_location_for_Oracle Fusion Applications_patches_only
Download the following patches:
Download patch 14543240 to be used for finding conflicting patches, as described in Section 2.1.15, "Find Conflicting Patches".
Download the version of OPatch that is delivered in patch 6880880, version 11.2.0.3.3, which is used in Section 2.2.4.1, "Run RUP Lite for RDBMS".
Some new Release 6 features require that all database schemas be registered in the credential store. Perform the following steps to ensure that all database schemas are registered in the credential store. You can perform some of the steps in interactive mode or non-interactive mode. Steps 1 through 3 are the same for both modes.
Copy the following file to FA_ORACLE_HOME
and unzip it there:
REPOSITORY_LOCATION/installers/pre_install/pcubundle.zip
If files already exist in this directory, run unzip in overwrite mode so that existing files are overwritten.
Ensure that the following files in the FA_ORACLE_HOME/
lcm/util/bin
directory have execute permission: templateGen.sh
, iniGen.sh
, faschemasutil.sh
, and schemaPasswordChangeTool.sh
.
Run the templateGen
utility to create the csf_template.ini
template file.
(Unix) cd APPLICATIONS_BASE/fusionapps/applications/lcm/util/bin setenv JAVA_HOME java_home_location templateGen.sh -appbase APPLICATIONS_BASE (Windows) cd APPLICATIONS_BASE\fusionapps\applications\lcm\util\bin set JAVA_HOME=java_home_location templateGen.cmd -appbase APPLICATIONS_BASE
For the -appbase argument, specify the complete directory path to the APPLICATIONS_BASE
directory.
The templateGen
utility generates the following template files in the config directory:
standard_template.ini
csf_template.ini
Complete this process by using interactive or non-interactive mode:
For more information about the utilities used in this process, see "Changing Oracle Fusion Applications Passwords in the Oracle Database" in the Oracle Fusion Applications Administrator's Guide.
Perform the following steps for non-interactive mode:
Make a copy of csf_template.ini
from the APPLICATIONS_BASE/
fusionapps/applications/lcm/util/config
directory. In this example, the copy is named csf_plain.ini
.
Manually edit csf_plain.ini
as follows:
Add the correct value for the master_password
property. This value must be 8 or more characters.
For each line that contains #text#
or #password#
, replace #text#
or #password#
with the correct values for your environment.
Note:
Do not alter csf_plain.ini
beyond these changes, to prevent incorrect results.
Create an encrypted version of csf_plain.ini
and delete the clear-text input file. This step requires an encryption tool, such as the lcmcrypt
tool or the Linux gpg
tool, that takes an encrypted file and a passphrase and writes the decrypted contents to the standard output. In the following example, the command reads the passphrase from the standard input and produces an encrypted output file, csf_plain.ini.enc
.
echo password | ./lcmcrypt.sh -encrypt -inputfile csf_plain.ini
Run iniGen.sh
in non-interactive mode, which also requires a decryption tool, to take an encrypted file and a passphrase and write the decrypted contents to the standard output. iniGen.sh
uses the value of the master_password
property to encrypt all other passwords in the generated input file. It also alters the value of the master_password
property back to master_password=ignore_me
in the generated input file. Note that the master password you use in the command is the same password that should be added in csf_plain.ini
, rather than "ignore_me" in non-interactive mode.
The following example uses lcmcrypt
:
cd APPLICATIONS_BASE/fusionapps/applications/lcm/util/bin echo password | ./lcmcrypt.sh -decrypt -inputfile csf_plain.ini.enc | ./iniGen.sh -nonInteractive -templatefile ../config/csf_template.ini -outputfile ../config/csf_encrypted.ini -appbase APPLICATIONS_BASE
The call to lcmcrypt
reads the passphrase from the standard input and writes the clear text version of csf_plain.ini.enc
to standard output, which is then piped to the standard input of iniGen.sh
.
Run schemaPasswordChangeTool.sh
to seed CSF keys, as shown in the following example:
cd APPLICATIONS_BASE/fusionapps/applications/lcm/util/bin echo master_password | ./schemaPasswordChangeTool.sh -inputfile ../config/ csf_encrypted.ini -appbase APPLICATIONS_BASE
The schema password change tool uses the master password from standard input to decrypt entries in the input file. The tool requires that the INTERNAL section have the ini.type=CSF
property to run in CSF mode, which then inserts and updates only CSF entries.
Perform the following steps for interactive mode:
Run the iniGen
command to create the csf_encrypted.ini
input file.
Use the template file you created in Step 3, and write the csf_encrypted.ini
input file to the same directory as the template file. Both of these files should be in the APPLICATIONS_BASE/
fusionapps/applications/lcm/util/config
directory. The iniGen.sh
command prompts for all required values, including the password for all relevant database schemas. It also prompts for a master password for encrypting entries in the input file.
Note:
If your sys
password is different from other schema passwords, select no when responding to the following question: "Do you want to update the same password for all schemas (yes/no)? default yes".
(Unix) cd APPLICATIONS_BASE/fusionapps/applications/lcm/util/bin ./iniGen.sh -appbase APPLICATIONS_BASE -templatefile ../config/csf_template.ini -outputfile ../config/csf_encrypted.ini (Windows) cd APPLICATIONS_BASE\fusionapps\applications\lcm\util\bin iniGen.cmd -appbase APPLICATIONS_BASE -templatefile ..\config\csf_template.ini -outputfile ..\config\csf_encrypted.ini
Ensure that the Common Domain Administration server is up. Then run the schemaPasswordChangeTool
command to ensure all database schemas are registered in the credential store. This command prompts for a master password for decrypting entries in the input file.
(Unix) cd APPLICATIONS_BASE/fusionapps/applications/lcm/util/bin ./schemaPasswordChangeTool.sh -appbase APPLICATIONS_BASE -inputfile ../config/csf_encrypted.ini (Windows) cd APPLICATIONS_BASE\fusionapps\applications\lcm\util\bin schemaPasswordChangeTool.cmd -appbase APPLICATIONS_BASE -inputfile ..\config\csf_encrypted.ini
Refer to Release Notes for Oracle Fusion Applications 11g Release 6 (11.1.6) to verify that your database and Sql*Net tuning parameters are set properly to avoid timeout errors during the upgrade.
If you performed JDeveloper customizations to a SOA composite and then you deployed the composite to the SOA runtime, you must perform manual steps to merge your customizations during the installation. To ensure that your customizations can be merged successfully, review the recommendations in "Merging Runtime Customizations from a Previously Deployed Revision into a New Revision" in the Oracle Fusion Applications Extensibility Guide before you start RUP Installer.
You will merge your customizations after the SOA Preverification configuration assistant fails during the installation. For more information, see Section 6.21, "Merging SOA Composite JDeveloper Customizations During SOA Preverification".
Ensure that you have your own versions of any customized BI Publisher reports. If a release 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.
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 WebLogic Scripting Tool Command Reference.
Set the APPLICATIONS_BASE
and REPOSITORY_LOCATION
environment variables. Set the APPLICATIONS_BASE
environment variable to point to the directory that contains Oracle Fusion Applications. For example, if Oracle Fusion Applications is installed in /server01/APPTOP/fusionapps
, then set the APPLICATIONS_BASE
environment variable to /server01/APPTOP
. Set the REPOSITORY_LOCATION
environment variable to point to the root directory where the repository is staged, as described in Section 2.1.2, "Download the Release Repository".
Examples follow:
(Unix) setenv APPLICATIONS_BASE /server01/APPTOP/ setenv REPOSITORY_LOCATION /server01/Release6Repo/ (Windows) set APPLICATIONS_BASE=\server01\APPTOP\ set REPOSITORY_LOCATION=\server01\Release6Repo\
Note:
Set these environment variables on all hosts that share the same APPLICATIONS_BASE
before running all upgrade tools and utilities mentioned in this guide.
Run the Health Checker utility directly from REPOSITORY_LOCATION
and from the primordial host. You can run these checks any number of times prior to your down time. Ensure that you set the environment variables described in Section 2.1.12, "Set Environment Variables".
For more information about Health Checker, see Section 1.5.1, "Pre-Upgrade Tasks Performed by Health Checker Before Down Time".
Run Health Checker using the following command syntax:
(Unix) $REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/bin/hcplug.sh -manifest $REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/config/PreDowntimeChecks.xml [-DlogLevel=log_level] (Windows) %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\bin\hcplug.cmd -manifest %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\config\PreDowntimeChecks.xml [-DlogLevel=log_level]
Review the Health Checker log file or the HTML summary report to see if any errors occurred that require corrective action. The log file and the HTML summary are located in APPLICATIONS_CONFIG/
fapatch/logs/
release_version/
healthchecker
.
After you resolve the issue that caused the error, start Health Checker again to run the failed tasks. You must rerun Health Checker until there are no failed tasks. For more information, see Section 6.25, "Troubleshooting Health Checker Pre-Down Time Checks".
Oracle Provisioning records installation information about the following Oracle homes separately from information about other products: Oracle Business Intelligence (Oracle BI), Oracle Global Order Processing (GOP), Web Tier, and Web Tier Common Oracle home. RUP Installer expects information about all products to be recorded in the same place. For more information about home directories, see "Provisioned Oracle Fusion Applications Home Directories" in the Oracle Fusion Applications Administrator's Guide.
The following steps describe how to manually register all missing Oracle homes in central inventory.
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 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
.
(Windows) BI_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Note:
Rerunning the ATTACH_HOME
command does not cause any issues.
Run attachHome
from the GOP Oracle home, for example, APPLICATIONS_BASE
\fusionapps\gop
.
(Windows) GOP_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Run attachHome
from the Web Tier Oracle home, for example, APPLICATIONS_BASE
\webtier_mwhome\webtier
.
(Windows) WEBTIER_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Run attachHome
from the Web Tier Common Oracle home, for example, APPLICATIONS_BASE
\webtier_mwhome\oracle_common
.
(Windows) WEBTIER_COMMON_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Run attachHome
from the Web Tier Webgate Oracle home, for example, APPLICATIONS_BASE\webtier_mwhome\webgate
.
(Windows) WEBTIER_WEBGATE_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Run attachHome
from the Oracle Common Oracle home, for example, APPLICATIONS_BASE\fusionapps\oracle_common
.
(Windows) COMMON_HOME\oui\bin\attachHome.bat -jreLoc JAVA_HOME_LOCATION
Register the dependency between the BI Oracle home and Oracle Common Oracle home.
Back up the existing file, C:\ProgramFiles\Oracle\Inventory\ContentsXML\inventory.xml
.
Update this inventory.xml
file as follows:
<HOME NAME="OH198367808" LOC="APPLICATIONS_BASE/fusionapps/bi" TYPE="O" IDX="12"> <DEPHOMELIST> <DEPHOME LOC="APPLICATIONS_BASE/fusionapps/oracle_common"/> </DEPHOMELIST> </HOME>
Register the dependency between Web Tier Oracle home and Web Tier Common Oracle home.
Back up the existing file, C:\ProgramFiles\Oracle\Inventory\ContentsXML\inventory.xml
.
Update this inventory.xml
file as follows:
<HOME NAME="OH987588708" LOC="APPLICATIONS_BASE/webtier_mwhome/webtier" TYPE="O" IDX="13"> <DEPHOMELIST> <DEPHOME LOC="APPLICATIONS_BASE/webtier_mwhome/oracle_common"/> </DEPHOMELIST> </HOME>
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. Verify that there are entries for GOP and for BI, and that the BI entry lists the Oracle Common dependency you specified. Do the same for Web Tier information.
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>
If you installed any post-Release 5 Oracle Fusion Middleware one-off patches on your Oracle Fusion Applications environment, they may conflict with patches in the Release 6 repository. To avoid this issue, you must obtain the list of conflicting patches, download the equivalent post-Release 6 one-off patches, and run the patch removal script.
Perform the following steps to obtain the list of conflicting patches:
Follow the instructions in the README.txt file of patch 14543240, which you downloaded in Section 2.1.5, "Download Other Patches Required by the Upgrade", to run the script to obtain the list of conflicting patches. You must run this script on the following hosts: RDBMS, IDM, OHS, and the primordial host.
Keep a copy of the conflicting patches report for retrieval in the case of failure or restore. Note that the conflict checker maintains separate log files every time you run it by labeling the log directory with a timestamp.
Contact Oracle Support to obtain any post-Release 6 patches that provide equivalent functionality that will be lost if the conflicts are rolled back. Download these patches to the location mentioned in Section 2.1.4, "Download Mandatory Post-Release 6 Patches". You will run the patch removal script in Section 2.2, "Pre-Upgrade Steps - During Down Time".
If you followed steps to scaleout hosts, you may have added the Administration Server of the scaled out host to a new machine. This section provides the steps to temporarily add the Administration Server back to the originally provisioned machine so that all domain directories can be found by RUP Installer. During post-upgrade steps, you add the Administration Server back to the machine that was created during scaleout.
Perform the following steps to run the validation for domain directories and to temporarily update the machine for Administration Servers, if needed.
Unzip validatedomains.zip
into any directory on the primordial host.
Run the validatedomains
utility:
(Unix) ./validatedomains.sh APPLICATIONS_BASE (Windows) validatedomains.bat APPLICATIONS_BASE
If the utility reports any domains that failed the validation, perform the following steps on the Administration Server of each of the reported domains:
Log in to the WebLogic console for the domain.
Navigate to Environment, then Machines.
Find the machine that corresponds to the hostname for which the Administration Server was initially provisioned.
Click on the machine and go to the Servers tab. Note that the Administration Server should not appears on the list of servers. If it does appear on the list, either this domain passed validation or this is not the originally provisioned machine for the Administration Server.
Click Lock & Edit to make changes.
Click Add.
Select the AdminServer and click Finish.
Click Activate Changes to apply the changes.
Verify that all files under the APPLICATIONS_CONFIG
directory are owned and readable by the operating system user who is running the upgrade.
This section describes the following preparation steps for upgrading to Release 6, all of which must be performed during your system down time.
This step is run by a shell script, runSESDisableIndexOptimizer.sh
(runSESDisableIndexOptimizer.bat
for Windows), located in the REPOSITORY_LOCATION
/installers/farup/Disk1/upgrade/bin
directory. The script calls the Oracle Secure Enterprise Search (Oracle SES) searchadmin
utility in order to stop Index Schedules that have one of the following statuses: LAUNCHING, EXECUTING, STOPPING, or RUNNING. After all Index Schedules have been stopped, Index Optimization is disabled.
Ensure the environment variables described in Section 2.1.12, "Set Environment Variables" are set and then run the script from the primordial host. Primordial host is define in Section 2.1.1, "Before You Begin".
Use the following command syntax:
(Unix) setenv JAVA_HOME java_home_location $REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/bin/runSESDisableIndexOptimizer.sh (Windows) set JAVA_HOME=java_home_location %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\bin\runSESDisableIndexOptimizer.bat
This section contains steps to follow for all platforms. For Windows platforms, also follow the steps in Section 2.2.2.5, "Steps for Windows".
To prevent locks on patched objects and other data issues during patching, perform the following tasks.
Stop all servers and processes (including BI Presentation Servers), except the OPSS Security Store and the database, before starting the installation. If you want to use the fastartstop
utility to do this, see "Understand Starting and Stopping with the fastartstop Utility" in the Oracle Fusion Applications Administrator's Guide.
You can skip this step if you successfully completed the steps in Section 2.2.2.1, "Stop All Servers" and all servers were cleanly shut down.
If servers were not cleanly shut down, set the CrashRecoveryEnabled
property in nodemanager.properties
to "false" for all domains by running the following command:
updateNMProperties.pl -appBase APPLICATIONS_BASE_location -preUpgrade [-verbose]
The updateNMProperties.pl
script can be found in REPOSITORY_LOCATION/
installers/farup/Disk1/upgrade/bin
.
If the updateNMProperties.pl
script fails in Windows, update the value of CrashRecoveryEnabled
to "false" in FA_ORACLE_HOME\
instance\nodemanager\
host_name
\nodemanager.properties
.
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 2.2.2.5, "Steps for Windows".) Note that you must start the Node Manager for all domains and the OPMN control process after the first installer completes successfully and before proceeding to the second installer.
For more information, see "Stopping Node Manager" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.
Use the following procedure to stop the OPMN control processes for Oracle Business Intelligence, GOP, and Web Tier (OHS). This procedure also stops all BI server processes, all GOP processes, and the OHS process.
Note:
There should be no Web Tier processes on this installation if you are running OHS from a separate installation (DMZ or otherwise). In this case, you do not need to stop the Web Tier processes.
Set ORACLE_INSTANCE
to the location of the target Oracle instance directory.
Go to the bin
directory under the target Oracle instance directory.
Run the opmnctl
program from the current directory with the stopall
command.
The following example is for Oracle Business Intelligence. 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) setenv INSTANCE_HOME APPLICATIONS_CONFIG/BIInstance cd $ORACLE_INSTANCE/bin ./opmnctl stopall (Windows) set INSTANCE_HOME=APPLICATIONS_CONFIG\BIInstance cd $ORACLE_INSTANCE\bin .\opmnctl stopall
Example for GOP:
(Unix)setenv ORACLE_INSTANCE APPLICATIONS_CONFIG/gop_1 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) setenv INSTANCE_HOME APPLICATIONS_CONFIG/CommonDomain_webtier 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 2.1.1, "Before You Begin".
For more information about concepts related to ORACLE_HOME
and ORACLE_INSTANCE
, refer to the "Understanding Oracle Fusion Middleware Concepts" chapter in the Oracle Fusion Middleware Administrator's Guide.
To verify there are no active ODI sessions, follow the steps in "Monitoring Executions Results" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Perform the following steps before running RUP Installer on Windows.
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 the 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 RUP Installer. Before starting 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.
Perform the following steps to upgrade the Oracle Identity Management domain to 11g Release 6 (11.1.6):
Remove conflicting patches on all nodes in the Oracle Identity Management domain.
To remove conflicting patches, run the patch removal script by following the instructions contained in the README.txt file in patch 14543240. You downloaded patch 14543240 in Section 2.1.5, "Download Other Patches Required by the Upgrade".
Important:
You must run the conflicting patch removal script on every node in the domain before you apply any upgrade patch. If you run this script at any time other than before upgrading, the system may be left in an unstable state. Specifically, you must run the script on each of the following nodes before applying any upgrade patch:
IDM Node
IAM Node
OHS Node
You can learn more about each of the nodes in the domain by referring to the "Oracle Identity Management Overview" section of the Oracle Fusion Applications Installation Guide for 11g Release 6 (11.1.6).
Apply upgrade patches to each of the nodes in the Oracle Identity Management domain.
To apply the upgrade patches, perform the steps in the "Oracle Identity Management Patches for the IDM Domain" section of the Oracle Fusion Applications Installation Guide for 11g Release 6 (11.1.6).
Determine if any additional mandatory patches are required and apply them.
To determine if any additional patches are required for upgrading the Oracle Identity Management domain, refer to the "Additional Mandatory Patches for the IDM Domain" section of the Release Notes for Oracle Fusion Applications 11g Release 6 (11.1.6).
Important:
If any additional patches are listed in that section of the Release Notes, you must apply them to upgrade the Oracle Identity Management domain.
Review known problems and perform workarounds.
Known issues, and their workarounds, in each release are documented in the Release Notes. Review the known problems in Oracle Identity Management for this release and perform their workarounds by referring to each of the following sections in the Release Notes for Oracle Fusion Applications 11g Release 6 (11.1.6):
Pre-Installation Known Issues
Installation Known Issues
Post-Installation Known Issues
Platform-Specific Known Issues
Upgrade Known Issues
Post Upgrade Known Issues
Run Time Environment Known Issues
Note:
Before you perform the steps in this section, you must remove any conflicting patches from the RDBMS host. Follow the steps in the README.txt file of patch 14543240 to run the script on the RDBMS host. You downloaded patch 14543240 in Section 2.1.5, "Download Other Patches Required by the Upgrade". Ensure that you run this script only before upgrading. If you run this script at any time other than before upgrading, the system may be left in an unstable state.
When you run RUP Installer, the patches you downloaded in Step 2, Section 2.1.15, "Find Conflicting Patches", will automatically apply.
Run the RUP Lite for RDBMS utility to perform the tasks required to update your Oracle Fusion Applications database before you upgrade. RUP Lite for RDBMS can be run in three modes: validate
, setdbparameters
, and apply
. For more information, see Section 1.6, "RUP Lite for RDBMS Utility".
RUP Lite for RDBMS uses non-interactive OPatch calls to apply RDBMS patches. OPatch tries to install and configure Oracle Configuration Manager (OCM) if OCM has not already been installed and configured. This causes non-interactive OPatch calls to fail in some cases. To avoid this issue, Oracle recommends that you install OCM prior to running RUP Lite for RDBMS. If you plan to use OCM, you should configure it after you install it. If you do not plan to use OCM, you can either configure it in disconnected mode or let RUP Lite for RDBMS configure it. If you install OCM and do not configure it, RUP Lite for RDBMS will automatically configure it in disconnected mode. For more information, see "Installing Oracle Configuration Manager Using the Command Line Interface" in the Oracle Configuration Manager Installation and Administration Guide.
If you do not use Oracle Exadata Database Machine, run RUP Lite for RDBMS to automatically apply the mandatory Oracle Database patches mentioned in the "Oracle Database" section of Oracle Fusion Applications Release Notes, 11g Release 6 (11.1.6). This step applies Oracle Database patches that reside in both the REPOSITORY_LOCATION
and the 11.1.6.0.0_post_repo_patches
directories, which you downloaded in Section 2.1.4, "Download Mandatory Post-Release 6 Patches". Follow the steps in Section 2.2.4.1, "Run RUP Lite for RDBMS".
If you use Oracle Exadata Database Machine, manually apply the patches listed in Section 2.2.4.4, "Apply Exadata Patches" followed by any patches you downloaded in Section 2.1.4, "Download Mandatory Post-Release 6 Patches". Do not run RUP Lite for RDBMS.
If you are running Oracle Fusion Applications on a RAC database, follow the steps in Section 2.2.4.2, "Run RUP Lite for RDBMS in a RAC Database".
Perform the following steps to run RUP Lite for RDBMS in three modes: validate
, setdbparameters
, and apply
:
Apply the version of OPatch that is delivered in patch 6880880, version 11.2.0.3.3, which you downloaded in Section 2.1.5, "Download Other Patches Required by the Upgrade".
Copy the TPBundler.zip
file to any temporary directory, such as work_dir in the following example:
cp REPOSITORY_LOCATION/installers/pre_install/TPBundler.zip work_dir
Unzip TPBundler.zip
in the work_dir directory, which contains the following files after unzipping:
createTPBundle.jar createTPBundle.cmd createTPBundle.sh ojdl.jar tpBundleConfig_DB.xml tpBundleConfig_IDM.xml tpBundleConfig_OHS.xml README.txt
The createTPBundler
utility creates the RDBMS patch bundle, DBPatches.zip
, and RUP Lite for RDBMS. This patch bundle contains the mandatory prerequisite patches that are delivered in REPOSITORY_LOCATION
as well as any patches you may have downloaded.
Use the following command syntax to run createTPBundler
, which creates DBPatches.zip
in a temporary directory, referred to as work_dir in the example. Note that work_dir must have read/write permissions.
(Unix) sh createTPBundle.sh -shiphomelocation REPOSITORY_LOCATION -tempdir work_dir -target DB [-patchdownloadloc location_of_downloaded_patches] (Windows) createTPBundle.cmd -shiphomelocation REPOSITORY_LOCATION -tempdir work_dir -target DB [-patchdownloadloc location_of_downloaded_patches]
The following options are available for createTPBundler:
-shiphomelocation
: Location of the createTPBundler
repository.
-tempdir
: Destination directory to which the generated zip file was copied.
-target:
Target against which the copy should be initiated. Valid values are IDM, DB, OH. Use the DB value.
-patchdownloadloc
: Location of the patch directory where you downloaded the patches in Section 2.1.4, "Download Mandatory Post-Release 6 Patches". Use this option only if you downloaded patches to a directory other than the default patch download directory, which is 11.1.6.0.0_post_repo_patches
.
-logfile
: Full path of the createTPbundle
log file. The default is createTPBundle.log
in the current directory.
-loglevel
: Log level for the createTPbundler
utility. Valid values are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST. The default value is INFO.
Copy DBPatches.zip
to any temporary directory on the database server host.
Log in to the database server host.
Unzip DBPatches.zip
to any temporary directory on the database server host. The following subdirectories and files exist after unzipping.
|-- DB_timestamp -- db_server_bundle |-- README.txt |-- bin | |-- ruplite.bat | |-- ruplite.sh |-- metadata | |-- env.properties | |-- installer.properties | |-- plugin-metadata.txt |-- custom_db_server | -- database | -- patch | -- downloaded one-off patches |-- db_server | |-- database | |-- opatch | | -- OPatch zip file | |-- patch | | -- One-off patches in repository | |-- psu | | -- Patch Set Updates in repository |-- db | |--RUP Lite related files |-- lib | |--RUP Lite related files |-- ruplite | |--RUP Lite related files |-- techpatch | |--TPU related files
Perform this step only if you are running RUP Lite for RDBMS on an Oracle VM environment.
As the root user, change the permissions on the DB_timestamp subdirectory:
chmod -R 777 DB_timestamp
Exit out of root user to ensure that you do not perform the remaining steps as root.
Set executable permissions on ruplite.sh
. (Unix only)
chmod -R 755 DB_timestamp/db_server_bundle/bin/ruplite.sh
Set the JAVA_HOME
environment variable as shown in the following example:
(Unix) setenv JAVA_HOME java_home_location (must be jdk6) (Windows) set JAVA_HOME=java_home_location (must be jdk6)
Update the following properties in the work_dir/
DB_
timestamp/
db_server_bundle/
metadata/env.properties
file. Example values are shown.
ORACLE_SID=Use an instance name that belongs to the fusionapps
database.
ORACLE_HOME=Use an Oracle home directory on which patches must be applied, such as /u01/db/11.2.0.3
.
TNS_ADMIN=Use a valid tns_admin
location, which is typically located under the grid infra and contains listener.ora
and sqlnet.ora
files.
LISTENER_NAME=Use a listener name.
PFILE=/u01/db/11.2.0.3/dbs/init.ora
, for example. You can retrieve this value by running the following query:
select NAME, VALUE from v$parameter where NAME like '%file%';
Update the PFILE
property if your database is started using pfile.
DBSERVER_RESTART=true or false.
To minimize downtime, you can use "false" for setdbparameters
mode, and "true" for apply
mode.
If DBSERVER_RESTART
is set to "false", the database server, listener and other related services must be manually stopped before running RUP Lite in apply
mode. Then after running RUP Lite in apply
mode, you must manually run Steps a through d.
If the value for this property is set to "true", RUP Lite automatically stops the listener and database before applying patches. In addition, RUP Lite automatically performs the following actions after applying patches when DBSERVER_RESTART
=true:
Start the database instance.
Start the listener.
Run catbundle.sql
with arguments "psu apply" on non-windows and "winbundle apply" on windows.
(Unix) $ORACLE_HOME/rdbms/admin/catbundle.sql psu apply (Windows) %ORACLE_HOME%\rdbms\admin\catbundle.sql winbundle apply
For a list of catbundle.sql
errors that can be ignored, see Section 6.28, "Ignorable Errors Reported by catbundle.sql".
Run ORACLE_HOME
/rdbms/admin/catmetx.sql
.
(Unix) $ORACLE_HOME/rdbms/admin/catmetx.sql (Windows) %ORACLE_HOME%\rdbms\admin\catmetx.sql
Verify that the java version is 1.6 or above by using the following command:
(Unix) $JAVA_HOME/bin/java -version (Windows) %JAVA_HOME%\bin\java -version
If your version is lower, download 1.6 or a higher version from My Oracle Support.
Stop all user applications.
Change directory to the following location:
DB_
timestamp/
db_server_bundle/bin
Run RUP Lite for RDBMS in validate
mode. The database instance and listener must be up.
(Unix) ruplite.sh validate (Windows) ruplite.bat validate
Review the log file, output/logs/ruplitevalidate.log
, to confirm whether the database parameters contain the values you set in Step 11 and the values displayed in Table 1-3, "Recommended Values for Database Parameters". If any errors occurred, you can find them in this log file.
If any of the parameters do not contain the recommended value, proceed to the next step to run RUP Lite for RDBMS in setdbparameters
mode. If all parameters are correct, proceed to Step 19 to run RUP Lite for RDBMS in apply
mode.
Run RUP Lite for RDBMS in setdbparameters
mode. The database instance and listener must be up.
(Unix) ruplite.sh setdbparameters (Windows) ruplite.bat setdbparameters
Review the log file, output/logs/ruplitesetdbparameters.log
, to confirm whether the database parameters contain the values displayed in Table 1-3, "Recommended Values for Database Parameters". If any errors occurred, you can find them in this log file also.
Running RUP Lite for RDBMS in apply
mode starts and stops only the Fusion Applications database listener and the database server. You must stop any other applications or processes that are running from the Oracle Fusion Applications home directory, except the OPSS Security Store, before you run RUP Lite for RDBMS. For more information, see "Starting and Stopping" in the Oracle Fusion Applications Administrator's Guide. Also confirm that the BI presentation servers are shut down.
You can set the parameter DBSERVER_RESTART
(available in metadata/env.properties
) to "false" if you want to manually shut down the database, stop the listener before patching, and start it up after applying the patches. For Windows, if you set DBSERVER_RESTART
to "false", follow the steps in Section 2.2.4.3, "Stop Services on Windows Before Running RUP Lite For RDBMS".
Note:
To avoid an issue with active files while patching, ensure that no applications or processes are running from the ORACLE_HOME
that is referenced in metadata/env.properties
. If DBSERVER_RESTART
=true, you can ignore the database instance and listener processes because RUP Lite brings them down.
Run RUP Lite for RDBMS in apply
mode.
(Unix) ruplite.sh (Windows) ruplite.bat
Review the following log files located under the output/logs
directory if any errors occurred:
ruplitedb.log tp_property_editor_timestamp.log db_apply_downloaded_patches_timestamp.log db_apply_repository_patches_timestamp.log db_validate_downloaded_patches_timestamp.log db_validate_repository_patches_timestamp.log downloaded_patch_validate_results_timestamp.xml repository_patch_validate_results_timestamp.xml post_db_restart_actions_timestamp.log
If RUP Lite for RDBMS fails, resolve the issue reported in the log files. When you restart a failed session, RUP Lite for RDBMS ignores the successful actions, starts with the failed action, and proceeds from that point.
The post_db_restart_actions_
timestamp.
log
file includes the output from catbundle.sql
and catmetx.sql
. For a list of catbundle.sql
errors that can be ignored, see Section 6.28, "Ignorable Errors Reported by catbundle.sql".
If you set DBSERVER_RESTART
to "false", perform the steps in Step 11, a. through d.
You must manually execute any manual steps that are documented in the README.txt
file of the patches you applied with RUP Lite for RDBMS. RUP Lite for RDBMS does not execute manual steps from the README.txt
file of the patch.
Perform the following steps to run RUP Lite for RDBMS in a RAC database. You must run RUP Lite for RDBMS on all available file systems. This may involve multiple hosts and nodes. Note that a single Oracle home can be shared by multiple nodes, and in this case, running RUP Lite on a single node of such a group is sufficient.
Follow Steps 1 through 10 in Section 2.2.4.1, "Run RUP Lite for RDBMS".
Stop all user applications that use the Oracle home directory being patched.
Update the following properties in the work_dir/
DB_
timestamp/
db_server_bundle/
metadata/env.properties
file. Example values are shown.
ORACLE_HOME=Use an Oracle home directory on which patches must be applied, such as /u01/db/11.2.0.3
.
ORACLE_SID=Use an instance name that belongs to the fusionapps
database and is run against the ORACLE_HOME set in the previous property.
TNS_ADMIN=Use a valid tns_admin
location, which is typically located under the grid infra and contains listener.ora
and sqlnet.ora
files.
LISTENER_NAME=Use a listener name.
PFILE=/u01/db/11.2.0.3/dbs/init.ora
, for example. You can retrieve this value by running the following query:
select NAME, VALUE from v$parameter where NAME like '%file%';
Update the PFILE
property if your database is started using pfile.
DBSERVER_RESTART=false
Note that the value of DBSERVER_RESTART must be "false".
Verify that the java version is 1.6 or above by using the following command:
(Unix) $JAVA_HOME/bin/java -version (Windows) %JAVA_HOME%\bin\java -version
Change directory to the following location:
DB_
timestamp/
db_server_bundle/bin
Run RUP Lite for RDBMS in validate
mode. The database instance and listener must be up.
(Unix) ruplite.sh validate (Windows) ruplite.bat validate
Review the log file, output/logs/ruplitevalidate.log
, to confirm whether the database parameters contain the values you set in Step 3 and the values displayed in Table 1-3, "Recommended Values for Database Parameters". If any errors occurred, you can find them in this log file also.
If any of the parameters do not contain the recommended value, proceed to the next step to run RUP Lite for RDBMS in setdbparameters
mode. If all parameters are correct, proceed to Step 10.
Run RUP Lite for RDBMS in setdbparameters
mode. The database instance and listener must be up.
(Unix) ruplite.sh setdbparameters (Windows) ruplite.bat setdbparameters
Review the log file, output/logs/ruplitesetdbparameters.log
, to confirm whether the database parameters contain the values displayed in Table 1-3, "Recommended Values for Database Parameters". If any errors occurred, you can find them in this log file also.
Shut down all Oracle RAC databases on all nodes in the cluster, even those that are sharing the same host. Database instances that are running could cause issues that prevent patches from applying successfully or you could receive errors because the patches update files that are in use.
To shut down an Oracle RAC database, enter the following command in a command window, where CRS_home
is the location of the Grid home directory and sales
is the name of the database in the following example:
(Unix) CRS_home/bin/srvctl stop database -d sales (Windows) CRS_home\bin\srvctl stop database -d sales
Stop the listener that is running from all Oracle homes in the cluster, using the following command. Note that all services must be shut down if the OIM and OID databases are configured on same listener.
(Unix) CRS_home/bin/srvctl stop listener [-l listener_name] (Windows) CRS_home\bin\srvctl stop listener [-l listener_name]
To avoid an issue with active files while patching, ensure that no applications or processes are running from the ORACLE_HOME that is referenced in metadata/env.properties
.
Run RUP Lite for RDBMS in apply
mode.
(Unix) ruplite.sh (Windows) ruplite.bat
Review the following log files located under the output/logs
directory if any errors occurred:
ruplitedb.log tp_property_editor_timestamp.log db_apply_downloaded_patches_timestamp.log db_apply_repository_patches_timestamp.log db_validate_downloaded_patches_timestamp.log db_validate_repository_patches_timestamp.log downloaded_patch_validate_results_timestamp.xml repository_patch_validate_results_timestamp.xml post_db_restart_actions_timestamp.log
If RUP Lite for RDBMS fails, resolve the issue reported in the log files. When you restart a failed session, RUP Lite for RDBMS ignores the successful actions, starts with the failed action, and proceeds from that point.
You must manually execute any manual steps that are documented in the README.txt
file of the patches you applied with RUP Lite for RDBMS. RUP Lite for RDBMS does not execute manual steps from the README.txt
file of the patch.
If there is more than one ORACLE_HOME in the RAC database, you do not need to run SQL scripts again when patching the 2nd through the nth ORACLE_HOME, but you do need to perform any manual steps that update ORACLE_HOME.
RAC databases often share a single ORACLE_HOME for all RAC instances. If you have this configuration, continue to the next step.
If you do not have this configuration, you must update the files in the other ORACLE_HOMEs for your RAC database. To update the other ORACLE_HOMEs, repeat Steps 4 through 8 in Section 2.2.4.1, "Run RUP Lite for RDBMS" for RAC instances with non-shared ORACLE_HOMEs. Then repeat Steps 3 through 16 in this section for all RAC instances. Note that this may involve multiple hosts and nodes.
Start the database.
Start the listener from all Oracle homes in the cluster. For Windows, start the services described Section 2.2.4.3, "Stop Services on Windows Before Running RUP Lite For RDBMS".
After the database is started, run the following commands:
(Unix) cd $ORACLE_HOME/rdbms/admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @catbundle.sql psu apply SQL> QUIT (Windows) cd %ORACLE_HOME%\rdbms\admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @catbundle.sql winbundle apply SQL> QUIT
For a list of catbundle.sql
errors that can be ignored, see Section 6.28, "Ignorable Errors Reported by catbundle.sql".
(Unix) cd $ORACLE_HOME/rdbms/admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @catmetx.sql SQL> QUIT (Windows) cd %ORACLE_HOME%\rdbms\admin sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> @catmetx.sql SQL> QUIT
For a Windows platform, the following services should be started and stopped by RUP Lite for RDBMS:
OracleOraDb11g_home1TNSListenerLISTENER_<SID>
OracleOraDb11g_home1ClrAgent
OracleDBConsole<SID>
OracleJobScheduler<SID>
OracleService<SID>
OracleMTSRecoveryService
Windows Management Instrumentation
Distributed Transaction Coordinator
Oracle <SID> VSS Writer Service
If RUP Lite for RDBMS fails to stop or start a service, you can manually manage each service from the Control Panel. Select Administrative Tools, then Services. Right click on each service and choose the Stop or Start option.
If you are on Linux64, Solaris Sparc64, or Solaris86-64 platforms and use the Oracle Exadata Database Machine, download and apply the quarterly database patch for your platform, the generic patches in the following list, and the list of specific patches for your platform from My Oracle Support.
Apply the quarterly database patch (Patch 14474780 - QUARTERLY DATABASE PATCH FOR EXADATA (OCT 2012 - 11.2.0.3.11) for your platform:
Linux: p14474780_112030_Linux-x86-64.zip
Solaris Sparc64: p14474780_112030_SOLARIS64.zip
Solaris86-64: p14474780_112030_Solaris86-64.zip
Apply all of the following generic patches, which are not platform-specific:
p12317925_112030_Generic.zip
p13508115_112030_Generic.zip
p14698700_112030_Generic.zip
Apply the following Exadata patches if you are on the Linux64 platform:
p12552578_1120311ExadataDatabase_Linux-x86-64.zip
p12646746_112030_Linux-x86-64.zip
p12977501_112030_Linux-x86-64.zip
p12985184_112030_Linux-x86-64.zip
p13014128_112030_Linux-x86-64.zip
p13078786_112030_Linux-x86-64.zip
p13365700_112030_Linux-x86-64.zip
p13404129_112030_Linux-x86-64.zip
p13615767_1120311ExadataDatabase_Linux-x86-64.zip
p13632653_112030_Linux-x86-64.zip
p13714926_1120311ExadataDatabase_Linux-x86-64.zip
p13902963_1120311ExadataDatabase_Linux-x86-64.zip
p14029429_112030_Linux-x86-64.zip
p14058884_112030_Linux-x86-64.zip
p14164849_112030_Linux-x86-64.zip
p14226599_112030_Linux-x86-64.zip
p14499293_1120311ExadataDatabase_Linux-x86-64.zip
p14653598_1120311ExadataDatabase_Linux-x86-64.zip
p14679292_112030_Linux-x86-64.zip
p14741727_1120311ExadataDatabase_Linux-x86-64.zip
p14757709_1120311ExadataDatabase_Linux-x86-64.zip
p14793338_1120311ExadataDatabase_Linux-x86-64.zip
p14837414_1120311ExadataDatabase_Linux-x86-64.zip
p15843238_1120311ExadataDatabase_Linux-x86-64.zip
Apply the following Exadata patches if you are on the Solaris Sparc64 platform:
p12552578_1120311ExadataDatabase_SOLARIS64.zip
p12646746_112030_SOLARIS64.zip
p12977501_112030_SOLARIS64.zip
p12985184_112030_SOLARIS64.zip
p13014128_112030_SOLARIS64.zip
p13078786_112030_SOLARIS64.zip
p13365700_112030_SOLARIS64.zip
p13404129_112030_SOLARIS64.zip
p13615767_1120311ExadataDatabase_SOLARIS64.zip
p13632653_112030_SOLARIS64.zip
p13714926_1120311ExadataDatabase_SOLARIS64.zip
p13902963_1120311ExadataDatabase_SOLARIS64.zip
p14029429_112030_SOLARIS64.zip
p14058884_112030_SOLARIS64.zip
p14164849_112030_SOLARIS64.zip
p14226599_112030_SOLARIS64.zip
p14499293_1120311ExadataDatabase_SOLARIS64.zip
p14653598_1120311ExadataDatabase_SOLARIS64.zip
p14679292_112030_SOLARIS64.zip
p14741727_1120311ExadataDatabase_SOLARIS64.zip
p14757709_1120311ExadataDatabase_SOLARIS64.zip
p14793338_1120311ExadataDatabase_SOLARIS64.zip
p14837414_1120311ExadataDatabase_SOLARIS64.zip
p15843238_1120311ExadataDatabase_SOLARIS64.zip
Apply the following Exadata patches if you are on Solaris X64 platform:
p12552578_1120311ExadataDatabase_Solaris86-64.zip
p12646746_112030_Solaris86-64.zip
p12977501_112030_Solaris86-64.zip
p12985184_112030_Solaris86-64.zip
p13014128_112030_Solaris86-64.zip
p13078786_112030_Solaris86-64.zip
p13365700_112030_Solaris86-64.zip
p13404129_112030_Solaris86-64.zip
p13615767_1120311ExadataDatabase_Solaris86-64.zip
p13632653_112030_Solaris86-64.zip
p13714926_1120311ExadataDatabase_Solaris86-64.zip
p13902963_1120311ExadataDatabase_Solaris86-64.zip
p14029429_112030_Solaris86-64.zip
p14058884_112030_Solaris86-64.zip
p14164849_112030_Solaris86-64.zip
p14226599_112030_Solaris86-64.zip
p14499293_1120311ExadataDatabase_Solaris86-64.zip
p14653598_1120311ExadataDatabase_Solaris86-64.zip
p14679292_112030_Solaris86-64.zip
p14741727_1120311ExadataDatabase_Solaris86-64.zip
p14757709_1120311ExadataDatabase_Solaris86-64.zip
p14793338_1120311ExadataDatabase_Solaris86-64.zip
p14837414_1120311ExadataDatabase_Solaris86-64.zip
p15843238_1120311ExadataDatabase_Solaris86-64.zip
If you do not update the database by running RUP Lite for RDBMS, run the following script as SYS user on all database instances to prevent issues during the Bootstrapping Patch Manager configuration task:
ORACLE_HOME/rdbms/admin/catmetx.sql
Run the Health Checker utility directly from REPOSITORY_LOCATION
and from the primordial host. Ensure that you set the environments variables described in Section 2.1.12, "Set Environment Variables".
For more information about Health Checker, see Section 1.5.2, "Pre-Upgrade Tasks Performed by Health Checker During Down Time".
Run Health Checker using the following command syntax:
$REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/bin/hcplug.sh -manifest $REPOSITORY_LOCATION/installers/farup/Disk1/upgrade/config/PreUpgradeDowntimeChecks.xml [-DlogLevel=log_level] (Windows) %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\bin\hcplug.cmd -manifest %REPOSITORY_LOCATION%\installers\farup\Disk1\upgrade\config\PreUpgradeDowntimeChecks.xml [-DlogLevel=log_level]
Review the Health Checker log file or the HTML summary report to see if any errors occurred that require corrective action. The log file and the HTML summary are located in APPLICATIONS_CONFIG/
fapatch/logs/
release_version/
healthchecker
.
After you resolve the issue that caused the error, start Health Checker again to run the failed tasks. You must rerun Health Checker until there are no failed tasks.
For more information, see Section 6.26, "Troubleshooting Health Checker Down Time Checks".
The following backups must be performed:
Back up your entire Oracle Fusion Applications environment by following the steps in "Backing Up and Recovering Oracle Fusion Applications" in the Oracle Fusion Applications Administrator's Guide. You should also back up your central inventory.
For additional back up steps that are specific to Windows, refer to Section 2.2.7.3, "Back Up Steps for Windows Platforms".
RUP Installer upgrades all WLS domains to the 11gR1 PS5 MLR1 (11.1.1.6.1) level so you must perform the following backups. Perform your backups in directories from which you can restore. 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.
(Unix) setenv ORACLE_HOME OID_ORACLE_HOME setenv ORACLE_INSTANCE OID_INSTANCE_HOME (Windows) set ORACLE_HOME=OID_ORACLE_HOME set ORACLE_INSTANCE=OID_INSTANCE_HOME
Example:
(Unix) setenv ORACLE_HOME /u01/oid/oid_home setenv ORACLE_INSTANCE /u01/oid/oid_inst (Windows) set ORACLE_HOME=\u01\oid\oid_home set ORACLE_INSTANCE \u01\oid\oid_inst
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 command. Note that you are prompted for the Operational Data Store (ODS) password.
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 cn=FAPolicies
node to the srcOid.ldif
file. Once generated, move this file to the directory that was identified earlier, to hold all backup data.
Perform the following steps if you need 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 command:
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 command:
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 to the BI Domain upon failure.
Back up the Oracle Fusion Applications environment, including APPLICATIONS_BASE
, inventory, registry entries, Oracle Identity Management, the database and the System environment PATH variable of the Oracle Fusion Applications host machine.
APPLICATIONS_BASE
contains 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 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\\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 OPMN services and BI Presentation Catalog deployment configuration assistants in RUP Installer.
Save the system PATH variable.
Append the following parameters to JRE_MEMORY_OPTIONS
in REPOSITORY_LOCATION\
installers\fusionapps\Disk1\install\win64\oraparam.ini
:
"-Xmx512m -XX:+UnlockDiagnosticVMOptions -XX:InitialClassBlockMemory=100M"
Backup the existing ATG_HOME/
atgpf/lib/oracle.apps.fnd.applxdf.jar
file.
Follow the steps in the README.txt
file of patch 14543240 to run the script to remove conflicting patches from the primordial host. You must run this script on the primordial host. You ran the script to find conflicting patches in Section 2.1.15, "Find Conflicting Patches".
Note:
Ensure that you run this script only before upgrading. If you run this script at any time other than before upgrading, the system may be left in an unstable state.
When you run RUP Installer, the patches you downloaded in step 3, Section 2.1.15, "Find Conflicting Patches" will automatically apply.
Restore ATG_HOME/
atgpf/lib/oracle.apps.fnd.applxdf.jar
from the backup to its original location.
To prevent an error during the upgrade, you must temporarily enable anonymous binds in Oracle Internet Directory. To enable all anonymous binds on the Oracle Internet Directory instance with componentName
oid1
using ldapmodify
, run the following command:
ldapmodify -D cn=orcladmin -Q -p portNum -h hostname -f ldifFile
with an LDIF file such as the following example:
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclAnonymousBindsFlag orclAnonymousBindsFlag: 1
You can also use Oracle Enterprise Manager Fusion Middleware Control to enable anonymous binds. For more information, see "Managing Anonymous Binds" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. You will disable anonymous binds after the upgrade by setting the value of the orclAnonymousBindsFlag
to 0.
Remove the /u01/lcm
directory from all nodes, as its contents have been moved in Release 6.
Perform the steps in this section only if you are running Oracle Fusion Applications in an Oracle VM environment that was created from the official releases of Oracle VM templates for Oracle Fusion Applications Release 2 (11.1.2) and higher. The content is not applicable for any Oracle VM environments that are created using other methods. For more information, see Section 1.7, "RUP Lite for OVM Utility".
Note:
To ensure you are upgrading an OVM environment and before you run RUP Lite for OVM, confirm that the host related properties in APPLICATIONS_BASE/
ovabext/deployfw/deployprops/ovm-ha-deploy.properties
properly describe the physical machines in the environment. For IDM nodes, the location is /u01/ovmext/deployfw/deployprops/ovm-ha-deploy.properties
.
Perform the following steps to run RUP Lite for OVM in offline mode on each node of your Oracle VM environment:
Perform the following steps to install the Oracle Fusion Applications 11.1.6 Lifecycle Management Tools for Oracle VM Installer repository on the primordial host. This repository includes RUP Lite for OVM.
Copy fasaaslcmtools.zip
from OVAB_HOME to the OVM nodes. OVAB_HOME is the top-level directory for the Oracle Virtual Assembly Builder that contains all of the software needed to deploy Oracle Fusion Applications as an Oracle VM instance.
Unzip fasaaslcmtools.zip
.
RUP Lite for OVM is installed under /u01/lcm/rupliteovm
. Run the installer as the Oracle user in silent mode, using the ORACLE_HOME=/u01/lcm
option to specify the install location and using the -invPrtLoc
option to override the inventory location, as shown in the following examples:
Admin host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/APPLTOP/fusionapps/jdk6 -silent -invPtrLoc /u01/APPLTOP/fusionapps/applications/oraInst.loc ORACLE_HOME=/u01/lcm
APPOHS host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/APPLTOP/webtier_mwhome/webtier/jdk6 -silent -invPtrLoc /u01/APPLTOP/webtier_mwhome/webtier/oraInst.loc ORACLE_HOME=/u01/lcm
OID host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/oid/jrockit-jdk1.6.0_24 -silent -invPtrLoc /u01/oid/oid_home/oraInst.loc ORACLE_HOME=/u01/lcm
OIM host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/oim/jrockit-jdk1.6.0_24 -silent -invPtrLoc /u01/oim/oim_home/oraInst.loc ORACLE_HOME=/u01/lcm
AuthOHS host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/ohsauth/ohsauth_home/jdk6 -silent -invPtrLoc /u01/ohsauth/ohsauth_home/oraInst.loc ORACLE_HOME=/u01/lcm
WebChat host
fasaaslcmtools/Disk1/runInstaller -jreLoc /u01/APPLTOP/beehive_mwhome/jdk6 -silent -invPtrLoc /u01/APPLTOP/beehive_mwhome/oraInst.loc ORACLE_HOME=/u01/lcm
Update the env.properties
file under the rupliteovm/metadata
directory with the required property values for all plug-ins used by RUP Lite for OVM. For information about the plug-ins, see Section 1.7, "RUP Lite for OVM Utility". If a plug-in does appear on this list, it does not have any properties.
SetupCredentials (runs in offline and online mode)
The first property enables the validation of passwords by prompting twice for the required credentials. If you need to change the password in the wallet, set the second property to true. This allows you to overwrite the existing password for a specific plug-in the wallet.
ovm.plugin.SetupCredentials.enable_password_validation=true ovm.plugin.SetupCredentials.enable_password_update=false
ApplyMemorySettings (runs in offline mode)
ovm.plugin.ApplyMemorySettings.enabled=true
SetServerPassphrase (runs in offline mode)
ovm.plugin.SetServerPassphrase.enabled=true
GenerateOptimizedQueryPlans (runs in offline mode)
ovm.plugin.GenerateOptimizedQueryPlans.enabled=true
UpdateHTTPProxySettings (runs in offline mode)
ovm.plugin.UpdateHTTPProxySettings.enabled=true
UpdateWLSUmask (runs in offline mode)
ovm.plugin.UpdateWLSUmask.enabled=true
ConfigureODIAgent (runs in offline mode)
ovm.plugin.ConfigureODIAgent.enabled=true
UpdateSESDBConnection (runs in online mode)
ovm.plugin.UpdateSESDBConnection.enabled=true
DeployECSF (runs in online mode)
ovm.plugin.DeployECSF.enabled=true ovm.plugin.DeployECSF.connection_timeout_seconds=300
DisableWebchatConnections (runs in online mode)
ovm.plugin.DisableWebchatConnections.enabled=true
UpdateResolvConf (runs in post-root mode)
If you have additional DNS servers, search domains, or want to set options such as timeout and attempt, set the following properties and run this plug-in.
If no additional DNS servers, search domains or options are needed, disable this plug-in so it does not run.
ovm.plugin.UpdateResolvConf.enabled=true
# Optional additional dns name server IP addresses (comma delimited)
#example: ovm.plugin.UpdateResolvConf.dns_servers=ip_adress,ip_address
ovm.plugin.UpdateResolvConf.dns_servers=
# Optional additional resolv.conf options (comma delimited)
#example: ovm.plugin.UpdateResolvConf.options=timeout:1,attempts:2
ovm.plugin.UpdateResolvConf.options=
# Optional additional resolv.conf search domains (comma delimited)
#example: ovm.plugin.UpdateResolvConf.search=example.com,x.example.com
ovm.plugin.UpdateResolvConf.search=
The dns_servers property
is a comma separated list of IP addresses of the dns servers to add to the /etc/resolv.conf
file.
EnableEMRemoteMonitoring (runs in post-root mode)
ovm.plugin.EnableEMRemoteMonitoring.enabled=true
Confirm that the OVM_STORAGE_MOUNT
and APPLTOP
properties in the env.properties
file are set correctly, for example, OVM_STORAGE_MOUNT=/u01
and APPLTOP=/u01/APPLTOP
.
Run RUP Lite for OVM as the applications user.
Set the JAVA_HOME
directory, for example:
setenv JAVA_HOME /assemblybuild/jre
Examples of jre
locations for other nodes follow:
AuthOHS Node: /u01/ohsauth/oracle_common/jdk
OIM Node: /u01/oim/jrockit_160_24_D1.1.2-4
OID Node: /u01/oid/oracle_common/jdk
Run ruplite.sh
in offline mode from the rupliteovm
directory.
cd /u01/lcm/rupliteovm bin/ruplite.sh offline
Respond to the following prompts, which will be stored in a wallet file in the rupliteovm/output/wallet
directory.
RUP Lite Wallet Key: If a wallet already exists, enter the value for the existing key. If the wallet does not exist, a new one will be created using the key you provide. The key must be at least 8 characters long and include at least one numeric character. ID Store RW User Password: FA Admin Password:
If no plug-ins run that require secure properties, the wallet creation and access is skipped and you are not prompted for the wallet key.
For information about RUP Lite for OVM troubleshooting, see Section 2.2.12.5, "Troubleshoot RUP Lite for OVM".
The Oracle Fusion Applications 11.1.6 Lifecycle Management Tools for Oracle VM Installer repository, including RUP Lite for OVM, only needs to be installed once for each set of nodes that share the /u01
storage mount. The repository installation on the primordial host is accessible to all Oracle Fusion Applications nodes, including primary, secondary, and BI nodes, as well as any corresponding scaleout nodes. The repository must be installed separately in /u01/lcm
for the OHS node, the IDM nodes, and the Webchat node, if they are enabled.
The shared installation location can be used to run RUP Lite for OVM from multiple machines. Logs and checkpoint files for each machine are created in machine specific subdirectories under RUP Lite's output directory, /u01/lcm/rupliteovm/output
.
RUP Lite for OVM must be run on all nodes of the OVM environment.
Review the rupliteovm/output/logs/ruplite.log
file to confirm there are no errors. You can also check rehydration framework logs under /assemblybuilder/logs
or /var/log
for any errors. Review the following troubleshooting information for specific plug-ins:
ValidateEnvironment: If this plug-in fails, RUP Lite for OVM stops. You must resolve any errors reported in the log file and then run RUP Lite for OVM again.
SetupCredentials: If this plug-in fails, RUP Lite for OVM stops. Typical causes of failure are an incorrect key for an existing wallet, or specifying a key for a new wallet that does not meet Oracle's minimum standards. You must resolve any errors reported in the log file and then run RUP Lite for OVM again.
Note that you are prompted for the password twice and that both responses must be identical. If you need to change the password in the wallet, set the ovm.plugin.SetupCredentials.enable_password_update property
to true. If this property is enabled, when the SetupCredentials
plug-in reruns, you are given the option to overwrite the existing password for a particular plug-in, in the wallet. By default this feature is disabled.
ApplyMemorySettings: Check the fusionapps_start_params.properties
files in the environment, which are located under the bin
directory of each domain. Ensure that the minmaxmemory
settings in the files are at least as high as the settings in the template under the ovm/metadata
directory that corresponds to the environment's topology.
SetServerPassphrase: This plug-in is rerunnable. Verify this plug-in was successful by confirming that, under the admin-apps
directory of the FA node, the config.xml
files of each domain under each node contain the following properties:
<server-private-key-pass-phrase-encrypted>encryption_string=</server-private-key-pass-phrase-encrypted> <custom-identity-key-store-pass-phrase-encrypted>encryption_string=</custom-identity-key-store-pass-phrase-encrypted> <custom-trust-key-store-pass-phrase-encrypted>encryption_string=</custom-trust-key-store-pass-phrase-encrypted>
GenerateOptimizedQueryPlans: This plug-in is rerunnable. Verify this plug-in was successful by connecting to the database as fusion_mds
and running the following command:
SELECT TO_CHAR(last_analyzed, 'yyyy/mm/dd hh:mi:ss am') as last_analyzed FROM user_tables;
The results should show that the tables were just analyzed.
UpdateHTTPProxySettings: This plug-in is rerunnable. Verify that the fusion.default.default.sysprops
property in fusionapps_start_params.properties
of each domain contains localhost and 127.0.0.1 as part of non-proxy hosts.
UpdateWLSUmask: This plug-in is rerunnable. Under each domain directory, verify that bin/startWebLogic.sh
contains umask 027
instead of umask 037
. Also confirm that init-info/startscript.xml
and init-info/startscript-unsub.xml
do not contain any umask 037
strings.
ConfigureODIAgent: This plug-in is rerunnable. Verify this plug-in was successful by performing the following steps:
Open the following URL: http://
big_IP_internal_end_point_for domain:
port/
odiconsole
Login as FAAdmin.
Click Browse.
Expand Topology, then Agents, and then Physical agents.
Select an agent for a domain that has ODI installed, for example, FusionCrmOdiAgent
.
Right click the agent and select View. Confirm that the host name is the LBR host.
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 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 assistants will fail. You must also start the IDM Domain Administration Server.
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 added any servers, you must start the new servers at least once. This step is not required for a server that has already been started once since Provisioning.
To proceed with the upgrade, see Chapter 3, "Upgrading to Oracle Fusion Applications 11g Release 6 (11.1.6)".