2 Oracle Fusion Middleware Pre-Upgrade Tasks
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 can be performed 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 14c (14.1.2.0.0)
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. |
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 14c (14.1.2.0.0) 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. |
Optional Update security policy files if you are using enhanced encryption (AES 256). |
Some of the security algorithms used in Fusion Middleware 14c (14.1.2.0.0) 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 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. |
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 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.
-
Backing Up Your Environment in Administering Oracle Fusion Middleware
-
Upgrading and Preparing Your Oracle Databases for 14c (14.1.2.0.0) in Planning an Upgrade of Oracle Fusion Middleware
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.
Note:
This step is only required for managed or collocated domains. Standalone domains will not have this 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.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.
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 Upgrading Oracle WebLogic Server.
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:
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.
# 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
Exporting Schemas Before You Upgrade
Use data pump export to backup the schemas that will be upgraded.
# 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
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.
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';
Verifying Certification and System Requirements
Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation. You may be required to upgrade your operating system, hardware or other software packages.
Note:
When checking the certification, system requirements, and interoperability information, be sure to check specifically for any operating system requirements. It is important for you to download software specifically designed for your operating system 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.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 14c (14.1.2.0.0).
Verify System Requirements and Specifications
It is important to use both the System Requirements and Specifications document and the Oracle Fusion Middleware Certification Matrix 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 Oracle Fusion Middleware Certification matrix are met. For example, if the Certification Matrix indicates that your product is certified for installation on 64-Bit Oracle Linux 8, the System Requirements and Specifications document should be used to verify that your Oracle Linux 8 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:
Do not attempt an upgrade if you are unable to meet the minimum system requirements.
- Processor Requirements
- Java Development Kit (JDK) Requirements
- General Memory and Disk Space Requirements
- Product-Specific Memory and Disk Space Requirements
- Network Requirements
- UNIX Operating System Requirements
- Windows Operating Systems Requirements
- Virtualization Requirements
- Database Requirements
What if my operating system is not supported?
If you are running your environment on an unsupported operating system, you will need to create a supported environment before you begin your upgrade. Do not attempt an upgrade on an unsupported operating system.
Use the migration steps for your environment.
Migrating a Managed Domain from an Unsupported Operating System
If you are currently running your managed or collocated Oracle Fusion Middleware domain on an unsupported operating system, then you must migrate your existing environment to a supported operating system before you upgrade.
After the migration, validate that all of your existing Oracle Fusion Middleware 12c (12.2.1.4.0) software is working properly on the updated machine, and only then perform the upgrade to Oracle Fusion Middleware 14c (14.1.2.0.0).
In these tasks, host refers to the existing unsupported source machine and target refers to the new supported target machine.
Note:
These steps assume that your database is located on a separate host and will not be moved.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.Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.
An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the correct order.
Note:
The procedures in this section describe how to stop the existing, pre-upgrade servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Remote Console. See Starting and Stopping Administration and Managed Servers and Node Manager.
As of release 14c (14.1.2.0.0), the WebLogic Server Administration Console has been removed. For comparable functionality, you should use the WebLogic Remote Console. For more information, see Oracle WebLogic Remote Console.
Note:
It is important that you stop the following servers in the correct order.
Step 1: Stop System Components
To stop system components, such as Oracle HTTP Server, use the stopComponent
script:
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
-
(Windows)
EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name
You can stop system components in any order.
Step 2: Stop Any 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 SOA servers and processes in this order:
-
Business Activity Monitoring (BAM) Managed Server
-
Oracle Service Bus (OSB) Managed Server
-
Service-Oriented Architecture (SOA) Managed Server
-
Oracle Web Services Manager (OWSM) Managed Server
Step 3: Stop the Administration Server
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.
Step 4: Stop Node Manager
To stop Node Manager, close the command shell in which it is running.
Alternatively, after setting 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 Oracle WebLogic Server.
Back Up All Files from the Host Machine
Make sure that you have created a complete backup of your entire 12c (12.2.1.4.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 operating system upgrade takes place on the same machine, there is a risk of corrupting the source environment if the upgrade fails.For general information about creating a complete backup of your existing environment, 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 in12c_ORACLE_HOME/wlserver/common/
The following steps explain how to use the pack command to create a domain template jar file. This is only one method that can be used to create a backup. Consult your own backup and recovery plans to choose the backup method that best suits your deployment.
- Pack the domain that was created on the unsupported host using the
pack command as
follows:
cd ORACLE_HOME/oracle_common/common/bin/
./pack.sh -domain=/scratch/username/<product>_12214/user_projects/domains/base_domain -template=/scratch/<product>.jar - template_author=<user_name> -template_name=<product>_domain
- Copy the domain template jar file that you just created to the new
supported host.
Do not unpack the jar file. At this stage you are just copying the file to a temporary location on the new host until it is time to unpack the domain into the new 14.1.2 Oracle Home. To simplify the unpack process, consider recreating the exact same directory structure that you used in your 12.2.1.4 domain. This will ensure that the file is not overwritten.
Note:
Do not proceed with the upgrade until you have a complete backup.
Set Up the Target Machine with the 12c 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.
Copy the Contents of the Domain Template to the New Target Host
Unpack the contents of the generated domain template jar file on the target host. The directory structure on the target machine must be identical to the structure of the host machine.
- On the target machine, navigate to the new Oracle home.
cd 1412_ORACLE_HOME/oracle_common/common/bin/
- Use the unpack command to copy the files to the new
target:
./unpack.sh -domain=/scratch/<username>/<product>_12214/user_projects/domains/base_domain -template=/scratch/<product>.jar -user_name=weblogic -password=<enter your password>
Install the 14c (14.1.2.0.0) Product Distributions on the Target Machine
Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 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 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 12c (12.2.1.4.0) Node Manger files that you backed up from the source 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 14c (14.1.2.0.0).
Note:
If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade.Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware
If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK before you begin.
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.
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
.
Verify the Database User for the WLSSchemaDataSource Data Source
This step is required if your existing domain has a
WLSSchemaDataSource
data source.
If your domain has the WLSSchemaDataSource
data source, then you
will need to verify which database user is assigned to it. If
<PREFIX>_WLS_RUNTIME
is assigned to it, then you need
to change that to <PREFIX>_WLS
.
- The 14c (14.1.2.0.0) Upgrade
Assistant uses the information in the
WLSSchemaDataSource
data source,when a domain-based schema upgrade is performed. That upgrade will fail if the<PREFIX>_WLS
database user is not assigned to theWLSSchemaDataSource
, or if<PREFIX>_WLS
is not entered as the "Schema User Name" on the "WLS Schema" page of the Upgrade Assistant. - Oracle recommends that you use the 12c Oracle WebLogic
Administration Console to change the database user to
<PREFIX>_WLS
in theWLSSchemaDataSource
data source. Doing this will avoid the Upgrade Assistant failure, and also allow the Reconfiguration Wizard to pre-populate fields with the correct values. - The
<PREFIX>_WLS_RUNTIME
database user is reserved for use with a newWLSRuntimeSchemaDataSource
, which was introduced in 14c (14.1.2.0.0). This newWLSRuntimeSchemaDataSource
will be created when the 14c (14.1.2.0.0) Reconfiguration Wizard (reconfig.sh) is used to upgrade the domain.
<PREFIX>_WLS_RUNTIME
to
<PREFIX>_WLS
.
- Log in the 12c (12.2.1.4.0) Administration Console.
- In the administration console under Domain Structure, expand Services (by clicking the + next to it). Then click Data Sources.
- If the user in Properties field contains
<PREFIX>_WLS_RUNTIME
, change it to<PREFIX>_WLS
. - Save the change.
- Use the Change Center to commit the change, if your domain is running in production mode.
Cloning Your Source Environment for Testing
Create a copy of your source environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your environment.
Cloning your source environment for testing is recommended, but not required.
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.-
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 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.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 14c (14.1.2.0.0) 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.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.
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.Note:
In this example we are using the nameFMW
for our non-SYSDBA administrator. Substitute
FMW
with your admin name.
CREATE USER FMW IDENTIFIED BY "<FMW password>";
GRANT pdb_dba TO FMW;
GRANT MANAGE SCHEDULER TO FMW;
GRANT USE ON EDITION ORA$BASE TO FMW WITH GRANT OPTION;
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_aq 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 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_job 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 EXECUTE ON SYS.DBMS_ASSERT 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 dba_objects TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_queue_subscribers TO FMW WITH GRANT OPTION;
GRANT SELECT ON dba_subscr_registrations TO FMW WITH GRANT OPTION;
GRANT EXECUTE ON DBMS_RLS TO FMW WITH GRANT OPTION;
GRANT READ ON CTXSYS.CTX_PENDING TO FMW WITH GRANT OPTION;
GRANT SELECT ON SYS.V_$PARAMETER TO FMW WITH GRANT OPTION;
GRANT CREATE PROCEDURE TO FMW;
GRANT SELECT ON dba_users TO FMW WITH GRANT OPTION;
GRANT ALL ON sys.v_$parameter TO FMW WITH GRANT OPTION;
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 14c (14.1.2.0.0) |
Upgrading and Preparing the Fusion Middleware Database for a SOA Suite Upgrade |
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 |
Optional Upgrade your standalone Oracle HTTP Server. This can be done before or after the upgrade. |
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 14c (14.1.2.0.0).
It is imperative that you understand the Oracle Database requirements for upgrading to Oracle SOA Suite and BPM 14c (14.1.2.0.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 14c (14.1.2.0.0). Always refer to the latest database certification matrix for the most current information.
-
About the Database Profile Custom Variable in Installing and Configuring Oracle SOA Suite and Business Process Management
-
Introduction to SOA Composite Applicationand Identifying the Profile or Size of the Database in Administering Oracle SOA Suite and Oracle Business Process Management Suite
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.
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 14c (14.1.2.0.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.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).
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.
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.