About the Reduced Downtime Upgrade Process

C About the Reduced Downtime Upgrade Process

Review the flowchart 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 in Upgrading to the Oracle Fusion Middleware Infrastructure.

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 FMW Infrastructure from a Previous 12c Release in Upgrading to the Oracle Fusion Middleware Infrastructure.

Figure C-1 Process Flowchart for a Reduced Downtime Upgrade

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

Table C-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 C-1 Tasks for Performing a Reduced Downtime Upgrade of Oracle Fusion Middleware 12c (12.2.1.3.0) Release

Task Description

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 in Upgrading to the Oracle Fusion Middleware Infrastructure.
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 Oracle Fusion Middleware Infrastructure.
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.	Note: You do not have to perform schema upgrade for reduced downtime upgrade of WebLogic Server 12c (12.2.1.3.0).
Required If your product included a configuration upgrade, pack the domain on Host 1.	See Packing the Domain on Host 1.
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 in the Existing Oracle Home on Host 2.
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.

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 in Upgrading to the Oracle Fusion Middleware Infrastructure.

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 Oracle Fusion Middleware Infrastructure.

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.

Note:

You do not have to perform schema upgrade for reduced downtime upgrade of WebLogic Server 12c (12.2.1.3.0).

Required

If your product included a configuration upgrade, pack the domain on Host 1.

See Packing the Domain on Host 1.

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 in the Existing Oracle Home on Host 2.

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.

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 in Upgrading to the Oracle Fusion Middleware Infrastructure.
Make sure that you are using the appropriate JDK version for this release. The minimum JDK version is jdk1.8.0_321.
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

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).

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 , 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:

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
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:

Enter the following command:
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
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 Installing Software with the Oracle Universal Installer.

Installing Oracle Fusion Middleware Infrastructure

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.6.0) product distributions into the same Oracle home on the target system.

You must install the product distributions on each host during the upgrade.

The supported JDK version for 12c (12.2.1.6.0) is 1.8.0_321. Ensure that you upgrade to JDK version 1.8.0_321 or later, before installing the 12c (12.2.1.6.0) software.

Note:

Do not use reduced downtime upgrade if the starting point for the upgrade is not 12c (12.2.1.3.0).

To install Oracle Fusion Middleware Infrastructure distribution:

Sign in to the target system.
Download the Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.1_infrastructure.jar) from Oracle Technology Network or Oracle Software Delivery Cloud to your target system.
Change to the directory where you downloaded the 12c (12.2.1.6.0) product distribution.
Start the installation program for Oracle Fusion Middleware Infrastructure :
- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.6.0_infrastructure.jar
- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.6.0_infrastructure.jar
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.
On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.
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.
On the Installation Location screen, specify the existing 12c (12.2.1.3.0) Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see About the Directories for Installation and Configuration in Planning an Installation of Oracle Fusion Middleware.
On the Installation Type screen, select Fusion Middleware Infrastructure and click Next.
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).
On the Security Updates screen, enter your My Oracle Support account information so you can receive the latest product information and security updates via your My Oracle Support account.
This screen appears the first time you install an Oracle product on a host.

If you do not have an Oracle Support account and you are sure that you want to skip this step, clear the check box and verify your selection in the follow-up dialog box.
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.
On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.
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.

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.

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:

Go to the oracle_common/upgrade/bin directory:
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
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

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

Table C-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:

On the Welcome screen, review information about the readiness check. Click Next.
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.
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.
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.
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.
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 C-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 Product Schemas and Component Configurations

When upgrading to Fusion Middleware 12 c (12.2.1.4.0), if your product component includes a schema and/or a config upgrade, you have to upgrade the supported product schemas and component configurations on Host 1, by using the Upgrade Assistant.

For the list of schemas and component configuration that you can upgrade to 12c (12.2.1.4.0), see the following sections of Upgrading with the Upgrade Assistant

Packing the Domain on Host 1

After you have performed a config upgrade for your product component, you must pack the domain on Host 1 by using the pack command.

See Packing the Domain on the Primary Node.

For information about the pack command, see The Pack Command in Creating Templates and Domains Using the Pack and Unpack Commands.

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 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:

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:

Enter the following command:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.

Starting the Managed Servers

To start the Managed Servers:

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
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.

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

Performing the Upgrade on Host 2

After you have completed the upgrade on host 1, perform the following steps on each additional host in your environment. Our standard topology 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.

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, , 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:

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
When prompted, enter your user name and password.

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:

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 Installing Software with the Oracle Universal Installer.

Installing the Software in the Existing Oracle Home on Host 2

After you have uninstalled the software from the 12c (12.2.1.3) Oracle home, install the 12c (12.2.1.4) binaries into the same Oracle home, on Host 2.

You must install the software on each host in your deployment. Follow the same process that you used to install the software on Host 1. Ensure that you begin with an empty directory.

Unpacking the Domain on Host 2

After completing the config upgrade, you had packed your domain on Host 1. You must now unpack the domain on Host 2 by using the unpack command.

See Unpacking the Domain on the Secondary Node.

For information about the unpack command, see The Unpack Command in Creating Templates and Domains Using the Pack and Unpack Commands.

Restarting the Managed Servers and Processes

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

To start the Managed Servers:

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
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 .

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.