2 Preparing to Upgrade

The topics in this section describe the tasks you must perform before you attempt an upgrade to Oracle Fusion Middleware 12c.

WARNING:

Before you upgrade to Oracle Fusion Middleware 12c, you must preform the required pre-upgrade tasks for your deployed components. Complete only those tasks that apply to your environment.

Failure to perform these tasks may result in a failed upgrade.

2.1 Pre-Upgrade Checklist

The tasks described in this pre-upgrade checklist assume that you read Planning an Upgrade to Oracle Fusion Middleware 12c and understand the requirements of this upgrade.

Complete all applicable tasks before you begin the upgrade process.

Note:

The procedures you perform depend on the configuration of your existing system, the components you are upgrading, and the environment you want to create at the end of the upgrade and configuration process.

In addition to the common, pre-upgrade procedures described here, you may also have component-specific tasks to perform. Consult your component-specific upgrade documentation for other required procedures.

Table 2-1 Tasks to Perform Before You Upgrade to Oracle Fusion Middleware 12c

Task	Description	Documentation
Create a complete backup of your pre-upgrade environment.	REQUIRED FOR ALL UPGRADES. Back up all system-critical files and database(s) that contain any schemas that will be upgraded before you begin your upgrade. If the upgrade fails, you will need to restore your pre-upgrade environment and begin the upgrade again.	Creating a Complete Backup (Required)
Verify that you are installing and upgrading your product on a supported hardware and software configuration.	As part of the upgrade planning process, you already verified that your hardware and software configurations are supported by the latest certifications and requirements documents. Just before you start the upgrade, verify this information again, as the certification requirements may have changed. Make sure that you have applied the latest patches to your components before you upgrade.	Verifying Certification and System Requirements
Remove any outdated or unused data before you upgrade.	To optimize performance, consider purging data and objects that will not be used in the upgraded environment.	Purging Unused Data
Clone your production environment.	In addition to creating a complete backup of your system files, you should also clone your production environment. This environment can be used to test the upgrade.	Cloning Your Production Environment (Recommended)
Verify that you are running a 64-bit operating system. Most Oracle Fusion Middleware 12c components require a 64-Bit operating system.	Required only if you are currently running a 32-bit operating system.	Migrating from a 32-Bit to a 64-Bit Operating System
Depending on your upgrade starting point, you may be required to create new 12c schemas before an upgrade.	Oracle Fusion Middleware 12c requires that you use the Repository Creation Utility (RCU) to create new schemas before you can upgrade your existing environment.	Creating the Required Schemas Before an Upgrade
If you are using a file-based policy store, then you must reassociate it to a database-based policy store.	This step is not required if you are upgrading from a previous 12c release.	Reassociating File-based Policy Stores to Database-based Policy Stores (Required)
Understand the schema requirements when using an OID-based security store.	If you are using an OID-based security store, you will need to create a 12c OPSS schema before you upgrade.	Creating the 12c OPSS Schema for an OID-based Security Store
Oracle recommends that you maintain the highest level of security for all Fusion Middleware security stores.	Before the upgrade, back up your existing security stores and then upgrade them using the security store-specific procedures.	Upgrading Security Stores to the Latest Version
Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK.	Required only if you plan to use enhanced encryption (such as AES 256). Oracle recommends that you apply the required policy files to the JDK before you upgrade.	Using Enhanced Encryption (AES 256)
Create a new Non-SYSDBA user to avoid running the upgrade as SYS/SYSDBA.	Oracle recommends that you create a non-SYSDBA user called fmw to run Upgrade Assistant with only those privileges required by the Upgrade Assistant.	Creating a Non-SYSDBA User
Oracle Database Users: 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 (12.2.1).	This step is required only if you are using an Edition-Based Redefinition (EBR) database.	Creating an Edition on the Server for Edition-Based Redefinition (Optional)
You must download and install into a new Oracle home the new 12c products before you upgrade.	Install the 12c (12.2.1) versions of the products you already have in your pre-upgrade environment. Note that some products have not yet been released for 12c (12.2.1), but will become available in a future release.	Downloading and Installing the 12c Oracle Fusion Middleware Product Distributions
Run a pre-upgrade readiness check.	Before you begin the actual upgrade process, run the Upgrade Assistant in -readiness mode to perform a read-only analysis of your pre-upgrade environment. If there are any issues, you must correct them before the upgrade.	Running a Pre-Upgrade Readiness Check
Use the component-specific upgrade documentation to complete your upgrade.	The documentation covers component-specific tasks that are required for the upgrade. Some of the tasks are performed before the upgrade and some are performed after. Always consult your Oracle Fusion Middleware upgrade documentation to ensure you have a successful upgrade.	Locating Your Component-Specific Upgrade Documentation

2.2 Creating a Complete Backup (Required)

Before you install any new Release 12c distributions and begin upgrading your Oracle Fusion Middleware 11g or 12c deployment, be sure you have backed up all system-critical files; including all of the databases that host your Oracle Fusion Middleware schemas.

See Backing Up Your Environment for more information.

2.3 Cloning Your Production Environment (Recommended)

Oracle strongly recommends that you create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.

For more information on creating a test environment to use to roll out an upgrade, see "Moving from a Test to a Production Environment" in Administering Oracle Fusion Middleware.

Upgrades cannot be reversed. In most cases, if an error occurs, you must stop the upgrade and restore the entire environment from backup and begin the upgrade process from the beginning. Identifying potential upgrade issues in a development environment can eliminate unnecessary downtime.

Note:

You can run the Readiness Check on the cloned production environment to help identify potential upgrade issues.

Performing pre-upgrade testing on a cloned environment provides important data that can be applied to your overall production upgrade plan.

Additional benefits of running an upgrade in a cloned production environment include the following:

Uncover and correct any upgrade issues.
Practice completing an end-to-end upgrade.
Understand the upgrade performance and how purge scripts can help.
Understand the time required to complete the upgrade.
Understand the database resource usage (such as temporary tablespace; PGA, etc).

2.4 Verifying Certification and System Requirements

The certification matrix and system requirements documents should be used in conjunction with each other to verify that your environment meets the necessary requirements for installation.

NOTE: When checking the certification, system requirements, and interoperability information, be sure to check specifically for any 32-bit or 64-bit system requirements. It is important for you to download software specifically designed for the 32-bit or 64-bit environment, explicitly.

WARNING: Make sure that your current environment has been patched to the latest patch set BEFORE you begin the upgrade. Certifications are based on fully patched environments unless stated otherwise.

2.4.1 Verify Your Environment Meets Certification Requirements

Make sure that you are installing your product on a supported hardware or software configuration. For more information, see Certification Matrix for 12c (12.2.1).

Oracle has tested and verified the performance of your product on all certified systems and environments; whenever new certifications occur, they are added to the proper certification document right away. New certifications can occur at any time, and for this reason the certification documents are kept outside of the documentation libraries and are available on Oracle Technology Network.

2.4.2 Verify System Requirements and Specifications

The Oracle Fusion Middleware System Requirements and Specifications document should be used to verify that the requirements of the certification are met. For example, if the certification document indicates that your product is certified for installation on 64-Bit Oracle Linux 7, this document should be used to verify that your Oracle Linux 7 system has met the required minimum specifications, like disk space, available memory, specific platform packages and patches, and other operating system-specific items. This document is updated as needed and resides outside of the documentation libraries. The latest version is available on Oracle Technology Network.

For a complete description of the system requirements for installing and upgrading to Oracle Fusion Middleware 12c, see "Review System Requirements and Specifications".

NOTE: When you install the Oracle Fusion Middleware Release 12c software in preparation for upgrade, you should use the same user account that you used to install and configure the Oracle Fusion Middleware 11g software. On UNIX operating systems, this will ensure that the proper owner and group is applied to new Oracle Fusion Middleware 12c files and directories

2.4.3 Verify that the database hosting Oracle Fusion Middleware is supported.

It is imperative that you understand the Oracle Database requirements when upgrading and ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. You must have a supported Oracle database configured with the required schemas before you can run Fusion Middleware 12c.

2.4.4 Verify that the JDK is certified for this release of Oracle Fusion Middleware.

Before you can install any Oracle Fusion Middleware product using a generic installer, you must download and install a supported JDK on your system.

Make sure that the JDK is installed outside of the Oracle home. The Oracle Universal Installer validates that the designated Oracle home directory is empty, and the install will not progress until an empty directory is specified. If you install JDK under Oracle home, you will experience issues in future operations. So, it is recommended that you use the /home/oracle/products/jdk directory for the location of your JDK installation. You can then use the java -jar command to run the installer JAR file.

For more information on the difference between generic and platform-specific installers, "Understanding the Difference Between Generic and Platform-Specific Distributions" in the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files.

To download the required JDK, use your browser to navigate to the following URL and download the Java SE JDK:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

2.5 Migrating from a 32-Bit to a 64-Bit Operating System

Most Oracle Fusion Middleware 12c components require a 64-Bit operating system. If you are running a 32-bit environment, then you must migrate your 32-bit environment to a 64-bit software environment before you upgrade.

Note:

When checking the certification, system requirements, and interoperability information, be sure to check specifically for any 32-bit or 64-bit system requirements. It is important for you to download software specifically designed for the 32-bit or 64-bit environment, explicitly.

Make sure to validate the migration to ensure all your Oracle Fusion Middleware 11g software is working properly on the 64-bit machine, and only then perform the upgrade to Oracle Fusion Middleware 12c.

In these tasks, host refers to the 32-bit source machine and target refers to the new 64-bit target machine.

NOTE: These steps assume that your database is located on a separate host and will not be moved.

Upgrading an operating system typically involves the following:

CAUTION: These steps are provided as an example of the operating system upgrade process and may or may not include all of the procedures you will be required to perform to update your specific operating system. Consult your operating system's upgrade documentation for more information.

2.5.1 Task 1: Procure the hardware that will support your upgrade's 64-bit software requirement.

Make sure that you have supported target hardware in place before you begin the upgrade process.

2.5.2 Task 2: Stop all processes, including the Administration Server, Managed Servers, and Node Manager.

You must stop all processes, including the Administration Server, Managed Servers, and Node Manager, if they are started on the host. For example, to stop the Administration Server:

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2.5.3 Task 3: Back up all files from the 32-bit host machine.

Make sure that you have created a complete backup of your entire 11g deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

Note that if the upgrade from 32-bit to 64-bit takes place on the same machine, there is a risk of corrupting the source environment if the upgrade fails.

For more information on backing up your 11g files, see "Backing Up Your Environment" in the Oracle® Fusion Middleware Administrator's Guide.

During the upgrade you must have access to the contents of the following:

11g Domain Home
11g /nodemanager directory located in MW_HOME/wlserver_10.3/common/

Some of the backup and recovery procedures described in "Backing Up Your Environment" in Oracle® Fusion Middleware Administrator's Guide are product-specific. Do not proceed with the upgrade until you have a complete backup.

2.5.4 Task 4: Set up the target 64-bit machine with the 11g host name and IP address.

The host name and IP address of the target machine must be made identical to the host. This will require you to change the IP address and name of the source machine or decommission the source machine to avoid conflicts in the network.

The process of changing an IP address and host name vary by operating system. Consult your operating system's administration documentation for more information.

2.5.5 Task 5: Restore the 11g domain backup from 32bit Host to 64bit Host.

Restore the files you backed up in Task 3 using the same directory structure that was used in 11g. The directory structure on the target machine must be identical to the structure of the host machine.

For detailed information about restoring your 11g files to the 64-bit target machine, see "Recovering Your Environment" in Oracle® Fusion Middleware Administrator's Guide.

2.5.6 Task 6: Install the 12c (12.2.1) product distribution(s) on the target machine.

For detailed instructions, see Planning an Installation of Oracle Fusion Middleware and the component-specific installation guides for the component(s) you are installing.

2.5.7 Task 7: Upgrade the target 64-bit environment using the standard upgrade procedure.

Refer to your component-specific upgrade guides for details on upgrading the component and performing any post-upgrade tasks. For more information, see the component-specific upgrade guides for the component(s) you are upgrading.

NOTE: The Node Manager upgrade procedure requires access to the original Node Manager files. Use the 11g Node Manger files that were backed up from the source machine as part of Task 3: Back up all files from the 32-bit host machine..

2.6 Creating the Required Schemas Before Upgrade

Before you upgrade, you may be required to create new schemas for your 12c deployment.

To determine which additional schemas need to be created for 12c, compare the component schemas you have in your existing environment to the schemas required for your upgrade. The component-specific upgrade guides will identify the schemas that are required for your components.

For more information, see "Identifying Schemas that Can be Upgraded with the Upgrade Assistant".

If you are upgrading from 11g, note the following:

In 12c there is a new schema that must be created before you can upgrade from 11g. The new Service Table schema (prefix_STB) stores basic schema configuration information that can be accessed and used by other Oracle Fusion Middleware components during domain creation. For more information, see "Understanding the Service Table Schema".

Note:
If you have not created the Service Table schema, you might encounter the error message "UPGAST-00328 : The schema version registry table does not exist on this database." If that happens is it necessary to create the service table schema in order to run Upgrade Assistant.
The audit schema now includes two additional schemas which will also need to be created before running 12c. When upgrading audit services (_IAU), make sure that you select _IAU_APPEND and _IAU_VIEWER in addition to _IAU.

2.7 Purging Unused Data

Purging unused data before an upgrade can optimize the upgrade process. Some components provide automated purge scripts that can be run before an upgrade. If you are using purge scripts, wait until the purge is complete before starting the upgrade process. The upgrade will fail if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas.

NOTE: If a large amount of data needs to be purged, consider partitioning tables or employing other data optimization strategies. Using scripts to remove large amounts of data may impact performance.

For more information, see "Developing a Purging and Partitioning Methodology" and "Developing a Database Growth Management Strategy" in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

2.8 Reassociating File-based Policy Stores to Database-based Policy Stores (Required)

Your policy stores must be database-based and not file based. If you are using a file-based or OID-based policy store, you must reassociate the store to a database-based store prior to upgrade. If you are already using database-based policy store, then you do not have to perform these tasks.

2.8.1 Creating 11g OPSS and IAU Schemas

Create new 11g Oracle Platform Security Services (OPSS) and Audit Schemas (IAU) schemas in a supported Database using the 11g Repository Creation Utility.

For more information about creating 11g schemas, see "Obtaining and Running Repository Creation Utility" in the 11g version of the Oracle Fusion Middleware Repository Creation Utility User's Guide.

2.8.2 Reassociating the 11g Policy Store with the Database-Based Policy Store and OPSS Schema

If you are using a file-based policy store in your 11g environment, then reassociate the file-based store with the database-based repository and OPSS schema.

For information about reassociating the 11g OPSS schema with database-based repository, see "Reassociating the OPSS Security Store".

2.8.3 Validating that the Policy Store Reassociation Worked

To verify that the policy store reassociation worked, complete the following steps:

Log in to Enterprise Manager Fusion Middleware Control.
Navigate to Domain > Security > Security Provider Configuration
Click Configure under the "Audit Service" section of the screen to access the following screen:
The table should now display the entry "Oracle Database" in the "Provider Type" field. If the Provider Type displays "File", the reassociation was not successful.

2.9 Creating the 12c OPSS Schema for an OID-based Security Store

If you are using an Oracle Internet Directory (OID)-based security store in 11g, use the 12c Repository Creation Utility (RCU) to create the new 12c OPSS schema. In the Upgrade Assistant, select the OPSS schema; the Upgrade Assistant upgrades the OID-based security store. You do not need to reassociate an OID-based security store before upgrade.

Note:

The 12c OPSS database schema is required so you can reference the 12c schema during the reconfiguration of the domain. Your domain will continue to use the OID-based security store after the upgrade.

2.10 Upgrading Security Stores to the Latest Version

Before upgrading the OPSS security store, back it up so that it can be recovered in case the upgrade fails. For details about backing up the security store, see Backing Up and Recovering the OPSS Security Store.

The security upgrade procedure varies depending on the type of security store you start from. The security store to be upgraded can be file-, OID-, or DB-based. Note the procedures vary according to the type of source audit data store (file- or DB-based).

2.11 Creating a Non-SYSDBA User

Oracle recommends that you create a user with the privileges required to upgrade the schemas. The privileges listed below must be granted before starting the Upgrade Assistant.

"FMW" is the user you can create to run the Upgrade Assistant. In the example below welcome1 is the password. Make sure that you specify your actual password when granting privileges.

Note:

If you do not already have the v$xatrans$ table, then remove the following line from the script below:

   grant select on v$xatrans$ to FMW with grant option;

This table is not created by default. If you want to create this table, run the XAVIEW.SQL script before creating this user.

create user FMW identified by welcome1;

grant dba to FMW;

grant execute on DBMS_LOB to FMW with grant option;

grant execute on DBMS_OUTPUT to FMW with grant option;

grant execute on DBMS_STATS to FMW with grant option;

grant execute on sys.dbms_aqadm to FMW with grant option;

grant execute on sys.dbms_aqin to FMW with grant option;

grant execute on sys.dbms_aqjms to FMW with grant option;

grant execute on sys.dbms_aq to FMW with grant option;

grant execute on utl_file to FMW with grant option;

grant execute on dbms_lock to FMW with grant option;

grant select on sys.V_$INSTANCE to FMW with grant option;

grant select on sys.GV_$INSTANCE to FMW with grant option;

grant select on sys.V_$SESSION to FMW with grant option;

grant select on sys.GV_$SESSION to FMW with grant option;

grant select on dba_scheduler_jobs to FMW with grant option;

grant select on dba_scheduler_job_run_details to FMW with grant option;

grant select on dba_scheduler_running_jobs to FMW with grant option;

grant select on dba_aq_agents to FMW with grant option;

grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;

grant select on dba_2pc_pending to FMW with grant option;

grant select on dba_pending_transactions to FMW with grant option;

grant execute on DBMS_FLASHBACK to FMW with grant option;

grant execute on dbms_crypto to FMW with grant option;

grant execute on DBMS_REPUTIL to FMW with grant option;

grant execute on dbms_job to FMW with grant option;

grant select on pending_trans$ to FMW with grant option;

grant select on dba_scheduler_job_classes to fmw with grant option;

grant select on SYS.DBA_DATA_FILES to FMW with grant option;

grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;

grant select on v$xatrans$ to FMW with grant option;

grant execute on sys.dbms_system to FMW with grant option;

grant execute on DBMS_SCHEDULER to FMW with grant option;

grant select on dba_data_files to FMW with grant option;

grant execute on UTL_RAW to FMW with grant option;

grant execute on DBMS_XMLDOM to FMW with grant option;

grant execute on DBMS_APPLICATION_INFO to FMW with grant option;

grant execute on DBMS_UTILITY to FMW with grant option;

grant execute on DBMS_SESSION to FMW with grant option;

grant execute on DBMS_METADATA to FMW with grant option;

grant execute on DBMS_XMLGEN to FMW with grant option;

grant execute on DBMS_DATAPUMP to FMW with grant option;

grant execute on DBMS_MVIEW to FMW with grant option;

grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;

Note

Oracle Database 11.2.0.3 Database Users ONLY: You must apply Oracle Patch 13036331 before you begin the upgrade. Go to My Oracle Support to download the patch.

If you do not apply this patch, then you will have to grant additional privileges for some schemas.

2.12 Using Enhanced Encryption (AES 256)

The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code.

Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK. If you plan to use enhanced encryption (such as AES 256), Oracle recommends that you apply these policy files to the JDK before you upgrade. For more information, see the following:

Java Cryptography Architecture Oracle Providers Documentation

If you do not apply these policy files to the JDK before you begin the upgrade, the upgrade can fail and you will have to restore the entire pre-upgrade environment and start the upgrade from the beginning.

2.13 Creating an Edition on the Server for Edition-Based Redefinition (Optional)

For Oracle Database Users Only: Edition-based redefinition enables you to upgrade an Oracle Database component of an application while it is in use, thereby minimizing or eliminating down time.

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 (12.2.1). The new edition for 12.2.1 must be a child of your existing 11g or 12c edition.

To create an edition on the database server, log in as SYS (or another Oracle user that has DBA privileges) and use the following command:

SQL> create edition Oracle_FMW_12_2_1 as child of Oracle_FMW_11_1_1_7_0;
Edition created.

Note that in the code example above, 'Oracle_FMW_11_1_1_7_0' is used as an example of the edition name you specified in RCU 11.1.1.6 or 11.1.1.7 when the 11.1.1.6 or 11.1.1.7 schemas were created. Be sure to provide the actual name used when creating the edition.

During the upgrade procedure, you will be prompted to launch the Reconfiguration Wizard to reconfigure your existing domain. Before running the Reconfiguration Wizard, you must specify the database default edition. Use the following SQL to manually setup the default edition name for the database, for example:

ALTER DATABASE DEFAULT EDITION = edition_name;

2.14 Maintaining Custom Domain Environment Settings

Changes made to the setDomainEnv script - or any other startup script - before an upgrade will be overwritten by new, regenerated scripts during the domain reconfiguration process. Consider creating a separate file to store your domain customizations before you upgrade as described in "Maintaining Your Custom setDomainEnv Settings (Optional)".

Note:

If you are unable to create the setUserOverrides script before an upgrade, you will need to reapply your settings as described in "Reapplying Customizations to setDomainEnv".

2.15 Downloading and Installing the 12c Oracle Fusion Middleware Product Distributions

Product distributions can be downloaded from either Oracle Technology Network (OTN) or Oracle Software Delivery Cloud. For more information on which site you should visit to obtain your distribution, see the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files page.

After you have downloaded all the necessary software, you can then proceed to install and configure your software.

To get started with your installations, refer to the "Install, Patch, and Upgrade" common tasks page in the Oracle Fusion Middleware 12c (12.2.1) Documentation Library on OTN.

NOTE: The Oracle Fusion Middleware Infrastructure distribution must be installed before the component-specific distributions.

2.16 Running a Pre-Upgrade Readiness Check

The Upgrade Assistant can be run in -readiness mode to perform a read-only, pre-upgrade check on your domain. If issues are detected, you can correct them before starting the actual upgrade.

Note:

The readiness check can be run with the system online, and depending on how comprehensive the checks are, the readiness checks could run for a long time before completing.

To perform a readiness check on your pre-upgrade environment, you will launch the Upgrade Assistant in -readiness mode as shown below:

Change directory to ORACLE_HOME/oracle_common/upgrade/bin on Unix operating systems or ORACLE_HOME\oracle_common\upgrade\bin on Windows operating systems.
Enter the following command to start the Upgrade Assistant.

On UNIX operating systems:

./ua -readiness

On Windows operating systems:

ua.bat -readiness

Provide the required information in each of the Upgrade Assistant screens. The screens you see will vary depending on the upgrade options you select. The sections below describe the upgrade options and the information you will need to provide.

2.17 Locating Your Component-Specific Upgrade Documentation

You can now begin your upgrade. Use the following table to determine which upgrade-specific tasks you will need to complete for your 12c upgrade.

Table 2-2 Documentation for Completing Your Upgrade

Product Area	If you are upgrading...	Use this upgrade document...
Oracle WebLogic Server - Standalone	An Oracle WebLogic Server that is not being managed by or registered to an existing Fusion Middleware 11g domain.	Upgrading Oracle WebLogic Server
Custom Oracle Application Developer Framework Applications with Oracle WebLogic Server (referred to as Infrastructure in 12c)	A managed 11g WebLogic Server domain that has been deployed with a set of custom Oracle Application Developer Framework applications.	Upgrading to the Oracle Fusion Middleware Infrastructure
Oracle HTTP Server - Managed or Standalone	An Oracle HTTP Server that is configured to work with a WebLogic domain for management functions is a managed server. An Oracle HTTP Server that is not managed by, or registered to, an Oracle WebLogic domain is a standalone server.	Upgrading Oracle HTTP Server
Oracle SOA Suite and BPM	SOA Suite components including: Business Process Management (BPM), Oracle Service Bus (OSB), Enterprise Security Services (ESS), Managed File Transfer (MFT), Business Activity Monitoring (BAM), and workflow instance data.	Upgrading Oracle SOA Suite and Business Process Management
User Messaging Service	User Messaging Service	Administering Oracle User Messaging Service
Oracle Data Integrator	Data Integrator	Upgrading Oracle Data Integrator