1. Upgrading SOA Suite and Business Process Management
  2. Oracle Fusion Middleware Pre-Upgrade Tasks

2 Oracle Fusion Middleware Pre-Upgrade Tasks

Before you start the upgrade process be sure to complete the required pre-upgrade tasks for your components and environment.

The required pre-upgrade tasks must be completed before you start the upgrade. Failure to complete the required tasks may result in a failed upgrade or extended system downtime. Complete only those tasks that apply to your deployment.

Note:

Depending on which Oracle SOA products are being upgraded, you may need to perform additional pre-upgrade tasks. Products such as Oracle Service Bus and User Messaging Service may require additional pre- and post-upgrade configuration tasks.

Oracle Fusion Middleware Pre-Upgrade Checklist

Perform the tasks in this checklist before you begin any upgrade to ensure you have a successful upgrade and limited downtime.

Upgrades are performed while the servers are down. This checklist identifies important and often time-consuming pre-upgrade tasks that you can perform before the upgrade to limit your downtime. The more preparation you can do before you begin the upgrade process, the less time you will spend offline.

Note:

The pre-upgrade procedures you perform will 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. Complete only those tasks that apply to your configurations or use cases.

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

Task Description

Required

Create a complete backup of your existing environment.

Back up all system-critical files and database(s) that contain any schemas that are to be upgraded. If the upgrade fails, you must restore your pre-upgrade environment and begin the upgrade again.

See Creating a Complete Backup.

Optional

Create additional backup files for an online recovery operation.

If the upgrade fails, and you will need to perform an online recovery, Oracle recommends that you generate additional back up files to facilitate the recovery.

Optional

Clone your production environment to use as an upgrade testing platform.

In addition to creating a complete backup of your system files, Oracle strongly recommends that you clone your production environment. This environment can be used to test the upgrade.

See Cloning Your Production Environment for Testing.

Required

Verify that you are installing and upgrading your product on a supported hardware and software configuration.

Caution:

Do not attempt an upgrade if you are unable to use the latest supported operating system. As with all supported configurations, failure to comply with these requirements may cause your upgrade to fail.

Verify that your hardware and software configurations (including operating systems) are supported by the latest certifications and requirements documents. Also make sure to use a supported JDK version before you install the 12c product distributions.

Oracle recommends that you verify this information right before you start the upgrade as the certification requirements are frequently updated.

Note:

Make sure that you have applied the latest patches to your components before you upgrade.

See Verifying Certification and System Requirements.

Required for 32–bit Operating Systems Only

Migrate to a 64-bit operating system before you can upgrade.

This is required only if you are currently running an unsupported 32–bit operating system.

See Migrating from a 32-Bit to a 64-Bit Operating System.

Optional

Update security policy files if you are using enhanced encryption (AES 256).

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 the latest required policy files to the JDK before you upgrade.

See Updating Policy Files when Using Enhanced Encryption (AES 256).

Optional

Purge any outdated or unused data before you upgrade.

To optimize performance, Oracle strongly recommends that you purge data and objects that will not be used in the upgraded environment.

See Purging Unused Data.

Required for Oracle Database 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 (12.2.1.3.0).

If you are using an Edition-Based Redefinition (EBR) database, you must create the edition before starting the upgrade.

See Creating an Edition on the Server for Edition-Based Redefinition.

Optional

Create a Non-SYSDBA user to run the Upgrade Assistant.

Oracle recommends that you create the FMW user to run Upgrade Assistant. User FMW can run the Upgrade Assistant without system administration privileges.

See Creating a Non-SYSDBA User to Run the Upgrade Assistant

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Creating a Complete Backup

Before you start an upgrade, back up all system-critical files, including the databases that host your Oracle Fusion Middleware schemas.

The backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table so that you can restore the contents back to its pre-upgrade state if the upgrade fails.

The Upgrade Assistant Prerequisites screen prompts you to acknowledge that backups have been performed before you proceed with the actual upgrade. However, note that the Upgrade Assistant does not verify that a backup has been created.

See:
  • Backing Up the Schema Version Registry Table
    Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table or the FMWREGISTRY.SCHEMA_VERSION_REGISTRY$ table.
  • Maintaining Customized Domain and Environment Settings
    If you have modified any domain-generated, server startup scripts, or configuration files in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations. Save your customized files to a shared library location so that you can continue to use them after the upgrade.

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Backing Up the Schema Version Registry Table

Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table or the FMWREGISTRY.SCHEMA_VERSION_REGISTRY$ table.

Each Fusion Middleware schema has a row in the SYSTEM.SCHEMA_VERSION_REGISTRY$ table. If you run the Upgrade Assistant to update an existing schema and it does not succeed, you must restore the original schema before you can try again. Before you run the Upgrade Assistant, make sure you back up your existing database schemas and the schema version registry.

Note:

Before you upgrade a schema using the Upgrade Assistant, you must perform a complete database backup. During the upgrade, you are required to acknowledge that backups have been performed.

Parent topic: Creating a Complete Backup

Maintaining Customized Domain and Environment Settings

If you have modified any domain-generated, server startup scripts, or configuration files in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations. Save your customized files to a shared library location so that you can continue to use them after the upgrade.

Every domain installation includes dynamically-generated domain and server startup scripts, such as setDomainEnv. These files are replaced by newer versions during the installation and upgrade process. To maintain your custom domain-level environment settings, Oracle recommends that you create a separate file to store the custom domain information before you upgrade, instead of modifying the scripts directly.

For example, if you want to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.cmd (Windows) or setUserOverrides.sh (UNIX) and configure it to add custom libraries to the WebLogic Server classpath, specify additional command-line options for running the servers, or specify additional environment variables. When using the pack and unpack commands, any custom settings that you add to this file are preserved during the domain upgrade operation and are carried over to the remote servers.

The following example illustrates startup customizations in a setUserOverrides file:
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command-line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

If the setUserOverrides file exists during a server startup, the file is included in the startup sequence and any overrides contained within this file take effect. You must store the setUserOverrides file in the EXISTING_DOMAIN_HOME/bin directory.

Note:

If you are unable to create the setUserOverrides script before an upgrade, you need to reapply your settings as described in Re-apply Customizations to Startup Scripts in Oracle Fusion Middleware Upgrading Oracle WebLogic Server.

Parent topic: Creating a Complete Backup

Special Considerations for Online Backup and Recovery

Perform these additional backup tasks if your environment includes multiple middleware homes, and performing a full database restore after an upgrade failure is not a desirable option.

Understanding the Impact of a Full Database Restore

It is important that you understand the impact of a full database restore when creating your backup and recovery plan. If your upgrade fails, you may be required to perform a complete database restore. However, in some cases this may not be possible or desirable.

  • Is your database shared by production environments that must remain online when a single FMW home is being upgraded?

  • Does your database need to remain online when recovering from a failed upgrade?

  • Is performing a full database restore an undesirable solution for recovering from a failed upgrade?

If you answered ‘yes’ to any of the following questions, then complete these additional pre-upgrade tasks before you begin:

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Saving Grants on SYS Owned Objects

In the event of an upgrade failure, all grants to SYS owned objects will be lost when the schema is dropped. Oracle recommends that you create a script that can be used to re-apply the grants if necessary.

An example of how to create this script is shown below.  Please note the following about the generated SQL script:  
  • The spooled output will need to be edited before it can be executed by SQLPlus, the text of the SQL queries and the "spool off" command need to be removed from the spooled file.
  • Some of the grants may return errors when being applied after a drop/import of a schema.  Some instances where this is not a fatal error are:
    - The grant already exists
    - The name of the grant object is dynamically generated when the schema is created. For example, advanced queueing views are named QTnnnnnnnn_BUFFER.
Sample SQLPlus commands to create a script for re-applying grants:
# The schema prefix in this example is "DEV"
$ORACLE_HOME/bin/sqlplus username/password
exec dbms_metadata.set_transform_param(dbms_metadata.SESSION_TRANSFORM,'SQLTERMINATOR',TRUE); 
set long 100000
set longchunksize 100000
set lines 1000
set termout off echo off newp 0 spa 0 pages 0 feed off head off trims on tab off
spool /tmp/create-grants.sql
select dbms_metadata.get_granted_ddl ('OBJECT_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('SYSTEM_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('DEFAULT_ROLE',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS');
spool off

Parent topic: Special Considerations for Online Backup and Recovery

Exporting Schemas Before You Upgrade

Use data pump export to backup the schemas that will be upgraded.

For information on using data pump, see Oracle Data Pump in Oracle Database Utilities guide.
The following example shows a sample export:
# The schema prefix in this example is "DEV"
# The schemas being exported are for the SOA, BPM and ESS environments
$ORACLE_HOME/bin/sqlplus username/password
create directory data_pump_directory as '/scratch/db12cr2/export';
 
expdp username/password schemas=DEV_STB,DEV_SOAINFRA,DEV_IAU_VIEWER,DEV_MDS,DEV_IAU_APPEND,DEV_WLS,DEV_UMS,DEV_OPSS,DEV_IAU,DEV_ESS directory=data_pump_directory dumpfile=export.dmp compression=ALL

Parent topic: Special Considerations for Online Backup and Recovery

Identifying Queue States Before an Upgrade

In the event of a an upgrade failure, the queues must be manually restarted. Take inventory of these queues to assist in restarting them.

The restoration of a single schema will not restart any queues that are imported. You will need to restart all of the enabled queues. The following example shows the SQL commands that can be used to generate a list of the queues that would need to be restarted in the event of a failed upgrade. Provide the correct schema prefix for each schema owner.
set pagesize 20;
set linesize 200;
COLUMN OWNER FORMAT A50
COLUMN NAME FORMAT A50
select owner,name,enqueue_enabled,dequeue_enabled from dba_queues where owner='DEV_SOAINFRA';

Parent topic: Special Considerations for Online Backup and Recovery

Cloning Your Production Environment for Testing

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.

Cloning your production environment for testing is recommended, but not required.

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:

It is beyond the scope of this document to describe the cloning procedures for all components and operating systems. Cloning procedures are component and operating system-specific. At a high level, you install the pre-upgrade version of your component domain on a test machine, create the required schemas using the Repository Creation Utility (RCU), and perform the upgrade.
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, and so on).

Note:

You can run the pre-upgrade Readiness Check on the cloned production environment to help identify potential upgrade issues with your data, but you must perform a complete test upgrade on a cloned environment to ensure a successful upgrade.

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Verifying Certification and System Requirements

Review the certification matrix and system requirements documents 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.

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Verify Your Environment Meets Certification Requirements

Oracle has tested and verified the performance of your product on all certified systems and environments. Make sure that you are installing your product on a supported hardware or software configuration.

Whenever new certifications occur, they are added to the appropriate 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. See the Certification Matrix for 12c (12.2.1.3.0).

Parent topic: Verifying Certification and System Requirements

Verify System Requirements and Specifications

It is important to verify that the system requirements such as disk space, available memory, specific platform packages and patches, and other operating system-specific items are met.

Use the Oracle Fusion Middleware System Requirements and Specifications document to verify that the requirements of the certification are met. For example, if the Certification Matrix for 12c (12.2.1.3.0) indicates that your product is certified for installation on 64-Bit Oracle Linux 7, the System Requirements and Specifications document should be used to verify that your Oracle Linux 7 system has met the required minimum specifications such as 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 on the Oracle Technology Network (OTN).

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 existing, pre-upgrade Oracle Fusion Middleware software. On UNIX operating systems, this ensures that the proper owner and group is applied to new Oracle Fusion Middleware 12c files and directories.

If you are running a 32–bit environment, you will need to perform an additional set of steps:

Parent topic: Verifying Certification and System Requirements

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

If you have a 32–bit operating system, then you must migrate your 32-bit environment to a 64-bit software environment before you upgrade.

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

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 must perform to update your specific operating system. Consult your operating system's upgrade documentation for more information.

Parent topic: Verify System Requirements and Specifications

Procure the Hardware That Supports the Upgrade's 64-bit Software Requirement

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

Stop All Processes

Before upgrading, you must stop all processes, including Managed Servers, the Administration Server, and Node Manager, if they are started on the host.

Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

  • (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

  • (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Stop 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, use the stopWebLogic script:

  • (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

  • (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Stop Node Manager

To stop Node Manager, close the command shell 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. See stopNodeManager in WLST Command Reference for WebLogic Server.

Back Up All Files from the 32-bit Host Machine

Make sure that you have created a complete backup of your entire 12c (12.2.1.2.0) 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:

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.

See Backing Up Your Environment in Oracle Fusion Middleware Administrator's Guide.

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

  • 12c_DOMAIN_HOME

  • 12c/nodemanager directory located in 12c_ORACLE_HOME/wlserver/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.

Set Up the Target 64-bit Machine with the 12c (12.2.1.2.0) Host Name and IP Address

The host name and IP address of the target machine must be made identical to the host. This requires 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.

Restore the 12c (12.2.1.2.0) Backup from 32-bit Host to 64-bit Host

Restore the files you backed from the 32-bit host using the same directory structure that was used in 12c (12.2.1.2.0). The directory structure on the target machine must be identical to the structure of the host machine.

See Recovering Your Environment in Oracle Fusion Middleware Administrator's Guide.

Install the 12c (12.2.1.3.0) Product Distributions on the Target Machine

Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 12c (12.2.1.3.0) product distributions in a new Oracle home on the target machine.

Refer to the component-specific installation guides for the component(s) you are installing.

Upgrade the Target 64-bit Environment Using the Standard Upgrade Procedure

After installing the product on the target machine, you must upgrade each product component individually using an Upgrade Utility specified in the component-specific upgrade guide and complete any post-upgrade tasks.

If you are upgrading additional components, see the component-specific upgrade guide.

Note:

The Node Manager upgrade procedure requires access to the original Node Manager files. Use the 11g Node Manger files that you backed up from the 32-bit source machine as part of Back Up All Files from the 32-bit Host Machine.

Verify That the Database Hosting Oracle Fusion Middleware is Supported

You must have a supported Oracle database configured with the required schemas before you run Oracle Fusion Middleware 12c (12.2.1.3.0).

Review the Fusion Middleware database requirements before starting the upgrade to ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. See the Certification Matrix for 12c (12.2.1.3.0).

Note:

If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade. See Upgrading and Preparing Your Oracle Databases for 12c (12.2.1.3.0) in Planning an Upgrade of Oracle Fusion Middleware.

Parent topic: Verifying Certification and System Requirements

Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware

At the time this document was published, the certified JDK for 12c (12.2.1.3.0) was 1.8.0_131.

Refer to the Oracle Fusion Middleware Supported System Configurations information on the Oracle Technology Network (OTN) to verify that the JDK you are using is supported.

If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK, from the following website:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

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 does not progress until an empty directory is specified. If you install JDK under Oracle home, you may experience issues in future operations. Therefore, Oracle recommends that you use install the JDK in the following directory: /home/oracle/products/jdk.

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

Parent topic: Verifying Certification and System Requirements

Updating Policy Files when Using Enhanced Encryption (AES 256)

If you plan to use enhanced encryption, such as Advanced Encryption Standard (AES) 256, in your upgraded environment, Oracle recommends that you apply the latest required policy files to the JDK before you upgrade.

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. See Java Cryptography Architecture Oracle Providers Documentation.

Note:

If you attempt to use enhanced encryption without applying these policy files to the JDK before you begin the upgrade, the upgrade can fail and you must restore the entire pre-upgrade environment and start the upgrade from the beginning.

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Purging Unused Data

Purging unused data and maintaining a purging methodology before an upgrade can optimize the upgrade process.

Some components have automated purge scripts. If you are using purge scripts, wait until the purge is complete before starting the upgrade process. The upgrade may fail if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas.

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Creating an Edition on the Server for Edition-Based Redefinition

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.

Edition-based redefinition enables you to upgrade an application's database objects while the application is in use, thus minimizing or eliminating downtime. This is accomplished by changing (redefining) database objects in a private environment known as an edition. Only when all the changes have been made and tested, you make the new version of the application available to users.

Note:

This task must be completed by an Oracle Database User with DBA privileges.

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 11g or 12c edition.

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

create edition Oracle_FMW_12_2_1_1 as child of Oracle_FMW_11_1_1_7_0;

where Oracle_FMW_11_1_1_7_0 is an example of the edition name you specified in RCU 11.1.1.7 when the 11.1.1.7 schemas were created. Be sure to provide the actual name used when creating the edition.

The following message notifies you that the edition is created successfully:

Edition created.

During the upgrade, you are 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 command to manually set up the default edition name for the database, for example:

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1_1;

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Creating a Non-SYSDBA User to Run the Upgrade Assistant

Oracle recommends that you create a non-SYSDBA user called FMW to run the Upgrade Assistant. This user has the privileges required to modify schemas, but does not have full administrator privileges.

SYSDBA is an administrative privilege that is required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for a fully empowered database administrator. When you connect with the SYSDBA privilege, you connect with a default schema and not with the schema that is generally associated with your user name. For SYSDBA, this schema is SYS. Access to a default schema can be a very powerful privilege. For example, when you connect as user SYS, you have unlimited privileges on data dictionary tables. Therefore, Oracle recommends that you create a non-SYSDBA user to upgrade the schemas. The privileges listed below must be granted to user FMW before starting the Upgrade Assistant.

Notes:

The non-SYSDBA user FMW is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW user. Note that privileges required for running the Upgrade Assistant may change from release to release. 
By default, the v$xatrans$ table does not exist. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, the grant select privilege on thev$xatrans$ table is required only by Oracle Identity Governance. If you do not require Oracle Identity Governance for configuration, or if you do not have the v$xatrans$ table, then remove the following line from the script: 
   grant select on v$xatrans$ to FMW with grant option;
In the example below, password is the password that you set for the FMW user. When granting privileges, make sure that you specify your actual password.
create user FMW identified by password;
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_TABLESPACE_USAGE_METRICS 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;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

If you are upgrading Oracle Identity Manager (OIM) schema, ensure that the FMW user has the following additional privileges:

grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Performing SOA-Specific Pre-Upgrade Tasks

In addition to the Oracle Fusion Middleware pre-upgrade requirements, you may also be required to complete additional SOA-specific upgrade tasks depending on your pre-upgrade environment.

Review the pre-upgrade tasks that apply to the SOA, Business Process Management and integrated products. Perform only those tasks that apply to your environment.

Caution:

Failure to properly prepare for an upgrade may lead to unrecoverable errors and upgrade failures. Make sure that you have completed all applicable pre-upgrade tasks before beginning the upgrade.

Pre-Upgrade Task More Information

Required

Verify that your environment meets the Oracle Database requirements for upgrading to Oracle SOA Suite and BPM 12c (12.2.1.3.0)

Upgrading and Preparing the Fusion Middleware Database for a SOA Suite Upgrade

Required

Verify that your tablespaces are sized appropriately (insufficient sizing will result in a failed upgrade).

Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces
SOA Composer Users Only: Note that uncommitted changes are not available after upgrade. Committing SOA Composer Changes Before Upgrade
Required only if you are upgrading from a previous 12c release.

Delete the existing cloudsdk deployment from the domain before upgrade.

 Deleting the cloudsdk Application when Upgrading from a Previous 12c Release

Required only if upgrading User Messaging Service (UMS)

Complete the required pre-upgrade tasks for User Messaging Service (UMS) if you are upgrading UMS as part of your SOA Suite upgrade.

Performing Pre-Upgrade Tasks for User Messaging Service (UMS)

Required only if upgrading Oracle Service Bus (OSB)

Complete the required pre-upgrade tasks for Oracle Service Bus (OSB) if you are upgrading OSB as part of your SOA Suite upgrade.

Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)

Optional

Upgrade your standalone Oracle HTTP Server. This can be done before or after the upgrade.

Upgrading a Standalone Oracle HTTP Server

Parent topic: Oracle Fusion Middleware Pre-Upgrade Tasks

Upgrading and Preparing the Fusion Middleware Database for a SOA Suite Upgrade

You must have a supported database configured with the required schemas before you can run Fusion Middleware 12c (12.2.1.3.0).

It is imperative that you understand the Oracle Database requirements for upgrading to Oracle SOA Suite and BPM 12c (12.2.1.3.0), and ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. You must have a supported database configured with the required schemas before you can run Fusion Middleware 12c (12.2.1.3.0). Always refer to the latest database certification matrix for the most current information.

As part of the Fusion Middleware pre-upgrade process, you verified that your database is supported. However it is important to note that when installing or identifying a database to use with Oracle SOA Suite, there are additional considerations, including the size and profile of the database and its ability to store data for large numbers of Oracle SOA Suite composite applications. For more information, see the following resources:

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces

Oracle recommends that you add more data files to the existing SOA database tablespace to prevent a failed upgrade.

While important for all tablespaces, it is especially important to make sure that the 11g SOAINFRA tablespace and IAS_TEMP tablespace are sized for a successful upgrade.

Note:

Once a database schema upgrade has failed due to a sizing error, you cannot simply add more disk space and retry the upgrade. The schemas have been left in an inconsistent state and may have been marked "INVALID". You cannot recover from this error without restoring the original, pre-upgrade environment from backups.

Two sample commands are provided below. Size the files according to your own use case scenarios.

To add datafiles to SOAINFRA tablespace:

Connect to the database as sysdba and run the following command: 

alter tablespace <PREFIX>_SOAINFRA add datafile '<DB_HOME>/oradata/orcl/<New_SoaInfra_DBF_FileName>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

To add tempfiles to IAS_TEMP tablespace:

Connect to the database as sysdba and run the following command:

alter tablespace PREFIX_IAS_TEMP add tempfile '<DB_HOME>/oradata/orcl/<New_iastemp_dbf_filename>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

For more information on sizing your tablespaces before upgrade, see Creating Datafiles and Adding Datafiles to a Tablespace.

Committing SOA Composer Changes Before Upgrade

If you do not commit or rollback your changes to the SOA Composer sandbox before you upgrade, your changes may not be propagated to the new environment.

Before you start the upgrade, make sure that you have committed or rolled back any changes that you do or do not want propagated to the upgraded environment.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Upgrading Custom Applications Using Oracle JDeveloper 12c

If you have deployed custom applications to a SOA 11g domain, then the application deployments should function as they did in Oracle Fusion Middleware 11g after the upgrade procedure is complete.

If you want to take advantage of new Oracle 12c features, download and install the Oracle SOA Suite or Oracle Business Process Management Quick Start for Developers.

The Quick Start for Developers distributions provide Oracle JDeveloper 12c users with the required extensions for developing Oracle SOA Suite and Oracle Business Process Management applications.

For more information, see Installing Oracle SOA Suite Quick Start for Developers.

Note:

Oracle QuickStart is required if you want to use new Oracle SOA 12c features.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Deleting the cloudsdk Application when Upgrading from a Previous 12c Release

If you installed cloudsdk in your pre-upgrade environment, you must delete it before starting the upgrade.

This step is required only if cloudsdk was deployed in a previous 12c release.

The 12c (12.2.1.3.0) version of cloudsdk is automatically deployed on the servers and could conflict with the previously deployed application due to a change in the naming conventions.
  1. Login into the Oracle WebLogic console.
    Enter the URL in your Web browser. For example:

    http://host1.example.com:7001/em

    Enter the Oracle Fusion Middleware administrator user name and password and click Login.

  2. Click Deployments from the Domain Configuration panel of the console.
    (Optional) Enter the result of the step only if necessary. Do not state the obvious results. Tasks should be as concise as possible.
  3. Click the Control tab.
  4. Select cloudsdk and click Stop - Force stop now.
  5. Click Configuration.
  6. Select cloudsdk and click Delete.
  7. Click on Release configuration.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Performing Pre-Upgrade Tasks for User Messaging Service (UMS)

Complete the required pre-upgrade tasks for User Messaging Service (UMS) if you are upgrading UMS as part of your SOA Suite upgrade.

If you are Upgrading User Messaging Service from 11g to 12c, you may need to perform additional pre-upgrade tasks such as manually copying the configuration files from the managed server to the Admin server. If you are upgrading UMS from a previous 12c release, then you will not have to perform this task again.

For more information, see Upgrading User Messaging Service.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)

You must complete the required pre-upgrade tasks for Oracle Service Bus (OSB) if you are upgrading OSB as part of your SOA Suite upgrade.

If you are upgrading a SOA domain with Oracle Service Bus, you must preform several required pre-upgrade tasks. See Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB).

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Upgrading a Standalone Oracle HTTP Server

If you are upgrading a standalone Oracle HTTP Server, then you should follow the instructions in Upgrading Oracle HTTP Server.

This optional step can be performed before or after the upgrade.

To upgrade a standalone Oracle HTTP Server instance (one that is not associated with an 11g domain) or to upgrade the HTTP server at another time, refer to Upgrading Oracle HTTP Server.

Note:

Managed Oracle HTTP Servers, those that are associated with an existing domain, are upgraded automatically during the Infrastructure upgrade process. You do not have to upgrade your managed HTTP Server separately.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks

Wires Missing After Migrating SOA Composite

Wires that connect services and references may be missing from composite after an upgrade from 11g. You must apply a patch to correct this issue.

After you upgrade from 11g, you may notice that the wires that connect services and references may be missing from composite. This issue is caused when the 11g JDev version of the SCA project migrator is higher than the new 12c version. To fix this, you must apply a patch to modify the 11g SCA project migrator version.

To apply the patch, go to https://support.oracle.com and search for Doc ID 2356254.1.

Note:

In most cases the 11g SCA project migrator will have a lower version number than the newly installed 12c migrator and this issue will not occur.

Parent topic: Performing SOA-Specific Pre-Upgrade Tasks