3 Upgrading to SOA Suite and Business Process Management 12c (12.2.1.1)

This section provides the end-to-end procedure for upgrading a single-node, SOA Suite with Business Process Management 11g production installation to SOA Suite with Business Process Management 12c (12.2.1.1).

Note:

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.

Identifying potential upgrade issues in a cloned environment can eliminate unnecessary downtime of your production environment.

3.1 Understanding the SOA Suite and BPM Upgrade Process Flow

This flowchart and the accompanying text describes the high-level steps for upgrading the Oracle Fusion Middleware SOA Suite 11g to 12c (12.2.1.1)

The steps you take to upgrade your existing domain will vary depending on how your domain is configured and which components are being upgraded. Follow only those steps that are applicable to your deployment.

Table 3-1 Task Descriptions for Upgrading Oracle SOA Suite

Description More Information

Required

If you have not done so already, perform all of the required pre-upgrade tasks for the components you are upgrading.

For all required pre-upgrade tasks, see Oracle Fusion Middleware Pre-Upgrade Checklist

For SOA domains that include Oracle BAM, see Performing the Pre-Upgrade Tasks for Oracle BAM

When upgrading Oracle Service Bus (with or without Oracle SOA), see Performing Pre-Upgrade Tasks for Oracle Service Bus (OSB)

Required

You must install Fusion Middleware Infrastructure 12c (12.2.1.1) in a NEW Oracle home on the same host as the 11g production deployment before you begin the upgrade.

In 12c, Oracle home is used to describe the 11g Middleware home.

See Installing the Infrastructure Software

This link will take you to the Installing and Configuring Oracle Fusion Middleware Infrastructure guide.

NOTE: Install but do not use the Configuration Wizard to configure the newly installed domain domain. You will use the Reconfiguration Wizard during the upgrade to configure the existing 11g domain.

Required

Install SOA Suite and Business Process Management 12c (12.2.1.1) and any integrated SOA-integrated distributions (Oracle HTTP Server, Oracle Service Bus, etc) in your newly created Oracle home.

See Installing Oracle SOA Suite and Business Process Management 12c (12.2.1.1)

NOTE: You must install the Fusion Middleware 12c (12.2.1.1) distributions for each SOA-integrated product you are upgrading. For example, if you are upgrading a SOA 11g environment with Oracle Service Bus, you must acquire the Oracle Service Bus 12c (12.2.1.1) distribution as well as the Oracle SOA Suite and BPM 12c (12.2.1.1) distribution.

Required

Shut down the 11g Environment (stop all Administration and Managed Servers).

WARNING: Failure to shut down your servers during an upgrade may lead to data corruption.

See Stopping SOA Servers and Processes

Required

Launch the 12c (12.2.1.1) Repository Creation Utility (RCU) and create the new required 12c schemas.

See Creating the Required SOA Schemas Before You Upgrade from 11g

Required

Run the Upgrade Assistant to upgrade the 11g database schemas and to migrate all active (in flight) instance data.

See Upgrading Schemas Using the Upgrade Assistant

NOTE: The upgrade of active instance data is started automatically when running the Upgrade Assistant. Once the data is successfully upgraded to the new 12.2.1 environment, you can close the Upgrade Assistant. The closed instances will continue to upgrade through a background process.

For more information, see Administering and Monitoring the Upgrade of SOA Instances.

Optional

SOA instances are automatically migrated during the upgrade. You can, however, actively manage and administer the ongoing upgrade of closed instances using the administration SQL scripts or Oracle Fusion Middleware Enterprise Manager Control.

See Administering and Monitoring the Upgrade of SOA Instances.

Required only if Oracle BAM is part of your upgrade.

If the 11g SOA domain that you are upgrading includes Oracle Business Activity Monitoring (BAM), you must complete all of the BAM-specific pre-upgrade tasks before you run the Reconfiguration Wizard. If you do not complete these steps before you attempt to run the Reconfiguration Wizard, then the upgrade will fail.

See Upgrading from Oracle SOA Suite with Oracle Business Activity Monitoring 11g to 12c

NOTE: Business Activity Monitoring (BAM) has been completely redesigned in 12c, and requires additional steps before reconfiguring the domain and after the upgrade.

Required

Run the Reconfiguration Wizard to reconfigure the domain and node manager.

See Reconfiguring the Domain Using the Reconfiguration Wizard

Required

Run the Upgrade Assistant (again) to upgrade domain configurations.

See Upgrading the Domain Component Configurations Using the Upgrade Assistant

Required only if there are tasks that apply to your configurations.

Perform the required post-upgrade configuration tasks (if needed).

See Performing Post Upgrade Tasks

Required

As part of the upgrade verification process, Oracle recommends that you start the new Administration and Managed Servers and node manager to ensure there are no issues.

See Starting and Stopping Servers

Required

As part of the upgrade verification process, Oracle recommends that you ensure all of the upgraded components are working as expected.

See Verifying the Domain Component Configurations Upgrade

3.2 Installing Oracle SOA Suite and Business Process Management 12c (12.2.1.1)

Before you can upgrade your existing SOA and Business Process Management (BPM) components, you must first install the Oracle Fusion Middleware Infrastructure and the Oracle SOA Suite and Business Process Management 12c (12.2.1.1) product distributions.

You will install the 12c (12.2.1.1) product distributions into a new Oracle home directory. Do not use your existing Oracle home directory for the installation.

Verify that you have installed all prerequisite software. Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF). For more information, see Installing the Infrastructure Software

If your SOA domain has other SOA-integrated components, you must install those distributions, as well. See the Oracle Fusion Middleware documentation library for a complete list of installation guides for each product distribution. Be sure to review any of the component-specific chapters in this book to determine if additional pre-upgrade steps for your additional installations.

  1. Log in to the target system.
  2. Go to the directory where you downloaded the installation program.
  3. Launch the installation program by running the java executable from the JDK directory on your system:
    • On UNIX operating systems: /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

    • On Windows operating systems: C:\home\Oracle\Java\jdk1.8.0_77\bin\java -jar <component_name>.jarfmw_12.2.1.0.0_PRODUCT.jar

    For example: cd /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

    Be sure to replace the JDK location in these examples with the actual JDK location on your system.

  4. Follow the instructions described in Navigating the Installation Screens. This link will take you to the Oracle SOA Suite and Business Process Management Installation Guide where you will find installation procedures for all of the supported topologies.
  5. At the end of the installation you will be prompted to start the Configuration Wizard to configure a new domain for 12c (12.2.1.1)

3.3 Creating the Required SOA Schemas Before You Upgrade from 11g

If you are upgrading from a supported 11g release, you may need to create the new 12c required schemas in a supported database before you can upgrade.

Note:

OID-based Security Store Users Only: If you are using an OID-based security store in 11g, you must create the new 12c schema _STB and the _OPSS schema using the Repository Creation Utility (RCU).

You do not need to reassociate an OID-based security store before upgrade. When upgrading schemas with the Upgrade Assistant, select the new OPSS schema and the Upgrade Assistant upgrades the OID-based security store automatically.

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

Table 3-2 Required Schemas for SOA and SOA integrated products

If you are upgrading... Create these 12c schemas before you upgrade

SOA Suite (SOA)

Service Table (_STB)

Audit Services (_IAU)

Business Process Monitoring (BPM)

Service Table (_STB)

Audit Services (_IAU)

Business Activity Monitoring (BAM)

Schemas required for SOA Suite

And:

WebLogic Services (_WLS)

Managed File Transfer (MFT)

Service Table (_STB)

Audit Services (_IAU)

Oracle Service Bus (OSB)

In Oracle Fusion Middleware 11g releases it was possible to run Oracle Service Bus (OSB) without a database, as the SOA schema was not required. In 12c, however, you must have a supported database configured with the required SOA schemas before you can run Oracle Service Bus 12c (12.2.1.1).

SOA Infrastructure (_SOAINFRA)

Service Table (_STB)

User Messaging (_UMS)

NOTE: It is possible to install Oracle Service Bus without running Oracle SOA, but you must create the _SOAINFRA and _STB schemas.

User Messaging Service (UMS)

Service Table (_STB)

Audit Services (_IAU)

To create schemas using the RCU:
  1. Set the JAVA_HOME environment variable and add $JAVA_HOME/bin to $PATH, if you have not done so already. The current supported JDK version is jdk1.8.0_77
  2. Navigate to the 12c ORACLE_HOME/oracle_common/bin directory on your system.
  3. Start RCU:
    On Unix operating systems:

    ./rcu

    On Windows operating systems:

    rcu.bat

  4. Complete the schema creation by navigating the RCU screens. When creating new schemas for the upgrade, make sure to choose Select existing prefix and locate the prefix you used to create your existing schemas.
    NOTE: The Common Infrastructure Services (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.
    .
    For more information, see Navigating the RCU Screens to Create the Schemas in Installing and Configuring the Oracle Fusion Middleware Infrastructure

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

The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments.

If you are using an OID-based security store in 11g, you must create the new 12c schemas using the Repository Creation Utility (RCU).

You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically.

Note:

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

3.4 Running a Pre-Upgrade Readiness Check

The Upgrade Assistant can be run in -readiness mode to identify potential upgrade issues before you perform an actual upgrade.

The readiness check is a read-only operation that scans your existing domain or database schemas and produces a text file with the results of the scan. If your pre-upgrade environment has issues, you can correct those issues and then rerun the readiness check before you upgrade.

By default, the Readiness Check Report file is located in the following Oracle 12c directory: ORACLE_HOME/oracle_common/upgrade/logs

Note:

You can run the readiness check while the system is online. Depending on the comprehensiveness of the checks, the readiness checks can take more time to complete. Oracle recommends that you run the Readiness Check during slower usage periods to prevent performance degradation.
To perform a readiness check on your pre-upgrade environment, launch the Upgrade Assistant in -readiness mode:
  1. Go to the bin directory:

    On UNIX operating systems:

    ORACLE_HOME/oracle_common/upgrade/bin

    On Windows operating systems:

    ORACLE_HOME\oracle_common\upgrade\bin

  2. Enter the following command to start the Upgrade Assistant.

    On UNIX operating systems:

    ./ua -readiness

    On Windows operating systems:

    ua.bat -readiness

    You can also launch the Upgrade Assistant with logging parameters as shown in the UNIX example below:

    ./ua [-logLevel <log_level] [-logDir <log_directory>]

    Logging level. Select one of the following:
    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

    The default logging level is NOTIFICATION.

    When troubleshooting, consider setting the -logLevel to TRACE so that more information will be logged. If additional information is not needed, change the logLevel as the Upgrade Assistant's log files can become very large when -logLevel TRACE is used.

    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 it is necessary to create the service table schema in order to run Upgrade Assistant.

    If this occurs, you will need to create the required 12c schemas with the Repository Creation Utility (RCU).

    Table 3-3 Upgrade Assistant Screens: Readiness Check

    Screen When Screen Appears Description
    Welcome

    Always.

    This screen provides an overview of the readiness check.

    Readiness Check Type:

    • Individually Selected Schemas

    • Domain Based

    Always.

    Readiness checks are only performed on schemas or component configurations that are at a supported upgrade starting point. There are two options to choose from. These options are described below:

    • Use the Individually Selected Schemas option to be able to select the schemas you want to review prior to upgrade.

    • Use the Domain Based option to let the Upgrade Assistant perform a readiness check per domain.

    Available Components

    When Individually Selected Schemas option is selected.

    This screen lists the available components for which the schemas will be selected. If you select something here, readiness check will be performed on that component's schema.

    All Schemas Component List

    Any time a schema readiness check is done.

    This screen is shown any time a schema readiness check is done. This could be when you select Individually Selected Schemas or Domain Based with the Include checks for all schemas option.
    Schema Credentials

    Always.

    Use this screen to enter information required to connect to the selected schema and the database that hosts the schema. If the schema that is to be upgraded was created by RCU in a prior Fusion Middleware release then you will see a drop-down menu listing the possible schema names.

    DBA User Name: Oracle recommends that you run the Upgrade Assistant as FMW and not SYSDBA. If you have not yet created the FMW user, see Creating a Non-SYSDBA User to Run Upgrade Assistant

    Readiness Summary

    Always.

    This screen provides a high-level overview of the readiness checks to be performed based on your selections.

    Click Save Response File if you plan to run the Upgrade Assistant again in -response (or silent) mode.

    Readiness Check

    Always.

    This screen displays the current status of the readiness check. Depending on what you have selected to check, the process can take several minutes.

    For a detailed report, click View Readiness Report. This button appears only after all the readiness checks are complete.

    Caution:

    To prevent performance degradation, consider running the readiness check during off-peak hours.
    Readiness Success

    If the readiness check completes successfully.

    You can now review the complete report.

    If the readiness check encounters an issue or error, review the log file to identify the issues, correct the issues, and then restart the readiness check.

    By default, the Readiness Check Report file is located in the following Oracle 12c directory:

    ORACLE_HOME/oracle_common/upgrade/logs

3.5 Stopping SOA Servers and Processes

Before running Upgrade Assistant, you must shut down ALL Oracle Fusion Middleware Managed Servers, Administration Servers, and system components (such as OHS) that may be using the schemas or configurations you want to update.

Note:

Failure to shut down servers and processes may result in an incomplete or failed upgrade.

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

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
            managed_server_name admin_url  
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd 
            managed_server_name admin_url 

When prompted, enter your user name and password.

Stop SOA servers and processes in this order:

  1. Business Activity Monitoring (BAM) Managed Server

  2. Oracle Service Bus (OSB) Managed Server

  3. Service-Oriented Architecture (SOA) Managed Server

  4. Oracle Web Services Manager (OWSM) Managed Server

  5. Administration Servers

  6. Node Managers

    If you are running Node Manager, you should also stop the Node Manager. You can do this by closing the console window in which Node Manager is running, or by using the stopNodeManager WLST command.

  7. Webtier (including the Oracle HTTP Server)

3.6 Upgrading Schemas with the Upgrade Assistant

Follow these tasks to upgrade your schemas with the Upgrade Assistant.

3.6.1 Generating Log Files During SOAINFRA Schema Upgrade (Recommended)

To facilitate troubleshooting the upgrade, Oracle recommends that you generate log files when upgrading _SOAINFRA schema. Logging is disabled by default.

To enable logging:

  1. Create the soainfra user directory with the name UPGRADE_DIR
  2. Enable debugging logs by calling function set_LogLevel(1) or ALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';

You can also launch the Upgrade Assistant with logging parameters as shown in the UNIX example below:

./ua [-logLevel <log_level>] [-logDir <log_directory>]

3.6.2 Identifying Schemas that Can be Upgraded with the Upgrade Assistant

Review the list of available schemas before you begin the upgrade by querying the schema version registry.

This optional step can be used if you want to manually query the schema_version_registry table before you start the upgrade process. It is important to note that the Upgrade Assistant identifies all schemas that are available for an upgrade and allows you to select the individual schemas you want to upgrade or allow Upgrade Assistant to upgrade all of the schemas in the domain. In addition, when you run the Upgrade Assistant in —readiness mode, you will receive a report with all of the schemas and their current pre-upgrade versions.

If you are using an Oracle database, connect to the database as a user having Oracle DBA privileges, and run the following from SQL*Plus to get the current version numbers:

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

The following report is generated when saved to a SQL script, for example version.sql.

If the number in the "VERSION" is at 11.1.1.7.0 or higher, and the STATUS column is 'VALID', then the schema is supported for upgrade.

If an upgrade is not needed for a schema, the schema_version_registry table retains the schemas at their pre-upgrade version after the upgrade.

Tip:

Compare the information you collect from the schema version registry and the corresponding schemas to determine whether there are schemas in your domain that are not available for an upgrade yet.

Notes about the schemas that need to be upgraded

  • For most components, the only schema version starting points that are valid for upgrading are 11g Release 1 (1.1.1.7.0, 11.1.1.8.0, or 11.1.1.9.0) or 12c (12.1.2, 12.1.3, or 12.2.1.0). If your schemas are not at a supported version, then you must upgrade them before using the 12c (12.2.1.1) upgrade procedures.

    Some components, such as Oracle Enterprise Data Quality and Oracle Golden Gate Veridata, support an upgrade from versions other than the standard Oracle Fusion Middleware supported versions.

    Refer to your component-specific installation and upgrade documentation for additional information about the schemas that are required for your upgrade.

  • If you used an OID-based policy store in 11g, make sure that you create a new 12c (12.2.1.1) OPSS schema before you perform the upgrade. After the upgrade, the OPSS schema will still remain LDAP-based store.

  • You can only upgrade schemas for products that are available for upgrade in the Oracle Fusion Middleware 12c (12.2.1.1) release. Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.1).

3.6.3 Starting the Upgrade Assistant

Start the Upgrade Assistant on the host where Administration Server is running, by doing the following:

  1. On UNIX operating systems:: change directory to ORACLE_HOME/oracle_common/upgrade/bin.

    On Windows operating systems: change directory to ORACLE_HOME\oracle_common\upgrade\bin.

  2. Enter the following command to start the Upgrade Assistant:

    On UNIX operating systems:

    ./ua

    On Windows operating systems:

    ua.bat

    You can also launch the Upgrade Assistant with logging parameters as shown in the UNIX example below:

    ./ua [-logLevel <log_level] [-logDir <log_directory>]

    Logging level. Select one of the following:
    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

    The default logging level is NOTIFICATION.

    Note:

    When troubleshooting, consider setting the -logLevel to TRACE so that more information will be logged. If additional information is not needed, change the logLevel as the Upgrade Assistant's log files can become very large when -logLevel TRACE is used.

3.6.4 Upgrading SOA Schemas with the Upgrade Assistant

Use the Upgrade Assistant to upgrade your supported schemas to 12c (12.2.1.1)

The Upgrade Assistant displays a sequence of screens listed when upgrading schemas. Perform the action(s) for each of the screen.

Table 3-4 Upgrade Assistant Screens: Upgrading Schemas

Screen Description and Action Required

Welcome

This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks.

Schemas

Select Individually Selected Schemas.

Available Components

This screen provides a list of installed Oracle Fusion Middleware components that have schemas that can be upgraded. When you select a component, the schemas and any dependencies are automatically selected.

For example, when Oracle SOA is selected, the Oracle SOA (_SOAINFRA), Audit Services (_IAU), Metadata Service (_MDS), Oracle Platform Security Services(_OPSS), and User Messaging Services (_UMS) schemas will be included in the upgrade.

When Managed File Transfer is selected, Audit Services (_IAU), Enterprise Scheduler (_ESS) and Platform Security Services (OPSS) will be included in the upgrade.

Description of GUID-C60649BE-E01A-4571-982C-090AA493C64B-default.png follows
Description of the illustration GUID-C60649BE-E01A-4571-982C-090AA493C64B-default.png

Domain Directory

This screen appears if you selected Oracle Platform Security Services or Oracle Audit Services on the Available Components screen.

Enter the absolute path to the existing WebLogic domain directory, or click Browse to navigate to and select the domain directory you are upgrading.

Prerequisites

Check that the prerequisites for schema upgrade are met. You must select each prerequisite before you click Next.

CAUTION: Upgrade Assistant will NOT verify that these prerequisites have been met.

Schema Credentials

Use this screen to enter database connection details for each of the schemas you are upgrading.

  1. Select a the database type from the Database Type drop-down menu.

  2. Enter the database connection details, and click Connect.

  3. Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema.

    In some cases, such as _ORASDPM, you will need to manually enter the Schema User Name and password.

    11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. Upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as the _UMS schema.

  4. Click Next.

Notes:

  • The title of Schema Credentials screen varies, depending upon the schemas you are upgrading. For example, if you are upgrading the _SOAINFRA schema, the screen title appears as "SOAINFRA Schema".

  • For information on the fields required to connect to the database, click Help.

Examine

Review the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.

Verify that the Source Version displayed for each schema is listing the correct version number for the schema to be upgraded.

Upgrade Summary

Review the summary of the options that you have selected for schema upgrade. Verify that the correct Source and Target versions are listed for each schema you intend to upgrade.

Click Upgrade to upgrade the schemas, or click Back if you wish to change the configurations.

Upgrade Progress

Review the status of the current upgrade process.

NOTE: The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

Click Next when the upgrade is complete.

Upgrade Success

Click Close if the Upgrade was successful.

If the upgrade failed or if you canceled the upgrade before it completed successfully, you should review the log files, restore the backed up environment, and restart the Upgrade Assistant.

3.6.5 Verifying the Schema Upgrade

Use the following SQL command to verify that the schema version in schema_version_registry has been properly updated.

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

Check that the number in the VERSION column matches the latest version number for that schema. See Schemas That Require an Upgrade to verify that the updated version number is correct for your schema(s).

In the query result, the STATUS field will be either UPGRADING or UPGRADED during the schema patching operation, and will become VALID when the operation is completed.

If the status appears as INVALID, the schema update failed. You should examine the logs files to determine the reason for the failure.

3.6.6 Verifying the Instance Upgrade (if applicable)

If instances were upgraded as part of your schema upgrade, verify that there were no errors with the instances.

  • If the Upgrade Assistant reports that there are no additional instances to be upgraded, then simply close the Upgrade Assistant UI and continue with the remaining upgrade procedures (launching the Reconfiguration Wizard for example).

  • If the Upgrade Assistant reports that there was an error during the instance upgrade, then correct the error(s) and resubmit the database job to complete the upgrade. You can also use the Report Upgrade Summary administration script (Option 1) to check the UPGRADE ERROR COUNT section of the report. For more information, see Resolving Instance Upgrade Errors.

  • If there are still closed instances to be upgraded, then you will be notified that the upgrade of the closed instances will continue in the background after you close the Upgrade Assistant. Do not close the Upgrade Assistant until UA reports it is finished and you see the following:

    Oracle SOA
    1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
    2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
    Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management. 
    

3.6.7 Checking for Invalid Database Objects

If you are using an Oracle database, you should recompile database objects after running the Upgrade Assistant by connecting to the database as SYS and running the following from SQL*Plus:

SQL>@?/rdbms/admin/utlrp.sql

This will compile the database objects that were upgraded by Upgrade Assistant.

Then issue the following query to ensure there are no longer any invalid database objects:

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

None of the database objects for the upgraded schema should be invalid at this point. If there are any, run the utlrp.sql command again and check again. If the problem persists, you should file a service request.

3.6.8 Upgrading Partitioned Schema Tables from 11g

If you are upgrading an Oracle SOA 11g installation that includes schemas partitioned as described in the Oracle SOA Suite 11g Administration Guide, and you want to continue with this specific table partitioning strategy in SOA 12c (12.2.1.1), then you must complete these required steps to upgrade your partitioned schema tables.

Note:

This procedure is required only if you plan to use the existing Oracle SOA 11g table partitioning strategy in your upgraded 12c environment. If you are upgrading from a previous 12c release, you will not need to complete this procedure.

Understanding the Upgrade of Partitioned Schema Tables

Oracle SOA Suite 12c introduces a new set of Fabric tables on which the equi-partitioning strategy is based. The procedure described below enables you to align the existing 11g strategy with the new 12c Fabric tables without rebuilding the dependent Service Engine tables like BPEL, for example. The partition alignment will model the new Fabric 12c table partitions against the now obsolete 11g COMPOSITE_INSTANCE partitions (which all other/existing partitions should already be aligned). The new 12c Fabric Table that will drive the equi-partitoning strategy is called "SCA_FLOW_INSTANCE".

Before You Begin

Review the following to understand how the upgrade may impact your deployment:
  • To align the new SOA 12c Fabric tables, dummy/empty RANGE partitions will be added which are modeled on the now obsolete 11g composite_instance table. This means that approximately 10 new Fabric tables will be recreated into partitioned tables.

  • You can convert RANGE partitioning to INTERVAL-RANGE partitioning during this process as Oracle Fusion Middleware SOA Suite 12c now supports both.

    You can chose to continue with RANGE partitioning or convert to INTERVAL-RANGE partitioning as part of this process. An INTERVAL-RANGE table can house both RANGE and INTERVAL-RANGE partitions with the first partition always being a RANGE partition (called a transition point). Note that when the tables are converted to INTERVAL-RANGE , there will still be the existing RANGE partitions until new INTERVAL-RANGE partitions are automatically allocated.

  • The 11g SOA strategy did not provide any recommendations on the use of a MAXVALUE partitions. If you choose to convert to INTERVAL-RANGE partitioning and the MAXVALUE partition is not empty, then the table will need to be rebuilt. However, if the MAXVALUE partition is empty then it will just be dropped as part of the conversion to INTERVAL-RANGE. However, if the MAXVALUE partition is empty, then it will be dropped as part of the conversion. ( INTERVAL-RANGE partitioning does not allow a MAXVALUE partition as partitions are automatically allocated.)

  • The process involves the use of the TRS (Table Recreation Scripts) utility. You will be required to edit some of the generated scripts. The editing is required to correct the DDL syntax, as the generated DDL can vary between installations and RDBMS versions or may have been customized.

  • The verification scripts in 12.2.1.1 are upgrade-aware and consider the instances in both the 12c sca_flow_instance and 11g composite_instance tables.

Note:

Oracle recommends that you create a complete backup of the schemas and database before starting this process. Oracle also recommends that you execute this procedure in a test environment before attempting in production (including the verification scripts).

Process Overview

The upgrade of partitioned schema tables happens in two phases:

Phase 1: Generate the DDL script.

  • Correct partition keys

  • Honor any DDL changes

  • Partition new 12c Fabric tables

    Creates Dummy RANGE partitions modeled against “composite_instance”

  • Handle MAXVALUE partition (if interval required)

Phase 2: Edit and run the DDL script.

  • Edit the DDL script.

  • Execute DDL script.

  • Check Log files.

Phase 1: Generating the DDL Script

  1. As SYSDBA, create TRS_DIR and grant read, write to <soainfra>..
    SQL > create directory TRS_DIR as ‘/../../..’;
    SQL>  grant read,write on directory TRS_DIR to <soainfra>
    
  2. Enable debug mode.

    ALTER PROCEDURE debug_purge  COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' ║ REUSE SETTINGS; 
    ALTER PROCEDURE log_info COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' REUSE  ║  SETTINGS;
     
    
  3. Navigate to the following directory:
    12C_mwhome/soa/common/sql/soainfra/sql/oracle/122110/trs12/ 
    
  4. Edit trs_migrate_exec.sql for any changes you require. The table below describes the parameters and available options:
    Parameter Options
    range_interval R (range) or I (interval)
    interval_clause  'NUMTOYMINTERVAL(1, ''MONTH'')‘
    Specified by SQL conversion functions
    • NUMTODSINTERVAL converts n to an INTERVAL DAY TO SECOND literal.

    • NUMTOYMINTERVAL converts number n to an INTERVAL YEAR TO MONTH literal.

    partition G (group1 or 2) or P (partial)

    Identifies 11g partitioning strategy

    drop_flag Drop original tables; true, false
    redo_flag Generate redo; true false
    DOP Degree of parallel
    sql_trace SQL Trace; true, false

    If true, ensure the soainfra user has been granted "alter session" privilege.

    The following shows a sample code snippet. Make sure to provide your own parameter options.
    set echo on;
    set serverout on;
    DECLARE
    range_interval  varchar2(1)  := 'I';
    interval_clause varchar2(40) := 'NUMTOYMINTERVAL(1, ''MONTH'')';
    partition       varchar2(1)  := 'G';
    drop_flag       boolean      := true;
    redo_flag       boolean      := false;
    DOP             number       := 0;
    sql_trace       boolean      := false;
    BEGIN
     trs_mig.trs_migrate (range_interval, interval_clause, partition, drop_flag,
       redo_flag, DOP, sql_trace);
    END;
    /
    
  5. Run trs_migrate_exec.sql to generate the DDL script.

Phase 2: Editing and Executing the DDL Script

Once the DDL script has been generated, you will need to edit the script before executing it.
  1. Open the generated DDL script and search for comments about the COMPOSITE_INSTANCE partitions. You must update the DDL of each the new Fabric table and add these partitions wherever these comments are found.
    CREATE TABLE "PART_SOAINFRA"."SCA_FLOW_INSTANCE_M"
       (    "FLOW_ID" NUMBER(*,0),
            "FLOW_CORRELATION_ID" VARCHAR2(100),
     ….
      TABLESPACE "DEV12_SOAINFRA" ;    <REMOVE SEMICOLON
    /*                                 <REMOVE COMMENTS (if any)                                                         
    REM The RANGE partitions are based on COMPOSITE_INSTANCE
    REM    INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
    REM    (PARTITION p0 VALUES LESS THAN (TO_DATE('2007-02-01', 'YYYY-MM-DD')),
    REM    (PARTITION p1 VALUES LESS THAN (TO_DATE('2007-03-01', 'YYYY-MM-DD')));
    */
    PARTITION BY RANGE (CREATED_TIME)
    INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
    (
    PARTITION P0 VALUES LESS THAN (TO_DATE(TIMESTAMP' 2007-02-01 00:00:00' ,'YYYY-MM-DD')),,    <REMOVE TIMESTAMP, 00:00:00 and LAST COMMA
                                                    
    
    The edited script should look like this:
    CREATE TABLE "PART_SOAINFRA"."SCA_FLOW_INSTANCE_M"
       (    "FLOW_ID" NUMBER(*,0),
            "FLOW_CORRELATION_ID" VARCHAR2(100),
     ….
      TABLESPACE "DEV12_SOAINFRA" 
    PARTITION BY RANGE (CREATED_TIME)
    INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
    (
    PARTITION P0 VALUES LESS THAN (TO_DATE('2007-02-01' ,'YYYY-MM-DD')),
    PARTITION P1 VALUES LESS THAN (TO_DATE('2007-03-01' ,'YYYY-MM-DD')));
    
    .
  2. Run/test the edited DDL script in a test environment first.
  3. Check the log in TRS_DIR for errors.
  4. Test verification scripts.

3.7 Reconfiguring the Domain Using the Reconfiguration Wizard

After upgrading the schemas, run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c.

When you use the Reconfiguration Wizard to reconfigure a WebLogic Server domain, the following items are automatically updated, depending on the applications in the domain:

  • WLS core infrastructure

  • Domain version

Note:

The Reconfiguration Wizard does not update any of your own applications that are included in the domain.
Specifically, when you reconfigure a domain the following occurs:
  • The domain version number in the config.xml file for the domain is updated to the Administration Server's installed WebLogic Server version.

  • Reconfiguration templates for all installed Oracle products are automatically selected and applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version.

  • Start scripts are updated.

Note:

Once the domain reconfiguration process starts, it is irreversible. Prior to running the Reconfiguration Wizard, ensure that you have backed up the domain as described in Backing Up the Domain. If an error or other interruption occurs while running the Reconfiguration Wizard, you must restore the domain by copying the files and directories from the backup location to the original domain directory. This is the only way to ensure that the domain has been returned to its original state prior to reconfiguration.
Follow these instructions to reconfigure the existing domain using the Reconfiguration Wizard. For general information about how the domain is reconfigured, see Reconfiguring WebLogic Domains.

3.7.1 Backing Up the Domain

Prior to running the Reconfiguration Wizard, make a backup copy of the domain directory:

  1. Copy the source domain to a separate location to preserve the contents.
    For example, copy C:\domains\mydomain to C:\domains\mydomain_backup.
  2. Prior to updating the domain on each remote Managed Server, make a backup copy of the domain directory on each remote machine.
  3. Verify that the backed up versions of the domain are complete.
If domain reconfiguration fails for any reason, you must copy all files and directories from the backup directory into the original domain directory to ensure that the domain is returned entirely to its original state prior to reconfiguration.

3.7.2 Starting the Reconfiguration Wizard

Start the Reconfiguration Wizard in graphical mode by doing the following:

  1. Log in to the system on which the domain resides.
  2. Open the command shell (on UNIX operating systems) or open a command prompt window (on Windows operating systems).
  3. Edition Based Database Users Only: If your schemas are configured with EBR database, a default edition name must be manually supplied before you run the Reconfiguration Wizard.

    Run the following SQL command to set the default edition:

    ALTER DATABASE DEFAULT EDITION = edition_name;
    

    where edition_name is the name of the child edition name.

  4. Go to the following directory:

    (UNIX Operating Systems) ORACLE_HOME/oracle_common/common/bin

    (Windows Operating Systems) ORACLE_HOME\oracle_common\common\bin

    where ORACLE_HOME is your 12c Oracle home directory.

  5. Execute the following command:

    (UNIX Operating Systems) ./reconfig.sh -log=log_file -log_priority=ALL

    (Windows Operating Systems) reconfig.cmd -log=log_file -log_priority=ALL

    where log_file is the absolute path of the log file you'd like to create for the domain reconfiguration session. This can be helpful if you need to troubleshoot the reconfiguration process..

    The parameter -log_priority=ALL ensures that logs are logged in fine mode.

    Note:

    When you run reconfig.cmd or reconfig.sh, the following error message might display to indicate that the default cache directory is not valid:

    *sys-package-mgr*: can't create package cache dir
    

    You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

3.7.3 Reconfiguring the Domain

Note that you may not see every screen listed below. In addition, you may need to complete additional screens based on your environment setup. For more information, see Reconfiguring WebLogic Domains.

Table 3-5 Reconfiguration Wizard Screens

Reconfiguration Wizard Screen Description and Action Required
Select Domain

Enter the absolute path to the existing domain directory, or click Browse to navigate to and select the domain directory.

Reconfiguration Setup Progress

Shows the progress of applying the reconfiguration templates.

Domain Mode and JDK

Domain mode cannot be changed.

Select the JDK to use in the domain or click Browse to navigate to the JDK you want to use.

Note that Oracle Fusion Middleware 12c requires Java SE 7. For more information, see Verifying Certification and System Requirements.

Database Configuration Type

Use the RCU Data option to connect to the Server Table (_STB) schema. The Repository Creation Utility (RCU) will automatically use service table schema to load the other 12c schema credentials automatically. Always verify the data on the JDBC screens that follow.

NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created by 12c RCU, the default connection data will be retrieved from the _STB schema. If no connection data for a given schema is found in the _STB schema, then the default connection data is used.

JDBC Data Sources

This screen is displayed if you created custom data sources for a database-based OPSS security store or Audit Data store in 11g.

Use this screen to configure the JDBC data sources defined in your domain source.

JDBC Data Sources Test

Test the data source connections you configured on the JDBC Data Sources screen.

JDBC Component Schema

Specify the data source settings for each of the schemas listed on the screen, by selecting the check box adjacent to each schema name.

You must specify the 11g schema details for the schemas that you just upgraded. For the others, specify the 12.2.1.1 schema details.

JDBC Component Schema Test

Test the configurations that you specified for the data sources in the previous screen. Select the check boxes adjacent to the names of the schemas to test, and click Test Selected Connections.

The result of the test is indicated in the Status column. Click Next when the test is successful for all the schemas.

Node Manager

This screen is displayed only if the domain you are reconfiguring is currently using a per-host Node Manager. Use this screen to select the Node Manager configuration to use for the reconfigured domain. The resulting configuration depends on the combination of options you select for Node Manager Type and Node Manager Configuration.

Advanced Configuration

The categories that are listed on this screen depend on the resources defined in the templates you selected for the domain during domain configuration.

For example, when the SOA Suite and BPM template is being applied to the domain, select the Managed Servers, Clusters and Coherence if one or more of the following applies:

  • You have more than one managed server in a single domain (soa_server1 and bam_server1, for example)

  • You need to modify cluster or coherence data

For information on using the other advanced configuration options, such as Node Manager, Deployments and Services, Domain Front End Host Capture and JMS File Store, see the online help.

Managed Servers

You must specify the actual hostname for the Listen Address for each managed server in your domain.

Do not use the default localhost or All Local Addresses option.

You must specify the actual hostname as hostname.company.com

When upgrading from 12.1.3 to 12.2.1.1, you must assign the server to the appropriate Server Groups. See Targeting Server Groups Using the Reconfiguration Wizard

Assign Servers to Machines

If you have created servers as part of the upgrade process, then select the server name in the Servers list box and target them to the correct Node Manager Machine.

Otherwise, no action is required on this screen when you are upgrading or reconfiguring the domain.

Assign Servers to Clusters

Cluster Upgrades Only: If you are upgrading clusters, use this screen to assign Managed Servers to clusters.

Note that only Managed Servers are displayed in the Server list box. The Administration Server is not listed because it cannot be assigned to a cluster.

Note:

SOA UPGRADES ONLY: When OWSMPM is in its own cluster and not part of SOA or OSB clusters, you should target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster, target only OSB-MGD-SVRS-ONLY to the OSB cluster and target WSMPM-MAN-SVER server group to OWSM . When upgrading 12.1.3 to 12.2.11, you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

Configuration Summary

Review the configuration summary.

Click Reconfig to reconfigure the domain, or click Back to change the configurations.

Reconfiguration Progress

Review the reconfiguration progress. Click Next when the process is complete.

Reconfiguration Success

Review the final status of the reconfiguration process. Click Finish to exit the Reconfiguration Wizard.

3.8 Upgrading the Domain Component Configurations Using the Upgrade Assistant

Use the Upgrade Assistant to update any remaining WebLogic component configurations within the domain.

Follow the instructions in the following sections to upgrade any additional domain component configurations using the Upgrade Assistant.

Note:

Do not start the Administration Server before launching the Upgrade Assistant.

3.8.1 Starting the Upgrade Assistant in Graphical User Interface (GUI) Mode

The Upgrade Assistant is used to upgrade schemas, component configurations and standalone system components.

Oracle recommends that you successfully complete the upgrade of schemas and component configurations for a single domain before beginning the upgrade of another domain.

Note:

The Upgrade Assistant should be run by a non-SYSDBA user whenever possible. The steps to create a user who has the privileges required to upgrade the schemas are described in Creating a Non-SYSDBA User.
To start the Upgrade Assistant:
  1. On UNIX operating systems:: change directory to ORACLE_HOME/oracle_common/upgrade/bin.

    On Windows operating systems: change directory to ORACLE_HOME\oracle_common\upgrade\bin.

  2. Enter the following command to start the Upgrade Assistant:

    On UNIX operating systems:

    ./ua

    On Windows operating systems:

    ua.bat

    You can also launch the Upgrade Assistant with logging parameters as shown in the UNIX example below:

    ./ua [-logLevel <log_level] [-logDir <log_directory>]

    Logging level. Select one of the following:
    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

    The default logging level is NOTIFICATION.

    Note:

    When troubleshooting, consider setting the -logLevel to TRACE so that more information will be logged. If additional information is not needed, change the logLevel as the Upgrade Assistant's log files can become very large when -logLevel TRACE is used.

3.8.2 Upgrading SOA Component Configurations

Describes the screens of the Upgrade Assistant when upgrading WebLogic Component Configurations.

NOTE: The screens you see are based on your environment. You may or may not see all of the screens described below. For more information on using the Upgrade Assistant screens, see the online help.

Note:

Additional configuration tasks may be required.

After the Upgrade Assistant has successfully completes the upgrade of your schemas and component configurations, you may need to perform the tasks described in Performing Post Upgrade Tasks to ensure that your components continue to function as expected.

Table 3-6 Upgrade Assistant Screens: Upgrading WebLogic Component Configurations

Screen Description and Action Required

Welcome

This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks.

Click Next to continue.

WebLogic Components

Select the All Configurations Used by a Domain option to upgrade component configurations for a managed WebLogic Server domain. You must enter the domain directory for the domain that you are upgrading now.

Click Next.

OWSM Policy Manager

This screen is displayed if your 11g environment has multiple WebLogic Server domains, but the OWSM Policy Manager is only in one WLS domain and the OWSM agents are in other domains.

Provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

For information about the fields on this page, click Help, or refer to OWSM Policy Manager.

Component List

This screen provides a list of components that will be included in the domain component configuration upgrade.

Prerequisites

Check if the prerequisites for component configurations upgrade are met.

CAUTION: The Upgrade Assistant will not validate that these prerequisites have been performed.

UMS Configuration

This screen is presented if there are remote managed servers hosting UMS 11g configuration files. You must provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

NOTE: You may be required to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See Upgrade Assistant: Copying UMS Configuration Files.

Examine

Review the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.

Upgrade Summary

Review the summary of the options that you have selected for schema upgrade.

Click Upgrade to upgrade the schemas, or click Back if you wish to change the configurations.

Upgrade Progress

Review the status of the upgrade process.

Click Next when the upgrade is complete.

Upgrade Success

Click Close if the Upgrade was successful.

If the upgrade failed or if you canceled the upgrade before it completed successfully, you should review the log files, restore the backed up environment, and restart the Upgrade Assistant.

3.9 Managing Your Upgraded Oracle Fusion Middleware 12c Software

Table 3-7 lists some common administration tasks you will likely want to perform after upgrading. In addition, the component-specific administration guides may provide additional configuration tasks to perform after an upgrade.

Table 3-7 Basic Administration Tasks

Task Description More Information

Performing additional post-upgrade configuration steps for your component.

In addition to the post-upgrade tasks described Performing Post Upgrade Tasks, you may also need to perform additional configuration tasks to ensure your newly upgraded components function as expected.

Getting familiar with Fusion Middleware administration tools

Get familiar with the various tools available which you can use to manage your environment.

Overview of Oracle Fusion Middleware Administration Tools

Configuring Secure Sockets Layer (SSL)

Learn how to set up secure communications among between Oracle Fusion Middleware components using SSL.

Configuring SSL in Oracle Fusion Middleware

Monitoring Oracle Fusion Middleware

Learn how to keep track of the status of Oracle Fusion Middleware components.

Monitoring Oracle Fusion Middleware