C 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 SOA Suite with Business Activity Monitoring from a Previous 12c Release.

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
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 SOA Suite and Business Process Management.
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 Upgrading SOA Schemas Using the Upgrade Assistant. Note: Configuration upgrade is not applicable when you upgrade SOA with BPM. 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 Identifying Schemas that Can Be Upgraded to 12c (12.2.1.4.0) Identifying Configurations That Can Be Upgraded with the Upgrade Assistant
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.
• 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 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
  

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 SOA Suite and Business Process Management
  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 SOA Schemas Using the Upgrade Assistant
  Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.
• 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.
   Stop SOA servers and processes in this order:

   1. Business Activity Monitoring (BAM) Managed Server

   2. Oracle Service Bus (OSB) Managed Server

   3. Service-Oriented Architecture (SOA) Managed Server

   4. Oracle Web Services Manager (OWSM) Managed Server

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

Installing the 12c (12.2.1.4.0) Product Distributions for Oracle SOA Suite and Business Process Management

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:

• Make sure that you have uninstalled the existing product distributions before installing the 12c (12.2.1.4.0) distributions.

• Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).

• If your SOA domain has other SOA-integrated components, such as Oracle Service Bus, Managed File Transfer, or Oracle B2B, you must install those distributions into the same Oracle home. Oracle Business Activity Monitoring and Business Process Management are part of the SOA distribution soa.jar.

To install the Oracle SOA Suite component distributions:

1. Sign in to the target system.
2. Download the following distributions from from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:
   • Fusion Middleware Infrastructure distribution (fmw_12.2.1.4.0_infrastructure.jar)
   • Fusion Middleware SOA Suite and Business Process Management distribution (fmw_12.2.1.4.0_soa.jar)
   • If you are running Managed File Transfer, Oracle Service Bus or Oracle B2B, download the Managed File Transfer distribution (fmw_12.2.1.4.0_mft.jar), Oracle Service Bus (fmw_12.2.1.4.0_osb.jar), and Oracle B2B (fmw_12.2.1.4.0_b2b.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

   Note:

   When you run the scripts (for example: ORACLE_HOME/oui/bin/deinstall.sh) to uninstall the product, it does not clear all the files in ORACLE_HOME. A few configuration files remain in ORACLE_HOME. During the installation, use the -novalidation flag to ensure that the Infrastructure binaries are installed correctly.
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 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.
8. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected, and click Next.
9. 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).
10. 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.

11. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.
12. 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.
13. After you have installed the Infrastructure, repeat steps 3 through 13 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 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:

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 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 SOA Schemas Using the Upgrade Assistant

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

Caution:

Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.

Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

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

   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.

   For example, when Oracle SOA is selected, the Oracle SOA (_SOAINFRA), Audit Services (_IAU), Metadata Service (_MDS), Oracle Platform Security Services(_OPSS), and User Messaging Services (_UMS) schemas will be included in the upgrade.

   When Managed File Transfer is selected, Audit Services (_IAU), Enterprise Scheduler (_ESS) and Platform Security Services (OPSS) will be included in the upgrade.

4. The Domain Directory screen appears when Oracle Platform Security Services or Oracle Audit Services is selected on the Available Components screen. Enter the absolute path to the existing WebLogic domain directory, or click Browse to navigate to and select the domain directory you are upgrading
5. 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.
6. 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):

   Element	Description
   Database Type	The database type chosen for upgrade must be identical to the database type that was selected when RCU originally created the schema. If you select Oracle Edition-Based Redefinition (EBR) as the database type, the schema that you are upgrading also must have been created by RCU as the EBR database type. In particular, Upgrade Assistant never converts schemas from one database type to another. The options include: Oracle Database Microsoft SQL Server IDM DB2 MySQL Java DB Oracle Database enabled for edition-based redefinition
   Edition Name	For database type "Oracle Database enabled for edition-based redefinition" (EBR database) you will need to enter the name of an existing Edition in the Edition Name element field. The database schema upgrade will occur in the edition you have chosen.
   Database Connect String	Enter the location of the database. For example, if you are selecting an Oracle database, the following URL format could be used: host:port/db_service_name If you are using a Microsoft SQL Server or IBM DB2 database, select the database type from the drop-down menu to see an example of the syntax that can be used for each database type.
   DBA User Name	Enter the database user name used to connect to the database. Oracle Database Users Only: If SSL authentication is used, then the DBA User Name field may be optional. If you do provide a DBA User Name, then the information will be used during the database authentication. For Oracle database users, if you are not running as SYS or SYSDBA, then user of Upgrade Assistant must have all of the privileges granted in the FMW user account. Refer to your component-specific upgrade documentation for more information on creating a non-sysdba user to run Upgrade Assistant.
   DBA Password	Enter the password associated with the specified DBA database user. Oracle Database Users Only: If SSL authentication is used, then the DBA Password field may be optional. If you do provide a DBA user name and password, then the information will be used during the database authentication.
   Schema User Name	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. Upgrading from a Previous 12c Release: As of release 12.1.2.0.0 the schema name for UCSUMS schema changed. The new name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade. If Upgrade Assistant does not automatically recognize the possible schemas and cannot display them in a drop-down list, then you must manually enter the name in a text field. 11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses prefix_ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.
   Schema Password	Enter the password associated with the specified schema user name.
7. On the Create Schemas screen, specify if you want the Upgrade Assistant to create the missing schemas. By default the Create missing schemas for the specified domain option is enabled. The Upgrade Assistant will attempt to create the missing schemas for the domain using the database connection details and schema owner name provided. The Upgrade Assistant creates the schemas using the default tablespace settings.
   Select Use same passwords for all schemas if the same password is used for all schemas. Enter and confirm the password in the table. You only have to supply the password once.

   Note:

   Do not allow the Upgrade Assistant to create schemas for you if you require customized options for your schemas. The schemas are created using the default Repository Creation Utility (RCU) settings. For example, if your schemas require additional tablespace, you must use the RCU to create the schemas.

   If you do not want the Upgrade Assistant to create these schemas for you, deselect the Create missing schemas for the specified domain option and click Next. You will have to run the Repository Creation Utility to create the schemas.

8. The Create Schema Defaults screen appears if you selected the Create missing schemas for the specified domain option. The default datafile size is listed for each component schema and auxiliary schema. If you need to modify the size of the tablespace datafile ,or make any other changes to the default schema settings, use the Repository Creation Utility to create the schemas. You cannot modify the tablespace settings from the Upgrade Assistant.
9. 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 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.

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

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

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:

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

   1. Business Activity Monitoring (BAM) Managed Server

   2. Oracle Service Bus (OSB) Managed Server

   3. Service-Oriented Architecture (SOA) Managed Server

   4. Oracle Web Services Manager (OWSM) Managed 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 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.

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.