B About the Reduced Downtime Upgrade Process

Review the flowchart and roadmap for an overview of the upgrade process for Oracle Fusion Middleware if you are performing a reduced downtime upgrade.

A reduced downtime upgrade process is different from a standard Fusion Middleware upgrade process. This type of upgrade requires at least a two-node cluster environment and is performed in a rolling fashion so that one node is always up to accomplish the reduced downtime upgrade. In the standard upgrade flow, all servers and processes are stopped prior to initiating the upgrade.

Before you begin the reduced downtime upgrade:

• Back up the database schemas.
• Back up the domain directory and the application directory.
• Back up the UI /similar customizations.

For details about backing up, see Creating a Complete Backup.

After taking the required back ups, uninstall the previous version of the software to ensure that an empty Oracle Home is available to install the new product distributions. This is the key difference between the two upgrade processes. In addition, if your product requires a schema and/or a config upgrade, you will need to run the Upgrade Assistant twice, once each for schema upgrade and for config upgrade.

Note:

Oracle Fusion Middleware 12c (12.2.1.3) is the only supported starting point for a reduced downtime upgrade. You cannot perform a reduced downtime upgrade if you are upgrading from a supported Fusion Middleware 11g or 12c (12.2.1.2.0 or earlier) release, or if you do not have a multi-node environment. To perform a reduced downtime upgrade from 12c (12.1.3 or 12.2.1.2), you must first upgrade to 12.2.1.3 using the standard upgrade process. See Upgrading Oracle WebCenter from a Previous 12c Release.

Figure B-1 Process Flowchart for a Reduced Downtime Upgrade

Description of "Figure B-1 Process Flowchart for a Reduced Downtime Upgrade "

Table B-1 lists the high-level steps that you need to perform for a reduced downtime upgrade of the Oracle Fusion Middleware 12c (12.2.1.3.0) release. You must repeat these steps for each additional host.

Table B-1 Tasks for Performing a Reduced Downtime Upgrade of Oracle Fusion Middleware 12c (12.2.1.3.0) Release

Task	Description
Required Before you begin a reduced downtime upgrade, you must complete the required pre-upgrade tasks.	The pre-upgrade tasks include reviewing the pre-upgrade checklists; backing up the Oracle home, domain directory, and component schemas; and using the appropriate JDK version. For a complete list of the pre-upgrade tasks, see Required Tasks that Must be Completed Before You Begin.
Required Create a complete backup of your existing environment, on all hosts.	See Creating a Complete Backup.
Required Stop the servers and processes on Host 1.	Before starting the upgrade process, stop all the servers, components, and processes on Host 1. See Stopping Components, Servers and Processes on Host 1.
Required Uninstall the Fusion Middleware 12c (12.2.1.3.0) product distributions on Host 1.	Uninstall the Fusion Middleware 12c (12.2.1.3.0) product distributions from the exisiting ORACLE_HOME so you can install the Fusion Middleware Infrastructure 12c (12.2.1.4.0) into the same directory. See Uninstalling the Software.
Required Install 12c (12.2.1.4.0) product distributions into the existing Oracle Home on Host 1.	Install Oracle Fusion Middleware Insfrastructure 12c (12.2.1.4.0) by using the Oracle Universal Installer. You must install 12c (12.2.1.4.0) product distributions into the same ORACLE_HOME. See Installing the 12c (12.2.1.4.0) Product Distributions for Oracle WebCenter.
Optional Run the Readiness Check.	Running the Readiness Check by using the Upgrade Assistant helps you determine whether your pre-upgrade environment is ready for upgrade. See Running a Pre-Upgrade Readiness Check.
Required If applicable to your product, perform the schema and config upgrade separately on Host 1, by using the Upgrade Assistant.	See the following topics: Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant Upgrading WebCenter Sites Domain Components Using the Upgrade Assistant Upgrading WebCenter Portal Domain Components For the list of schemas and component configuration that you can upgrade to 12c (12.2.1.4.0), see the following sections of Oracle Fusion Middleware Upgrading with the Upgrade Assistant Identifying Schemas that Can Be Upgraded to 12c (12.2.1.4.0) Identifying Configurations That Can Be Upgraded with the Upgrade Assistant
Required If your product included a configuration upgrade, pack the domain on Host 1.	See Packing the Domain and Updating the Domain Properties.
Required Restart the servers and processes on Host 1.	The upgrade process is complete. You can now restart the servers, components, and processes. See Restarting Node Manager, Administration Server, Managed Servers and Components on Host 1.
Required Validate the upgrade on Host 1.	After you complete the upgrade, perform the upgrade validation tasks. See Validating the Upgrade.
Required Stop the servers and processes on Host 2.	Before starting the upgrade, you must stop the system components, managed servers and node manager on Host 2. See Stopping the Components, Servers and Processes on Host 2.
Required Uninstall Fusion Middleware Insfrastructure 12 c (12.2.1.3.0) on Host 2.	Uninstall Fusion Middleware Infrastructure 12c (12.2.1.3.0) from the exisiting ORACLE_HOME so you can install the Fusion Middleware Infrastructure 12c (12.2.1.4.0) into the same directory. See Uninstalling the Software.
Required Install Fusion Middleware Insfrastructure 12c (12.2.1.4.0) and any other product distributions that you run in your domain on Host 2.	See Installing the Software into the Existing Middleware Home.
Required If you have packed the domain on Host 1, unpack the domain on Host 2.	See Unpacking the Domain on Each Additional Host.
Required Restart the servers and processes on Host 2.	After the upgrade is complete, restart the servers and processes. See Restarting the Managed Servers and Processes.
Required Validate the upgrade on Host 2.	After restarting the servers and processes, perform the upgrade validation tasks. See Validating the Upgrade.

• Performing a Reduced Downtime Upgrade
  If you are upgrading from Fusion Middleware 12c (12.2.1.3) release, you can use this process to upgrade your multi-node domain without shutting down all of the servers at the same time.

Performing a Reduced Downtime Upgrade

If you are upgrading from Fusion Middleware 12c (12.2.1.3) release, you can use this process to upgrade your multi-node domain without shutting down all of the servers at the same time.

The procedures described in this section are based on the Oracle Fusion Middleware Standard Installation Topology (SIT) and require that you have a multi-node environment. The standard installation topology for Oracle Fusion Middleware Infrastructure has a standard WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers. Host 1 is used to describe the procedures performed on the host with the Administration server and Host 2 is used to describe the procedures performed on the other managed server host(s). If you have more than two hosts in your environment, be sure to complete the procedures on each additional node.

Required Tasks that Must be Completed Before You Begin

Review the following before you begin a reduced downtime upgrade:

• Review the preupgrade checklists for the components in your deployment. The checklists are found in each of the component-specfic upgrade guides. Some products may require additional steps before performing the upgrade.
• Create a complete backup of the Oracle home (on all of the nodes), the entire domain directory (on all of the nodes) and component schemas before performing the upgrade. In addition, Oracle recommends that you create a backup of UI customizations and the applications directory, in addition to domain directory. See Creating a Complete Backup.
• Make sure that you are using the appropriate JDK version for this release. For this release the correct version is jdk1.8.0_211
• If you are upgrading a shared component directory, back up the contents of the shared directory before the upgrade. The configuration upgrade makes changes to these directories.
• Make sure that your backups include any modified scripts, such as setStartupEnv.sh, for example. The upgrade will overwrite any customized files and you will lose your changes.

• Performing the Upgrade on Host 1
  
• Performing the Upgrade on Host 2
  
• Validating the Upgrade
  After you have completet the upgrade on all hosts, complete the standard upgrade verification tasks to ensure that all components will continue to work as expected.

Performing the Upgrade on Host 1

Perform the following tasks on the machine that hosts the Administration server and serves as the primary machine for your deployment.

• Stopping Components, Servers and Processes on Host 1
  You must shut down all of the system components, processes, servers (including the Administration Server and any managed servers), and the node manager (if running).
• Uninstalling the Software
  When performing a rolling upgrade, an empty directory is required for installing the new binaries prior to upgrading.
• Installing the 12c (12.2.1.4.0) Product Distributions for Oracle WebCenter
  Before starting your upgrade, uninstall the software from the existing Oracle home, then use the Oracle Universal Installer to install the 12c (12.2.1.4.0) product distributions into the same Oracle home on the target system. You must install the product distributions on each host during the upgrade.
• Running a Pre-Upgrade Readiness Check
  To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.
• Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant
  Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.
• Upgrading WebCenter Portal Domain Components
  
• Upgrading WebCenter Sites Domain Components Using the Upgrade Assistant
  Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.
• Packing the Domain and Updating the Domain Properties
  If you are upgrading WebCenter Sites or WebCenter Portal as part of your reduced downtime upgrade, then you will need to pack the domain from Host 1 and unpack it during the upgrade on Host 2. You will also need to update the configuration properties before you start the servers.
• Restarting Node Manager, Administration Server, Managed Servers and Components on Host 1
  After the upgrade, you must restart the components, servers, and processes in the correct order.

Stopping Components, Servers and Processes on Host 1

You must shut down all of the system components, processes, servers (including the Administration Server and any managed servers), and the node manager (if running).

Note:

The procedures in this section describe how to stop components, servers, and processes using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console.

An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the following order:

• System Components (if any)
• Managed Server(s)
• Administration Server
• Node Manager

Stopping System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

Execute the following script for each component:

 
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Stopping the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
   (Windows)DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
2. When prompted, enter your user name and password.

Stopping the Administration Server

When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To stop the Administration Server:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
   (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
2. When prompted, enter your user name, password, and the URL of the Administration Server.

Stopping the Node Manager

To stop Node Manager, close the command shell/prompt in which it is running.

Alternatively, after having set the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down.

Uninstalling the Software

When performing a rolling upgrade, an empty directory is required for installing the new binaries prior to upgrading.

Note:

You must deinstall the upperstack components first, then deinstall JRF. After deinstalling the JRF, back up any remaining files and then delete all files in the directory. The installation directory must be empty.

Follow the instructions in this section to remove the software from the existing ORACLE_HOME. You will reinstall the new software into this same directory.

To start the Oracle Universal Installer in deinstallation mode, execute the following command:

UNIX: ORACLE_HOME/oui/bin/deinstall.sh

Windows: ORACLE_HOME\oui\bin\deinstall.cmd

If you want to uninstall the product in a silent (command-line) mode, see Running the Oracle Universal Installer for Silent Uninstallation in Oracle Fusion Middleware Installing Software with the Oracle Universal Installer.

Installing the 12c (12.2.1.4.0) Product Distributions for Oracle WebCenter

Before starting your upgrade, uninstall the software from the existing Oracle home, then use the Oracle Universal Installer to install the 12c (12.2.1.4.0) product distributions into the same Oracle home on the target system. You must install the product distributions on each host during the upgrade.

Note:

When Infrastructure is required for the upgrade, you must install the Oracle Fusion Middleware distribution first before you install other Fusion Middleware products.

Before you begin, note the following:

• Ensure that you install only those product binaries that you have uninstalled. For example, if your 12c (12.2.1.3) Oracle home has WebCenter Content (WCC) and WebCenter Portal (WCP), uninstall them and install the product binaries for both 12c (12.2.1.4) WCC and WCP. Likewise, if the 12c (12.2.1.3) Oracle home has only WCC, uninstall and install only 12c (12.2.1.4) WCC.

• Use the same install path (Oracle home) for the installation of the new distributions that you used for the previous distributions that you uninstalled.

To install the 12c (12.2.1.4.0) distributions:

1. Sign in to the target system.
2. Download the applicable product distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:
   • Oracle Fusion Middleware Infrastructure (fmw_12.2.1.4.0_infrastructure.jar)
   • Oracle WebCenter Content (fmw_12.2.1.4.0_wccontent.jar)
   • Oracle WebCenter Portal (fmw_12.2.1.4.0_wcportal.jar)
   • Oracle WebCenter Sites (fmw_12.2.1.4.0_wcsites.jar)
3. Change to the directory where you downloaded the 12c (12.2.1.4.0) product distribution.
4. Start the installation program for Oracle Fusion Middleware Infrastructure:
   • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.4.0_infrastructure.jar
   • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.4.0_infrastructure.jar

After your Infrastructure installation is complete, you will install the remaining distributions the same way using the correct distribution names. For example, to start the installation program for Oracle WebCenter Content, use fmw_12.2.1.4.0_wccontent_generic.jar as the distribution name

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
   Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location, and click Next.

   Note:

   The Installation Inventory Setup screen does not appear on Windows operating systems.
6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.
7. On the Auto Updates screen, select an option:

   • Skip Auto Updates: If you do not want your system to check for software updates at this time.

   • Select patches from directory: To navigate to a local directory if you downloaded patch files.

   • Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

   Click Next.
8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
   For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.
9. On the Installation Type screen, select the products to install.
   Click Next.
10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
    To view the list of tasks that are verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).
11. On the Installation Summary screen, verify the installation options that you selected.
    If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.

    Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.
13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.
14. After you have installed Oracle Fusion Middleware Infrastructure, repeat the steps above to install the other product distributions.

Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

• About Running a Pre-Upgrade Readiness Check
  You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.
• Starting the Upgrade Assistant in Readiness Mode
  Use the -readiness parameter to start the Upgrade Assistant in readiness mode.
• Performing a Readiness Check with the Upgrade Assistant
  Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.
• Understanding the Readiness Report
  After performing a readiness check for your domain, review the report to determine whether you need to take any action for a successful upgrade.

About Running a Pre-Upgrade Readiness Check

You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.

The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.

You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.

You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.

Note:

To prevent performance from being affected, Oracle recommends that you run the readiness check during off-peak hours.

Starting the Upgrade Assistant in Readiness Mode

Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

To perform a readiness check on your pre-upgrade environment with the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:
   • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
   • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
2. Start the Upgrade Assistant.
   • (UNIX) ./ua -readiness
   • (Windows) ua.bat -readiness

   Note:

   If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter the following error:

   Xlib: connection to ":1.0" refused by server
   Xlib: No protocol specified 

   To resolve this issue, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

   If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

   For information about other parameters that you can specify on the command line, see:

• Upgrade Assistant Parameters
  

Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table B-2 Upgrade Assistant Command-Line Parameters

Parameter	Required or Optional	Description
-readiness	Required for readiness checks Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).	Performs the upgrade readiness check without performing an actual upgrade. Schemas and configurations are checked. Do not use this parameter if you have specified the -examine parameter.
-threads	Optional	Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas. The value must be a positive integer in the range 1 to 8. The default is 4.
-response	Required for silent upgrades or silent readiness checks	Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).
-examine	Optional	Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the -readiness parameter.
-logLevel attribute	Optional	Sets the logging level, specifying one of the following attributes: TRACE NOTIFICATION WARNING ERROR INCIDENT_ERROR The default logging level is NOTIFICATION. Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.
-logDir location	Optional	Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files. The default locations are: (UNIX) ORACLE_HOME/oracle_common/upgrade/logs ORACLE_HOME/oracle_common/upgrade/temp (Windows) ORACLE_HOME\oracle_common\upgrade\logs ORACLE_HOME\oracle_common\upgrade\temp
-help	Optional	Displays all of the command-line options.

Performing a Readiness Check with the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

Readiness checks are performed only on schemas or component configurations that are at a supported upgrade starting point.

To complete the readiness check:

1. On the Welcome screen, review information about the readiness check. Click Next.
2. On the Readiness Check Type screen, select the readiness check that you want to perform:
   • Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.

     When you select this option, the screen name changes to Selected Schemas.

   • Domain Based allows the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.

     When you select this option, the screen name changes to Schemas and Configuration.

     Leave the default selection if you want the Upgrade Assistant to check all schemas and component configurations at the same time, or select a specific option:

     • Include checks for all schemas to discover and review all components that have a schema available to upgrade.

     • Include checks for all configurations to review component configurations for a managed WebLogic Server domain.

   Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.
   If you selected Domain Based: On the Component List screen, review the list of components that are present in your domain for which you want to perform a readiness check.
   If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

   Depending on the components you select, additional screens may display. For example, you may need to:

   • Specify the domain directory.

   • Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. Then click Connect.

     Note:

     Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the readiness check with the correct database type selected to ensure that the correct database type is applied to all schemas.

   • Select the Schema User Name option and specify the Schema Password.

     Note:

     The Upgrade Assistant automatically enables default credentials. If you are unable to connect, make sure that you manually enter the credentials for your schema before you continue.
   Click Next to start the readiness check.
4. On the Readiness Summary screen, review the summary of the readiness checks that will be performed based on your selections.
   If you want to save your selections to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.
   For a detailed report, click View Log.
   Click Next.
5. On the Readiness Check screen, review the status of the readiness check. The process can take several minutes.
   If you are checking multiple components, the progress of each component displays in its own progress bar in parallel.
   When the readiness check is complete, click Continue.
6. On the End of Readiness screen, review the results of the readiness check (Readiness Success or Readiness Failure):

   • If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the actual upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.

   • If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check. The log file is managed by the command-line options you set.

Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine whether you need to take any action for a successful upgrade.

The format of the readiness report file is:

readiness<timestamp>.txt

Where, timestamp indicates the date and time of when the readiness check was run.

A readiness report contains the following information:

Table B-3 Readiness Report Elements

Report Information	Description	Required Action
Overall Readiness Status: SUCCESS or FAILURE	The top of the report indicates whether the readiness check passed or completed with one or more errors.	If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade.
Timestamp	The date and time that the report was generated.	No action required.
Log file location /oracle_common/upgrade/logs	The directory location of the generated log file.	No action required.
Domain Directory	Displays the domain location	No action required.
Readiness report location /oracle_common/upgrade/logs	The directory location of the generated readiness report.	No action required.
Names of components that were checked	The names and versions of the components included in the check and status.	If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, do not attempt an upgrade.
Names of schemas that were checked	The names and current versions of the schemas included in the check and status.	Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, do not attempt an upgrade.
Individual Object Test Status: FAIL	The readiness check test detected an issue with a specific object.	Do not upgrade until all failed issues have been resolved.
Individual Object Test Status: PASS	The readiness check test detected no issues for the specific object.	If your readiness check report shows only the PASS status, you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade.
Completed Readiness Check of <Object> Status: FAILURE	The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index, or datatype.	Do not upgrade until all failed issues have been resolved.
Completed Readiness Check of <Object> Status: SUCCESS	The readiness check test detected no issues.	No action required.

Here is a sample Readiness Report file. Your report may not include all of these checks.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain

Starting readiness check of components.

Oracle Platform Security Services
   Starting readiness check of Oracle Platform Security Services.
     Schema User Name: DEV3_OPSS
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Starting schema test:  Test that the schema does not contain any unexpected tables  TEST_UNEXPECTED_TABLES
   Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
   Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
   Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
   Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
   Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
   Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
   Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
   Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
   Starting schema test:  SEQUENCE_TEST  Test that the Oracle Platform Security Services schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
   Finished readiness check of Oracle Platform Security Services with status: SUCCESS.

Oracle Audit Services
   Starting readiness check of Oracle Audit Services.
     Schema User Name: DEV3_IAU
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
   Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
   Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
   Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
   Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
   Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
   Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
   Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
   Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
   Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
   Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
   Starting datatype test for table OIDCOMPONENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_CUSTOM_01:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_BASE:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table WS_POLICYATTACHMENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table OWSM_PM_EJB:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table XMLPSERVER:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table SOA_HCFP:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting schema test:  SEQUENCE_TEST  Test that the audit schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
   Starting schema test:  SYNONYMS_TEST  Test that the audit schema required synonyms are present
   Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
   Finished readiness check of Oracle Audit Services with status: FAILURE.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
     Schema User Name: DEV3_STB
     Database Type: Oracle Database
     Database Connect String: 
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Oracle JRF
   Starting readiness check of Oracle JRF.
   Finished readiness check of Oracle JRF with status: SUCCESS.

System Components Infrastructure
   Starting readiness check of System Components Infrastructure.
   Starting config test:  TEST_SOURCE_CONFIG  Checking the source configuration.
     INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
   Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
   Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
   Starting config test:  CIEConfigPlugin.readiness.test  This tests the readiness of the domain from CIE side.
   Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Finished readiness check of components.

Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

To upgrade product schemas with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

   Note:

   For more information about any Upgrade Assistant screen, click Help on the screen.
2. On the Selected Schemas screen, select the schema upgrade operation that you want to perform:
   • Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

     Caution:

     Upgrade only those schemas that are used to support your 12c (12.2.1.4.0) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.4.0).
   • All Schemas Used by a Domain to allow the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

     Note:

     Oracle recommends that you select All Schemas Used by a Domain for most upgrades to ensure all of the required schemas are included in the upgrade.

   Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. When you select a component, the schemas and any dependencies are automatically selected.
4. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

   Note:

   The Upgrade Assistant does not verify whether the prerequisites have been met.
5. On the Schema Credentials screen(s), specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

   • Select the database type from the Database Type drop-down menu.

   • Enter the database connection details, and click Connect.

   • Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

     Note:

     The component ID or schema name is changed for UCSUMS schema as of release 12.1.2, which means the Upgrade Assistant does not automatically recognize the possible schemas and display them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
6. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
   If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Oracle Fusion Middleware Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

   Note:

   • If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

   • Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

7. On the Upgrade Summary screen, review the summary of the schemas that will be upgraded and/or created.
   Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.
   If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.
   Click Next .
8. On the Upgrade Progress screen, monitor the status of the upgrade.

   Caution:

   Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
   If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

   Note:

   The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

   Click Next.

9. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard.

   If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at NEW_ORACLE_HOME/oracle_common/upgrade/logs.

   Note:

   If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

Upgrading WebCenter Portal Domain Components

You can upgrade the WebCenter Portal domain components by using the Upgrade Assistant. For instructions, see Understanding the Component Configurations Upgrade in Oracle Fusion Middleware Upgrading with the Upgrade Assistant.

Note:

Configuration upgrade is not applicable for WebCenter Content.

Upgrading WebCenter Sites Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

When performing a reduced downtime upgrade for WebCenter Sites, you must run the Upgrade Assistant a second time to upgrade the component configurations. This step is not needed for the other WebCenter components.

To upgrade domain component configurations with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

   Note:

   For more information about any Upgrade Assistant screen, click Help on the screen.
2. On the next screen:

   • Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

   • In the Domain Directory field, enter the WebLogic domain directory path.

   Click Next.

3. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
   If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.
4. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

   Note:

   The Upgrade Assistant does not verify whether the prerequisites have been met.
5. On the WebCenter Sites Source Version screen, select 12.2.1.0.0 or Later and click Next. This is the starting point of your upgrade.
6. (Clustered environment) If the Source environment is a Clustered environment, use the pack/unpack utility to apply the changes to other cluster members in the domain.
   In Primary node, go to path of target environment and execute PACK command:
   $ORACLE_HOME/oracle_common/common/bin
   In Secondary cluster member nodes, go to target environment and execute UNPACK command:
   $ORACLE_HOME/oracle_common/common/bin
   1. On each of the Secondary cluster member nodes, replace the Sites config folder with the one from the Primary node by copying the $DOMAIN_HOME/wcsites/wcsites/config/ to each of the nodes from the Primary node.
   2. On each of the Secondary cluster member nodes, update the following files located at DOMAIN_HOME/wcsites/wcsites/config/:
      • host properties:

        In this file, replace IP-Address details of Primary node with Secondary node details

      • jbossTicketCacheReplicationConfig.xml:

        Update the bind_addr property with a valid host or IP address of Primary node with Secondary node details for this Secondary cluster node

        Note:

        Oracle recommends changing the multicastGroupPort value to a unique value greater than 2048. Ensure that the multicast port used in jbossTicketCacheReplicationConfig.xml is the same on each node in the cluster but is different on other clusters running on the same network.
      • cas-cache.xml:

        If you are using IPv6 addressing, set multicastGroupAddress value to a valid IPv6 multicast address. This value must be the same for each node in the cluster. For example: [ff0x:0:0:0:0:0:0:301].

        Set the timeToLive parameter to a value appropriate for your environment (typically 1). The timeToLive field must be changed from the default value of 0 if the cluster members are not all collocated on the same machine. This field must be set based on the distribution of your clustered machines, as shown in the following table:

        Table B-4 Description of the different values of the timeToLive field

        timeToLive Value	Description
        1	Multicast packets restricted to the same subnet.
        32	Multicast packets restricted to the same site.
        64	Multicast packets restricted to the same geographical region.
        128	Multicast packets restricted to the same continent.
        256	No restriction.

        Repeat this step for cs-cache.xml, linked-cache.xml, and ss-cache.xml files.

        Note:

        For all these 4-xml files(cas-cache.xml, cs-cache.xml, linked-cache.xml, and ss-cache.xml) the values of “multicastGroupAddress”, “timeToLive”, “multicastGroupPort” should be appropriate as per the Primary node
   3. On each of the Secondary cluster member node go to path EXISTING_DOMAIN_HOME/bin and modify setStartupEnv.sh file
      • Ensure –Dsites.node=<Secondary cluster node name>. If this parameter is not present then add this parameter
      • Ensure –Dsites.config=<Folder Path containing wcs_properties.json file>

      Note:

      The wcs_properties.json file is shared among Primary and Secondary cluster member nodes, so the location path of this file should be the same for Primary and Secondary cluster member nodes.
7. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
   If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Oracle Fusion Middleware Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

   Note:

   • If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

   • Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
   The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.
   Click Upgrade to start the upgrade process.
9. On the Upgrade Progress screen, monitor the status of the upgrade.

   Caution:

   Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
   If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

   Note:

   The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

   Click Next.

10. If the configuration upgrade is successful, summary files are generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    If the source is a clustered environment, the summary details are generated for each cluster as follows:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs
    Click Close to close the Upgrade Assistant.

Packing the Domain and Updating the Domain Properties

If you are upgrading WebCenter Sites or WebCenter Portal as part of your reduced downtime upgrade, then you will need to pack the domain from Host 1 and unpack it during the upgrade on Host 2. You will also need to update the configuration properties before you start the servers.

1. Pack the domain on the host where admin server resides (Host 1)

After you have completed a successful upgrade on Host 1, use the following command to pack the domain. Later you will unpack the domain to use on Host 2.

cd ORACLE_HOME/common/bin 

./pack.sh -managed=true -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -template_name=wc_domain_template

2. Update the setStartupEnv.sh with the appropriate WebCenter Sites configuration properties.

The setStartupEnv.sh is located in DOMAIN_HOME\bin.

Open the setStartupEnv.sh file in "%STARTUP_GROUP%"=="WCSITES-MGD-SVR" and update SERVER_SYSTEM_PROPERTIES.

For example, :-Dsites.config=/u01/shared/wcsites/wcsites/config

Make sure that the WebCenter Sites.configuration parameter is updated with appropriate value

Restarting Node Manager, Administration Server, Managed Servers and Components on Host 1

After the upgrade, you must restart the components, servers, and processes in the correct order.

Note:

The procedures in this section describe how to start servers and processes using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Starting Administration and Managed Servers and Node Manager in Oracle Fusion Middleware Administering Oracle Fusion Middleware.

The components must be started in the following order:

• Node Manager
• Administration Server
• Managed Server(s)
• System Components

Note:

If you are unable to successfully start any of the following components on Host 1, do not proceed with the upgrade on the remaining Hosts. You must first resolve the issues with the components on Host 1.

Note:

Windows Users Only: When restarting the servers on a Windows operating system, the upgraded domain might fail with a parsing exception. To fix this parsing error, add the property "-Doracle.xml.schema/Ignore_Duplicate_components=true" to the server startup script setDomainEnv.cmd.

Starting the Node Manager

To start Node Manager:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/startNodeManager.sh
   (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

Starting the Administration Server

To start the Administration Server:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/startWebLogic.sh
   (Windows) DOMAIN_HOME\bin\startWebLogic.cmd
2. When prompted, enter your user name, password, and the URL of the Administration Server.

Starting the Managed Servers

To start the Managed Servers:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
   (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
2. When prompted, enter your user name and password.

Starting Component Processes

When you stopped the Administration Server, you also stopped the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware ControlAfter the upgrade, you will need to restart all of these processes.

1. Navigate to the DOMAIN_HOME\bin directory.
2. Execute the following script for each component
   /startComponent.sh component_name

Performing the Upgrade on Host 2

Once you have completed the upgrade on host 1, perform the following steps on each additional host in your environment. Our standard topoloy example includes only two hosts, but you may have more.

• Stopping the Components, Servers and Processes on Host 2
  You must stop the system components, managed servers and node manager running on Host 2.
• Uninstalling the Software
  When performing a rolling upgrade, an empty directory is required for installing the new binaries prior to upgrading.
• Installing the Software into the Existing Middleware Home
  Install the software into the empty Middleware home.
• Unpacking the Domain on Each Additional Host
  After you have installed the new 12c (12.2.1.4.0) binaries into the same Fusion Middleware home on Host 2, you must copy the domain directory for the applicable product (WebCenter Sites or WebCenter Portal) that you packed during the upgrade on Host 1.
• Restarting the Managed Servers and Processes
  After the upgrade is complete on Host 2, restart the managed servers.

Stopping the Components, Servers and Processes on Host 2

You must stop the system components, managed servers and node manager running on Host 2.

Stop the system components first, followed by the managed server(s) and then the node manager. Failure to stop the components in the correct order may result in a failed upgrade.

Stopping System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

Navigate to the DOMAIN_HOME\bin directory and execute the following script for each component:

./stopComponent.sh component_name 

Stopping the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
   (Windows)DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
2. When prompted, enter your user name and password.
   Stop SOA servers and processes in this order:

Stopping the Node Manager

To stop Node Manager, close the command shell/prompt in which it is running.

Alternatively, after having set the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down.

Uninstalling the Software

When performing a rolling upgrade, an empty directory is required for installing the new binaries prior to upgrading.

Note:

You must deinstall the upperstack components first, then deinstall JRF. After deinstalling the JRF, back up any remaining files and then delete all files in the directory. The installation directory must be empty.

Follow the instructions in this section to remove the software from the existing ORACLE_HOME. You will reinstall the new software into this same directory.

To start the Oracle Universal Installer in deinstallation mode, execute the following command:

UNIX: ORACLE_HOME/oui/bin/deinstall.sh

Windows: ORACLE_HOME\oui\bin\deinstall.cmd

If you want to uninstall the product in a silent (command-line) mode, see Running the Oracle Universal Installer for Silent Uninstallation in Oracle Fusion Middleware Installing Software with the Oracle Universal Installer.

Installing the Software into the Existing Middleware Home

Install the software into the empty Middleware home.

Uninstall the software from the existing Oracle home before installing the 12c (12.2.1.4.0) product distributions. Install the software using the same process you used to install on Host 1.

When upgrading Oracle WebCenter Sites, unpack the domain and copy the config directory from Host 1 to Host 2.

Unpacking the Domain on Each Additional Host

After you have installed the new 12c (12.2.1.4.0) binaries into the same Fusion Middleware home on Host 2, you must copy the domain directory for the applicable product (WebCenter Sites or WebCenter Portal) that you packed during the upgrade on Host 1.

cd ORACLE_HOME/common/bin

./unpack.sh -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -overwrite_domain=true

Restarting the Managed Servers and Processes

After the upgrade is complete on Host 2, restart the managed servers.

To start the Managed Servers:

1. Enter the following command:
   (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
   (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
2. When prompted, enter your user name and password.

Validating the Upgrade

After you have completet the upgrade on all hosts, complete the standard upgrade verification tasks to ensure that all components will continue to work as expected.

See Tasks to Perform After Upgrade.

Note:

Only perform those tasks that pertain to your environment, configuration and preferences. These tasks are meant to assist you in verfiying that the upgrade was successful. You may need to perform additional testing based on your configuration.

Recovering from a Failed Upgrade

If your upgrade is unsuccessful, you will need to restore your environment from backup. Make sure that you include your backed up configuration and script files. Restore the backup of the Oracle home (on all of the nodes), the entire domain directory (on all of the nodes) and component schemas. In addition, you will need to restore any UI customizations and the applications directory, in addition to domain directory.