About the Reduced Downtime Upgrade Process

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 Data Integrator 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

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 Data Integrator.
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 Product Schemas 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 Identifying Schemas that Can Be Upgraded to 12c (12.2.1.4.0) Identifying Configurations That Can Be Upgraded with the Upgrade Assistant
Required If your product included a configuration upgrade, pack the domain on Host 1.	Note: Configuration upgrade is not applicable for upgrading Oracle Data Integrator.
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.

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

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 Product Schemas 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

Required

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

Note:

Configuration upgrade is not applicable for upgrading Oracle Data Integrator.

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.

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.

Parent topic: About the Reduced Downtime Upgrade Process

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 Data Integrator
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 Product 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.

Parent topic: Performing a Reduced Downtime Upgrade

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

Parent topic: Performing the Upgrade on Host 1

Stopping System Components

To stop system components, such as Oracle Data Integrator, 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.

Parent topic: Performing the Upgrade on Host 1

Installing the 12c (12.2.1.4.0) Product Distributions for Oracle Data Integrator

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.

Installing Oracle Data Integrator Java EE Environment
Before beginning your upgrade, download Oracle Data Integrator 12c (12.2.1.4.0) distribution on the target system and install it using Oracle Universal Installer.

Parent topic: Performing the Upgrade on Host 1

Installing Oracle Data Integrator Java EE Environment

Before beginning your upgrade, download Oracle Data Integrator 12c (12.2.1.4.0) distribution on the target system and install it using Oracle Universal Installer.

Note:

The ODI Enterprise installation process will automatically install Oracle Fusion Middleware Infrastructure if it is not already installed.

To install Oracle Data Integrator Java EE environment:

Sign in to the target system.
Download the following from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:
- Oracle Data Integrator (fmw_12.2.1.4.0_odi_Disk1_1of1.zip)
Change to the directory where you downloaded the 12c (12.2.1.4.0) product distribution.
Unzip the installer fmw_12.2.1.4.0_odi_Disk1_1of1.zip file.
Start the ODI installation:
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.4.0_odi.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.4.0_odi.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 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.
On the Installation Type screen, select Enterprise Installation.
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 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.

Parent topic: Installing the 12c (12.2.1.4.0) Product Distributions for Oracle Data Integrator

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.

Parent topic: Performing the Upgrade on Host 1

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.

Parent topic: Running a Pre-Upgrade Readiness Check

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) NEW_ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) NEW_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

Parent topic: Running a Pre-Upgrade Readiness Check

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) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `NEW_ORACLE_HOME\oracle_common\upgrade\logs` `NEW_ORACLE_HOME\oracle_common\upgrade\temp`
`-help`	Optional	Displays all of the command-line options.

Parent topic: Starting 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.

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

Parent topic: Running a 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.

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 `NEW_ORACLE_HOME/oracle_common/upgrade/logs`	The directory location of the generated log file.	No action required.
Readiness report location `NEW_ORACLE_HOME/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 Tue May 30 11:15:52 EDT 2016
Log file is located at: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
   Starting readiness check of Oracle Metadata Services.
     Schema User Name: DEV11_MDS
     Database Type: Oracle Database
     Database Connect String: machinename@yourcompany.com
     VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
   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_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
     EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
   Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
   Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ 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_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_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
   Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
   Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
   Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
   Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ 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 MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   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_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 schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Finished readiness check of Oracle Metadata Services with status: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from 11g (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes 
     INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
   Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes +++ FAIL

Note:

You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.

Parent topic: Running a Pre-Upgrade Readiness Check

Upgrading Product Schemas Using the Upgrade Assistant

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

Notes:

If you are using external authentication, make sure that external authentication is changed to internal authentication before upgrading product schemas.
Edition-based redefinition (EBR) Users Only: Before upgrading an Edition-Based Redefinition (EBR) enabled schema, you must connect to the database server and create an edition on the database server for 12c. The new edition for 12c must be a child of your existing 12c edition. See Creating an Edition on the Server for Editions-Based Redefinition.

To upgrade product schemas with the Upgrade Assistant:

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.
On the Selected Schemas screen, select Individually Selected Schemas.

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.
On the Available Components screen, select Oracle Data Integrator to upgrade the Master and Work Repository schema.
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.
On the ODI Schema screen, specify the database connection details for each schema you are upgrading:
- Select the database type from the Database Type drop-down menu.
- Enter the database connection details, and click Connect.
- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

On the ODI Options screen, select all of the options.

Table C-4 ODI Options

Option	Description
Replace Knowledge Modules with mandatory updates	This selection replaces standard Knowledge Modules with the newest version. Customizations to Oracle installed Knowledge Modules will be overwritten. But if you copy an installed Knowledge Module and customize the Knowledge Module, the customizations are not lost.
Upgrade topology and security metadata	This selection replaces topology and security artifacts such as Technologies, Datatypes, Security Profiles and others with the newest version. Customizations of installed objects will be overwritten. If the object is copied and customized, then the customizations are not lost.

See Advanced Upgrade Options.

On the ODI Supervisor screen, enter the Supervisor account credentials for the ODI repository to be upgraded.

The installed Supervisor account is SUPERVISOR. Check with your ODI administrator for proper Supervisor account name and password, supplied when prompted by the Repository Creation Utility (RCU) when creating the Master and Work repositories for ODI.

Note:
When All Schemas Used by a Domain is selected, the Supervisor credentials for ODI are not pre-populated in the first instance as the domain does not contain them. If there are multiple ODI schemas, the Upgrade Assistant populates the user entry using the first set of credentials.
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.
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 .
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.
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.

Parent topic: Performing the Upgrade on Host 1

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.

Parent topic: Performing the Upgrade on Host 1

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

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.

Parent topic: Performing a Reduced Downtime Upgrade

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.

Parent topic: Performing the Upgrade on Host 2

Stopping System Components

To stop system components, Oracle Data Integrator, 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.

Parent topic: Performing the Upgrade on Host 2

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.

Parent topic: Performing the Upgrade on Host 2

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.

Parent topic: Performing the Upgrade on Host 2

Validating the Upgrade

Now that the upgrade is complete on all of the hosts, complete the standard upgrade verification tasks described in this guide to ensure that our components will continue to work as expected.

Note:

Only perform those tasks that pertain to your envivornment, 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 enviroment 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.

Parent topic: Performing a Reduced Downtime Upgrade