C About the Reduced Downtime Upgrade Process
Review the flowchart for an overview of the upgrade process for Oracle Fusion Middleware if you are performing a reduced downtime upgrade.
A reduced downtime upgrade process is different from a standard Fusion Middleware upgrade process. This type of upgrade requires at least a two-node cluster environment and is performed in a rolling fashion so that one node is always up to accomplish the reduced downtime upgrade. In the standard upgrade flow, all servers and processes are stopped prior to initiating the upgrade.
- Back up the database schemas.
- Back up the domain directory and the application directory.
- Back up the UI /similar customizations.
For details about backing up, see Creating a Complete Backup in Upgrading to the Oracle Fusion Middleware Infrastructure.
After taking the required back ups, uninstall the previous version of the software to ensure that an empty Oracle Home is available to install the new product distributions. This is the key difference between the two upgrade processes. In addition, if your product requires a schema and/or a config upgrade, you will need to run the Upgrade Assistant twice, once each for schema upgrade and for config upgrade.
Note:
Oracle Fusion Middleware 12c (12.2.1.3) is the only supported starting point for a reduced downtime upgrade. You cannot perform a reduced downtime upgrade if you are upgrading from a supported Fusion Middleware 11g or 12c (12.2.1.2.0 or earlier) release, or if you do not have a multi-node environment. To perform a reduced downtime upgrade from 12c (12.1.3 or 12.2.1.2), you must first upgrade to 12.2.1.3 using the standard upgrade process. See Upgrading Oracle FMW Infrastructure from a Previous 12c Release in Upgrading to the Oracle Fusion Middleware Infrastructure.Figure C-1 Process Flowchart for a Reduced Downtime Upgrade
![Description of Figure C-1 follows Description of Figure C-1 follows](img/zero_downtime_fmw.png)
Description of "Figure C-1 Process Flowchart for a Reduced Downtime Upgrade "
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 in Upgrading to the Oracle Fusion Middleware Infrastructure. |
Required Stop the servers and processes on Host 1. |
Before starting the upgrade process, stop all the servers, components, and processes on Host 1. |
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
|
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 |
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. |
Required If applicable to your product, perform the schema and config upgrade separately on Host 1, by using the Upgrade Assistant. |
Note: You do not have to perform schema upgrade for reduced downtime upgrade of WebLogic Server 12c (12.2.1.3.0). |
Required If your product included a configuration upgrade, pack the domain on Host 1. |
|
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. |
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
|
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. |
Required Validate the upgrade on Host 2. |
After restarting the servers and processes, perform the upgrade validation tasks. |
Performing a Reduced Downtime Upgrade
If you are upgrading from Fusion Middleware 12c (12.2.1.3) release, you can use this process to upgrade your multi-node domain without shutting down all of the servers at the same time.
The procedures described in this section are based on the Oracle Fusion Middleware Standard Installation Topology (SIT) and require that you have a multi-node environment. The standard installation topology for Oracle Fusion Middleware Infrastructure has a standard WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers. Host 1 is used to describe the procedures performed on the host with the Administration server and Host 2 is used to describe the procedures performed on the other managed server host(s). If you have more than two hosts in your environment, be sure to complete the procedures on each additional node.
Required Tasks that Must be Completed Before You Begin
Review the following before you begin a reduced downtime upgrade:
- Review the preupgrade checklists for the components in your deployment. The checklists are found in each of the component-specfic upgrade guides. Some products may require additional steps before performing the upgrade.
- Create a complete backup of the Oracle home (on all of the nodes), the entire domain directory (on all of the nodes) and component schemas before performing the upgrade. In addition, Oracle recommends that you create a backup of UI customizations and the applications directory, in addition to domain directory. See Creating a Complete Backup in Upgrading to the Oracle Fusion Middleware Infrastructure.
- Make sure that you are using the appropriate JDK version for this release. The minimum JDK version is jdk1.8.0_321.
- If you are upgrading a shared component directory, back up the contents of the shared directory before the upgrade. The configuration upgrade makes changes to these directories.
- Make sure that your backups include any modified scripts, such as
setStartupEnv.sh
, for example. The upgrade will overwrite any customized files and you will lose your changes.
Performing the Upgrade on Host 1
Perform the following tasks on the machine that hosts the Administration server and serves as the primary machine for your deployment.
- Stopping Components, Servers and Processes on Host 1
- Uninstalling the Software
- Installing Oracle Fusion Middleware Infrastructure
- Running a Pre-Upgrade Readiness Check
- Upgrading Product Schemas and Component Configurations
- Packing the Domain on Host 1
- Restarting Node Manager, Administration Server, Managed Servers and Components on Host 1
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.- System Components (if any)
- Managed Server(s)
- Administration Server
- Node Manager
Stopping System Components
To stop system components, such as , use the stopComponent
script:
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
Stopping the Managed Servers
stopManagedWebLogic
script:
Uninstalling the Software
When performing a rolling upgrade, an empty directory is required for installing the new binaries prior to upgrading.
Note:
You must deinstall the upperstack components first, then deinstall JRF. After deinstalling the JRF, back up any remaining files and then delete all files in the directory. The installation directory must be empty.Follow the instructions in this section to remove the software from the existing ORACLE_HOME
. You will reinstall the new software into this same directory.
To start the Oracle Universal Installer in deinstallation mode, execute the following command:
UNIX: ORACLE_HOME/oui/bin/deinstall.sh
Windows: ORACLE_HOME\oui\bin\deinstall.cmd
If you want to uninstall the product in a silent (command-line) mode, see Running the Oracle Universal Installer for Silent Uninstallation in Installing Software with the Oracle Universal Installer.
Installing Oracle Fusion Middleware Infrastructure
Before starting your upgrade, uninstall the software from the existing Oracle home, then use the Oracle Universal Installer to install the 12c (12.2.1.6.0) product distributions into the same Oracle home on the target system.
You must install the product distributions on each host during the upgrade.
Note:
Do not use reduced downtime upgrade if the starting point for the upgrade is not 12c (12.2.1.3.0).Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.
About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in -readiness
mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.
The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.
The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.
You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.
You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.
Note:
To prevent performance from being affected, Oracle recommends that you run the readiness check during off-peak hours.
Starting the Upgrade Assistant in Readiness Mode
Use the -readiness
parameter to start the Upgrade Assistant in readiness mode.
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 |
---|---|---|
|
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 |
|
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. |
|
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). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
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)
(Windows)
|
|
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.
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
|
The directory location of the generated log file. |
No action required. |
Domain Directory | Displays the domain location | No action required. |
Readiness report location
|
The directory location of the generated readiness report. |
No action required. |
Names of components that were checked |
The names and versions of the components included in the check and status. |
If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, do not attempt an upgrade. |
Names of schemas that were checked |
The names and current versions of the schemas included in the check and status. |
Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, do not attempt an upgrade. |
Individual Object Test Status: FAIL |
The readiness check test detected an issue with a specific object. |
Do not upgrade until all failed issues have been resolved. |
Individual Object Test Status: PASS |
The readiness check test detected no issues for the specific object. |
If your readiness check report shows only the PASS status, you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade. |
Completed Readiness Check of <Object> Status: FAILURE | The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index, or datatype. | Do not upgrade until all failed issues have been resolved. |
Completed Readiness Check of <Object> Status: SUCCESS | The readiness check test detected no issues. | No action required. |
Here is a sample Readiness Report file. Your report may not include all of these checks.
Upgrade readiness check completed with one or more errors.
This readiness check report was created on Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain
Starting readiness check of components.
Oracle Platform Security Services
Starting readiness check of Oracle Platform Security Services.
Schema User Name: DEV3_OPSS
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test: Test that the schema does not contain any unexpected tables TEST_UNEXPECTED_TABLES
Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test: SEQUENCE_TEST Test that the Oracle Platform Security Services schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
Finished readiness check of Oracle Platform Security Services with status: SUCCESS.
Oracle Audit Services
Starting readiness check of Oracle Audit Services.
Schema User Name: DEV3_IAU
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test: TEST_UNEXPECTED_COLUMNS Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting schema test: SEQUENCE_TEST Test that the audit schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
Starting schema test: SYNONYMS_TEST Test that the audit schema required synonyms are present
Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
Finished readiness check of Oracle Audit Services with status: FAILURE.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Schema User Name: DEV3_STB
Database Type: Oracle Database
Database Connect String:
Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables
Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views
Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Oracle JRF
Starting readiness check of Oracle JRF.
Finished readiness check of Oracle JRF with status: SUCCESS.
System Components Infrastructure
Starting readiness check of System Components Infrastructure.
Starting config test: TEST_SOURCE_CONFIG Checking the source configuration.
INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Starting config test: CIEConfigPlugin.readiness.test This tests the readiness of the domain from CIE side.
Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Finished readiness check of components.
Upgrading Product Schemas and Component Configurations
When upgrading to Fusion Middleware 12 c (12.2.1.4.0), if your product component includes a schema and/or a config upgrade, you have to upgrade the supported product schemas and component configurations on Host 1, by using the Upgrade Assistant.
Packing the Domain on Host 1
After you have performed a config upgrade for your product component, you
must pack the domain on Host 1 by using the pack
command.
See Packing the Domain on the Primary Node.
For information about the pack
command, see The Pack Command in Creating Templates and Domains Using the Pack and Unpack Commands.
Restarting Node Manager, Administration Server, Managed Servers and Components on Host 1
After the upgrade, you must restart the components, servers, and processes in the correct order.
Note:
The procedures in this section describe how to start servers and processes using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Starting Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.The components must be started in the following order:
- Node Manager
- Administration Server
- Managed Server(s)
- System Components
Note:
If you are unable to successfully start any of the following components on Host 1, do not proceed with the upgrade on the remaining Hosts. You must first resolve the issues with the components on Host 1.Note:
Windows Users Only: When restarting the servers on a Windows operating system, the upgraded domain might fail with a parsing exception. To fix this parsing error, add the property "-Doracle.xml.schema/Ignore_Duplicate_components=true
" to the server startup script setDomainEnv.cmd.
Performing the Upgrade on Host 2
After you have completed the upgrade on host 1, perform the following steps on each additional host in your environment. Our standard topology example includes only two hosts, but you may have more.
Stopping the Components, Servers and Processes on Host 2
You must stop the system components, managed servers and node manager running on Host 2.
Stopping System Components
To stop system components, , use the
stopComponent
script:
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
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.
Unpacking the Domain on Host 2
After completing the config upgrade, you had packed your domain on Host 1.
You must now unpack the domain on Host 2 by using the unpack
command.
See Unpacking the Domain on the Secondary Node.
For information about the unpack
command, see The Unpack Command in Creating Templates and Domains Using the Pack and Unpack Commands.
Validating the Upgrade
After you have completet the upgrade on all hosts, complete the standard upgrade verification tasks to ensure that all components will continue to work as expected.
See .
Note:
Only perform those tasks that pertain to your environment, configuration and preferences. These tasks are meant to assist you in verfiying that the upgrade was successful. You may need to perform additional testing based on your configuration.Recovering from a Failed Upgrade
If your upgrade is unsuccessful, you will need to restore your environment from backup. Make sure that you include your backed up configuration and script files. Restore the backup of the Oracle home (on all of the nodes), the entire domain directory (on all of the nodes) and component schemas. In addition, you will need to restore any UI customizations and the applications directory, in addition to domain directory.