Oracle® Fusion Middleware

Upgrading SOA Suite and Business Process Management

12c (12.2.1.2)

E77900-03

December 2016

This guide provides instructions for upgrading and redeploying your Oracle SOA Suite and Business Process Management 11g or 12c applications to Oracle SOA Suite 12c (12.2.1.2).

Oracle Fusion Middleware Upgrading SOA Suite and Business Process Management, 12c (12.2.1.2)

E77900-03

Copyright © 2013, 2016, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Lisa Jamen

Contributors: Jay Kasi, Robert Donat, Vamsee Goruganthu, Subramanian Hariharan, Suresh Krishnaswamy, William Norcott, Renga Rengarajan, Michael Rubino, Sitaraman Swaminathan

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

- Audience

- Conventions

- Related Documents

1 Introduction to Oracle SOA Suite and Business Process Management Upgrade

- 1.1 Understanding the Oracle SOA Suite and Business Process Management Upgrade to 12c (12.2.1.2)

- 1.2 Understanding the Starting Points for a SOA Suite 12c (12.2.1.2) Upgrade

- 1.3 Understanding the Interoperability and Compatibility Restrictions Before You Upgrade

- 1.4 Understanding SOA Domain Upgrade Restrictions

- 1.5 Understanding the Standard SOA Upgrade Topologies

- 1.6 Understanding How to Use this Guide for Your Upgrade

2 Oracle Fusion Middleware Pre-Upgrade Tasks

- 2.1 Oracle Fusion Middleware Pre-Upgrade Checklist

- 2.2 Creating a Complete Backup

- 2.2.1 Backing Up the Schema Version Registry Table

- 2.2.2 Maintaining Custom Domain Environment Settings

- 2.3 Cloning Your Production Environment for Testing

- 2.4 Verifying Certification and System Requirements

- 2.4.1 Verify Your Environment Meets Certification Requirements

- 2.4.2 Verify System Requirements and Specifications

- 2.4.3 Verify That the Database Hosting Oracle Fusion Middleware Is Supported

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

- 2.5 Updating Policy Files when Using Enhanced Encryption (AES 256)

- 2.6 Purging Unused Data

- 2.7 Creating an Edition on the Server for Edition-Based Redefinition

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

- 2.9 Identifying Existing Schemas Available for Upgrade

- 2.10 Performing SOA-Specific Pre-Upgrade Tasks

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

- 2.10.1.1 Adding Datafiles to the SOAINFRA and IAS_TEMP Tablespaces

- 2.10.2 Committing SOA Composer Changes Before Upgrade

- 2.10.3 Upgrading Custom Applications Using Oracle JDeveloper 12c

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

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

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

- 2.10.7 Upgrading a Standalone Oracle HTTP Server

3 Upgrading SOA Suite and Business Process Management from 11g

- 3.1 About the SOA Suite and BPM Upgrade Process Flow

- 3.2 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

- 3.3 Creating the Required 12c Schemas with the RCU

- 3.4 Running a Pre-Upgrade Readiness Check

- 3.4.1 About Running a Pre-Upgrade Readiness Check

- 3.4.2 Starting the Upgrade Assistant in Readiness Mode

- 3.4.2.1 Upgrade Assistant Parameters

- 3.4.3 Performing a Readiness Check with the Upgrade Assistant

- 3.4.4 Understanding the Readiness Report

- 3.5 Stopping Servers and Processes

- 3.6 Upgrading Schemas with the Upgrade Assistant

- 3.6.1 Upgrading Product Schemas

- 3.6.1.1 Starting the Upgrade Assistant

- 3.6.1.1.1 Upgrade Assistant Parameters

- 3.6.1.2 Upgrading SOA Schemas Using the Upgrade Assistant

- 3.6.1.3 Verifying the Schema Upgrade

- 3.6.2 Upgrading Partitioned Schema Tables from 11g

- 3.7 Reconfiguring the Domain

- 3.7.1 Backing Up the Domain

- 3.7.2 Starting the Reconfiguration Wizard

- 3.7.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

- 3.8 Upgrading Domain Component Configurations

- 3.8.1 Starting the Upgrade Assistant

- 3.8.1.1 Upgrade Assistant Parameters

- 3.8.2 Upgrading Domain Components Using the Upgrade Assistant

4 Upgrading Oracle Service Bus (without Oracle SOA Suite) from 11g

- 4.1 Understanding the Oracle Service Bus Standalone Upgrade to 12c

- 4.2 Upgrade Limitations for Oracle Service Bus 12c (12.2.1.2)

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

- 4.3.1 Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

- 4.3.2 Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

- 4.3.3 Deleting All Services, Projects and Resources

- 4.3.4 Migrating Oracle Service Bus Resources from Previous Releases

- 4.4 Installing Oracle Service Bus

- 4.5 Creating the Required 12c Schemas with the RCU

- 4.6 Stopping Servers and Processes

- 4.7 Upgrading an Oracle Service Bus Domain (without SOA)

- 4.7.1 Starting the Upgrade Assistant

- 4.7.1.1 Upgrade Assistant Parameters

- 4.8 Reconfiguring the Domain

- 4.8.1 Backing Up the Domain

- 4.8.2 Starting the Reconfiguration Wizard

- 4.8.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

- 4.9 Upgrading Domain Component Configurations

- 4.9.1 Starting the Upgrade Assistant

- 4.9.1.1 Upgrade Assistant Parameters

- 4.9.2 Upgrading Domain Components Using the Upgrade Assistant

- 4.10 Performing Post Upgrade Tasks for Oracle Service Bus

- 4.10.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- 4.10.2 Importing Domain Configuration Data

- 4.10.3 Importing Security Configurations

- 4.10.4 Upgrading Your XQuery Resources

- 4.10.5 Understanding 12c Split-Joins

- 4.11 Troubleshooting Oracle Service Bus Upgrade

- 4.11.1 Resolving the HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host

- 4.11.2 Resolving the HTTP 404 Error When Accessing OSB Console

5 Upgrading Oracle SOA Suite with Oracle Business Activity Monitoring from 11g

- 5.1 Understanding an Upgrade to Business Activity Monitoring 12c (12.2.1.2)

- 5.2 Understanding the SOA with Oracle BAM 11g Upgrade Process Flow

- 5.3 Performing the Pre-Upgrade Tasks for Oracle BAM

- 5.3.1 Creating a New Oracle BAM 11g Domain Before You Upgrade

- 5.3.2 Exporting All Oracle BAM 11g Artifacts from the Existing Domain

- 5.3.3 Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

- 5.3.4 Creating a Complete Backup of the Oracle BAM 11g Domain

- 5.4 Upgrading a SOA with Oracle BAM Domain to 12c

- 5.4.1 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

- 5.4.2 Creating the Required 12c Schemas with the RCU

- 5.4.3 Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas

- 5.4.4 Stopping Servers and Processes

- 5.4.5 Running the Upgrade Assistant to Upgrade Schemas

- 5.4.5.1 Upgrading Product Schemas

- 5.4.5.1.1 Starting the Upgrade Assistant

- 5.4.5.1.2 Upgrading SOA Schemas Using the Upgrade Assistant

- 5.4.5.1.3 Verifying the Schema Upgrade

- 5.4.6 Reconfiguring the 11g Domain with the Reconfiguration Wizard

- 5.4.6.1 Reconfiguring the Domain

- 5.4.6.1.1 Backing Up the Domain

- 5.4.6.1.2 Starting the Reconfiguration Wizard

- 5.4.6.1.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

- 5.4.7 Running the Upgrade Assistant to Upgrade Component Configurations

- 5.4.7.1 Upgrading Domain Component Configurations

- 5.4.7.1.1 Starting the Upgrade Assistant

- 5.4.7.1.2 Upgrading Domain Components Using the Upgrade Assistant

- 5.5 Performing Post Upgrade Configuration Tasks for Oracle SOA with Oracle BAM 12c

- 5.5.1 Starting the Admininstration (Admin) Server

- 5.5.2 Launching the WebLogic Server Administration 12c Console

- 5.5.3 Deleting the UMS JMS Resources Running on the Oracle BAM Server or Oracle BAM Cluster

- 5.5.4 Deleting Subdeployment Resources Targeted to UMS JMS Server Targeted to Oracle BAM

- 5.5.5 Removing the Oracle BAM Servers and Clusters from the Domain

- 5.5.6 Removing Unnecessary Oracle BAM 11g Files from the Upgraded Domain

- 5.5.7 For Cluster Upgrades Only: Stop the Admin and Managed Servers

- 5.5.7.1 Stop the Admin Server and SOA Managed Server(s)

- 5.5.8 For Cluster Upgrades Only: Run the Pack Command where the Admin Server and Managed Servers are Installed

- 5.5.9 For Cluster Upgrades Only: Run the Unpack Command to Replicate the Domain Configuration of SOAHOST1 on SOAHOST2.

- 5.5.10 Restarting the Admin Server

- 5.5.11 Configuring 11g Oracle BAM Adapter to Work With SOA 12c Domain

- 5.5.12 Restarting the SOA Managed Servers

- 5.5.13 Deleting the Existing UMS Email Driver from the SOA Domain

- 5.6 Extending the SOA Domain with Oracle BAM 12c

- 5.6.1 Stop the Admin Server and SOA Managed Server(s)

- 5.6.2 Extend the SOA 12c Domain with Oracle BAM 12c Domain Template

- 5.6.3 Create the New UMS Email Driver for the Oracle BAM Server

- 5.6.4 Import the Oracle BAM 11g data objects and EMS data to the BAM 12c server.

- 5.6.5 Manually recreate the 11g BAM dashboards, alerts, and other artifacts for use in the BAM 12c domain.

- 5.6.6 Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

- 5.6.6.1 Task 1: Disable the Process Metrics.

- 5.6.6.2 Task 2: Determing the exportType to be used for the migration.

- 5.6.6.3 Task 3: (UNIX Only) Run migrateBPMProcessCubes script from the 12c SOA home.

- 5.6.6.4 Task 4: (Windows Only) Export data object definitions and data from 11g BPM Process Cubes and then import them to 12c.

- 5.6.6.5 Task 5: (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server.

- 5.6.6.6 Task 6: (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server.

- 5.6.6.7 Task 7: (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server.

- 5.6.6.8 Task 8: Restart the Oracle BAM server once the migration has completed successfully.

- 5.6.6.9 Task 9: Enable the process metrics while the Oracle BAM server is running.

- 5.6.7 Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional)

- 5.6.7.1 Disable the Process Metrics.

- 5.6.7.2 Run the Oracle BAM migration utility to migrate the Monitor Express data.

- 5.6.7.3 Import the BPM data to Oracle BAM 12c.

- 5.6.7.4 Enable publishing to BAM 12c.

- 5.6.8 Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)

- 5.6.8.1 Task 1: Update the classpath to include the interface JAR file.

- 5.6.8.2 Task 2: Recreate Standard Views

- 5.6.8.3 Task 3: Recreate Process-Specific Views

- 5.7 Recovering from a Failed Oracle BAM Upgrade

- 5.7.1 Resolving the CFGFWK-60950 Error

- 5.7.2 Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration

- 5.7.3 Error Handling for UNIX Operating Systems

- 5.7.4 Error Handling for Windows Operating Systems

6 Upgrading Oracle SOA Suite and Business Process Management from a Previous 12c Release

- 6.1 Understanding an Upgrade from a Previous 12c Release

- 6.2 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

- 6.3 Running a Pre-Upgrade Readiness Check

- 6.3.1 About Running a Pre-Upgrade Readiness Check

- 6.3.2 Starting the Upgrade Assistant in Readiness Mode

- 6.3.2.1 Upgrade Assistant Parameters

- 6.3.3 Performing a Readiness Check with the Upgrade Assistant

- 6.3.4 Understanding the Readiness Report

- 6.4 Stopping Servers and Processes

- 6.5 Upgrading Product Schemas

- 6.5.1 Starting the Upgrade Assistant

- 6.5.1.1 Upgrade Assistant Parameters

- 6.5.2 Upgrading SOA Schemas Using the Upgrade Assistant

- 6.5.3 Verifying the Schema Upgrade

- 6.6 Reconfiguring the Domain

- 6.6.1 Backing Up the Domain

- 6.6.2 Starting the Reconfiguration Wizard

- 6.6.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

- 6.7 Upgrading Domain Component Configurations

- 6.7.1 Starting the Upgrade Assistant

- 6.7.1.1 Upgrade Assistant Parameters

- 6.7.2 Upgrading Domain Components Using the Upgrade Assistant

7 Upgrading Oracle SOA Suite with Business Activity Monitoring from a Previous 12c Release

- 7.1 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

- 7.2 Running a Pre-Upgrade Readiness Check

- 7.2.1 About Running a Pre-Upgrade Readiness Check

- 7.2.2 Starting the Upgrade Assistant in Readiness Mode

- 7.2.2.1 Upgrade Assistant Parameters

- 7.2.3 Performing a Readiness Check with the Upgrade Assistant

- 7.2.4 Understanding the Readiness Report

- 7.3 Stopping Servers and Processes

- 7.4 Upgrading Product Schemas

- 7.4.1 Starting the Upgrade Assistant

- 7.4.1.1 Upgrade Assistant Parameters

- 7.4.2 Upgrading SOA Schemas Using the Upgrade Assistant

- 7.4.3 Verifying the Schema Upgrade

- 7.5 Reconfiguring the Domain

- 7.5.1 Backing Up the Domain

- 7.5.2 Starting the Reconfiguration Wizard

- 7.5.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

8 Upgrading a Clustered SOA Environment

- 8.1 Upgrading a Clustered Topology

- 8.2 Understanding the SOA Cluster Upgrade Topology

- 8.3 Using Secured Task Forms in a Clustered Topology

- 8.4 Propagating Domain Configuration to Another Host

- 8.4.1 Copying the template file created in the previous step to SOAHOST2.

- 8.4.1.1 Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.

- 8.4.2 Executing the unpack Command from the 12c Oracle Home on SOAHOST2.

- 8.4.3 Completing the following verification steps after the unpack.

- 8.5 Post-Upgrade Tasks for Cluster Upgrades

- 8.5.1 Starting the Admin Server and SOA Managed Servers

- 8.5.2 Removing OWSM Targets from SOA and OSB Clusters

- 8.5.3 Updating OWSM Cross-Component Wiring

- 8.5.4 Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

- 8.5.5 Preventing Duplicate Messages When Using JMS Transport Proxy Service

9 Administering and Monitoring the Upgrade of SOA Instances

- 9.1 Understanding the Instance Upgrade Process

- 9.2 Understanding Instance Upgrade Background Jobs

- 9.3 Understanding the Flow Trace Changes in 12c

- 9.4 Using Purge Scripts Before You Upgrade

- 9.5 Using the Upgrade Administration Scripts

- 9.5.1 Accessing the Upgrade Scripts Menu

- 9.5.2 Running the Administration Scripts

- 9.6 Configuring the Administration Scripts

- 9.6.1 Changing Background Control Job Execution Schedule (Option 5)

- 9.6.2 Enabling and Disabling Background Control Job (Option 6)

- 9.6.3 Setting Control Job Parameters (Option 7)

- 9.6.4 Resetting Errored 11g instances (Option 9)

- 9.7 Stopping Upgrade Sessions and Jobs

- 9.8 Restarting an Incomplete Upgrade

- 9.9 Monitoring Upgrade Status with SQL Queries

- 9.10 Monitoring Upgrade Status with Fusion Middleware Control

- 9.10.1 Verifying Data Migration is Complete

- 9.10.2 Managing an Incomplete (Stopped) Upgrade

- 9.10.3 Optimizing the Display of Instances in Enterprise Manager

- 9.10.4 Viewing Instances that Faulted During the Upgrade

- 9.10.5 Viewing Instances Created Prior to Composite Redeployment

- 9.11 Resolving Instance Upgrade Errors

- 9.12 Restarting a Failed Upgrade

10 Performing Post Upgrade Tasks

- 10.1 Performing Post Upgrade Tasks

- 10.1.1 Updating the SOA Infrastructure Common Properties

- 10.1.2 Reapplying Start Script Properties for JVM

- 10.1.3 Reapplying Customizations to setDomainEnv.sh

- 10.1.4 Reapplying Customizations to XEngine Configuration Files

- 10.1.5 Copying Custom XPath Classes

- 10.1.6 Recreating Partition-Specific Roles for Application Roles and Policies

- 10.1.7 Upgrading Business Process Management (BPM) Metadata

- 10.1.8 Configuring an Oracle Fusion Middleware 12c Audit Data Store

- 10.1.9 Upgrading ServerSocket with Remote Clients

- 10.1.10 Reconfiguring Threads for SOA 12c

- 10.2 Verifying the Upgraded Components Work as Expected

- 10.2.1 Starting Servers and Processes

- 10.2.2 Verifying the Domain Component Configurations Upgrade

A Troubleshooting the Upgrade

- A.1 Reviewing the Release Notes

- A.2 Resolving Server Start Errors

- A.2.1 Reapplying Customizations to setDomainEnv.sh

- A.2.2 Reapplying Start Script Properties for JVM

- A.2.3 Reapplying Customizations to XEngine Configuration Files

- A.2.4 Copying Custom XPath Classes

- A.3 Recovering From a Failed Upgrade

- A.4 OWSM Data Source Connection Failure During Upgrade from 12c (12.1.3 or 12.2.1.0) to 12c (12.2.1.2)

- A.5 Troubleshooting a Failed BAM Upgrade

- A.6 Reapplying an EDNTopic to SOA JMS Module After Upgrade

- A.7 Troubleshooting Oracle Service Bus

- A.8 Troubleshooting Oracle Managed File Transfer (MFT) Upgrade Issues

- A.9 Error Starting OWSM After Upgrading to 12c

- A.10 Encryption Issues During Upgrade

- A.10.1 Updating Policy Files when Using Enhanced Encryption (AES 256)

- A.11 Upgrading Unsupported Domains with the Upgrade Assistant

- A.12 Business Rules Audit Trail Not Showing After Instance Upgrade

- A.13 Resolving a Coherence Cache Exception

- A.14 WSDL Generated Missing Elements for Custom Exception

- A.15 Failure to Connect to the ServerSocket through Remote Clients

- A.16 Troubleshooting Invalid Objects in Schema Registry

Preface

The following topics describe the intended audience, typographical conventions and additional resources that may be helpful during the upgrade process:

- Audience

- Conventions

- Related Documents
Upgrade documentation is organized by tasks in the 12c documentation library. The task-specific pages provide direct links to common upgrade procedures and related documentation.

Audience

This document is intended for administrators who are familiar with Oracle Fusion Middleware installation, upgrade, and administration tasks.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Related Documents

Upgrade documentation is organized by tasks in the 12c documentation library. The task-specific pages provide direct links to common upgrade procedures and related documentation.

You can refer the Oracle Fusion Middleware Library for additional information.

- For installation information, see Fusion Middleware Installation Documentation.

- For upgrade information, see Fusion Middleware 12c Upgrade Documentation.

- For administration-related information, see Fusion Middleware 12c Administration Documentation.

- For release-related information, see Fusion Middleware 12c Release Notes.

1 Introduction to Oracle SOA Suite and Business Process Management Upgrade

Learn how the upgrade to Oracle Fusion Middleware SOA Suite and Business Process Management 12c is performed. The procedures explain how to upgrade a production version of Oracle SOA Suite 11g or a previous 12c release, including the Oracle Fusion Middleware component configurations in that domain, to this release.

- Understanding the Oracle SOA Suite and Business Process Management Upgrade to 12c (12.2.1.2)
Understand how your pre-upgrade environment will be affected by the upgrade.

- Understanding the Starting Points for a SOA Suite 12c (12.2.1.2) Upgrade
Verify that your pre-upgrade environment is at a supported version before an upgrade.

- Understanding the Interoperability and Compatibility Restrictions Before You Upgrade
Read and understand how all of the components within your pre-upgrade domain will interact with the upgraded 12c (12.2.1.2) components.

- Understanding SOA Domain Upgrade Restrictions
Review the domain upgrade restrictions before starting the upgrade.

- Understanding the Standard SOA Upgrade Topologies
Your actual topology may vary, but the topologies described in this guide can be used to upgrade similar SOA Suite component topologies.

- Understanding How to Use this Guide for Your Upgrade
There are different upgrade paths depending on what is in your pre-upgrade environment. This guide covers all of the supported upgrade paths, so it is important that you understand which procedures to follow.

1.1 Understanding the Oracle SOA Suite and Business Process Management Upgrade to 12c (12.2.1.2)

Understand how your pre-upgrade environment will be affected by the upgrade.

When upgrading your existing SOA Suite 11g or 12c environment to SOA Suite and Business Process Management 12c (12.2.1.2), you should understand how your pre-upgrade environment will be affected by the upgrade. For example, schemas and domain directory upgrades are performed "in place" which updates the existing 11g files during the upgrade. The 12c (12.2.1.2) Oracle home binaries are upgraded "out of place" as the binaries are installed in a new directory.

The upgrade to 12c (12.2.1.2) includes the midtier and the schemas. You cannot perform a midtier-only or schema-only upgrade.

The list below describes how the upgrade is performed for the following Infrastructure and SOA Suite components:

- Oracle WebLogic Server, JRF and SOA Oracle Home Binaries - Upgraded Out of Place
You will install the Oracle Infrastructure ( WebLogic Server and JRF) 12c (12.2.1.2) and the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution binaries in a new Oracle home. The upgrade of binaries is considered "out of place" as the existing binaries are not overwritten.

- Schemas - Upgraded In Place
The schemas are upgraded "in place" which means that the Upgrade Assistant updates and overwrites the existing 11g or 12c schemas during the upgrade process. The servers must be down during this process.

- Instances - Migrated during the schema upgrade
The upgrade of active and closed instances happens automatically as part of the schema upgrade. You can manage the upgrade using administration scripts.

- Domain Directory Reconfiguration - Upgraded In Place
The existing SOA domain is upgraded "in place". During the upgrade you will provide the location of the existing 11g or 12c SOA domain and this domain will be reconfigured to point to the new SOA 12c (12.2.1.2) home directory.

- Domain Component Configuration - Upgraded In Place
After the reconfiguration of the existing SOA domain, the Upgrade Assistant is used again to upgrade any remaining domain component configurations that require an upgrade in the new SOA 12c (12.2.1.2) home directory.

Note:

Oracle recommends that you perform your domain upgrades in place. However, if an out-of-place domain upgrade is required, see Performing an Out-of-Place Domain Directory Upgrade in Planning an Upgrade of Oracle Fusion Middleware

1.2 Understanding the Starting Points for a SOA Suite 12c (12.2.1.2) Upgrade

Verify that your pre-upgrade environment is at a supported version before an upgrade.

You can upgrade to Oracle SOA Suite and Business Process Management 12c (12.2.1.2) from the following production starting points:

- SOA Suite and Business Process Management 12c (12.1.3), 12c (12.2.1.0) and 12c (12.2.1.1)

- SOA Suite 11g (11.1.1.9, 11.1.1.7)

Note:
If you are running SOA 11g (11.1.1.6) or earlier, you must first upgrade to SOA 11g (11.1.1.7 or 11.1.1.9) before you can upgrade. For more information, see Oracle® Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter Portal, and ADF in the Oracle Fusion Middleware 11g (11.1.1.7) upgrade documentation library.

1.3 Understanding the Interoperability and Compatibility Restrictions Before You Upgrade

Read and understand how all of the components within your pre-upgrade domain will interact with the upgraded 12c (12.2.1.2) components.

Before you begin the upgrade process from SOA Suite and BPM 11g to 12c (12.2.1.2) you must read and understand how all of the components within your 11g domain will be impacted by the upgrade. Understanding Interoperability and Compatibility provides a detailed matrix of which components can and cannot be upgraded together.

In general, you cannot upgrade a domain that contains components that are not yet available in Oracle Fusion Middleware12c (12.2.1.2). There are other restrictions on the components that can be upgraded to12c (12.2.1.2) and you need to be sure that you have reviewed this information carefully before you proceed with the upgrade.

See Also:Understanding SOA Domain Upgrade Restrictions

1.4 Understanding SOA Domain Upgrade Restrictions

Review the domain upgrade restrictions before starting the upgrade.

Some domains cannot be upgraded to 12c (12.2.1.2) because of known limitations and configuration changes from previous Fusion Middleware releases. Review the following to ensure your domains are not impacted by these restrictions. Domains that are impacted by these restrictions cannot be upgraded.

DO NOT ATTEMPT TO UPGRADE A DOMAIN THAT IS UNSUPPORTED.

The following list describes the known SOA domain upgrade restrictions.

- Domains that include SOA Core Extension cannot be upgraded in–place to 12c (12.2.1.2).
If your pre-upgrade environment contains SOA Core Extension, then you cannot upgrade to this release of Oracle Fusion Middleware. An upgrade of SOA Core Extension is not supported in 12c (12.2.1.2). If you want to include SOA Core Extension in your 12c (12.2.1.2) domain, you will have to manually migrate the files. Contact Oracle Support for more information.

- Domains that include the Cloud Adapters Pack should not be upgraded to12c (12.2.1.2)
If your pre-upgrade domain includes the Cloud Adapters Pack, you cannot upgrade to 12c (12.2.1.2).

- Domains that include Oracle Enterprise Repository cannot be upgraded to 12c (12.2.1.2)

If your pre-upgrade domain includes Oracle Enterprise Repository (OER), you cannot upgrade to 12c (12.2.1.2).

1.5 Understanding the Standard SOA Upgrade Topologies

Your actual topology may vary, but the topologies described in this guide can be used to upgrade similar SOA Suite component topologies.

This upgrade documentation provides detailed instructions for upgrading two typical SOA Suite configurations. These topologies are referred to as the Oracle Fusion Middleware 12c standard upgrade topologies. Specifically, for the purposes of this guide, a standard installation topology consists of a WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers or a standalone domain.

A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic Server domain, but it does not contain an Administration Server or Managed Servers. It can contain one or more instances of system components of the same type, such as Oracle HTTP Server, or a mix of system component types. For more information on the standalone topology, see What Is a Standalone Domain?

1.6 Understanding How to Use this Guide for Your Upgrade

There are different upgrade paths depending on what is in your pre-upgrade environment. This guide covers all of the supported upgrade paths, so it is important that you understand which procedures to follow.

The following table describes the procedures you will use based on your pre-upgrade environment. If your pre-upgrade environment includes other Oracle Fusion Middleware components, such as OracleWebCenter, you must refer to the component-specific upgrade guide for more information. For a complete list of upgrade guides available for this release, see Oracle Fusion Middleware 12c Upgrade Documentation .

If your pre-upgrade environment includes...

Refer to these upgrade procedures:

Oracle SOA Suite and Business Process Management (BPM) 11g

Upgrading SOA Suite and Business Process Management from 11g

Oracle SOA Suite and Business Process Management (BPM) 12c

Upgrading Oracle SOA Suite and Business Process Management from a Previous 12c Release

Clustered SOA and BPM Environment

Upgrading a Clustered SOA Environment

Oracle SOA Suite with Oracle Business Activity Monitoring (BAM) 11g

Upgrading Oracle SOA Suite with Oracle Business Activity Monitoring from 11g

Oracle SOA Suite with Oracle Business Activity Monitoring (BAM) 12c

Upgrading Oracle SOA Suite with Business Activity Monitoring from a Previous 12c Release

Domain with Oracle Business Activity Monitoring 11g Only

You cannot upgrade a BAM-only domain, but you can Import/Export BAM objects to 12c.

Exporting All Oracle BAM 11g Artifacts from the Existing Domain

Oracle Service Bus (OSB) 11g without SOA Suite
NOTE: Oracle Service Bus (OSB) 11g with SOA Suite will follow the standard upgrade procedures.

Upgrading an Oracle Service Bus Domain (without SOA)

Oracle User Messaging Service 11g or 12c

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

SOA Domain with AIAFP 11g or SOA Core Extension 12c

Not Supported — You must uninstall AIAFP 11g or SOA Core Extension to upgrade.

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.

- Creating a Complete Backup
Back up all system-critical files including all of the databases that host your Oracle Fusion Middleware schemas before you start the upgrade.

- 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.

- Verifying Certification and System Requirements
Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation.

- 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.

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

- 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.

- 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.

- Identifying Existing Schemas Available for Upgrade
This optional task enables you to review the list of available schemas before you begin the upgrade by querying the schema version registry. The registry contains schema information such as version number, component name and ID, date of creation and modification, and custom prefix.

- 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.

2.1 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.

- Make sure that your backup includes the schema version registry table. See Backing Up the Schema Version Registry Table.

- If you modified any of the startup scripts in your existing domain, you will need to copy them to temporary directory location (outside of the existing domain) during the upgrade and redeploy them after the upgrade. See Maintaining Custom Domain Environment Settings.

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.

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.2).

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

Optional

Identify which schemas are currently in your domain before you begin.

It is important that you know which schemas are in your pre-upgrade domain before you start the upgrade. You should know the schema owner names and passwords, as well as the versions of each schema.

See Identifying Existing Schemas Available for Upgrade.

2.2 Creating a Complete Backup

Back up all system-critical files including all of the databases that host your Oracle Fusion Middleware schemas before you start the upgrade.

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.

For more information about creating a backup, see:

- Backing Up Your Environment in Administering Oracle Fusion Middleware

- Upgrading and Preparing Your Oracle Databases for 12c in Planning an Upgrade of Oracle Fusion Middleware

In addition to creating a complete backup of your system, you must also create a backup of your schema version registry and any custom settings you want to use in your upgraded environment. See the following resources:

- Backing Up the Schema Version Registry Table
Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table.

- Maintaining Custom Domain Environment Settings
If you modified any domain generated or server startup scripts in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations.

2.2.1 Backing Up the Schema Version Registry Table

Your system backup must include the SYSTEM.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. Make sure you back up your existing database schemas and the schema version registry before you run the Upgrade Assistant.

Note:
Performing these backups prior to performing a schema upgrade is a prerequisite for running the Upgrade Assistant. During the upgrade you will be required to acknowledge that backups have been performed.

2.2.2 Maintaining Custom Domain Environment Settings

If you modified any domain generated or server startup scripts in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations.

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. Any custom settings you add to this file are preserved during the domain upgrade operation and are carried over to the remote servers when using the pack and unpack commands.

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 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.

2.3 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.

2.4 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.

- 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.

- 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.

- 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.

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

2.4.1 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. For more information, see the Certification Matrix for 12c (12.2.1.2).

2.4.2 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.2) 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:

- 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.

2.4.2.1 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 11g software is working properly on the 64-bit machine, and only then perform the upgrade to Oracle Fusion Middleware 12c.

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

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

Upgrading an operating system typically involves the following:

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

- 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.

- Back Up All Files from the 32-bit Host Machine
Make sure that you have created a complete backup of your entire 11g deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

- Set Up the Target 64-bit Machine with the 11g Host Name and IP Address
The host name and IP address of the target machine must be made identical to the host. This require you to change the IP address and name of the source machine or decommission the source machine to avoid conflicts in the network.

- Restore the 11g 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 11g. The directory structure on the target machine must be identical to the structure of the host machine.

- Install the 12c Product Distributions on the Target Machine
Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 12c product distributions in a new Oracle home on the target machine.

- 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.

2.4.2.1.1 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.

2.4.2.1.2 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) 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

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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

2.4.2.1.3 Back Up All Files from the 32-bit Host Machine

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

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

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

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

- 11g Domain Home

- 11g /nodemanager directory located in $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.

2.4.2.1.4 Set Up the Target 64-bit Machine with the 11g Host Name and IP Address

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

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

2.4.2.1.5 Restore the 11g 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 11g. The directory structure on the target machine must be identical to the structure of the host machine.

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

2.4.2.1.6 Install the 12c Product Distributions on the Target Machine

Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 12c 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.

2.4.2.1.7 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.

For a complete upgrade procedure, see the component-specific upgrade guide for the component(s) you are upgrading.

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

2.4.3 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.

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. For more information, see the Certification Matrix for 12c (12.2.1.2).

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 in Planning an Upgrade of Oracle Fusion Middleware

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

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

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

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.

2.5 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. For more information, 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.

2.6 Purging Unused Data

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

Note:If a large amount of data needs to be purged, consider partitioning tables or employing other data optimization strategies. Using scripts to remove large amounts of data may impact performance. See the following information in Administering Oracle SOA Suite and Oracle Business Process Management Suite:

- Developing a Purging and Partitioning Methodology

- Developing a Database Growth Management Strategy

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.

If you are migrating closed 11g instance data, run the instance purge scripts before running the upgrade. See Using Instance Data Purge Scripts.

2.7 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 changes have been made and tested do 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, log 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 to manually set up the default edition name for the database, for example:

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1_1;

2.8 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 in this section must be granted to user FMW before starting the Upgrade Assistant.

Notes
If you created the non-SYSDBA user FMW in a previous release, you must drop and recreate this user before starting the upgrade. Running the Upgrade Assistant with an older FMW user may lead to a failed upgrade as new privileges may have been added. Oracle recommends that you drop and recreate the user instead of modifying the existing FMW user.

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 v$xatrans$ table is required only for Oracle Identity Manager. If you do not require Oracle Identity Manager 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, welcome1 is the password. Make sure that you specify your actual password when granting privileges.

create user FMW identified by welcome1;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
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;

Note:

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

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

2.9 Identifying Existing Schemas Available for Upgrade

This optional task enables you to review the list of available schemas before you begin the upgrade by querying the schema version registry. The registry contains schema information such as version number, component name and ID, date of creation and modification, and custom prefix.

You can let the Upgrade Assistant upgrade all of the schemas in the domain, or you can select individual schemas to upgrade. To help decide, follow these steps to view a list of all the schemas that are available for an upgrade:

1. If you are using an Oracle database, connect to the database by using an acount that has Oracle DBA privileges, and run the following from SQL*Plus:

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 ;

2. Examine the report that is generated. If the value in the VERSION column is at 11.1.1.7.0 or higher, and the STATUS column value 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 schema at its pre-upgrade version.

3. Note the schema prefix name that was used for your existing schemas. You will use the same prefix when creating new 12c schemas.

Notes

- If your existing schemas are not at a supported version, then you must upgrade them to a supported version before using the 12c (12.2.1.2) upgrade procedures. Refer to your pre-upgrade version documentation for more information.

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

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

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

2.10 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.

This section includes pre-upgrade tasks that apply to any SOA, Business Process Management, or integrated products being upgraded to 12c (12.2.1.1). 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.2)

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

- 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.2).

- 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.

- 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.

- 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.

- 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.

- 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.

- 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.

2.10.1 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.2).

It is imperative that you understand the Oracle Database requirements for upgrading to Oracle SOA Suite and BPM 12c (12.2.1.2), 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.2). 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:

- "About the Database Profile Custom Variable" in Installing and Configuring Oracle SOA Suite and Business Process Management

- "Introduction to SOA Composite Applications" in Administering Oracle SOA Suite and Oracle Business Process Management Suite

- "Identifying the Profile or Size of the Database" in Administering Oracle SOA Suite and Oracle Business Process Management Suite

- 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.

2.10.1.1 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.

2.10.2 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.

2.10.3 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.

2.10.4 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.2) 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.

2.10.5 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.

2.10.6 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).

2.10.7 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.

3 Upgrading SOA Suite and Business Process Management from 11g

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.2).

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.

- About the SOA Suite and BPM Upgrade Process Flow
This flowchart and the accompanying text describe the high-level steps for upgrading the Oracle Fusion Middleware SOA Suite 11g to 12c (12.2.1.2)

- Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management
Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

- Creating the Required 12c Schemas with the RCU
When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

- Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- Stopping Servers and Processes
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.

- Upgrading Schemas with the Upgrade Assistant
If you are upgrading non-partitioned schemas, follow the steps described in Upgrading Schemas with the Upgrade Assistant. If you are upgrading partioned schemas, follow the steps described in Upgrading Partitioned Schemas.

- Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

3.1 About the SOA Suite and BPM Upgrade Process Flow

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

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.

Figure 3-1 Upgrade Process Flowchart for SOA Suite and BPM

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.2) 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.

Install but do not use the Configuration Wizard to configure the newly installed 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.2) and any integrated SOA-integrated distributions (such as Oracle HTTP Server and Oracle Service Bus) in your newly created Oracle home.

You must install the Fusion Middleware 12c (12.2.1.2) 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 V distribution as well as the Oracle SOA Suite and BPM 12c (12.2.1.2) distribution.

Optional
Run a pre-upgrade readiness check with the Upgrade Assistant

Run the Upgrade Assistant in —readiness mode before you begin the upgrade to identify any potential issues with the pre-upgrade environment that could cause the upgrade to fail. If necessary, fix the issues and run the readiness check again.

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.

Required

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

The schemas you create will vary depending on your existing schema configuration.

Required

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

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

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 Oracle SOA Suite with Oracle Business Activity Monitoring from 11g

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.

During an upgrade, the Configuration Wizard is run in reconfiguration mode to update the existing domain to use the newly installed software.

Required

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

The Upgrade Assistant is used to update the reconfigured domain’s component configurations.

Required

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

Your components may not require any additional post-upgrade procedures.

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.

Oracle recommends that you ensure all of the upgraded components are working as expected before deleting your backups.

Required for Cluster Upgrades
Once you have verified that the upgrade was successful, you will need to propagate the environment to the other host.

Propagating Domain Configuration to Another Host

3.2 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

Note:
You must install the Oracle Fusion Middleware Infrastructure distribution first before installing other Fusion Middleware products, when Infrastructure is required for the upgrade.

Before you begin, note the following:

- If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0 or 12.2.1.1) you must install the 12c (12.2.1.2) distributions into a new Oracle home. Do not attempt to reuse the existing Oracle home for this upgrade. Upgrading to 12c (12.2.1.2) is not a patch release.

- Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).
Installing Fusion Middleware Infrastructure creates an Oracle home directory and lays supporting software to install other Fusion Middleware products.

- If your SOA domain has other SOA-integrated components, such as Oracle Service Bus, Managed File Transfer, or Oracle B2B, you must install those distributions into the same new Oracle home. Oracle Business Activity Monitoring and Business Process Management are part of the SOA distribution soa_generic.jar.

To install the Oracle SOA Suite component distributions:

1. Sign in to the target system where you want to install the 12c (12.2.1.2) product distribution.

2. Download the following distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Fusion Middleware Infrastructure distribution (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA Suite and Business Process Management distribution (fmw_12.2.1.2.0_soa_generic.jar)

- If you are running Managed File Transfer, Oracle Service Bus or Oracle B2B, download the Managed File Transfer distribution (fmw_12.2.1.2.0_mft_generic.jar), Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar), and Oracle B2B (fmw_12.2.1.2_b2b_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select Skip Auto Updates. Options are:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected, and click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that gets verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed the Infrastructure, repeat steps 3 through 13 to install the other product distributions.

3.3 Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

If you are upgrading from 11g, refer to the Pre-Upgrade Checklist to identify the existing schemas in your domain. The following schemas must exist before you upgrade to 12c:

- Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas. Note: If the Service Table schema does not exist, you may 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.

- Oracle Platform Security Services (OPSS) schema (prefix_OPSS). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can 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.

- The following table lists additional schemas that must exist:

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

If you are upgrading...

These 12c schemas must exist...

SOA Suite (SOA)

Service Table (_STB)

Audit Services (_IAU) —For 11g to 12c upgrades this schema needs to be created if there is an Oracle Platform Services (_OPSS) schema in the 11g source domain

NOTE: When Oracle Platform Security Services (_OPSS) is selected, the required Audit Services (_IAU) schemas (_IAU_APPEND, and _IAU_VIEWER) are automatically selected.

If you already have an _OPSS schema in the existing 11g domain (a database-based OPSS), and a file-based Audit Services (_IAU) schema, then you must create new Audit Services schema for the 12c domain.

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.2).

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 the 12c schemas with the RCU:

1. (Optional) If you are upgrading from 11g, and you would like to confirm which schemas are in your existing domain, connect to the database as a user with DBA privileges, and run the following code from SQL*Plus:

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 ;

2. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.2), the certified JDK is 1.8.0_101 and later.
Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

Add $JAVA_HOME/bin to $PATH.

3. Go to the oracle_common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. Start the RCU:

- (UNIX) ./rcu

- (Windows) rcu.bat

5. On the Welcome screen, click Next.

6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.
Click Next.

7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

Table 3-3 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

Option

Description and Example

Host Name

Specify the name of the server where your database is running in the following format:

examplehost.exampledomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

Port

Specify the port number for your database. The default port number for Oracle databases is 1521.

Service Name

Specify the service name for the database. Typically, the service name is the same as the global database name.

For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

examplehost.exampledomain.com

Username

Enter the user name for your database. The default user name is SYS.

Password

Enter the password for your database user.

Role

Select the database user's role from the drop-down list:

Normal or SYSDBA

Table 3-4 Connection Credentials for MySQL Databases

Option

Description and Example

Host Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 3-5 Connection Credentials for Microsoft SQL Server Databases

Option

Description and Example

Unicode Support

Select Yes or No from the drop-down list.

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
MSSQL named instances: A named instance is identified by the network name of the computer plus the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 3-6 Connection Credentials for IBM DB2 Databases

Option

Description and Example

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.

Password

Enter the password for your database user.

If the prerequisite check is successful, click OK to continue to the next page. If the check fails, review the details you entered and try again.

8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

Note: The Common Infrastructure Services Service Table (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.

9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.

10. On the Schema Passwords screen, specify the passwords for your schema owners.
Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.

11. On the Map Tablespaces screen, configure the desired tablespace mapping for the schemas you want to create.
Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.

You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.

12. Verify the information on the Summary screen and click Create to begin schema creation.
This screen contains information about the log files that were created from this RCU operation. You can click on the name of a particular log file to view the contents of that file.

13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

3.4 Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

- Starting the Upgrade Assistant in Readiness Mode
Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

- Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

- Understanding the Readiness Report
After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

3.4.1 About Running a Pre-Upgrade Readiness Check

You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.

The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.

You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.

You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.

Note:

To prevent performance from being affected, Oracle recommends that you run the readiness checks during off-peak hours.

3.4.2 Starting the Upgrade Assistant in Readiness Mode

Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

To perform a readiness check on your pre-upgrade environment with the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant.

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

Note:
If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter the following error:

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

To resolve this issue, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

For information about other parameters that you can specify on the command line, see:

- Upgrade Assistant Parameters

3.4.2.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 3-7 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

3.4.3 Performing a Readiness Check with the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

Readiness checks are performed only on schemas or component configurations that are at a supported upgrade starting point.

To complete the readiness check:

1. On the Welcome screen, review information about the readiness check. Click Next.

2. On the Readiness Check Type screen, select the readiness check that you want to perform:

- Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.
When you select this option, the screen name changes to Selected Schemas.

- Domain Based allows the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.
When you select this option, the screen name changes to Schemas and Configuration.

Leave the default selection if you want the Upgrade Assistant to check all schemas and component configurations at the same time, or select a specific option:

- Include checks for all schemas to discover and review all components that have a schema available to upgrade.

- Include checks for all configurations to review component configurations for a managed WebLogic Server domain.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.

If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

Depending on the components you select, additional screens may display. For example, you may need to:

- Specify the domain directory.

- Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. Then click Connect.

CAUTION
Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the readiness check with the correct database type selected to ensure that the correct database type is applied to all schemas.

- Select the Schema User Name and specify the Schema Password.

Click Next to start the readiness check.

4. On the Readiness Summary screen, review the summary of the readiness checks performed based on your selections.
If you want to save your selections to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

For a detailed report, click View Log.

Click Next.

5. On the Readiness Check screen, review the status of the readiness check. The process can take several minutes.
If you are checking multiple components, the progress of each component displays in its own progress bar in parallel.

When the readiness check is complete, click Continue.

6. On the End of Readiness screen, review the results of the readiness check (Readiness Success or Readiness Failure):

- If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the actual upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.

- If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check. The log file is managed by the command line options you set.

3.4.4 Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

The format of the readiness report file is:

readiness_timestamp.txt

where timestamp indicates the date and time of when the readiness check was run.

A readiness report contains the following information:

Table 3-8 Readiness Report Elements

Report Information

Description

Required Action

Overall Readiness Status: SUCCESS or FAILURE

The top of the report indicates whether the Upgrade readiness check passed or completed with one or more errors.

If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade.

Timestamp

The date and time that the report was generated.

No action required.

Log file location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated readiness report.

No action required.

Names of components that were checked

The names and versions of the components included in the check and status.

If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, then do not attempt an upgrade.

Names of schemas that were checked

The names and current versions of the schemas included in the check and status.

Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, then do not attempt an upgrade.

Individual Object Test Status: FAIL

The readiness check test detected an issue with a specific object.

Do not upgrade until all failed issues have been resolved.

Individual Object Test Status: PASS

The readiness check test detected no issues for the specific object.

If your readiness check report shows only the PASS status, then you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade.

Completed Readiness Check of <Object> Status: FAILURE

The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index or datatype.

Do not upgrade until all FAILED issues have been resolved.

Completed Readiness Check of <Object> Status: SUCCESS

The readiness check test detected no issues.

No action required.

Here is a sample Readiness Report file. Your report may or may not include all of these checks.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from an 11g release (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

Note:
You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.

3.5 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all 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 such as Identity Management 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 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 Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To stop your Fusion Middleware environment, follow the steps below.

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic 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

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

3.6 Upgrading Schemas with the Upgrade Assistant

If you are upgrading non-partitioned schemas, follow the steps described in Upgrading Schemas with the Upgrade Assistant. If you are upgrading partioned schemas, follow the steps described in Upgrading Partitioned Schemas.

Note:
Make sure that you select the procedure for your schema configuration. Partitioned schemas cannot be upgraded using the Upgrade Assistant.

- Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

- 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 12c (12.2.1.2), then you must complete these required steps to upgrade your partitioned schema tables.

3.6.1 Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading SOA Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

- Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

3.6.1.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

3.6.1.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 3-9 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

3.6.1.2 Upgrading SOA Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

Caution:

Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.

Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

To upgrade product schemas with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the Selected Schemas screen, select the schema upgrade operation that you want to perform:

- Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

Caution:
Upgrade only those schemas that are used to support your 12c (12.2.1.2) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.2).

- All Schemas Used by a Domain to allow the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. 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.

4. The Domain Directory screen appears when Oracle Platform Security Services or Oracle Audit Services is selected 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

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. On the Schema Credentials screen, specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

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

- Enter the database connection details, and click Connect.

- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

Note:
The component ID or schema name is changed for UCSUMS schema as of release 12.1.2.0, which means the Upgrade Assistant does not automatically recognize the possible schemas and displays them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.

If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

3.6.1.3 Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

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 ;

In the query result:

- Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.2.0 . Note, however, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

- 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.

- Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.
They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

3.6.2 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 12c (12.2.1.2), 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 partitioning 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.2 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

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

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

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

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.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. 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 before 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 in Upgrading Oracle WebLogic Server.

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the SOA Domain with the Reconfiguration Wizard
You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

3.7.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup 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. Before updating the domain on each remote Managed Server, create 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 before reconfiguration.

3.7.2 Starting the Reconfiguration Wizard

To start the Reconfiguration Wizard in graphical mode:

1. Sign 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 child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

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

- (Windows) 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 this command, the following error message might appear 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 SOA Domain with the Reconfiguration Wizard

You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.
NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the 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.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The optional categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain. Some common categories are described below.

Advanced Configuration > 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

Managed Servers >Targeting Server Groups

Note:
If you are upgrading a domain that was created in a previous 12c release (such as 12.1.3), you MUST target your servers to the correct Server Groups during the domain reconfiguration phase of the upgrade. Failure to target these servers may result in a failed upgrade and excess downtime.

a. On the Managed Servers screen, target each server to the correct Server Group by selecting the correct group name from the Server Groups drop-down menu.

b. Verify that Each of the servers is targeted to the correct server group and should not show as Unspecified.

Component and Server

Server Group

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

Advanced Configuration > 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.

Advanced Configuration > 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:
When OWSMPM is in its own cluster and not part of SOA or OSB clusters:

- Target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster

- Target only OSB-MGD-SVRS-ONLY to the OSB cluster

- Target WSMPM-MAN-SVER server group to OWSM

- When upgrading 12.1.3.0 to 12.2.1.2 you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

3.8 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Components Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

3.8.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

3.8.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 3-10 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

3.8.2 Upgrading Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. If your pre-upgrade environment has multiple WebLogic domains, but the Oracle Web Services Manager (OWSM) Policy Manager is in only one domain, and OWSM agents are in the other domains: On the OWSM Policy Manager screen, provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

4. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. If there are remote managed servers hosting User Messaging Services (UMS) configuration files: On the UMS Configuration screen, provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

Note:
You may need to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See Error while Copying User Messaging Service (UMS) Configuration Files.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard. The Post-Upgrade Actions window describes the manual tasks you must perform to make components functional in the new installation. This window appears only if a component has post-upgrade steps.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

4 Upgrading Oracle Service Bus (without Oracle SOA Suite) from 11g

Describes the upgrade-specific tasks for upgrading Oracle Service Bus 11g without Oracle SOA Suite and Business Process Management.

Note:
If Oracle Service Bus is part of your SOA 11g or a previous 12c domain, and you will be upgrading Oracle Service Bus as part of your Oracle SOA Suite upgrade to 12c (12.2.1.2), follow the standard upgrade process described in Upgrading SOA Suite and Business Process Management from 11g or Upgrading Oracle SOA Suite and Business Process Management from a Previous 12c Release.

- Understanding the Oracle Service Bus Standalone Upgrade to 12c
Follow this process flow to upgrade an Oracle Service Bus 11g deployment that does not include Oracle SOA Suite.

- Upgrade Limitations for Oracle Service Bus 12c (12.2.1.2)
If your Oracle Service Bus 11g topology is configured with more than one component within a single domain, then you will not be able to upgrade to 12c (12.2.1.2)

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

- Installing Oracle Service Bus
Before beginning your upgrade, use the Oracle Universal Installer to install the required product distribution on the target system. You can install and upgrade Oracle Service Bus without Oracle SOA Suite and Business Process Management, but you must still install the Oracle Fusion Middleware Infrastructure 12c (12.2.1.2) before upgrading Oracle Service Bus.

- Creating the Required 12c Schemas with the RCU
When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

- Stopping Servers and Processes
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.

- Upgrading an Oracle Service Bus Domain (without SOA)

- Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Performing Post Upgrade Tasks for Oracle Service Bus

- Troubleshooting Oracle Service Bus Upgrade

4.1 Understanding the Oracle Service Bus Standalone Upgrade to 12c

Follow this process flow to upgrade an Oracle Service Bus 11g deployment that does not include Oracle SOA Suite.

Oracle Service Bus (OSB) can be upgraded to 12c (12.2.1.2) with or without Oracle SOA Suite and Business Process Management. The upgrade steps in this topic describe how to upgrade Oracle Service Bus without SOA.

If Oracle Service Bus is part of your SOA 11g or a previous 12c domain, and you will be upgrading Oracle Service Bus as part of your Oracle SOA Suite upgrade to 12c (12.2.1.2), follow the standard upgrade process described in Upgrading SOA Suite and Business Process Management from 11g.

Note:
Even though your domain does not include SOA, you will still have to upgrade the _SOAINFRA schema to upgrade Oracle Service Bus metadata. Oracle Service Bus does not have a separate schema.

Task

Description

Required if Oracle Web Services Manager is not already deployed.
Deploy Oracle Web Services Manager Policy Manager in your existing 11g environment.

If Oracle Web Services Manager (OWSM) Policy Manager is not already deployed in your Oracle Service Bus 11g environment, then you must manually deploy it before you upgrade to 12c.

Required

Export services, projects and resources when upgrading Oracle Service Bus

You must export services, projects and resources into a configuration JAR file before you can upgrade to Oracle Service Bus 12c (12.2.1.2). After the upgrade, you will import the JAR file to the new 12c environment.

Required

Delete all services, projects and resources from the existing environment.

After the export, you must delete all user-created services, projects and resources before the upgrade.

Required

Install the 12c Oracle Fusion Middleware Infrastructure distribution into a new Oracle home.

You must install the 12c Infrastructure (which includes Oracle WebLogic Server and JRF components).

Required

Install Oracle Service Bus into a new Oracle home.

Obtain the Oracle Service Bus distribution and install the content to a new Oracle home.

Required
Run the Repository Creation Utility (RCU) to create the new required schema.

The Service Table schema (_STB) is a new required schema for all domains. If you are upgrading from 11g, you will have to create this schema before you can upgrade to 12c.
Oracle Service Bus also requires the SOA schema (_SOAINFRA) even when SOA is not part of your domain.

If you are upgrading from a previous 12c release, do not create another Service Table schema.

Required
Stop all servers and processes.

You must stop all servers and processes before starting the upgrade.

Required

Run the Upgrade Assistant to upgrade the required schemas.

If you are upgrading from a previous 12c release, the _SOAINFRA schema must be upgraded to 12c (12.2.1.2).

Required
Run the Reconfiguration Wizard to reconfigure the existing domain.

You will continue to use the existing domain after the upgrade, so it must be reconfigured to work with the new components.

Required
Run the Upgrade Assistant to configure the component configurations.

You will run the Upgrade Assistant a second time to update the component configuration to work in the new domain.

Required

Perform all post-upgrade tasks.

Perform the standard 12c post-upgrade tasks, as well as any post-upgrade OSB-specific tasks, that apply to your deployment.

4.2 Upgrade Limitations for Oracle Service Bus 12c (12.2.1.2)

If your Oracle Service Bus 11g topology is configured with more than one component within a single domain, then you will not be able to upgrade to 12c (12.2.1.2)

Upgrading Multiple Components that use UMS in a Single OSB Domain (Not Supported)

Certain Fusion Middleware components such as Oracle SOA, Oracle Service Bus (OSB) and Business Activity Monitoring (BAM) have a dependency on User Messaging Service (UMS) in 12c. If you configure more than one of these components within a single 12c (12.2.1.2) domain, then each of these components must run within its own cluster — even if there is only one server that runs that component.

In order to upgrade these components, you must create a separate cluster for each component during the domain reconfiguration as described in Clusters.

The supported upgrade topology for these components is described in Upgrading a Clustered Topology.

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

If you are upgrading Oracle Service Bus, you must perform the following tasks before you begin the upgrade. Review your own use case scenarios and existing deployment to determine if the following tasks apply to your environment.

1. Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

2. Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

3. Deleting All Services, Projects and Resources

4. Migrating Oracle Service Bus Resources from Previous Releases

4.3.1 Deploying Oracle Web Services Manager Policy Manager in Your 11g Environment

If Oracle Web Services Manager (OWSM) Policy Manager is not already deployed in your Oracle Service Bus 11g environment, then you must manually deploy it before you upgrade to 12c.

In 11g, both WebLogic security policies and OWSM policies were supported on Oracle Service Bus. As of 11g (11.1.1.7), WebLogic Security policies were deprecated, and are not supported in 12c (12.2.1.2). Because WebLogic security policies were available in 11g, deployment of the OWSM Policy Manager and use of the OWSM policies was optional. Since only OWSM policies are supported in 12c, OWSM Policy Manager deployment is mandatory.

For information on manually deploying the OWSM Policy Manager in your 11g environment, see Installing OWSM with WebLogic Server in Securing Web Services and Managing Policies with Oracle Web Services Manager.

4.3.2 Exporting Services, Projects and Resources when Upgrading Oracle Service Bus

You must export services, projects and resources into a configuration JAR file before you can upgrade to Oracle Service Bus 12c (12.2.1.2). After the upgrade, you will import the JAR file to the new 12c environment.

Note that you can manually export resources and services from older, supported releases. See Migrating Oracle Service Bus Resources from Previous Releases.

For more information, see Importing and Exporting Resources and Configurations in Developing Services with Oracle Service Bus.

4.3.3 Deleting All Services, Projects and Resources

After the export, you must delete all user-created services, projects and resources before the upgrade.

For information on using the Oracle Service Bus Console to delete resources, see How to Delete Projects, Folders, and Resources.

For information on using JDeveloper to delete resources, see How to Delete a Project or Resource.

4.3.4 Migrating Oracle Service Bus Resources from Previous Releases

You can manually export resources and services from the following releases and use them with Oracle Service Bus 12c (12.2.1.2):

- Oracle Service Bus 12c Release 12.1.3.0, 12.2.1.0, and 12.2.1.1

- Oracle Service Bus 11g Release: 11.1.1.7.0

- Oracle Service Bus 10.3 Releases: 10.3.1 and 10.3.0

- AquaLogic® Service Bus Releases 3.0 and later

For more information, see Importing and Exporting Resources and Configurations in Developing Services with Oracle Service Bus.

4.4 Installing Oracle Service Bus

Before beginning your upgrade, use the Oracle Universal Installer to install the required product distribution on the target system. You can install and upgrade Oracle Service Bus without Oracle SOA Suite and Business Process Management, but you must still install the Oracle Fusion Middleware Infrastructure 12c (12.2.1.2) before upgrading Oracle Service Bus.

Note:
You must install the Oracle Fusion Middleware Infrastructure distribution first before installing other Fusion Middleware products, when Infrastructure is required for the upgrade.

Before you begin, note the following:

- Oracle Service Bus requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).

- If you want to use Oracle Web Services Manager policies with Oracle Service Bus, then you must select the Oracle Web Services Manager extension template after selecting one of the Oracle Service Bus domain templates when configuring the Oracle WebLogic domain.

To install the required distributions for Oracle Service Bus:

1. Sign in to the target system where you want to install the 12c (12.2.1.2) product distribution.

2. Download the following distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Fusion Middleware Infrastructure distribution (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select Skip Auto Updates. Options are:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected and click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that gets verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed the Infrastructure, repeat steps 3 through 11 to install the Oracle Service Bus distribution.

4.5 Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

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.2).

If you are upgrading from 11g, refer to the Pre-Upgrade Checklist to identify the existing schemas in your domain. The following schemas must exist before you upgrade to 12c:

- Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas. Note: If the Service Table schema does not exist, you may 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.

- SOA Infrastructure schema (prefix_SOAINFRA).

- Oracle User Messaging Service schema (prefix_UMS ).

To create the 12c schemas with the RCU:

1. (Optional) If you are upgrading from 11g, and you would like to confirm which schemas are in your existing domain, connect to the database as a user with DBA privileges, and run the following code from SQL*Plus:

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 ;

2. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.2), the certified JDK is 1.8.0_101 and later.
Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

Add $JAVA_HOME/bin to $PATH.

3. Go to the oracle_common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. Start the RCU:

- (UNIX) ./rcu

- (Windows) rcu.bat

5. On the Welcome screen, click Next.

6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.
Click Next.

7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

Table 4-1 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

Option

Description and Example

Host Name

Specify the name of the server where your database is running in the following format:

examplehost.exampledomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

Port

Specify the port number for your database. The default port number for Oracle databases is 1521.

Service Name

Specify the service name for the database. Typically, the service name is the same as the global database name.

For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

examplehost.exampledomain.com

Username

Enter the user name for your database. The default user name is SYS.

Password

Enter the password for your database user.

Role

Select the database user's role from the drop-down list:

Normal or SYSDBA

Table 4-2 Connection Credentials for MySQL Databases

Option

Description and Example

Host Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 4-3 Connection Credentials for Microsoft SQL Server Databases

Option

Description and Example

Unicode Support

Select Yes or No from the drop-down list.

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
MSSQL named instances: A named instance is identified by the network name of the computer plus the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 4-4 Connection Credentials for IBM DB2 Databases

Option

Description and Example

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.

Password

Enter the password for your database user.

If the prerequisite check is successful, click OK to continue to the next page. If the check fails, review the details you entered and try again.

8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

Select the schemas required for Oracle Service Bus.

Note: The Common Infrastructure Services Service Table (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.

9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.

10. On the Schema Passwords screen, specify the passwords for your schema owners.
Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.

11. On the Map Tablespaces screen, configure the desired tablespace mapping for the schemas you want to create.
Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.

You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.

12. Verify the information on the Summary screen and click Create to begin schema creation.
This screen contains information about the log files that were created from this RCU operation. You can click on the name of a particular log file to view the contents of that file.

13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

4.6 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all 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 such as Identity Management 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 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 Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To stop your Fusion Middleware environment, follow the steps below.

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic 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

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

4.7 Upgrading an Oracle Service Bus Domain (without SOA)

Although there is no Oracle Service Bus schema, the database schema data for Oracle Service Bus is incorporated in the SOAINFRA schema. Therefore, to upgrade Oracle Service Bus, you must upgrade the SOAINFRA schema.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

4.7.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

4.7.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 4-5 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

4.8 Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

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

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

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.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. 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 before 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 in Upgrading Oracle WebLogic Server.

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the SOA Domain with the Reconfiguration Wizard
You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

4.8.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup 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. Before updating the domain on each remote Managed Server, create 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 before reconfiguration.

4.8.2 Starting the Reconfiguration Wizard

To start the Reconfiguration Wizard in graphical mode:

1. Sign 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 child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

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

- (Windows) 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 this command, the following error message might appear 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

4.8.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.
NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the 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.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The optional categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain. Some common categories are described below.

Advanced Configuration > 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

Managed Servers >Targeting Server Groups

Note:
If you are upgrading a domain that was created in a previous 12c release (such as 12.1.3), you MUST target your servers to the correct Server Groups during the domain reconfiguration phase of the upgrade. Failure to target these servers may result in a failed upgrade and excess downtime.

a. On the Managed Servers screen, target each server to the correct Server Group by selecting the correct group name from the Server Groups drop-down menu.

b. Verify that Each of the servers is targeted to the correct server group and should not show as Unspecified.

Component and Server

Server Group

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

Advanced Configuration > 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.

Advanced Configuration > 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:
When OWSMPM is in its own cluster and not part of SOA or OSB clusters:

- Target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster

- Target only OSB-MGD-SVRS-ONLY to the OSB cluster

- Target WSMPM-MAN-SVER server group to OWSM

- When upgrading 12.1.3.0 to 12.2.1.2 you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

4.9 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Components Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

4.9.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

4.9.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 4-6 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

4.9.2 Upgrading Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. If your pre-upgrade environment has multiple WebLogic domains, but the Oracle Web Services Manager (OWSM) Policy Manager is in only one domain, and OWSM agents are in the other domains: On the OWSM Policy Manager screen, provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

4. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. If there are remote managed servers hosting User Messaging Services (UMS) configuration files: On the UMS Configuration screen, provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

Note:
You may need to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See Error while Copying User Messaging Service (UMS) Configuration Files.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard. The Post-Upgrade Actions window describes the manual tasks you must perform to make components functional in the new installation. This window appears only if a component has post-upgrade steps.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

4.10 Performing Post Upgrade Tasks for Oracle Service Bus

After a successful upgrade, you may need to perform one or more of the following tasks. Review your own use case scenarios and existing deployment to determine if the following tasks apply to your environment.

Note:

If you experience any post-upgrade issues with Oracle Service Bus, refer to Troubleshooting Oracle Service Bus for a list of common solutions.

- Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

- Importing Domain Configuration Data

- Importing Security Configurations

- Upgrading Your XQuery Resources

- Understanding 12c Split-Joins

4.10.1 Configuring Oracle HTTP Server for the WLS_OSB Managed Servers

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster.

For more information, see Configuring Oracle HTTP Server for the Oracle Service Bus in the Enterprise Deployment Guide for Oracle SOA Suite.

4.10.2 Importing Domain Configuration Data

After the upgrade you will need to import the domain configuration data that you exported in Exporting Services, Projects and Resources when Upgrading Oracle Service Bus.

For more information, see How to Import Resources from a Configuration JAR File in the Console and Executing a Configuration File.

4.10.3 Importing Security Configurations

Use the Oracle WebLogic Administration Console to import the security data that you exported pre-upgrade into the new Oracle Service Bus domain.

For more information, see the "Import data into a security provider" section of the Oracle WebLogic Server Administration Console Online Help.

Note:

You must import the security information for each security provider separately.

4.10.4 Upgrading Your XQuery Resources

Oracle Service Bus supports XQuery 1.0. The older XQuery 2004 is also supported. Any new XQuery resource created in Service Bus uses the XQuery 1.0 version, by default.

If you have upgraded from a pre-12c Service Bus project, all XQuery resources in the project are configured to use the XQuery 2004 version.

For more information on upgrading XQuery Resources, see How to Upgrade Your XQuery Resources to use XQuery 1.0.

4.10.5 Understanding 12c Split-Joins

The Fusion Middleware 11g split-join business service will no longer exist in 12c because in 12c there is a direct way to invoke a split-join component from a pipeline or a proxy service. The upgrade process will automatically change all statically configured invoke references to a split-join business service as follows:

- The flow business service is removed. This means the Timeout property configured for the Flow business service is also removed.

- If the business service is located in the same project as the proxy service that invokes it, then the pipeline associated with that proxy service invokes the split-join directly.

- If the business service is located in a different project from the proxy service that invokes it, then a local proxy service is created to invoke the split-join. The local proxy service is invoked by the original proxy service.

4.11 Troubleshooting Oracle Service Bus Upgrade

If you experience post-upgrade issues with Oracle Service Bus, review the following and apply any relevant solutions.

- Resolving the HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host

- Resolving the HTTP 404 Error When Accessing OSB Console

4.11.1 Resolving the HTTP 404 Error After OSB Upgrade with OHS as Cluster Frontend Host

If you configure Oracle HTTP Server (OHS) as a cluster domain frontend host, then you must add the following code to the OHS configuration file (ohs.confg):

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>

Where ADMIN.SERVER:PORT is the machine name, server name and port number used for the OHS.

mymachine.us.mycompany.com:7001 as shown in this sample code example:

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>

4.11.2 Resolving the HTTP 404 Error When Accessing OSB Console

Prior to 12c, the OSB console was accessed using the following URL: http://[HOST]:[PORT]/sbconsole

In 12c, the OSB Console URL has changed to: http://[HOST]:[PORT]/servicebus.

After the upgrade, if you enter http://[HOST]:[PORT]/sbconsole, it should redirect to http://[HOST]:[PORT]/servicebus.

If the redirect fails, and you receive a HTTP 404 error, try direclty entering the 12c URL: http://[HOST]:[PORT]/servicebus.

5 Upgrading Oracle SOA Suite with Oracle Business Activity Monitoring from 11g

You can upgrade from a supported Oracle SOA Suite 11g environment that includes Business Activity Monitoring (BAM) to a SOA 12c (12.2.1.2) environment with the newly redesigned Oracle BAM 12c.

Note:
If you are upgrading from a previous Oracle SOA Suite with BAM 12c release, seeUpgrading Oracle SOA Suite with Business Activity Monitoring from a Previous 12c Release

- Understanding an Upgrade to Business Activity Monitoring 12c (12.2.1.2)
Upgrading from Oracle BAM 11g to BAM 12c cannot be handled with the standard upgrade procedures. You will need to perform several manual configuration tasks to complete the upgrade.

- Understanding the SOA with Oracle BAM 11g Upgrade Process Flow

- Performing the Pre-Upgrade Tasks for Oracle BAM

- Upgrading a SOA with Oracle BAM Domain to 12c
Use this procedure to upgrade a SOA 11g domain that includes Oracle BAM to a SOA 12c (12.2.1.2) domain that will also include Oracle BAM.

- Performing Post Upgrade Configuration Tasks for Oracle SOA with Oracle BAM 12c
To run the SOA 12c domain that will eventually include Oracle BAM 12c, you must perform additional configuration tasks after the upgrade.

- Extending the SOA Domain with Oracle BAM 12c
When you are ready to use Oracle BAM 12c with your upgraded SOA 12c environment, you must extend the domain to include the BAM 12c templates.

- Recovering from a Failed Oracle BAM Upgrade

5.1 Understanding an Upgrade to Business Activity Monitoring 12c (12.2.1.2)

Upgrading from Oracle BAM 11g to BAM 12c cannot be handled with the standard upgrade procedures. You will need to perform several manual configuration tasks to complete the upgrade.

Note:

The procedures described in the following sections apply only to upgrades from 11g. If you are upgrading an already upgraded 12c domain to this 12c release, you will follow the standard upgrade procedures described in Upgrading Oracle SOA Suite and Business Process Management from a Previous 12c Release

Oracle Business Activity Monitoring (BAM) 12c has been completely redesigned for use with Oracle SOA Suite 12c, so there is no direct upgrade path. The schemas, binaries, and directory structure used in Oracle BAM 12c are different than those used with Oracle BAM 11g. Therefore, upgrading from Oracle BAM 11g to BAM 12c cannot be handled with the standard upgrade procedures. You will need to perform several manual configuration tasks to complete the upgrade.

It is also important to understand that the only Oracle BAM 11g objects that can be used in your BAM 12c domain are data objects (DOs) and enterprise message sources (EMS). You will need to manually export these objects to an XML file and then import them into the BAM 12c domain. The other Oracle BAM 11g artifacts, such as dashboards for example, will have to be manually recreated in Oracle BAM 12c domain.

Oracle recommends that you continue to use your Oracle BAM 11g domain after the upgrade to allow time to create and test all of the necessary artifacts. Therefore, before you begin the SOA with Oracle BAM upgrade process, it is strongly recommended that you reinstall the Oracle BAM 11g domain in a separate location so that the source files remain untouched during the domain reconfiguration. You will configure SOA 12c to point to this new 11g domain after the upgrade as your existing 11g Oracle BAM domain will be altered and will not function with SOA 12c.

Note:

There is no upgrade support for an Oracle BAM-only domain (a domain without SOA). If you have a BAM-only domain, and want to upgrade to Oracle BAM 12c, then you must create a new Oracle BAM 12c domain and import data objects and recreate all the dashboards and alerts.

5.2 Understanding the SOA with Oracle BAM 11g Upgrade Process Flow

The following flowchart shows a process overview of upgrading a SOA 11g domain with Oracle BAM to a SOA 12c domain with Oracle BAM 12c.

5.3 Performing the Pre-Upgrade Tasks for Oracle BAM

The tasks in this section should be performed when upgrading a SOA domain with Oracle BAM 11g to 12c.

1. Creating a New Oracle BAM 11g Domain Before You Upgrade

2. Exporting All Oracle BAM 11g Artifacts from the Existing Domain

3. Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

4. Creating a Complete Backup of the Oracle BAM 11g Domain

5.3.1 Creating a New Oracle BAM 11g Domain Before You Upgrade

You will continue to use your existing Oracle Business Activity Monitoring (BAM) 11g domain after the upgrade, so you must install BAM 11g in a new domain home before you upgrade. If you do not create a new (separate) BAM 11g domain, you will not have a functioning BAM domain after the upgrade and you will lose many of your artifacts and configurations.

Note:

If you do not create separate domain for Oracle BAM 11g, then you will lose BAM artifacts and BAM-related configurations only (SOA artifacts will not be impacted).

In addition, any composites referring to BAM artifacts (such as adapters) or new instances will be faulted during runtime.

Use the installation instructions in the 11g version of the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

To preserve your existing 11g BAM environment, use the 11g ICommand to export ALL of your Oracle BAM 11g artifacts (not just DOs and EMS), and then import them into your new Oracle BAM 11g domain so you have a fully functional Oracle BAM 11g domain after the upgrade.

- Exporting All Oracle BAM 11g Artifacts from the Existing Domain

- Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

After the upgrade, you can continue using the Oracle BAM 11g domain. Alternatively, you can extend the 12c SOA domain with Oracle BAM 12c and export the DOs and EMS artifacts from 11g domain and import them into extended Oracle BAM 12c domain. For more information, see Extending the SOA Domain with Oracle BAM 12c.

5.3.2 Exporting All Oracle BAM 11g Artifacts from the Existing Domain

After you install and configure your new Oracle BAM 11g domain in its new location, you will have to use 11g Oracle BAM ICommand utility to export the data from the existing (old) Oracle BAM 11g domain and then import it into the new Oracle BAM 11g domain before you upgrade.

For more information on using the 11g Oracle BAM ICommand command-line utility to export data files, see the "Export" section of Monitoring Business Activity with Oracle BAM.

5.3.3 Importing Oracle BAM 11g Artifacts into the New Oracle BAM 11g Domain

After you have created a complete export XML of your Oracle BAM 11g artifacts (not just the DOs and EMS), you must import the XML file into the newly created Oracle BAM 11g domain. This will ensure that you continue to have a fully functioning Oracle BAM domain after the upgrade and domain reconfiguration.

For more information on using the 11g Oracle BAM ICommand command-line utility to export data files, see the "Import" section of Monitoring Business Activity with Oracle BAM.

5.3.4 Creating a Complete Backup of the Oracle BAM 11g Domain

In the event that the upgrade fails, you will need to restore the entire pre-upgrade environment using a backup version. Make sure that you have created a backup version of the entire Oracle BAM 11g environment before you continue with the upgrade process. Note that the backup domain is separate from the new Oracle BAM11g domain you created in Creating a New Oracle BAM 11g Domain Before You Upgrade.

For more information, see "Backup and Recovery Strategies for Upgrade" in the Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

5.4 Upgrading a SOA with Oracle BAM Domain to 12c

Use this procedure to upgrade a SOA 11g domain that includes Oracle BAM to a SOA 12c (12.2.1.2) domain that will also include Oracle BAM.

Do not perform these tasks until you have created a complete backup of the Oracle BAM 11g domain.

1. Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management
Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

2. Creating the Required 12c Schemas with the RCU
When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

3. Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas

4. Stopping Servers and Processes
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.

5. Running the Upgrade Assistant to Upgrade Schemas

6. Reconfiguring the 11g Domain with the Reconfiguration Wizard

7. Running the Upgrade Assistant to Upgrade Component Configurations

5.4.1 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

Note:
You must install the Oracle Fusion Middleware Infrastructure distribution first before installing other Fusion Middleware products, when Infrastructure is required for the upgrade.

Before you begin, note the following:

- If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0 or 12.2.1.1) you must install the 12c (12.2.1.2) distributions into a new Oracle home. Do not attempt to reuse the existing Oracle home for this upgrade. Upgrading to 12c (12.2.1.2) is not a patch release.

- Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).
Installing Fusion Middleware Infrastructure creates an Oracle home directory and lays supporting software to install other Fusion Middleware products.

- If your SOA domain has other SOA-integrated components, such as Oracle Service Bus, Managed File Transfer, or Oracle B2B, you must install those distributions into the same new Oracle home. Oracle Business Activity Monitoring and Business Process Management are part of the SOA distribution soa_generic.jar.

To install the Oracle SOA Suite component distributions:

1. Sign in to the target system where you want to install the 12c (12.2.1.2) product distribution.

2. Download the following distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Fusion Middleware Infrastructure distribution (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA Suite and Business Process Management distribution (fmw_12.2.1.2.0_soa_generic.jar)

- If you are running Managed File Transfer, Oracle Service Bus or Oracle B2B, download the Managed File Transfer distribution (fmw_12.2.1.2.0_mft_generic.jar), Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar), and Oracle B2B (fmw_12.2.1.2_b2b_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select Skip Auto Updates. Options are:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected, and click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that gets verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed the Infrastructure, repeat steps 3 through 13 to install the other product distributions.

5.4.2 Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.

In Oracle Fusion Middleware 11g releases it was possible to run Business Activity Monitoring (BAM) 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 Business Activity Monitoring 12c (12.2.1.2)

Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

If you are upgrading from 11g, refer to the Pre-Upgrade Checklist to identify the existing schemas in your domain. The following schemas must exist before you upgrade to 12c:

- Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas. Note: If the Service Table schema does not exist, you may 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.

- Oracle Platform Security Services (OPSS) schema (prefix_OPSS). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can 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.

- Audit Services (prefix_IAU)

- WebLogic Services (prefix_WLS). This schema is required for BAM in 12c; BAM does not have its own separate schema in 11g.

- Managed File Transfer (prefix_MFT). This schema was introduced in Release 12c (12.1.3) and is only needed if MFT is part of your domain.

To create the 12c schemas with the RCU:

1. (Optional) If you are upgrading from 11g, and you would like to confirm which schemas are in your existing domain, connect to the database as a user with DBA privileges, and run the following code from SQL*Plus:

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 ;

2. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.2), the certified JDK is 1.8.0_101 and later.
Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

Add $JAVA_HOME/bin to $PATH.

3. Go to the oracle_common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. Start the RCU:

- (UNIX) ./rcu

- (Windows) rcu.bat

5. On the Welcome screen, click Next.

6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.
Click Next.

7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

Table 5-1 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

Option

Description and Example

Host Name

Specify the name of the server where your database is running in the following format:

examplehost.exampledomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

Port

Specify the port number for your database. The default port number for Oracle databases is 1521.

Service Name

Specify the service name for the database. Typically, the service name is the same as the global database name.

For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

examplehost.exampledomain.com

Username

Enter the user name for your database. The default user name is SYS.

Password

Enter the password for your database user.

Role

Select the database user's role from the drop-down list:

Normal or SYSDBA

Table 5-2 Connection Credentials for MySQL Databases

Option

Description and Example

Host Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 5-3 Connection Credentials for Microsoft SQL Server Databases

Option

Description and Example

Unicode Support

Select Yes or No from the drop-down list.

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
MSSQL named instances: A named instance is identified by the network name of the computer plus the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 5-4 Connection Credentials for IBM DB2 Databases

Option

Description and Example

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.

Password

Enter the password for your database user.

If the prerequisite check is successful, click OK to continue to the next page. If the check fails, review the details you entered and try again.

8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

Select the schemas required for Oracle BAM.

Note: The Common Infrastructure Services Service Table (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.

9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.

10. On the Schema Passwords screen, specify the passwords for your schema owners.
Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.

11. On the Map Tablespaces screen, configure the desired tablespace mapping for the schemas you want to create.
Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.

You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.

12. Verify the information on the Summary screen and click Create to begin schema creation.
This screen contains information about the log files that were created from this RCU operation. You can click on the name of a particular log file to view the contents of that file.

13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

5.4.3 Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas

Before upgrading the 11g schemas with the Upgrade Assistant, you must change the names of the following Oracle BAM reconfiguration templates upgrade will fail.

Make sure that you have exported your 11g Oracle Business Activity Monitoring (BAM) data before completing this step. If you are unsure, read Exporting All Oracle BAM 11g Artifacts from the Existing Domain.

The templates can be found in the following 12c directory: $ORACLE_HOME/soa/common/templates/wls

Template Name

Rename To:

oracle.bam.reconfig_template_12.2.1.2.0.jar

oracle.bam.reconfig_template_12.2.1.2.0.jar.old

oracle.bam.reconfig.template_12.2.1.2.0.jar.rename

oracle.bam.reconfig_template_12.2.1.2.0.jar

5.4.4 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all 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 such as Identity Management 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 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 Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To stop your Fusion Middleware environment, follow the steps below.

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic 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

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

5.4.5 Running the Upgrade Assistant to Upgrade Schemas

Follow the standard procedure for upgrading schemas using the Upgrade Assistant.

When upgrading SOA Suite and BPM with Oracle BAM 11g schemas, select the following options on the Available Components screen (the schema names are listed for each):

- Oracle Platform Security Services (_OPSS)

- Oracle SOA (_SOAINFRA)

- Oracle Managed File Transfer (_MFT)

When Oracle Platform Security Services and Oracle SOA are selected, the following dependencies are also selected:

- Oracle Audit Services (_IAU)

- Oracle Metadata Services (_MDS)

- User Messaging Service (_ORASDPM)
NOTE: The 11g _ORASDPM schema has been renamed to _UMS in 12c. However, you must provide the 11g schema name prefix_ORASDPM when prompted in the Upgrade Assistant. The schema will continue to be <prefix>_ORASDPM for upgraded domains since schema names cannot be changed by Upgrade Assistant.

- Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

5.4.5.1 Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading SOA Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

- Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

5.4.5.1.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

5.4.5.1.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 5-5 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

5.4.5.1.2 Upgrading SOA Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

Caution:

Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.

Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

To upgrade product schemas with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the Selected Schemas screen, select the schema upgrade operation that you want to perform:

- Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

Caution:
Upgrade only those schemas that are used to support your 12c (12.2.1.2) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.2).

- All Schemas Used by a Domain to allow the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. 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.

4. The Domain Directory screen appears when Oracle Platform Security Services or Oracle Audit Services is selected 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

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. On the Schema Credentials screen, specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

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

- Enter the database connection details, and click Connect.

- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

Note:
The component ID or schema name is changed for UCSUMS schema as of release 12.1.2.0, which means the Upgrade Assistant does not automatically recognize the possible schemas and displays them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.

If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

5.4.5.1.3 Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

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 ;

In the query result:

- Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.2.0 . Note, however, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

- 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.

- Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.
They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

5.4.6 Reconfiguring the 11g Domain with the Reconfiguration Wizard

After you have renamed the Oracle BAM reconfiguration templates, start the Reconfiguration Wizard and follow the steps as described

The Reconfiguration Wizard will remove the Oracle BAM 11g application, library, BAMDataSource, BAMJMSSserver and BAMJmsSystemResource from the domain.

NOTE: After the upgrade, you must manually remove the Oracle BAM server and cluster after the upgrade as described in the post configuration taskRemoving the Oracle BAM Servers and Clusters from the Domain.

- Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

5.4.6.1 Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

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

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

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.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. 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 before 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 in Upgrading Oracle WebLogic Server.

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the SOA Domain with the Reconfiguration Wizard
You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

5.4.6.1.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup 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. Before updating the domain on each remote Managed Server, create 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 before reconfiguration.

5.4.6.1.2 Starting the Reconfiguration Wizard

To start the Reconfiguration Wizard in graphical mode:

1. Sign 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 child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

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

- (Windows) 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 this command, the following error message might appear 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

5.4.6.1.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.
NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the 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.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The optional categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain. Some common categories are described below.

Advanced Configuration > 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

Managed Servers >Targeting Server Groups

Note:
If you are upgrading a domain that was created in a previous 12c release (such as 12.1.3), you MUST target your servers to the correct Server Groups during the domain reconfiguration phase of the upgrade. Failure to target these servers may result in a failed upgrade and excess downtime.

a. On the Managed Servers screen, target each server to the correct Server Group by selecting the correct group name from the Server Groups drop-down menu.

b. Verify that Each of the servers is targeted to the correct server group and should not show as Unspecified.

Component and Server

Server Group

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

Advanced Configuration > 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.

Advanced Configuration > 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:
When OWSMPM is in its own cluster and not part of SOA or OSB clusters:

- Target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster

- Target only OSB-MGD-SVRS-ONLY to the OSB cluster

- Target WSMPM-MAN-SVER server group to OWSM

- When upgrading 12.1.3.0 to 12.2.1.2 you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

5.4.7 Running the Upgrade Assistant to Upgrade Component Configurations

After the domain reconfiguration, run the Upgrade Assistant (again) to upgrade any remaining component configurations.

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

5.4.7.1 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Components Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

5.4.7.1.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

5.4.7.1.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 5-6 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

5.4.7.1.2 Upgrading Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. If your pre-upgrade environment has multiple WebLogic domains, but the Oracle Web Services Manager (OWSM) Policy Manager is in only one domain, and OWSM agents are in the other domains: On the OWSM Policy Manager screen, provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

4. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. If there are remote managed servers hosting User Messaging Services (UMS) configuration files: On the UMS Configuration screen, provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

Note:
You may need to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See Error while Copying User Messaging Service (UMS) Configuration Files.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard. The Post-Upgrade Actions window describes the manual tasks you must perform to make components functional in the new installation. This window appears only if a component has post-upgrade steps.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

5.5 Performing Post Upgrade Configuration Tasks for Oracle SOA with Oracle BAM 12c

To run the SOA 12c domain that will eventually include Oracle BAM 12c, you must perform additional configuration tasks after the upgrade.

Note:

Oracle recommends that you first run the 12c SOA environment with Oracle BAM 11g. Once you have verified that the environment is functioning as expected, you can extend the domain with Oracle BAM 12c as described in Extending the SOA Domain with Oracle BAM 12c.

1. Starting the Admininstration (Admin) Server

2. Launching the WebLogic Server Administration 12c Console

3. Deleting the UMS JMS Resources Running on the Oracle BAM Server or Oracle BAM Cluster
These steps can be used to remove the UMS JMS resources for standalone or clustered environments. Note the additional steps needed for Oracle BAM cluster.

4. Deleting Subdeployment Resources Targeted to UMS JMS Server Targeted to Oracle BAM
Delete the subdeployment resources targeted to UMS JMS server targeted to Oracle BAM.

5. Removing the Oracle BAM Servers and Clusters from the Domain
While the Admin Server is running, use Weblogic Console to complete the following tasks.

6. Removing Unnecessary Oracle BAM 11g Files from the Upgraded Domain
Use the domainupdater script to remove any unnecessary 11g files from the upgraded domain.

7. For Cluster Upgrades Only: Stop the Admin and Managed Servers
If you are upgrading a cluster, you must stop the Admin and Managed Servers before you execute the pack and unpack commands.

8. For Cluster Upgrades Only: Run the Pack Command where the Admin Server and Managed Servers are Installed
To get the reconfigured domain, including NodeManager, onto the other node in the cluster, execute a managed pack from the Admin Server machine, and then unpack on the remote nodes.

9. For Cluster Upgrades Only: Run the Unpack Command to Replicate the Domain Configuration of SOAHOST1 on SOAHOST2.
Make sure that the Admin and Managed Servers are still stopped and then execute the following unpack command to create a full domain or a subset of a domain

10. Restarting the Admin Server
You must restart the 12c Administration Server before you execute the remaining configuration tasks.

11. Configuring 11g Oracle BAM Adapter to Work With SOA 12c Domain
Once the SOA 12c domain has been upgraded, you must configure the SOA 12c domain to use the Oracle BAM 11g domain.

12. Restarting the SOA Managed Servers
You must restart the SOA Managed Servers to complete the post configuration tasks.

13. Deleting the Existing UMS Email Driver from the SOA Domain
Due to incompatibility issues with the mail patterns, you must delete the UMS driver in Oracle Enterprise Manager.

5.5.1 Starting the Admininstration (Admin) Server

To start the Oracle WebLogic Administration Server, use the following script:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

5.5.2 Launching the WebLogic Server Administration 12c Console

To display the Administration Console:

1. Enter the following URL in a browser:

http://hostname:port_number/console

The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.

2. Log in using the user name and password supplied during installation or another administrative user that you created.

Alternatively, you can access the Administration Console from Fusion Middleware Control, from the home pages of targets such as the Administration Server or Managed Servers.

5.5.3 Deleting the UMS JMS Resources Running on the Oracle BAM Server or Oracle BAM Cluster

These steps can be used to remove the UMS JMS resources for standalone or clustered environments. Note the additional steps needed for Oracle BAM cluster.

1. Determine which JMS Server name is targeted to the Oracle BAM server or Oracle BAM cluster. You may have multiple JMS servers, and it is important to note which server is targeted to the Oracle BAM server or cluster before you continue. If you have only one UMS JMS Server, the default name is UMSJMSServer_auto_1. Always validate that the target of the selected UMS JMS Server is the Oracle BAM server or Oracle BAM cluster.

Navigate to the Summary of JMS Servers screen (shown below). From the Domain Structure menu, expand Services, select Messaging and then select JMS Servers. Locate the UMSJMSServer that is targeted to the Oracle BAM server.

In the example below, UMSJMSServer_auto_3 is the server targeted to the Oracle BAM server.

2. Delete the local queues for the UMS JMS Server targeted to Oracle BAM (UMSJMSServer_auto_3 in this example).

Navigate to the Summary of JMS Modules screen (shown below). From the Domain Structure menu, expand Services, select JMS Modules. Locate UMSJMSSystemResource and click to display the local (and distributed) queues in the Settings for UMSJMSSystemResource screen. You can filter the results to show only those queues targeted to your UMS JMS Server.

3. Oracle BAM Cluster Only: Select all Uniform Distributed Queues targeted only to the Oracle BAM server or cluster (UMSJMSServer_auto_3 in this example). (You can filter by type Uniform Distributed Queues). Click Delete.

CAUTION: Do not delete distributed queues that include server targets other than Oracle BAM. If there are other targeted servers, you must first remove (untarget) the Oracle BAM server from the distributed queue as shown in Step 4.

4. Untarget the Oracle BAM server from the distributed queue (if necessary).

To untarget the Oracle BAM server from the distributed queue, click the Targets tab from the Settings for UMSJMSSystemResource screen. Remove the checkmark next to the Oracle BAM server and click Save. Now you can safely delete the distributed queues as described in Step 3.

5. Delete the local queues that are targeted to the UMS JMS Server.

Select all local queues that are targeted to the UMS JMS Server targeted to Oracle BAM (UMSJMSServer_auto_3) from the Settings for UMSJMSSystemResource screen (as shown below):

6. Click Delete.

5.5.4 Deleting Subdeployment Resources Targeted to UMS JMS Server Targeted to Oracle BAM

Delete the subdeployment resources targeted to UMS JMS server targeted to Oracle BAM.

1. Delete the subdeployment resources from the UMS JMS Server.

From the Settings for UMSJMSSystemResource screen, click the Subdeployments tab.

2. Select the UMS JMS Server targeted to Oracle BAM (in the example below its UMSJMSServer_auto_3).

3. Click Delete.

5.5.5 Removing the Oracle BAM Servers and Clusters from the Domain

While the Admin Server is running, use Weblogic Console to complete the following tasks.

Note:

For more information on navigating through the Fusion Middleware Control Console, see Getting Started with Administering Oracle SOA Suite and Oracle BPM Suite.

1. Navigate to the Summary of JMS Servers screen (shown below). From the Domain Structure menu, expand Services, select Messaging and then select JMS Servers.

2. Select the UMSJMSServer_auto_x from the list. Make sure the Current Target is the Oracle BAM server.

3. Click Delete.

4. Navigate to the Summary of Persisted Stores screen (shown below).

5. Select UMSJMSFileStore_auto_x from the list. (Make sure the Target is the Oracle BAM server.)

6. Click Delete.

7. Navigate to the Summary of Clusters screen (shown below). From the Domain Structure menu, expand Environment and select Clusters.

8. Select bam_cluster from the list of clusters.

9. Click Delete.

10. Navigate to the Summary of Servers screen (shown below). From the Domain Structure menu, expand Environment and select Servers.

11. Select the Oracle BAM server(s) from the list.

12. Click Delete.

5.5.6 Removing Unnecessary Oracle BAM 11g Files from the Upgraded Domain

Use the domainupdater script to remove any unnecessary 11g files from the upgraded domain.

1. Stop the 12c Admin Server:

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

2. Run the domainupdater script from the SOA 12c home to remove any unnecessary legacy 11g files from the upgraded domain.

(UNIX) cd ORACLE_HOME/soa/bam/bin
./domainupdater.sh
Enter the 11g domain path: (ex:)/soa11g/user_projects/domains/soa_domain

(Windows) cd ORACLE_HOME\soa\bam\bin
domainupdater.cmd
Enter the 11g domain path: (ex:)\soa11g\user_projects\domains\soa_domain

3. Restart the 12c Admin Server.

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

5.5.7 For Cluster Upgrades Only: Stop the Admin and Managed Servers

If you are upgrading a cluster, you must stop the Admin and Managed Servers before you execute the pack and unpack commands.

To stop the WebLogic Server:

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

To stop the SOA server:

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

Managed servers must be stopped in the order described in the following:

- Stop the Admin Server and SOA Managed Server(s)

5.5.7.1 Stop the Admin Server and SOA Managed Server(s)

Stop the Managed Servers

Stop all of the 12c servers and processes that are currently running before you begin extending the domain.
Stop the SOA Managed Servers with 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.

Note:
Stop the 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

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 an Administration Server, use the following script:

DOMAIN_HOME/bin/stopWebLogic.sh

When prompted, enter your user name, password and the URL of the administration server

5.5.8 For Cluster Upgrades Only: Run the Pack Command where the Admin Server and Managed Servers are Installed

To get the reconfigured domain, including NodeManager, onto the other node in the cluster, execute a managed pack from the Admin Server machine, and then unpack on the remote nodes.

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

NOTE: The pack and unpack command utility must be run from 12c install directory pointing to the upgraded 11g domain.

Execute the pack command on the server where the Admin Server and one of the Managed Servers is installed.

In our example, you would execute the following on SOAHOST1:

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.2.1 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

- By default, the domainupgradetemplate is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the -template argument to the pack command:

ORACLE_COMMON_HOME/common/bin/

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

5.5.9 For Cluster Upgrades Only: Run the Unpack Command to Replicate the Domain Configuration of SOAHOST1 on SOAHOST2.

Make sure that the Admin and Managed Servers are still stopped and then execute the following unpack command to create a full domain or a subset of a domain

You can create a full domain or a subset of a domain used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.

A sample unpack command code snippet is shown below. Use this as an example only. Note that you must specify the "-overwrite_domain=true" flag on unpack.

For more information on using the pack command, see "Overview of the Pack and Unpack Commands" in Creating Templates and Domains Using the Pack and Unpack Commands.

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle Home directory (the installation directory for the 12.2.1 bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

5.5.10 Restarting the Admin Server

You must restart the 12c Administration Server before you execute the remaining configuration tasks.

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start an Administration Server, use the following script:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

When prompted, enter your user name, password and the URL of the administration server

5.5.11 Configuring 11g Oracle BAM Adapter to Work With SOA 12c Domain

Once the SOA 12c domain has been upgraded, you must configure the SOA 12c domain to use the Oracle BAM 11g domain.

Use the Oracle BAM 11g domain you created in Creating a New Oracle BAM 11g Domain Before You Upgrade.

For more information on how to configure this setup, see "Configuring Oracle BAM Adapter" in the 11g version of the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

5.5.12 Restarting the SOA Managed Servers

You must restart the SOA Managed Servers to complete the post configuration tasks.

Start the WebLogic Server Managed Server with following script:

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Start SOA servers and processes in this order:

1. Oracle Web Services Manager (OWSM) Managed Server

2. Service-Oriented Architecture (SOA) Managed Server

3. Oracle Service Bus (OSB) Managed Server

4. Business Activity Monitoring (BAM) Managed Server

Note:
The startup of a Managed Server will typically start the applications which are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

5.5.13 Deleting the Existing UMS Email Driver from the SOA Domain

Due to incompatibility issues with the mail patterns, you must delete the UMS driver in Oracle Enterprise Manager.

Note that you will create a new driver after you have extended the SOA 12c domain with the Oracle BAM 12c templates.

1. While the Admin Server and all the managed servers are running in the SOA domain, navigate to User Messaging Service, select the usermessagingdriver-mail service targeted to the soa_server.

From the User Messaging Email Driver drop-down menu, select Email Driver Properties as shown below.

2. Select the User Messaging Service Email driver name from the Target Navigation pane.

3. Click Delete.

4. Repeat the process for any other cluster present in the domain.

5.6 Extending the SOA Domain with Oracle BAM 12c

When you are ready to use Oracle BAM 12c with your upgraded SOA 12c environment, you must extend the domain to include the BAM 12c templates.

Complete the following tasks. Note that some tasks are optional.

1. Stop the Admin Server and SOA Managed Server(s)

2. Extend the SOA 12c Domain with Oracle BAM 12c Domain Template

3. Create the New UMS Email Driver for the Oracle BAM Server

4. Import the Oracle BAM 11g data objects and EMS data to the BAM 12c server.

5. Manually recreate the 11g BAM dashboards, alerts, and other artifacts for use in the BAM 12c domain.

6. Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

7. Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional)

8. Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)

5.6.1 Stop the Admin Server and SOA Managed Server(s)

Stop the Managed Servers

Stop all of the 12c servers and processes that are currently running before you begin extending the domain.
Stop the SOA Managed Servers with 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.

Note:
Stop the 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

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 an Administration Server, use the following script:

DOMAIN_HOME/bin/stopWebLogic.sh

When prompted, enter your user name, password and the URL of the administration server

5.6.2 Extend the SOA 12c Domain with Oracle BAM 12c Domain Template

Use the Configuration Wizard to extend the existing SOA domain with Oracle BAM 12c.

1. Launch the Configuration Wizard.

(UNIX) ORACLE_HOME/oracle_common/common/bin
./config.sh

(Windows) ORACLE_HOME\oracle_common\common\bin
config.cmd

2. Select Extend Existing Domain when prompted:

3. Select the following templates on the Templates screen:

- Oracle WSM Policy Manager - 12.2.1.0

- Oracle User Messaging Service - 12.2.1.0

- Oracle BAM Client - 12.2.1.0

- Oracle Enterprise Manager Plugin for BAM - 12.2.1.0

4. Complete the remaining Configuration Wizard screens as described in "Configuring the Oracle SOA Suite and Business Activity Monitoring (BAM) Topology" in Installing and Configuring Oracle SOA Suite and Business Process Management.

Certain Fusing Middleware components such as SOA, OSB and BAM have a dependency on UMS in 12c. If you configure more than one of these components within a single 12.2.1 domain, then each of these components must run within its own cluster — even if there is only one server that runs that component. See Figure 8-1 in Upgrading a Clustered SOA Environment.

When you reach the Advanced Configuration screen of the Configuration Wizard, select Managed Servers, Clusters, and Coherence to create a BAM cluster as described in "Clusters" in Creating WebLogic Domains Using the Configuration Wizard.

5.6.3 Create the New UMS Email Driver for the Oracle BAM Server

While the Oracle BAM server is running in the cluster, use Fusion Middleware Control Console to complete the following tasks:

1. Navigate to the Email Driver Properties screen.

From the Target Navigation pane, select User Messaging Service and from the User Messaging Email Driver drop-down menu, select Email Driver Properties (as shown below).

2. Click Create to add a new UMS Email driver.

3. Provide a unique name for the new Email driver in the Name field as shown below. Note that UMS needs to be configured on each cluster in a 12c domain. Therefore maintain the default selection for Configuration Level as Cluster as shown in the image.

4. Select Use Default Sender Address and enter EMAIL:emailid@company.com. Note that the EMAIL: prefix is mandatory in this field.

5. Click OK to create the new driver with the given properties.

5.6.4 Import the Oracle BAM 11g data objects and EMS data to the BAM 12c server.

Once you have extended the domain to include BAM 12c, you must export the data objects and EMS data from the BAM 11g environment you have been using with SOA 12c. You will then import this data to the SOA with BAM 12c environment.

1. Export the data objects and EMS data from the 11g BAM domain using the 11g ICommand command-line utility. (Note that the EMS definitions were upgraded as part of the standard upgrade process and do not need to be imported.)

The following example shows how to use ICommand 11g to export information about one or more objects in the Oracle BAM server to a XML file:

$11g_ORACLE_HOME/soa/bam/bin/icommand -cmd export -name "/Samples/Call Center" -type dataobject -file C:\CallCenter.xml

NOTE: You may need to modify the ICommand configuration file before you run the script. Specifically, verify that the correct usernames and passwords have been entered. The BAMICommandConfig.xml file is located in WLS_HOME/user_projects/domains/base_domain/config/fmwconfig/servers/bam_server1/applications/oracle-bam_11.1.1/config/.

The following is an example configuration file.

<host>www.example.com</host>
<port>7001</port>
<username>weblogic</username>
<password>welcome1</password>
<dbusername>SOAINFRA</dbusername>
<dbpassword>welcome1</dbpassword>
<dburl>jdbc:oracle:thin:@localhost:1521:orcl</dburl>

2. Import the XML file (created in the previous step) using the 12c BAMCommand command-line utility.

The following example shows how to use 12c BAMCommand to import the information:

$12c_ORACLE_HOME/soa/bam/bin/bamcommand -cmd import -file BPELOrderBookingDataObject.xml -upgrade 1 -username weblogic -port 7001 -host server.yourcompany.com

Note:

When you use the import command with the -upgrade parameter to bring Oracle BAM 11g artifacts into Oracle BAM 12c, some information is modified.

5.6.5 Manually recreate the 11g BAM dashboards, alerts, and other artifacts for use in the BAM 12c domain.

The dashboards, alerts, views, etc. you used in your BAM 11g domain must be recreated for the BAM 12c domain.

See the following sections of the BAM user guide, Monitoring Business Activity with Oracle BAM:

- Creating Dashboards

- Creating Alerts

- Creating Parameters

- Creating and Using Business Views

5.6.6 Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

Oracle strongly recommends that you perform the process cubes migration after extending an upgraded BPM 12c domain with BAM 12c. This migration will ensure that all of the necessary 12c data objects are created for BPM entities. This will also ensure the BPM process analytics data has been migrated from the 11g Process cubes (applicable only if cube tables are populated with run-time data).

While exporting and importing each archive, you will be required to provide the server admininstrator (admin) username and password, as well as the SOAINFRA schema username and password.

Note:

The process cubes migration is a required prerequisite before proceeding with the Monitor Express migration described in Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional).

This step is required even if you did not use Oracle BAM 11g Monitor Express with BPM 11g.

1. Task 1: Disable the Process Metrics.

2. Task 2: Determing the exportType to be used for the migration.

3. Task 3: (UNIX Only) Run migrateBPMProcessCubes script from the 12c SOA home.

4. Task 4: (Windows Only) Export data object definitions and data from 11g BPM Process Cubes and then import them to 12c.

5. Task 5: (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server.

6. Task 6: (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server.

7. Task 7: (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server.

8. Task 8: Restart the Oracle BAM server once the migration has completed successfully.

9. Task 9: Enable the process metrics while the Oracle BAM server is running.

5.6.6.1 Task 1: Disable the Process Metrics.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which Oracle SOA 12c server is installed.

For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.

The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.

The analytics attributes are listed.

10. If not already set to true, change the value of the DisableProcessMetrics attribute to true.

11. Click Apply.

5.6.6.2 Task 2: Determing the exportType to be used for the migration.

The exportType must be decided before migration because once the active instance migration is complete, and process analytics are enabled, you will not be able to go back and migrate the Completed instance data.

The valid exportType values are:

- INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default): Migrates only Active instance fact data archives

- ALL: Migrates all Active and Completed instance fact data archives

5.6.6.3 Task 3: (UNIX Only) Run migrateBPMProcessCubes script from the 12c SOA home.

The migrateBPMProcessCubes shell script performs migration in two phases: export and import. The first phase exports the following archives from BPM Process Cubes, and then the second phase imports them to BAM 12c.

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (if running with -exportType = ALL option)

Before running the migrateBPMProcessCubes script, you must set the following environment variables:

Environment Variable

Description

Sample Location

JAVA_HOME

The location where you install the supported Java Development Kit (JDK).

/u01/oracle/products/jdk_version

ORACLE_HOME

The Oracle home that is created for all the Oracle Fusion Middleware products on a host computer. This read-only directory contains binary and library files, the Oracle Common home directory, and the individual product directories for each Oracle Fusion Middleware product you install.
NOTE: This was known at the Middleware Home in 11g.

/install_location/Oracle_Home

PROD_DIR

The directory within the Oracle home, which contains the binary files associated with a logical product or feature set. The name of each product directory within the Oracle home is predefined by the installer and cannot be changed.

install_location/Oracle_Home/SOA

On UNIX Operating Systems:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

Where:

serverUrl      (mandatory) : BAM 12c Server URL
serverPort     (mandatory) : BAM 12c Server Port
serverUserName (mandatory) : BAM 12c Server  admin user
dbUrl          (mandatory) : SOA DB jdbc URL
dbUserName     (mandatory) : SOAINFRA schema username
exportDir      (mandatory) : A writable Directory where exported archives will be written
exportType     (optional ) : Export Type.  Valid values are
a)INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default):  Migrates only Active instance fact data archives
b)ALL                                             :  Migrates all Active and Completed instance fact data archives
importOnly     (optional ) : If specified, data object definition and data archive export phase is skipped and only import is performed. It is assumed that archives are already present under "exportDir"

Note:

If there were errors during the migration, you may need to manually correct the issues and start the script again. For more information, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5.6.6.4 Task 4: (Windows Only) Export data object definitions and data from 11g BPM Process Cubes and then import them to 12c.

The data object definitions migration is performed in two steps. Step one involves exporting the data from 11g process cubes and step 2 imports the data into 12c.

The first phase exports the following archives from BPM Process Cubes, and then the second phase imports them to BAM 12c.The export command shown below will generate the following archive files under the <exportDir> directory:

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (if running with -exportType = ALL option)

1. Export the data objects and definitions using the following code example: (make sure that you provide your actual directory names)

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

2. Import the data object definitions(DefinitionExport.zip) into the BAM server.

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DefinitionExport.zip> -mode update

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5.6.6.5 Task 5: (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server.

This command uses -datamode and -migrate parameters.

Use the following code example to import the dimension data:

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DimensionExport.zip>  -datamode update -migrate 1

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5.6.6.6 Task 6: (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server.

This command uses -datamode and -migrate parameters.

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

5.6.6.7 Task 7: (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server.

This command uses -datamode and -migrate parameters.

Use this command only if you used the exportType ALL when you migrated the data objects definitions for the BAM 11g process cubes.

cd %ORACLE_HOME%\bam\bin\

run the following command
bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

NOTE: After importing the archive for BAM 12c, review the bamcommand.log.* files under ORACLE_HOME/bam/bin directory to make sure no errors occurred. If error conditions do exist, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5.6.6.8 Task 8: Restart the Oracle BAM server once the migration has completed successfully.

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
bam_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
bam_server_name admin_url

When prompted, enter your user name and password.

5.6.6.9 Task 9: Enable the process metrics while the Oracle BAM server is running.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.

For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.

The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.

The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to false.

11. Click Apply.

5.6.7 Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional)

Prerequisite: Perform the steps in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)..

Complete this optional task only if want to be able to analyze historical data from BAM 11g through the BAM 12c process analytics dashboards. To do this, you must migrate the 11g process analytics data from BAM 11g the Monitor Express data objects to the BAM 12c Process star schema data objects.

Before you can upgrade the 11g Monitor Express data to BAM 12c Process Star schema, you must migrate 11g process cubes to the BAM 12c star schema to ensure that all of the necessary 12c data objects are created for BPM entities. This will also ensure the BPM process analytics data has been migrated from the 11g Process cubes (applicable only if cube tables are populated with run-time data).

Note:

If there are any errors while importing the archive files, you can roll back all of the imported data in the BAM 12c process star schema data objects by running the rollback SQL file.

From a BAM 12c database SQL prompt, log in as the SOAINFRA schema user, navigate to the <PATH> directory and execute the following command:

sql> @rollbackMonitorExpressMigration.sql

For additional error handling procedures, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

1. Disable the Process Metrics.

2. Run the Oracle BAM migration utility to migrate the Monitor Express data.

3. Import the BPM data to Oracle BAM 12c.

4. Enable publishing to BAM 12c.

5.6.7.1 Disable the Process Metrics.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.

For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.

The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.

The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to true.

11. Click Apply.

5.6.7.2 Run the Oracle BAM migration utility to migrate the Monitor Express data.

Data objects and data object definitions were migrated in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only).

The following command will generate the data export for BPM data in zipped CSV files:

java -cp
$DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.interface.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc6.jar:
$ORACLE_HOME/bam/modules/oracle.bam.client/bam-client.jar:
$ORACLE_HOME/bam/lib/bam-schema.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.hwfanalytics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.model.jar    oracle.bpm.metrics.dataobject.migration.application.Migrate11gBAMBPMTo12cDO  PropertyFiles

This command will generate "FactDataExport.zip" file under <PATH> directory.

NOTE: You can specify the composite name in the property file. If a composite name is specified, then data for only those composites will be migrated. If a composite name is not defined in the property file, then all the composite data will be migrated.

#*************************************
#Mandatory Fields
#*************************************
#11g User Name
BAM_11g_USER_NAME= <<11gUserName>>
#12c User Name
BAM_12c_SOURCE_NAME = <<12cUserName>>

#11g URL
BAM_11g_URL=jdbc:oracle:thin:@<<11gBAMSchemaDatabaseIP>>:<<Port>>:<<SID>>
#12c URL
BAM_12c_URL=jdbc:oracle:thin:@<<12cDatabaseIP>>:<<Port>>:<<SID>>

#Path where data to be exported
PATH = <<Path where data need to be exported>>
#*************************************
#Optional Fields
#************************************

COMPOSITE_LIST = <<List of Composite for which data needs to be exported. This is ':' separated>>
#If above mention configurable is missing then all the composite data will be migrated.
DATAOBJECT_FOLDER_PATH = <<DataObject Path If this field is absent then default path will taken as Samples/Monitor Express/BI_>>
#************************************

5.6.7.3 Import the BPM data to Oracle BAM 12c.

This step will ensure that the previously exported BPM Monitor Express data is imported to BAM 12c.

cd $DOMAIN_HOME/bam/bin

./bamcommand -host <<host>> -protocol t3 -dbusername <<DbUserName>>  -dburl jdbc:oracle:thin:@<<DBIP>>:<<Port>><<SID>> -username  <<weblogicUserName>> -cmd import  -file <<Path of BPM FactDataExport zip file >> -mode update -migrate 1

5.6.7.4 Enable publishing to BAM 12c.

Once the migration is complete, enable publishing to BAM 12c by setting the DisableProcessMetrics parameter to false.

1. Log in to the Fusion Middleware Control console.

2. In the Target Navigation pane, expand the Weblogic Domain node.

3. Select the domain in which the Oracle BAM server is installed.

For example, the domain might be soainfra or base_domain.

4. Right-click on the domain and select System MBean Browser.

The System MBean Browser page appears.

5. In the System MBean Browser, expand the Application Defined MBeans node.

6. Under Application Defined MBeans, expand the oracle.as.soainfra.config node.

7. Under oracle.as.soainfra.config, expand the Server: server_name node.

8. Under Server: server_name, expand the AnalyticsConfig node.

9. Under AnalyticsConfig, click analytics.

The analytics attributes are listed.

10. Change the value of the DisableProcessMetrics attribute to false.

11. Click Apply.

Note:

If there are any errors while importing the archive files, you can roll back all of the imported data in the BAM 12c process star schema data objects by running the rollback SQL file.

From a BAM 12c database SQL prompt, log in as the SOAINFRA schema user, navigate to the <PATH> directory and execute the following command:

sql> @rollbackMonitorExpressMigration.sql

For additional error handling procedures, see Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration.

5.6.8 Generating 11g Compatible Process Star Schema Data Views in 12c (Optional)

If you have an Oracle Fusion Middleware 11g application built on top of 11g process star schema views, and you want to continue to use the application in 12c, then you will need to recreate the views after the upgrade. The Star schema database views in 12c are different from the 11g views and cannot be automatically upgraded.

Specifically, the star schema database views in 12c have different names, are based on top of Oracle BAM data objects (and not on process cube tables), and are created at the composite level (instead of process level as in 11g). An automated utility is provided to assist you in recreating your views - both standard and process-specific - for use in your Oracle 12c environment.

1. Task 1: Update the classpath to include the interface JAR file.

2. Task 2: Recreate Standard Views

3. Task 3: Recreate Process-Specific Views

5.6.8.1 Task 1: Update the classpath to include the interface JAR file.

You must updated the CLASSPATH to include the location of the oracle.bpm.analytics.interface.jar file located in the SOA Home.

For example:

DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar

5.6.8.2 Task 2: Recreate Standard Views

Use the Standard View 11g Migration Utility to create 12c compatible versions of the following 11g standard views:

- BPM_ACTIVITY_DEFINITION_V

- BPM_ACTIVITY_INSTANCE_V

- BPM_ACTIVITY_PERFORMANCE_V

- BPM_PROCESS_DEFINITION_V

- BPM_PROCESS_INSTANCE_V

- BPM_PROCESS_PERFORMANCE_V

- BPM_ROLE_DEFINITION_V

Use the following command to run the utility:

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.util.StandardView11gMigrationUtil <initialContextFactory> <protocol> <hostname> <soa-port> <username>[]

Where:

- initialContextFactory is the JNDI Initial Context Factory such as weblogic.jndi.WLInitialContextFactory

- protocol is the RMI / JNDI protocol configured for the target server. Specify t3, IIOP, HTTP, T3s, IIOPS, or HTTPS.

- hostname is the full name of the host such as soa.mycompany.com

- soa-port is the SOA listening port such as 7001

- username is the server login name such as weblogic.

5.6.8.3 Task 3: Recreate Process-Specific Views

Use the Process Specific View 11g Migration Utility to create 12c compatible versions of the following 11g process-specific views:

- BPM_ACTV_INST_<viewIdentifier>_V

- BPM_ACTV_PERF_<viewIdentifier>_V

- BPM_PRCS_INST_<viewIdentifier>_V

- BPM_PRCS_PERF_viewIdentifier>_V

Use the following command to run the utility:

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.utill.ProcessSpecificView11gMigrationUtil <initialContextFactory> <protocol> <hostname> <soa-port> <username > [<composite-name>]

Where:

- initialContextFactory is the JNDI Initial Context Factory such as weblogic.jndi.WLInitialContextFactory

- protocol is the RMI / JNDI protocol configured for the target server. Specify t3, IIOP, HTTP, T3s, IIOPS, or HTTPS.

- hostname is the full name of the host such as soa.mycompany.com

- soa-port is the SOA listening port such as 7001

- username is the server login name such as weblogic.

- composite-name (optional) is the name of a single composite you want to create views

5.7 Recovering from a Failed Oracle BAM Upgrade

This section applies only when there are BAM servers in the domain. As part of BAM Upgrade, you can export BAM archives from 11g and import them into BAM 12c. If you receive any errors during this process, use this section to try to resolve the issues.

- Resolving the CFGFWK-60950 Error

- Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration

- Error Handling for UNIX Operating Systems

- Error Handling for Windows Operating Systems

5.7.1 Resolving the CFGFWK-60950 Error

If you received the CFGFWK-60950 error, rename the BAM templates as described in "Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas" and launch the Reconfiguration Wizard again.

If you received this error, you will need restore your entire pre-upgrade environment, perform the necessary pre-upgrade tasks and then perform the steps in the section listed above before you can attempt the reconfiguration process again.

5.7.2 Error Handling: 11g Process Cubes to BAM 12c Star Schema Migration

You may be able to resolve common errors by rolling back the data changes and rerunning the scripts with modified options.

Rollback All Data Changes:

1. Open a SQL session on the SOA database.

2. Log in as the SOAINFRA schema user and run the following script to roll back any data changes:

"<exportDir>/rollBackBPMProcessCubesMigration.sql"

Review the recommendations for your operating system:

- Error Handling for UNIX Operating Systems

- Error Handling for Windows Operating Systems

5.7.3 Error Handling for UNIX Operating Systems

If any unexpected errors occurred during migration, you can try the following steps to correct the issues:

For Errors that Occurred During the Import Phase:

If the error occurred while importing archives to BAM 12c, rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)., but add the "-importOnly" option. This can save time by skipping the export step.

For example:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

For Errors that Occurred During the Export Phase:

If the error occurred while exporting archives from BPM Process cubes, perform the following tasks:

1. Create a backup copy of the export directory defined as (<exportDir>)

2. Delete the contents of the <exportDir>.

3. Rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)., but remove the "-importOnly" option.

For example:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL]

Additional Information:

You can also try the following to help resolve any issues:

- After importing each archive to BAM 12c, review the bamcommond.log.* files located in the $ORACLE_HOME/bam/bin directory to make sure no errors occurred.

- Review the migration logs located in the <exportDir>/MigrationLogs.* :

5.7.4 Error Handling for Windows Operating Systems

Roll back all of the data changes as described above, and then try the following:

For Errors that Occurred During the Import Phase:

Reimport the archives as described in the following sections:

- Task 5: (Windows Only) Import dimension data (DimensionExport.zip) into the BAM server.

- Task 6: (Windows Only) Import active fact data (ActiveFactDataExport.zip) into the BAM server.

- Task 7: (Windows Only - if exportType=ALL) Import completed fact data (CompletedFactDataExport.zip) into the BAM server.

For Errors that Occurred During the Export Phase:

If the error occurred while exporting archives from BPM Process cubes, perform the following tasks:

1. Create a backup copy of the export directory defined as (<exportDir>)

2. Delete the contents of the <exportDir>.

3. Rerun the shell script "migrateBPMProcessCubes.sh" as described in Migrate 11g Process Cubes to BAM 12c Process Star Schema (BPM Users Only)., but remove the "-importOnly" option.

For example:

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

4. Repeat the remaining migration steps in Migrate the 11g Monitor Express data to BAM 12c Process Star schema. (Optional).

6 Upgrading Oracle SOA Suite and Business Process Management from a Previous 12c Release

If you are upgrading from a previous 12c release, use these steps to upgrade to this release.

Use these procedures to upgrade an existing SOA Suite and Business Process Management 12c (12.1.3, 12.2.1, or 12.2.1.1 ) domain to 12c (12.2.1.2)

Note:
If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0, 12.2.1.1), you must complete all of these tasks to upgrade to 12c (12.2.1.2) . Do not attempt to update the existing domain by installing the 12.2.1.2 distributions into the same Oracle home. Upgrading the domain to 12.2.1.2 is not a patch set installation.

- Understanding an Upgrade from a Previous 12c Release
Upgrading from a previous 12c release involves a different set of upgrade procedures than those used when upgrading from 11g, but still requires a full upgrade.

- Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management
Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

- Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- Stopping Servers and Processes
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.

- Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

- Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

6.1 Understanding an Upgrade from a Previous 12c Release

Upgrading from a previous 12c release involves a different set of upgrade procedures than those used when upgrading from 11g, but still requires a full upgrade.

When upgrading from a previous 12c release such as 12.1.2, 12.1.3, 12.2.1.0 or 12.2.1.1, you will perform a full upgrade to reach 12c (12.2.1.2)

6.2 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

Note:
You must install the Oracle Fusion Middleware Infrastructure distribution first before installing other Fusion Middleware products, when Infrastructure is required for the upgrade.

Before you begin, note the following:

- If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0 or 12.2.1.1) you must install the 12c (12.2.1.2) distributions into a new Oracle home. Do not attempt to reuse the existing Oracle home for this upgrade. Upgrading to 12c (12.2.1.2) is not a patch release.

- Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).
Installing Fusion Middleware Infrastructure creates an Oracle home directory and lays supporting software to install other Fusion Middleware products.

- If your SOA domain has other SOA-integrated components, such as Oracle Service Bus, Managed File Transfer, or Oracle B2B, you must install those distributions into the same new Oracle home. Oracle Business Activity Monitoring and Business Process Management are part of the SOA distribution soa_generic.jar.

To install the Oracle SOA Suite component distributions:

1. Sign in to the target system where you want to install the 12c (12.2.1.2) product distribution.

2. Download the following distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Fusion Middleware Infrastructure distribution (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA Suite and Business Process Management distribution (fmw_12.2.1.2.0_soa_generic.jar)

- If you are running Managed File Transfer, Oracle Service Bus or Oracle B2B, download the Managed File Transfer distribution (fmw_12.2.1.2.0_mft_generic.jar), Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar), and Oracle B2B (fmw_12.2.1.2_b2b_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select Skip Auto Updates. Options are:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected, and click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that gets verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed the Infrastructure, repeat steps 3 through 13 to install the other product distributions.

6.3 Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

- Starting the Upgrade Assistant in Readiness Mode
Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

- Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

- Understanding the Readiness Report
After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

6.3.1 About Running a Pre-Upgrade Readiness Check

You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.

The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.

You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.

You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.

Note:

To prevent performance from being affected, Oracle recommends that you run the readiness checks during off-peak hours.

6.3.2 Starting the Upgrade Assistant in Readiness Mode

Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

To perform a readiness check on your pre-upgrade environment with the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant.

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

Note:
If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter the following error:

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

To resolve this issue, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

For information about other parameters that you can specify on the command line, see:

- Upgrade Assistant Parameters

6.3.2.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 6-1 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

6.3.3 Performing a Readiness Check with the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

Readiness checks are performed only on schemas or component configurations that are at a supported upgrade starting point.

To complete the readiness check:

1. On the Welcome screen, review information about the readiness check. Click Next.

2. On the Readiness Check Type screen, select the readiness check that you want to perform:

- Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.
When you select this option, the screen name changes to Selected Schemas.

- Domain Based allows the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.
When you select this option, the screen name changes to Schemas and Configuration.

Leave the default selection if you want the Upgrade Assistant to check all schemas and component configurations at the same time, or select a specific option:

- Include checks for all schemas to discover and review all components that have a schema available to upgrade.

- Include checks for all configurations to review component configurations for a managed WebLogic Server domain.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.

If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

Depending on the components you select, additional screens may display. For example, you may need to:

- Specify the domain directory.

- Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. Then click Connect.

CAUTION
Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the readiness check with the correct database type selected to ensure that the correct database type is applied to all schemas.

- Select the Schema User Name and specify the Schema Password.

Click Next to start the readiness check.

4. On the Readiness Summary screen, review the summary of the readiness checks performed based on your selections.
If you want to save your selections to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

For a detailed report, click View Log.

Click Next.

5. On the Readiness Check screen, review the status of the readiness check. The process can take several minutes.
If you are checking multiple components, the progress of each component displays in its own progress bar in parallel.

When the readiness check is complete, click Continue.

6. On the End of Readiness screen, review the results of the readiness check (Readiness Success or Readiness Failure):

- If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the actual upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.

- If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check. The log file is managed by the command line options you set.

6.3.4 Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

The format of the readiness report file is:

readiness_timestamp.txt

where timestamp indicates the date and time of when the readiness check was run.

A readiness report contains the following information:

Table 6-2 Readiness Report Elements

Report Information

Description

Required Action

Overall Readiness Status: SUCCESS or FAILURE

The top of the report indicates whether the Upgrade readiness check passed or completed with one or more errors.

If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade.

Timestamp

The date and time that the report was generated.

No action required.

Log file location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated readiness report.

No action required.

Names of components that were checked

The names and versions of the components included in the check and status.

If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, then do not attempt an upgrade.

Names of schemas that were checked

The names and current versions of the schemas included in the check and status.

Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, then do not attempt an upgrade.

Individual Object Test Status: FAIL

The readiness check test detected an issue with a specific object.

Do not upgrade until all failed issues have been resolved.

Individual Object Test Status: PASS

The readiness check test detected no issues for the specific object.

If your readiness check report shows only the PASS status, then you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade.

Completed Readiness Check of <Object> Status: FAILURE

The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index or datatype.

Do not upgrade until all FAILED issues have been resolved.

Completed Readiness Check of <Object> Status: SUCCESS

The readiness check test detected no issues.

No action required.

Here is a sample Readiness Report file. Your report may or may not include all of these checks.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from an 11g release (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

Note:
You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.

6.4 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all 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 such as Identity Management 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 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 Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To stop your Fusion Middleware environment, follow the steps below.

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic 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

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

6.5 Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading SOA Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

- Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

6.5.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

6.5.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 6-3 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

6.5.2 Upgrading SOA Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

Caution:

Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.

Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

To upgrade product schemas with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the Selected Schemas screen, select the schema upgrade operation that you want to perform:

- Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

Caution:
Upgrade only those schemas that are used to support your 12c (12.2.1.2) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.2).

- All Schemas Used by a Domain to allow the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. 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.

4. The Domain Directory screen appears when Oracle Platform Security Services or Oracle Audit Services is selected 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

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. On the Schema Credentials screen, specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

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

- Enter the database connection details, and click Connect.

- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

Note:
The component ID or schema name is changed for UCSUMS schema as of release 12.1.2.0, which means the Upgrade Assistant does not automatically recognize the possible schemas and displays them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.

If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

6.5.3 Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

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 ;

In the query result:

- Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.2.0 . Note, however, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

- 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.

- Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.
They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

6.6 Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

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

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

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.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. 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 before 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 in Upgrading Oracle WebLogic Server.

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the SOA Domain with the Reconfiguration Wizard
You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

6.6.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup 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. Before updating the domain on each remote Managed Server, create 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 before reconfiguration.

6.6.2 Starting the Reconfiguration Wizard

To start the Reconfiguration Wizard in graphical mode:

1. Sign 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 child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

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

- (Windows) 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 this command, the following error message might appear 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

6.6.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.
NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the 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.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The optional categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain. Some common categories are described below.

Advanced Configuration > 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

Managed Servers >Targeting Server Groups

Note:
If you are upgrading a domain that was created in a previous 12c release (such as 12.1.3), you MUST target your servers to the correct Server Groups during the domain reconfiguration phase of the upgrade. Failure to target these servers may result in a failed upgrade and excess downtime.

a. On the Managed Servers screen, target each server to the correct Server Group by selecting the correct group name from the Server Groups drop-down menu.

b. Verify that Each of the servers is targeted to the correct server group and should not show as Unspecified.

Component and Server

Server Group

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

Advanced Configuration > 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.

Advanced Configuration > 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:
When OWSMPM is in its own cluster and not part of SOA or OSB clusters:

- Target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster

- Target only OSB-MGD-SVRS-ONLY to the OSB cluster

- Target WSMPM-MAN-SVER server group to OWSM

- When upgrading 12.1.3.0 to 12.2.1.2 you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

6.7 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Components Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

6.7.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

6.7.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 6-4 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

6.7.2 Upgrading Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. If your pre-upgrade environment has multiple WebLogic domains, but the Oracle Web Services Manager (OWSM) Policy Manager is in only one domain, and OWSM agents are in the other domains: On the OWSM Policy Manager screen, provide the credentials for the WebLogic Administration Server domain where the Oracle Web Services Manager (OWSM) Policy Manager is deployed.

4. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. If there are remote managed servers hosting User Messaging Services (UMS) configuration files: On the UMS Configuration screen, provide the credentials to these servers so that the Upgrade Assistant can access the configuration files.

Note:
You may need to manually copy the UMS configuration files if the Upgrade Assistant is unable to locate them. See Error while Copying User Messaging Service (UMS) Configuration Files.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard. The Post-Upgrade Actions window describes the manual tasks you must perform to make components functional in the new installation. This window appears only if a component has post-upgrade steps.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

7 Upgrading Oracle SOA Suite with Business Activity Monitoring from a Previous 12c Release

If your existing 12c deployment includes SOA Suite with Business Activity Monitoring (BAM), you will need to complete the following tasks to upgrade to the 12c (12.2.1.2) release.

Note:
If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0, or 12.2.1.1), you must complete all of these tasks to upgrade to 12c (12.2.1.2) . Do not attempt to update the existing domain by installing the 12.2.1.2 distributions into the same Oracle home. Moving the domain to 12.2.1.2 is not a patch set installation.

- Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management
Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

- Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- Stopping Servers and Processes
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.

- Upgrading Product Schemas
After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

- Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

7.1 Installing the 12c (12.2.1.2) Product Distributions for Oracle SOA Suite and Business Process Management

Before beginning your upgrade, use the Oracle Universal Installer to install the Oracle Fusion Middleware Infrastrucutre distribution, the Oracle SOA Suite and Business Process Management 12c (12.2.1.2) distribution, and any other SOA Suite products on the target system.

Note:
You must install the Oracle Fusion Middleware Infrastructure distribution first before installing other Fusion Middleware products, when Infrastructure is required for the upgrade.

Before you begin, note the following:

- If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0 or 12.2.1.1) you must install the 12c (12.2.1.2) distributions into a new Oracle home. Do not attempt to reuse the existing Oracle home for this upgrade. Upgrading to 12c (12.2.1.2) is not a patch release.

- Oracle SOA Suite requires the Oracle Fusion Middleware Infrastructure (Oracle WebLogic Server and JRF).
Installing Fusion Middleware Infrastructure creates an Oracle home directory and lays supporting software to install other Fusion Middleware products.

- If your SOA domain has other SOA-integrated components, such as Oracle Service Bus, Managed File Transfer, or Oracle B2B, you must install those distributions into the same new Oracle home. Oracle Business Activity Monitoring and Business Process Management are part of the SOA distribution soa_generic.jar.

To install the Oracle SOA Suite component distributions:

1. Sign in to the target system where you want to install the 12c (12.2.1.2) product distribution.

2. Download the following distributions from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Fusion Middleware Infrastructure distribution (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA Suite and Business Process Management distribution (fmw_12.2.1.2.0_soa_generic.jar)

- If you are running Managed File Transfer, Oracle Service Bus or Oracle B2B, download the Managed File Transfer distribution (fmw_12.2.1.2.0_mft_generic.jar), Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar), and Oracle B2B (fmw_12.2.1.2_b2b_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select Skip Auto Updates. Options are:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the product(s) to install. Product dependencies will be automatically selected, and click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that gets verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed the Infrastructure, repeat steps 3 through 13 to install the other product distributions.

7.2 Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

- About Running a Pre-Upgrade Readiness Check
You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

- Starting the Upgrade Assistant in Readiness Mode
Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

- Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

- Understanding the Readiness Report
After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

7.2.1 About Running a Pre-Upgrade Readiness Check

You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.

The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.

You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.

You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.

Note:

To prevent performance from being affected, Oracle recommends that you run the readiness checks during off-peak hours.

7.2.2 Starting the Upgrade Assistant in Readiness Mode

Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

To perform a readiness check on your pre-upgrade environment with the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant.

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

Note:
If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter the following error:

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

To resolve this issue, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

For information about other parameters that you can specify on the command line, see:

- Upgrade Assistant Parameters

7.2.2.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 7-1 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

7.2.3 Performing a Readiness Check with the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

Readiness checks are performed only on schemas or component configurations that are at a supported upgrade starting point.

To complete the readiness check:

1. On the Welcome screen, review information about the readiness check. Click Next.

2. On the Readiness Check Type screen, select the readiness check that you want to perform:

- Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.
When you select this option, the screen name changes to Selected Schemas.

- Domain Based allows the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.
When you select this option, the screen name changes to Schemas and Configuration.

Leave the default selection if you want the Upgrade Assistant to check all schemas and component configurations at the same time, or select a specific option:

- Include checks for all schemas to discover and review all components that have a schema available to upgrade.

- Include checks for all configurations to review component configurations for a managed WebLogic Server domain.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.

If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

Depending on the components you select, additional screens may display. For example, you may need to:

- Specify the domain directory.

- Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. Then click Connect.

CAUTION
Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the readiness check with the correct database type selected to ensure that the correct database type is applied to all schemas.

- Select the Schema User Name and specify the Schema Password.

Click Next to start the readiness check.

4. On the Readiness Summary screen, review the summary of the readiness checks performed based on your selections.
If you want to save your selections to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

For a detailed report, click View Log.

Click Next.

5. On the Readiness Check screen, review the status of the readiness check. The process can take several minutes.
If you are checking multiple components, the progress of each component displays in its own progress bar in parallel.

When the readiness check is complete, click Continue.

6. On the End of Readiness screen, review the results of the readiness check (Readiness Success or Readiness Failure):

- If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the actual upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.

- If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check. The log file is managed by the command line options you set.

7.2.4 Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.

The format of the readiness report file is:

readiness_timestamp.txt

where timestamp indicates the date and time of when the readiness check was run.

A readiness report contains the following information:

Table 7-2 Readiness Report Elements

Report Information

Description

Required Action

Overall Readiness Status: SUCCESS or FAILURE

The top of the report indicates whether the Upgrade readiness check passed or completed with one or more errors.

If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade.

Timestamp

The date and time that the report was generated.

No action required.

Log file location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated readiness report.

No action required.

Names of components that were checked

The names and versions of the components included in the check and status.

If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, then do not attempt an upgrade.

Names of schemas that were checked

The names and current versions of the schemas included in the check and status.

Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, then do not attempt an upgrade.

Individual Object Test Status: FAIL

The readiness check test detected an issue with a specific object.

Do not upgrade until all failed issues have been resolved.

Individual Object Test Status: PASS

The readiness check test detected no issues for the specific object.

If your readiness check report shows only the PASS status, then you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade.

Completed Readiness Check of <Object> Status: FAILURE

The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index or datatype.

Do not upgrade until all FAILED issues have been resolved.

Completed Readiness Check of <Object> Status: SUCCESS

The readiness check test detected no issues.

No action required.

Here is a sample Readiness Report file. Your report may or may not include all of these checks.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from an 11g release (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

Note:
You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.

7.3 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all 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 such as Identity Management 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 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 Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To stop your Fusion Middleware environment, follow the steps below.

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic 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

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: 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) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: 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. For more information, see stopNodeManager in WLST Command Reference for WebLogic Server.

7.4 Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading SOA Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

- Verifying the Schema Upgrade
After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

7.4.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see:

- Upgrade Assistant Parameters

7.4.1.1 Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 7-3 Upgrade Assistant Command Line Parameters

Parameter

Required or Optional

Description

-readiness

Required for readiness checks
NOTE: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant will create log files and temporary files.

The default locations are:

UNIX:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windows:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command line options.

7.4.2 Upgrading SOA Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

Caution:

Do not start the Upgrade Assistant if purge scripts or scheduled database jobs are running.

Wait until the purge or upgrade is complete before starting the upgrade process. The upgrade will fail if the purge scripts or instance upgrade jobs are running while using the Upgrade Assistant to upgrade your schemas.

If you must start the Upgrade Assistant, stop the purge and be sure to disable any scheduled jobs as described in Enabling and Disabling Background Control Job (Option 6).

To upgrade product schemas with the Upgrade Assistant:

1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

Note:
For more information about any Upgrade Assistant screen, click Help on the screen.

2. On the Selected Schemas screen, select the schema upgrade operation that you want to perform:

- Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

Caution:
Upgrade only those schemas that are used to support your 12c (12.2.1.2) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.2).

- All Schemas Used by a Domain to allow the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. 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.

4. The Domain Directory screen appears when Oracle Platform Security Services or Oracle Audit Services is selected 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

5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

Note:
The Upgrade Assistant does not verify whether the prerequisites have been met.

6. On the Schema Credentials screen, specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

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

- Enter the database connection details, and click Connect.

- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

Note:
The component ID or schema name is changed for UCSUMS schema as of release 12.1.2.0, which means the Upgrade Assistant does not automatically recognize the possible schemas and displays them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.

7. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

Note:

- If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

- Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

8. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.

If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

Click Upgrade to start the upgrade process.

9. On the Upgrade Progress screen, monitor the status of the upgrade.

Caution:
Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.

If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

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.

10. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

Note:
If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

7.4.3 Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

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 ;

In the query result:

- Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.2.0 . Note, however, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

- 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.

- Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.
They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

7.5 Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

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

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

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.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. 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 before 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 in Upgrading Oracle WebLogic Server.

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the SOA Domain with the Reconfiguration Wizard
You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

7.5.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup 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. Before updating the domain on each remote Managed Server, create 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 before reconfiguration.

7.5.2 Starting the Reconfiguration Wizard

To start the Reconfiguration Wizard in graphical mode:

1. Sign 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 child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

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

- (Windows) 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 this command, the following error message might appear 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

7.5.3 Reconfiguring the SOA Domain with the Reconfiguration Wizard

You must first reconfigure your existing domain using the Reconfiguration Wizard before running the Upgrade Assistant.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.
NOTE: For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the 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.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The optional categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain. Some common categories are described below.

Advanced Configuration > 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

Managed Servers >Targeting Server Groups

Note:
If you are upgrading a domain that was created in a previous 12c release (such as 12.1.3), you MUST target your servers to the correct Server Groups during the domain reconfiguration phase of the upgrade. Failure to target these servers may result in a failed upgrade and excess downtime.

a. On the Managed Servers screen, target each server to the correct Server Group by selecting the correct group name from the Server Groups drop-down menu.

b. Verify that Each of the servers is targeted to the correct server group and should not show as Unspecified.

Component and Server

Server Group

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

Advanced Configuration > 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.

Advanced Configuration > 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:
When OWSMPM is in its own cluster and not part of SOA or OSB clusters:

- Target only SOA-MGD-SVRS-ONLY user extensible server group to the SOA cluster

- Target only OSB-MGD-SVRS-ONLY to the OSB cluster

- Target WSMPM-MAN-SVER server group to OWSM

- When upgrading 12.1.3.0 to 12.2.1.2 you also need to target BAM-MGD-SVRS-ONLY to BAM cluster.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

8 Upgrading a Clustered SOA Environment

Describes the process of upgrading to a clustered SOA environment and performing post-upgrade configuration tasks.

- Upgrading a Clustered Topology

- Understanding the SOA Cluster Upgrade Topology

- Using Secured Task Forms in a Clustered Topology
The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task.

- Propagating Domain Configuration to Another Host
After verifying that the upgrade was sucessful, use these steps to propagate the newly upgraded files to another host.

- Post-Upgrade Tasks for Cluster Upgrades

8.1 Upgrading a Clustered Topology

Table 8-1 lists the steps required to upgrade the example clustered, multi-host Oracle SOA Suite topology illustrated in Figure 8-1.

Table 8-1 Oracle SOA Suite and BPM Cluster Upgrade Roadmap

Task

For More Information

Review the upgrade topology, and identify SOAHOST1 and SOAHOST2 on your setup.

See Understanding the SOA Cluster Upgrade Topology

Shut down the Administration Server, all the Managed Servers, and the Node Managers running on SOAHOST1 or SOAHOST2.

See Stopping Servers and Processes

Perform a complete upgrade of your 11g deployment on SOAHOST1. Perform the post-upgrade configurations that apply to your environment.

See Upgrading SOA Suite and Business Process Management from 11g

See Also:

If Business Activity Monitoring (BAM) is part of your domain, see Upgrading a SOA with Oracle BAM Domain to 12c

If Oracle Service Bus (OSB) is part of your domain, see Upgrading Oracle Service Bus (without Oracle SOA Suite) from 11g

After a successful upgrade, propagate the domain configuration of SOAHOST1 on SOAHOST2.

To do this, you must pack the domain on SOAHOST1, and unpack it on SOAHOST2 in a NEW domain.

See Propagating Domain Configuration to Another Host

Restart the Administration Server and the Managed Servers on SOAHOST1 and SOAHOST2.

Starting the Admin Server and SOA Managed Servers

Perform any additional post-upgrade configuration tasks for your environment.

See Performing Post Upgrade Tasks

8.2 Understanding the SOA Cluster Upgrade Topology

Figure 8-1 shows a sample topology of a clustered Oracle SOA Suite deployment with SOA, Oracle Web Services Manager (OWSM), Oracle Service Bus (OSB) and Oracle Business Activity Monitoring (Oracle BAM) in separate clusters across two application hosts, SOAHOST1 and SOAHOST2. The Oracle HTTP Server, Administration Server, Oracle Enterprise Manager Fusion Middleware Control and database are shared with both hosts.

Specifically, this chapter describes the steps required to upgrade a WebLogic domain that contains multiple WebLogic Server clusters that are scaled out to multiple host computers. You can apply the concepts and procedures in this chapter to your own specific Oracle SOA Suite environment.

The steps required to upgrade this sample topology are described in the next section in Table 8-1.

Note:

If you are upgrading Oracle BAM with SOA, see Upgrading a SOA with Oracle BAM Domain to 12c.

Figure 8-1 Clustered SOA Topology

8.3 Using Secured Task Forms in a Clustered Topology

The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task.

If your SOA composite includes a human task form, or if task forms are deployed on non-SOA servers, then you must secure the task form after the upgrade.

8.4 Propagating Domain Configuration to Another Host

After verifying that the upgrade was sucessful, use these steps to propagate the newly upgraded files to another host.

After you have completed your single node upgrade on SOAHOST1, use these steps to propagate the newly upgraded files to another node (in this example the secondary host is called SOAHOST2).

- Copying the template file created in the previous step to SOAHOST2.

- Executing the unpack Command from the 12c Oracle Home on SOAHOST2.

- Completing the following verification steps after the unpack.

8.4.1 Copying the template file created in the previous step to SOAHOST2.

Use the following command to copy domainupgradetemplate.jar file to SOAHOST2:

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

- Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.

8.4.1.1 Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.

In our sample topology, you would execute the following on SOAHOST1:

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle home directory (the installation directory for the 12c (12.2.1.2)bits).

- Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

- By default, the domainupgradetemplate is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the -template argument to the pack command:

ORACLE_COMMON_HOME/common/bin/

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

8.4.2 Executing the unpack Command from the 12c Oracle Home on SOAHOST2.

Make sure that the Administration and Managed Servers are still stopped and then execute the unpack command to create a full domain (or a subset of a domain) used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.

Note:
Do not attempt to unpack the domain on top of an existing domain. Oracle recommends that you unpack the contents of the domain upgrade template jar file into a new domain location.
It is important to note that even if you use the -overwrite_domain=true argument when unpacking the domain, the contents of the existing domain will remain in place and will cause issues with when starting the servers. For this reason, Oracle recommends that you unpack the domain template jar file into a new location, or, manually delete the contents of the existing location before you unpack.

A sample unpack command code snippet is shown below.

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=NEW_DOMAIN_LOCATION

In this example:

- 12c_ORACLE_HOME refers the actual path to the 12c Oracle home directory, the installation directory for the 12c (12.2.1.2).

- Replace NEW_DOMAIN_LOCATION with the actual path to the upgraded domain directory.

- domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.

- domainupgradetemplate is the name assigned to the domain template file.

8.4.3 Completing the following verification steps after the unpack.

1. Verify that WL_HOME, SOA_ORACLE_HOME, UMS_ORACLE_HOME in setDomainEnv.sh script from 11g domain are pointing to 12c.
See Reapplying Customizations to setDomainEnv.sh.

2. Start the Node Manager, WebLogic Administration Server, and the Managed Servers on SOAHOST1 and SOAHOST2 in the following order:

a. On SOAHOST1 and SOAHOST2, start the Node Manager.

b. On SOAHOST1, start the WebLogic Administration Server.

c. On SOAHOST1 and SOAHOST2, start the Managed Servers.

For more information, see Starting Servers and Processes. Carefully review the order in which Managed Servers should be started.

If you cannot start the servers or experience other technical issues, see Troubleshooting the Upgrade

Note:

During the upgrade, the Node Manager configuration files (nodermanager.properties, for example) are moved from 11g_DOMAIN_HOME/wlserver_10.3/ location to the 11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanager location. Therefore, the node manager in 12c has to be started from the 11g_DOMAIN_HOME domain directory.

8.5 Post-Upgrade Tasks for Cluster Upgrades

After a successful cluster upgrade, you may need to perform additional post-upgrade configurations tasks. Perform only those tasks that pertain to your clustered environment.

- Starting the Admin Server and SOA Managed Servers
Restart the Oracle WebLogic Administration server and any other SOA Managed servers.

- Removing OWSM Targets from SOA and OSB Clusters

- Updating OWSM Cross-Component Wiring

- Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

- Preventing Duplicate Messages When Using JMS Transport Proxy Service

8.5.1 Starting the Admin Server and SOA Managed Servers

Restart the Oracle WebLogic Administration server and any other SOA Managed servers.

Start the Administration Server

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start an Administration Server, use the following script:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

When prompted, enter your user name, password and the URL of the administration server

Start the Managed Servers

Start the WebLogic Server Managed Servers with the following script:

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Start SOA servers and processes in this order:

1. Oracle Web Services Manager (OWSM) Managed Server

2. Service-Oriented Architecture (SOA) Managed Server

3. Oracle Service Bus (OSB) Managed Server

4. Business Activity Monitoring (BAM) Managed Server

Note:
The startup of a Managed Server will typically start the applications which are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

8.5.2 Removing OWSM Targets from SOA and OSB Clusters

If your 12c domain includes an Oracle Web Services Manager (OWSM) in its own cluster and you have extended that domain with a SOA cluster and an OSB cluster, then post upgrade you must manually untarget the wsm-pm from the SOA and OSB clusters.

To remove the owsm-pm target from the SOA and OSB clusters:

1. Log in to the WebLogic Server Administration Console 12c.
Enter the following URL in a browser:

http://host name:port_number/console

The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.

2. Select Deployments from Domain Structure.

3. Select wsm-pm under Deployments.

4. In the settings for wsm-pm, select Targets.

5. Select wsm-pm component of type Enterprise Application and select Change Targets.

6. Uncheck SOA cluster and OSB cluster.

7. When prompted, click Yes to apply the changes.

8. REQUIRED: Once the wsm-pm is targeted only to the OWSM cluster, you must rewire the components as described in Updating OWSM Cross-Component Wiring.

8.5.3 Updating OWSM Cross-Component Wiring

After you have removed OWSM targets from SOA and OSB clusters as described in Removing OWSM Targets from SOA and OSB Clusters, you must rewire the OWSM Policy Manager components as described below:

1. Start the Administration (admin) server and one OWSM server.

2. Log in to the Oracle Enterprise Manager Fusion Middleware Control 12c console and navigate to the Cross Components Wiring > Components option.

3. Select OWSM Policy Manager from the list of available components:

4. From the Service End Points table, select the OWSM Policy Manager t3 connection entry and click Publish. The status will change from Out of Sync to Published.

5. Select OWSM Agent from the Component Type list. Select the t3 connection entry and click Bind.

6. Verify that the Service Type for the service end point is OWSM Policy Manager.

7. Repeat steps 5 and 6 to Bind the remaining component types. In this example, you will select com.oracle.ess and Fusion Middleware Control.

8.5.4 Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

After upgrading a SOA Cluster domain to 12.2.1, the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.

See the Administration Console online help for more information on reapplying the EDNTopic.

8.5.5 Preventing Duplicate Messages When Using JMS Transport Proxy Service

In a 12c cluster domain, jmsServers are targeted to migratable targets, which is different from the default behavior in 11g where jmsServers were targeted to an individual server.

When you configure a 12c proxy service based on the JMS transport, set the topic distribution mode to One-Copy-Per-Application or One-Copy-Per-Server. To prevent duplicate messages, do not use Compatibility mode in a clustered environment.

9 Administering and Monitoring the Upgrade of SOA Instances

Describes how open and closed SOA instances are upgraded to 12c (12.2.1) and the options a user has to administer and monitor the upgrade process.

The standard upgrade process for SOA Suite and BPM 12c provides an automated solution that will upgrade your open and closed instances. The upgrade of closed instances can be monitored and configured with the administration scripts described in the following sections:

- Understanding the Instance Upgrade Process

- Understanding Instance Upgrade Background Jobs

- Understanding the Flow Trace Changes in 12c

- Using Purge Scripts Before You Upgrade

- Using the Upgrade Administration Scripts

- Configuring the Administration Scripts

- Stopping Upgrade Sessions and Jobs

- Restarting an Incomplete Upgrade

- Monitoring Upgrade Status with SQL Queries

- Monitoring Upgrade Status with Fusion Middleware Control

- Resolving Instance Upgrade Errors

- Restarting a Failed Upgrade

9.1 Understanding the Instance Upgrade Process

The Upgrade Assistant framework delegates the upgrade of schemas to respective component installations (MDS, ORASDPM, OPSS, SOA, etc.) During the 12c SOA upgrade, the Upgrade Assistant can also upgrade instances.

What is being upgraded?

The SOA installation will also upgrade various components as part of upgrade process, including _MDS schema and the _SOAINFRA schema. The _SOAINFRA schema contains the following schema components:

- Schema definitions - such as tables and indexes

- Metadata - the data required to run the SOA server and SOA composites

Note:

The BPM metadata upgrade begins once you log into Business Process Composer 12c (12.2.1) for the first time (after a successful upgrade).

For more information on using Business Process Composer, see Developing Business Processes with Oracle Business Process Composer.

- Instance Data - the data created by the various composites. Instances can be open or closed.

How are these components upgraded?

During the 12c schema upgrade process, it is important to understand the order in which UA performs the upgrade of these components.

The upgrade occurs in four distinct stages:

1. Upgrade Assistant will upgrade 11g schema definitions.

2. Upgrade Assistant will then upgrade 11g metadata and create background control jobs to upgrade open instances.
NOTE: This process may be time consuming as the jobs will continue to run within UA until the final database job finishes upgrading the open instances. It is important not to close the Upgrade Assistant until the final job is complete.

For example, the time required to upgrade instances depends on the following:

- Size of prefix_SOAINFRA schema (number of open and closed instances)

- System configuration (such as the number of CPI's (cores), memory usage, disk I/O configuration).

- Speed of the system and size of driver tables

3. Once all of the open instances have been upgraded, the background jobs begin upgrading the closed instances. Note that the upgrade of closed instances continues to run in the background even after you close the Upgrade Assistant. However, if the background job is stopped, and there are still closed instances to be upgraded, then you must restart them with the administration scripts.

4. Finally, once the last job finishes upgrading the open instances, the Upgrade Assistant provides the upgrade status and lists the next steps to take in the upgrade process.
You should review the Upgrade Success screen of the Upgrade Assistant to determine your next steps based on the information provided. NOTE: If you are running in -response (silent) mode, this information will be listed in the UA stdout file.

- 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.

- 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 open 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.

Note:

The upgrade of closed instances will continue until all instances have been upgraded or the middle tier is started (such as the SOA managed server, for example.)

If the middle tier is started before all closed instances are upgraded, then the upgrade job will stop. You will have to use the administration scripts to manually restart the upgrade.

9.2 Understanding Instance Upgrade Background Jobs

The background jobs are created by Upgrade Assistant during the _SOAINFRA schema upgrade. These jobs run in the background and automate the upgrade of the open and closed instance data. It is important to understand how these jobs operate within the upgrade process and how you can manage them. The list below describes some important information about these jobs:

- Jobs are created by Upgrade Assistant (UA), but they are managed through administration scripts. You can use the administration scripts to configure how and when these jobs will run, for example.

- Jobs are automatically started after the schema upgrade process.

- Jobs that are initiated through UA are automatically stopped when one of the following occurs:

- The job is complete and all closed instances are migrated to 12c

- A middle tier application is started (a managed server, for example)

- The Stop Jobs script (Option 8) is started

- If closed instances have not yet been upgraded, then the background jobs will continue to run in the background - even after the Upgrade Assistant has been closed.

- If the job is stopped, and there are still instances to be upgraded, you can enable and schedule the jobs to run at another time using the administration scripts.
For more information on configuring the background jobs, see: Enabling and Disabling Background Control Job (Option 6), Stopping Upgrade Sessions and Jobs, and Restarting an Incomplete Upgrade.

9.3 Understanding the Flow Trace Changes in 12c

In 12c SOA, instances are controlled using flowIDs instead of ECIDs. When the Upgrade Assistant upgrades instances from 11g SOA to 12c SOA, there are few differences between the 11g upgraded flow instances and the newly created 12c instances. These differences will not impact the functionality of the flow trace, but it is important to note the differences.

The flow trace XML examples below show the following differences:

- The attributes ActionType and ActionName are new in 12c and are not available in 11g upgraded instances.

- Date and lastUpdatedDate are the same for 11g Upgraded instances.

- ElapsedTime for Entry Instance Id is 0 for 11g Upgraded instances.

Flow trace XML for 11g to 12c upgraded instances:

================================
<audit_trail
ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e"
flowId="96102"  flowCorrelationId="null"  activeInstances="0"
date="2013-09-02 00:09:52.133 PDT"  lastUpdatedDate="2013-09-02 00:09:52.156
PDT"  elapsedTime="23">
<entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02
00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT"
elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel"
type="component">
...
</entry>
</audit_trail>

Flow trace XML in newly created 12c instances:

====================================
<audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a"  flowId="6"
flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M"  activeInstances="0"
date="2013-10-28 05:35:12.738 PDT"  lastUpdatedDate="2013-10-28 05:35:12.825
PDT"  elapsedTime="87">
<entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
...
</entry>
</audit_trail>

In addition, the Recovery status of the new instances created in 12c for a caught fault in BPEL shows the fault as recovered as shown in Figure 9-1:

Figure 9-1 New 12c Instance Flow Trace

However, the Recovery status of an upgraded 11g instance for a caught fault in BPEL shows the fault as Nonrecoverable as shown in Figure 9-2:

Note:
The information passed from the 11g faults is not enough to correctly identify the state of a fault. To handle this, all the actual faults retrieved from 11g are initially identified as nonrecoverable. Dummy faults are then created to set the proper state (BPEL_invoke_recovery, Bpel_activity_recovery).

Therefore, if you see a warning or notice that the 11g faults are nonrecoverable, you can ignore the warning.

Figure 9-2 Upgraded 11g Instance Flow Trace

9.4 Using Purge Scripts Before You Upgrade

Use the purge scripts before you start the instance upgrade to purge the closed 11g instances that you do not need in the upgraded 12c environment. The 12c purge scripts will include non-migrated closed instances. This means that post upgrade, if you schedule to run 12c Purge scripts, the scripts will purge non-migrated closed instances. Using the purge scripts to remove closed instances can help improve the overall performance of the upgrade.

Note:

When upgrading open instances only, you may see an aborted status flow. A flow will be in an aborted state if the child flow was aborted in 11g.

All composite instance associated with this ECID will remain in terminated state.

For more information on using Auto Purge or purge scripts, see Managing Database Growth.

Caution:

Do not schedule purge jobs to run while the Upgrade Assistant background jobs are running. Running the scripts while Upgrade Assistant is running can cause the purge or upgrade to fail.

If you do configure purge scripts to run while Upgrade Assistant is running, you will see: "ORA-20099: ERROR The 11g to 12c Upgrade is in progress".

If you run UA while purge scripts are running, you will see: "SQLException: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired".

9.5 Using the Upgrade Administration Scripts

The upgrade administration scripts are included as part of the Upgrade Assistant functions provided with the SOA Suite installation. These PL/SQL scripts provide additional administrative control over the upgrade of instances. Once upgraded, the instances can be viewed from Oracle Enterprise Manager Console. If more detailed information is needed about the upgrade progress, then use the administration scripts for additional reporting and configuration options.

Note:

The administration upgrade scripts provide detailed information about the upgrade. These scripts provide additional configuration, administration, and monitoring functionality for your instance upgrade. You can configure these scripts to run (or not run) based on your own requirements.

The Fusion Middleware Control Console can also be used to administer and monitor the upgrade process, but you will have more administration options using the administration scripts.

Oracle recommends that you run the Report Upgrade Summary (Option 1) script after using the Upgrade Assistant to monitor Upgrade of closed instances.

For more information about using the Fusion Middleware Control Console to monitor the progress of the upgrade, seeMonitoring Upgrade Status with Fusion Middleware Control.

- Accessing the Upgrade Scripts Menu

- Running the Administration Scripts

9.5.1 Accessing the Upgrade Scripts Menu

There are several scripts that can be used to configure, administer and monitor your instance upgrade. These scripts can be accessed using the soa_upgrade_menu PL/SQL script.

To access the upgrade scripts menu:

1. Locate the /admin directory of the SOA home.
For example:

cd  <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/upgrade/admin

2. Use SQL* Plus to access the _SOAINFRA schema using the schema owner name and password.
For example:

sqlplus dev_soainfra/<welcome1>

where dev is the schema owner prefix you used when the SOAINFRA schema was created, and welcome1 is the schema password.

Note:

If you attempt to access the administration scripts using a user other than <prefix>_SOAINFRA, you will encounter the following error message:

ERROR at line 24:
ORA-06550: line 24, column 3:
PLS-00201: identifier 'CONTROL_MIGRATION.UPGRADE_STATUS_INFO' must be declared

3. Run the soa_upgrade_menu.sql script to see the upgrade administration options menu.

SQL> @soa_upgrade_menu.sql
==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

Table 9-1 describes the functionality of each script.

9.5.2 Running the Administration Scripts

The Administration Scripts Main Menu displays all of the options you have to monitor and administer the background control jobs and other administration tasks such as troubleshooting.

Caution:

The Advanced Options should only be used to troubleshoot the upgrade or to make changes to the upgrade process based on specific upgrade requirements. In most cases these scripts should only be executed by a designated system administrator or Oracle Support.

To run one of the administration scripts, enter an option number when prompted. Table 9-1 describes the functionality of each script.

Table 9-1 Menu Options for Upgrade Administration Scripts

Option Number

Scripts Name

Use this option to...

Description

1

Report Upgrade Summary

View the overall status of the upgrade.

The report is divided into sub-sections and provides an overview of the overall upgrade and the current run.

The Report Upgrade Summary shows the upgrade summary for METADATA, OPEN ECIDS (open instances) and ALL ECIDS (closed instances). The upgrade status is either COMPLETE or OUTSTANDING (still running).

In addition, it describes the following:

- Last upgrade date for closed 11g instances
The Maximum Upgrade Date for Closed 11g Instances section displays the closure date of the last upgraded flow. The upgrade starts with the most recently closed instances and continues until the oldest completed instance is upgraded. An instance flow that closed on January 1, 2014 would be upgraded before a flow that closed on December 1, 2013. A Maximum Upgrade Date of June 1, 2013 indicates that all closed instances up to June 1, 2013 have been upgraded and any instances that were closed before June 1, 2013 are still in the process of being upgrade.

- Upgrade error count
The UPGRADE ERROR COUNT displays the number of errors that have occurred during the upgrade. You can use the upgrade_error_log file to determine the cause of the errors.

For more information on handling upgrade errors, see Resolving Instance Upgrade Errors.

- Instance count since start of upgrade
The Overview Since Start of Upgrade shows the start date and time of the upgrade, the total number of instances to be upgraded and the number of instances remaining.

- Current Run Statistics
Upgrade data from the current upgrade run. Each run is numbered. In the sample report below, the data is from the first run (run:1). A designation of (run:2) would indicate that the upgrade was run for the second time and the statistics displayed are for second run.

- START COUNT: Details how many instances are outstanding as of the start of the RUN. For subsequent upgrade RUNs (run2, run3, etc.) the START COUNT total will detail what was remaining at the completion of the previous run.

- REMAINING COUNT: During the upgrade run a sum of "current instances that have not been processed" is collected every 5 minutes during the RUN. The "current instances that have not been processed" are then subtracted from the START COUNT to produce a REMAINING COUNT. REMAINING COUNT= START COUNT - "current instances that have not yet been processed"

- PROCESSED COUNT:
PROCESSED COUNT= START COUNT - REMAINING COUNT

The report data is shown below:

=============================================
Report Upgrade Summary
(Please wait for report to generate)
=============================================
.
. METADATA : COMPLETE
. OPEN FLOWS : COMPLETE
. ALL FLOWS : COMPLETE
.
. ------------------------------------------
. Date of last upgraded and closed 11g Flows
. ------------------------------------------
. DATE : NOT AVAILABLE OR ALL DATA UPGRADED
.
. NOTE: Closed 11g flows prior to this date
. may not be visible on the EM console
. until they are upgraded.
.
. ---------------------
. UPGRADE ERROR COUNT
. ---------------------
. COUNT : 0

PL/SQL procedure successfully completed.

Enter to continue..
.
---------------------------------------------
Upgrade Start Date and Initial Instance Count
---------------------------------------------
. Upgrade Start Date : 06/MAY/2014:04/50
. Initial Instance Count : 1881
. Outstanding Instances Count : 0
.
------------------------------------
CURRENT RUN STATISTICS (run#: 1)
------------------------------------
. Note: 1/ Statistics maybe from previous run
. until new statistics are generated.
. 2/ Statistics can take 10mins to refresh.
.
. STARTED: 06/MAY/2014:04/50
. ENDED: 06/MAY/2014:04/52
. START COUNT: 1881
. PROCESSED COUNT: 1881
. REMAINING COUNT: 0
.
========= End of Report =====================
Upgrade Counter (Oracle Internal Use): < 300

2

Report upgrade database sessions (Running sessions).

Determine which jobs are still running.

Do NOT use this information to manually kill the jobs.

The option will return running sessions data under 'Module', 'Inst', 'Sid' and 'Serial' columns.

For example:

======================================================
Report Upgrade Database Sessions (Running)
======================================================
.
Module                        Inst  Sid   Serial
---                        --  --   ----
SOAUPGRADECONTROLMAIN         1     122   16535
SOAUPGRADEDATA_0              1     228   14557
SOAUPGRADEDATA_1              1     64    46683
SOAUPGRADEDATA_2              1     180   621
SOAUPGRADEDATA_3              1     130   61577
SOAUPGRADESUBMITJOBS          1     172   66

Monitor job completion through the database scheduler job log.

CAUTION: Do not use this information to stop the sessions. Use the administration script as described in Stopping Upgrade Sessions and Jobs.

3

Report upgrade database background jobs (Completed jobs).

Determine which jobs have completed the upgrade.

The database sessions that perform the instance upgrades are executed as database jobs. Once the jobs are complete, the status can be viewed with this option. The user is not expected to understand what each job does, only to ensure that the status shows success without any errors.

The report displays the control job parameter values, the submitted upgrade job, current status of the job (submitted, waiting, running) and the job thread number (if applicable).

For example:

======================================================
Report Upgrade Database Background Jobs (Completed)
======================================================
.
.  State of last 15 completed Jobs in descending order
.
Log_date                 Job_name                   Status      ERROR
----                 ----                   ---      ----
21-FEB-2014 03:07:36  UPGRADE_SOA_METADATA_JOB      SUCCEEDED   0

4

Report background control job parameters.

View the current background control job parameters.

This option will report the parameters that are passed to the control job which coordinates the instance upgrade.

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

5

Change background control job execution schedule.

Change the repeat interval time and duration of the background control job.

By default, the background control job interval will start at 3AM (local time) and run for 4 hours (240 minutes) every day until all of the closed instances have been upgraded (set in terms freq=daily; byhour=3; byminute=0; bysecond=0). If you want this job to run at a different time, use this option to change the repeat interval.

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is
executed by the database scheduler.
Examples of repeat intervals can be found in the Oracle Database
Administors Guide.
Enter REPEAT INTERVAL:

For more information, see Changing Background Control Job Execution Schedule (Option 5)

NOTE: To change the duration of the run (default is 240 minutes), modify the JOB_MAX_RUNTIME using the Change Background Control Job Parameters (Option 7).

6

Enable/Disable background control job.

Enable or disable the background job.

By default, the Enable/Disable background control job is disabled (ENABLE: FALSE). Enter Y (Yes) to change the current setting. Note that disabling the control job will prevent the background control job from running at the specified repeat interval.

The setting will appear in the Summary Report as ENABLE: TRUE or FALSE.

Enter N (No) to retain the current setting.

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

For more information, see Enabling and Disabling Background Control Job (Option 6)

7

Change background control job parameters.

Change the BATCH_SIZE, MAX_COUNT, JOB_MAX _RUNTIME or DOP (degree of parallel (options 1-4).

Do not change the Advanced Options (options 5-14) unless instructed to do so by Oracle Support to troubleshoot an upgrade.

For most upgrades, the default values for the background control job parameters are sufficient. However, if you need to make changes, review the parameter descriptions in Setting Control Job Parameters (Option 7).

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

8

Stop upgrade database background sessions and jobs.

Stop the current background database sessions or jobs.

Use this option to gracefully stop the current background jobs or sessions as described in Stopping Upgrade Sessions and Jobs

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

9

Reset errored 11g instances.

Once an upgrade is run, check the upgrade_error_log and correct any reported errors. Then, use this option to resubmit those instances to process again in the next upgrade job.

This option will enable the instances with errors to be processed again in the next upgrade job. Use this option only after you have corrected the errors reported in the upgrade_error_log.

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.

Are you sure Y/N:

10

Report Current job run log (Oracle Internal Use).

Generate a report for Oracle Support that shows the parameters used in the current run.

The output of this report can be sent to Oracle Support when troubleshooting an upgrade.

You can also use this report to verify that any changes made to the Control Job Parameters are correct.

Example:
======================================================
Report Current RUN log (Oracle Internal Use)
======================================================
.
Module    Type Comment
---    --- -----
CONTROL  PARM batch_size            => 10000
CONTROL  PARM max_count             => 100000
CONTROL  PARM use_ctl_max_runtime   => 0
CONTROL  PARM use_job_max_runtime   => 0
CONTROL  PARM DOP                   => 4
CONTROL  PARM metadata_job_complete => FALSE
CONTROL  PARM data_job_complete     => FALSE
CONTROL  PARM open_ecids_complete   => FALSE
CONTROL  PARM first_time            => TRUE
CONTROL  PARM sql_trace             => FALSE
CONTROL  PARM metrics               => TRUE
CONTROL  PARM async                 => TRUE
CONTROL  PARM ctl_stoptime_d        => NULL
CONTROL  PARM job_stoptime_d        => NULL
CONTROL  INFO UPGRADE jobs submitted ASYNCRONOUS
METADATA INFO UPGRADE submitting: UPGRADE_SOA_METADATA_JOB
CONTROL  INFO CONTROL procedure waiting for (metadata and/or open ecids)
METADATA INFO UPGRADE UPGRADE_SOA_JOB will wait for UPGRADE_SOA_METADATA_J
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB0
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB1
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB2
DATA     INFO UPGRADE submitting: UPGRADE_SOA_JOB3
DATA     INFO UPGRADE will wait if UPGRADE_SOA_JOB running

11

Exit

Close the Script Administration Menu.

This option will close the menu.

9.6 Configuring the Administration Scripts

This section describes the steps needed to configure the upgrade administration scripts.

- Changing Background Control Job Execution Schedule (Option 5)

- Enabling and Disabling Background Control Job (Option 6)

- Setting Control Job Parameters (Option 7)

- Resetting Errored 11g instances (Option 9)

9.6.1 Changing Background Control Job Execution Schedule (Option 5)

Use Option 5 to change the execution schedule of the Background Control Job.

In the example below, the start time of the job was changed from 3AM to 4AM (local time).

Change Background Control Job Execution Schedule - Repeat Interval
==================================================================
The repeat interval determines when the control procedure is executed by the database scheduler.

Examples of repeat intervals can be found in the Oracle Database Administors Guide.

Enter REPEAT INTERVAL: freq=daily; byhour=4;

BEFORE Change  :  freq=daily; byhour=3;byminute=0; bysecond=0
AFTER Change   :  freq=daily; byhour=4

9.6.2 Enabling and Disabling Background Control Job (Option 6)

Use the Enable/Disable Background Control Job script (Option 6) to enable the start of a background control job OR to prevent the start of a scheduled control job. T

Note:

The background control job is disabled by default (ENABLE: FALSE). If you manually enable the job (ENABLE: TRUE), then you must also manually disable it.

ENABLE/DISABLE CONTROL JOB SCHEDULE
===================================
Disabling the Control Schedule will stop the Control job
from executing at the specified Repeat Interval.
Change ENABLE Y/N:

9.6.3 Setting Control Job Parameters (Option 7)

The Set Control Job Parameters script (option 7) can be used to configure the parameters described in Table 9-2.

Table 9-2 Background Control Job Parameters

Parameter

Default

Description

BATCH_SIZE

10000

Determines the number of updates (inserts, updates and deletes) that are sent to the database at one time for execution.

MAX_COUNT

100000

Determines the number of instances (ECIDs) that are fetched to upgrade before another MAX_COUNT worth of instances is fetched.

JOB_MAX_RUNTIME

240 minutes (4 hours)

This is the maximum number of minutes that a background control job will run.

DOP

4

The number of parallel execution servers associated with a single operation is known as the degree of parallelism (DOP). Parallel execution is designed to effectively use multiple CPUs.

CAUTION: Changing the degree of parallel is an advanced option. Refer to your database administration documentation for more information on setting the appropriate degree of parallelism for your deployment.

SQL_TRACE

FALSE

NOTE: Setting SQL_TRACE to TRUE can be used to debug and troubleshoot, but it may require the DBA to grant "alter session" to the soainfra user as shown below:

$ sqlplus / as sysdba
SQL> grant alter session to <soainfra>;

To Change the Job Control Parameters:

1. Launch the SOA Upgrade Menu using the steps in Accessing the Upgrade Scripts Menu.

Enter 7 in the Enter option field to run the Change Background Control Job Parameters script.

The SOA Upgrade Menu is shown below:

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

2. Enter the number of the parameter you want to change in the Enter Option field.

For example, to change the BATCH_SIZE, enter 1.

A complete list of control job parameters is listed as shown below:

1:  Set BATCH_SIZE
2:  Set MAX_COUNT
3:  Set JOB_MAX_RUNTIME
4:  Set DOP
.
Advanced Options:
.  (Options below for Oracle Internal Use)
.  (Please contact Oracle Support)
.
5:  Set METADATA_JOB_COMPLETE
6:  Set DATA_JOB_COMPLETE
7:  Set OPEN_ECIDS_COMPLETE
8:  Set CTL_MAX_RUNTIME
9:  Set FIRST_TIME
10: Set FIRST_CTL_MAX_RUNTIME
11: Set FIRST_JOB_MAX_RUNTIME
12: Set SQL_TRACE
13: Set METRICS
14: Set ASYNC
.
15: MAIN MENU
.
Enter option :

3. Change the value of the parameter by entering a new value. Click Enter to commit the change. Repeat this process for each parameter you want to change.

You can verify that the change was accepted by looking at the values in the Before Change and After Change fields.

4. Return to the Main Menu by entering 15 in the Enter Option field.

You will return to the main Administration Script menu.

==================================================
1:  Report upgrade summary.
2:  Report upgrade database sessions (Running sessions).
3:  Report upgrade database background jobs (Completed jobs).
4:  Report background control job parameters.
5:  Change background control job execution schedule.
6:  Enable/Disable background control job.
.
Advanced Options:
.
7:  Change background control job parameters.
8:  Stop upgrade database background sessions and jobs.
9:  Reset errored 11g instances.
10: Report Current job run log (Oracle Internal Use).
.
11: EXIT.
.
.   (NOTE: for error SP2-0309, please restart menu)
.
Enter option :

***********************************************************************************************

5. Verify that your changes have been made using the Report Background Control Job Parameters script (Option 4).

======================================================
Report Backgrond Control Job Parameters
------------------------------------------------------
BATCH_SIZE            : 10000
MAX_COUNT             : 100000
JOB_MAX_RUNTIME       : 240
DOP                   : 4
METADATA_JOB_COMPLETE : TRUE
OPEN_ECIDS_COMPLETE   : FALSE
DATA_JOB_COMPLETE     : FALSE
CTL_MAX_RUNTIME       : 1
FIRST_TIME            : FALSE
FIRST_CTL_MAX_RUNTIME : 0
FIRST_JOB_MAX_RUNTIME : 0
SQL_TRACE             : FALSE
METRICS               : TRUE
ASYNC                 : TRUE
-----------------------
ENABLE                : FALSE
REPEAT INTERVAL       : freq=daily; byhour=3; byminute=0; bysecond=0

9.6.4 Resetting Errored 11g instances (Option 9)

If the upgrade encountered errors during the run, resolve the issue(s) and then resubmit the errored instances by resetting the error flow_id from (-1) to null. The instances will be processed in the next scheduled background control job run.

For more information, see Resolving Instance Upgrade Errors.

Reset errored 11g instances
=======================
The 11g instances which have encountered an error will have their
flow_id set to -1. This reset updates the flow_id back to null
so they can be processed in the next exection of the background job.
.
The rows in the upgrade_error_log table will have their type column
set to zero. The rows in this table are not removed so that history
is not lost.
.
NOTE: Ensure to schedule and enable the background job.
Are you sure Y/N:

9.7 Stopping Upgrade Sessions and Jobs

You can use the administration scripts to stop a running session or job.

Note:

If you stop a running upgrade job before it has completed, you will not be able to query the remaining data or view it using Enterprise Manager Console.

The background jobs upgrade the newest instances first, so you can see how far the upgrade has progressed by looking at the timestamp of the last upgraded instance in the Upgrade Summary Report (Option 1) under the Maximum Upgrade Date for Closed 11g instances section.

There are two ways to stop the upgrade of read-only instances:

- Once the background database control job has started, use the Stop Upgrade Database Background Sessions and Job script (Option 8) to stop ALL of the upgrade sessions and jobs that are currently running. It can take a few minutes before all of the jobs have stopped.

Stop Upgrade Database Background Sessions/Jobs
==============================================
All upgrade sessions and jobs should stop but this may require 5 minutes to take affect.

There will be a one minute wait before this procedure returns.
Are you sure Y/N: Y
Enter for MENU

Use the Report Upgrade Database Sessions (Option 2) to verify that there are no jobs running.You can restart the upgrade job, if needed, by scheduling a job to run at a user-defined time. This is the preferred method.

- Start a middle tier application, such as the SOA Managed Server.
Once a mid-tier application such as a managed server is started, the upgrade of closed instances is stopped automatically. You can use the administration scripts to schedule the upgrade job to run at another time.

9.8 Restarting an Incomplete Upgrade

If the instance upgrade is stopped, it must be manually restarted using the administrations scripts as described below.

1. Enable the background control job using administration script option 6 - 'Enable/Disable background control job'.

See Enabling and Disabling Background Control Job (Option 6).

2. Schedule the background control job execution to run at specific time interval using administration script option 5 - 'Change background control job execution schedule'.

See Changing Background Control Job Execution Schedule (Option 5).

3. When the time interval specified in Step 2 is reached, the background control jobs starts. Monitor the upgrade status using the administration script option 1 'Report Upgrade Summary'.

See Option 1 in Table 9-1.

4. Once the upgrade is completed, log in to Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1) and verify that the Data Migration Completed link is displayed under SOA Runtime Health section.

See Verifying Data Migration is Complete.

9.9 Monitoring Upgrade Status with SQL Queries

This section provides SQL queries that can be used to monitor and validate upgrade in addition to the Administration Scripts.

To determine if...

Use this query

More Information

A flow instance has encountered an error during upgrade (flowId is set to -1 or -2).

Select count (*) from composite_instance where flow_id=-1;

select count(*) from composite_instance where flow_id = -1;

select count(*) from cube_instance where flow_id = -2

select count(*) from dlv_message where flow_id = -2;

select count(*) from mediator_instance where flow_id = -2;

Once Upgrade Assistant completes upgrading Open instances, Oracle recommends that you check for rows in UPGRADE_ERROR_LOG table within SOAINFRA schema. This table stores errored data that was not upgraded to 12c. The column ‘type' determines the type of error encountered. The different type of error that can be reported in the UPGRDAE_ERROR_LOG table:

- 0 : These errors were reported in the previous upgrade run. Type will be set to 0 while 'Resetting Errored 11g instances (Option 9)' of the Upgrade Administrative Script is executed.

- 1: Error occurred during the upgrade of instances.

- 2: Error occurred during upgrade of EDN error event store or Adapter rejected messages.

- 9: Error occurred during the upgrade of Metadata

- 12: Generic error occurred during the data upgrade process.

It is important to ensure that no errored records exist in these tables.

For more information, see Resetting Errored 11g instances (Option 9)

All Open instances are upgraded.

select count (*) from cube_instance where state < 5 and flow_id = -1;

select count (*) from dlv_message where  state in (0,1,4) and  flow_id = -1

select count (*) from mediator_instance where component_state between 4 and 15 and flow_id is null;

Run these queries post-upgrade to verify and they should return zero rows if all Open have been migrated.

9.10 Monitoring Upgrade Status with Fusion Middleware Control

In addition to the administration scripts, you can also use the Oracle Enterprise Manager Fusion Middleware Control Console to view the general status of the upgrade. The administration scripts will provide you with more administrative control of the upgrade jobs, but you can monitor the following with the Fusion Middleware Control Console:

Note:

If you need to perform advanced administration tasks for the upgrade, such as modifying the schedule or interval time of the upgrade, for example, you must use the administration scripts as described in Using the Upgrade Administration Scripts.

- Verifying Data Migration is Complete

- Managing an Incomplete (Stopped) Upgrade

- Optimizing the Display of Instances in Enterprise Manager

- Viewing Instances that Faulted During the Upgrade

- Viewing Instances Created Prior to Composite Redeployment

9.10.1 Verifying Data Migration is Complete

In the target navigation pane of Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1) and verify that the Data Migration Completed link is displayed under SOA Runtime Health section as shown below:

Figure 9-3 SOA Runtime Health: Data Migration Completed

Click Data Migration Complete and verify that the following message is displayed:

Figure 9-4 Migration Completed

Click OK to close the Migration Completed dialog box. You will see the SOA Runtime Health migration status message (Figure 9-5).

Figure 9-5 SOA Runtime Health: Migration Status Message

Click Close this message. The following confirmation dialog appears:

Figure 9-6 Hide Data Confirmation

Click Yes to hide the data migration completed alert. The Close the message button will disappear from the SOA Runtime Health section.

Click No to retain the alert in the SOA Runtime Health section.

9.10.2 Managing an Incomplete (Stopped) Upgrade

You can use Fusion Middleware Control to manage an incomplete upgrade, which can occur in the following situations:

- None of the open or closed instances are upgraded.

- Some of the open instances have upgraded. For example, if you stop the background control job manually using administration script option 8 (Stop upgrade database background sessions and jobs) during the upgrade of open instances.

- Only open instances have been upgraded.

- Some or none of the closed instances have been upgraded.

Note:

If you start the SOA managed servers before the instance upgrade is complete, Fusion Middleware Control will show the upgrade status as Data Migration Not Complete and you will have to manually restart the upgrade as described in Restarting an Incomplete Upgrade.

If the upgrade is not yet complete, Fusion Middleware Control can provide the maximum creation date for all 11g instances that have not yet been upgraded. This is important because the maximum creation date can also help you determine why some instances might not be visible in the 12c Enterprise Manager Console. For example, if you notice that some older 11g closed instances are not be visible in the Fusion Middleware Control console, you can check the maximum creation date for all non-upgraded instances to help you determine if its because the upgrade has not reached those instances yet.

To verify the status of an incomplete (stopped) upgrade using Middleware Control do the following:

In the target navigation pane of Oracle Enterprise Manager Fusion Middleware Control, expand SOA, click soa-infra (soa_server1). In the SOA Runtime Health section of the screen you will see the current status of the upgrade. For an incomplete upgrade, the status will be Data Migration Not Complete. You can refresh this screen every 5 minutes.

Figure 9-7 SOA Runtime Health: Data Migration Not Complete

Click Data Migration Not Complete and the following message is displayed:

Figure 9-8 SOA Runtime Health: Migration Not Complete Status Message

Data Migration Status:

- Active Instances: Shows the status of upgraded open instances. In the example above, the open instances have already been upgraded (status will be Completed).

- Inactive Instances: Shows the status of upgraded closed instances. In the example above, closed instances older than July 9, 2013 have not yet been upgraded. The upgrade is performed newest to oldest. Any instances that have not yet been upgraded will not appear in any Fusion Middleware Control reports or views. You can refresh the report every 5 minutes.

Note:

For a detailed report of the running upgrade, run the Report Upgrade Summary script (Option 1) as described in Running the Administration Scripts.

Once all the closed instances are upgraded, the link will change to Data Migration Completed as shown in Figure 9-4.

9.10.3 Optimizing the Display of Instances in Enterprise Manager

If your upgrade includes migrating a large number of instances (closed and open), you may experience performance issues when loading Enterprise Manager flow trace. To prevent performance degradation, create an index as described in the following steps:

1. Stop the Administration Server and any running managed servers.

2. Connect to SOAINFRA schema from SQLPLUS and execute the following command:

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

3. Restart the Administration Server and managed servers.

9.10.4 Viewing Instances that Faulted During the Upgrade

The 11g instances that incur a fault and fail during the upgrade can be seen only at the composite level post-upgrade. These instances will not be displayed at the partition level.

To view these instances, navigate to the Flow Instances tab of the deployed composite as shown in Figure 9-9:

Figure 9-9 Using the composite level to view instances that faulted during upgrade

NOTE: Use Search Options to specify a specific instance creation time or date range.

9.10.5 Viewing Instances Created Prior to Composite Redeployment

If a composite is redeployed with the same pre-upgrade revision, then you must navigate to the partition level (instead of composite level) to view these instances as shown in Figure 9-10.

Instances created after the upgrade, however, can be viewed in the 12c composite level.

Figure 9-10 Using the partition level to see instances created prior to upgrade

9.11 Resolving Instance Upgrade Errors

If the upgrade fails or the UPGRADE ERROR COUNT section of the Report Upgrade Summary report (Option 1) shows that there were errors in the current run, you must resolve the errors before resubmitting the instances to upgrade.

The upgrade_error_log can be used to diagnose the error situation and may provide guidance on how to resolve the issue. For more information on resolving common upgrade errors, see Recovering From a Failed Upgrade.

The table below describes each of the errors and possible resolutions:

Error Type

Description

Error Message

Resolution

0

These errors were reported in the previous upgrade run.

Type will be set to 0 after resetting the errored instances as described in Resetting Errored 11g instances (Option 9)).

Error message giving details about error occurred based on previous error type.

Correct the errors from the previous run and reset using Administrative Script.

1

Error occurred during the upgrade of instances.

The error message will have actual error thrown from the Upgrade script. It will also show a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

Debugging the root cause can be done by looking at the actual error along with the trace to get the location of the error.

ECID populated in the info column will be helpful in getting the data for failed instance.

2

Error occurred during upgrade of EDN error event store or Adapter rejected messages.

The error message will contain the string upgrade_rejected_message/upgrade_edn_message to determine which component it failed

It will contain the reason for failure along with the id of the message which failed.

Debugging can be done by analyzing the actual reason of the error. To get the details of the adapter/edn message which has failed the id logged as part of ERROR_MSG can be used.

9

Error occurred during the upgrade of metadata.

It will have details of the composite_dn for which the metadata upgrade has failed

It will have the actual error thrown from Upgrade script also with a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

Debugging can be done by looking at the actual error along with the trace to get the location of the error. Info column will give the whole composite_dn for which the metadata upgrade has failed.

12

Generic error occurred during the data upgrade process and not pertaining to any single instance.

Info will only contain the string migrate_soa

It will have the actual error thrown from Upgrade script also with a stack trace which will point out the line in the Upgrade PL/SQL script where the error has occurred.

This error type will be reported during upgrade run when the data upgrade as a whole fails and not necessarily pertaining to any particular instance.

An example of this type of error may be the TEMP table space issue.

9.12 Restarting a Failed Upgrade

Once the errors have been resolved, use the following steps to restart the upgrade:

1. Fix the error condition(s) displayed in the upgrade_error_log.

2. Remove the error flags from the upgrade_error_log as described in Resetting Errored 11g instances (Option 9). This will allow the errored instances to be resubmitted in a subsequent run.

3. Enable the background control job as described in Enabling and Disabling Background Control Job (Option 6). You will have to trigger another upgrade run.

4. If necessary, change the repeat interval time and duration of the background control job as described in Changing Background Control Job Execution Schedule (Option 5).

5. Monitor the upgrade status using the Report Summary Upgrade script (Option 1). The UPGRADE ERROR COUNT section of the report should show 0 errors. If errors persist, resolve the issue and repeat these steps.

10 Performing Post Upgrade Tasks

Summarizes the tasks you might have to perform after upgrading to Oracle SOA Suite 12c.

Note:

There are additional component-specific post upgrade tasks for the following:

For Business Activity Monitoring (BAM), see Upgrading Oracle SOA Suite with Oracle Business Activity Monitoring from 11g

For Oracle Service Bus (OSB), see Performing Post Upgrade Tasks for Oracle Service Bus

For User Messaging Service (UMS), see Upgrading User Messaging Service.

- Performing Post Upgrade Tasks

- Verifying the Upgraded Components Work as Expected

10.1 Performing Post Upgrade Tasks

The following tasks should be performed after an upgrade:

- Updating the SOA Infrastructure Common Properties
Use Oracle Enterprise Manager Fusion Middleware Control 12c to update the data display options in your upgraded environment.

- Reapplying Start Script Properties for JVM

- Reapplying Customizations to setDomainEnv.sh

- Reapplying Customizations to XEngine Configuration Files

- Copying Custom XPath Classes

- Recreating Partition-Specific Roles for Application Roles and Policies

- Upgrading Business Process Management (BPM) Metadata

- Configuring an Oracle Fusion Middleware 12c Audit Data Store

- Upgrading ServerSocket with Remote Clients

- Reconfiguring Threads for SOA 12c

10.1.1 Updating the SOA Infrastructure Common Properties

Use Oracle Enterprise Manager Fusion Middleware Control 12c to update the data display options in your upgraded environment.

If you are upgrading from Oracle Fusion Middleware 11g, and you restricted the display of instances and faults to a specific number of days, you will need to update this setting after the upgrade. In 12c, the default query duration setting is captured in hours and not days.

To update the query duration setting after the upgrade:

1. Log in to the Fusion Middleware Control 12c administration console:

http://machinename.mycompany.com:7001/console

2. Navigate to the SOA Infrastructure Common Properties screen by selecting the SOA managed server (ex: soa_server1) from the navigation panel.

3. Update the Default Query Duration as shown in the image below.

10.1.2 Reapplying Start Script Properties for JVM

If you used a start script to specify required startup properties, or to perform any other work required at start up in your 11g environment, then you will need to reapply the properties post-upgrade.

Specifically, if you have configured JRockit JVM arguments in your 11g environment, then these configurations must be reapplied post-upgrade. Oracle recommends that you use either startup-plan.xml or startscript.xml for configuring JVM startup parameters.

Caution:

Failure to update the start script arguments may prevent you from starting the SOA and OSB servers after the upgrade.

To enable the scripts:

1. In the nodemanager.properties file, set the StartScriptEnabled property to true. (The default is false.) If your start script is named startWebLogic.sh or startWebLogic.cmd, Node Manager uses one of those scripts as the default.

2. If you want to specify a custom start script, set the StartScriptName property to the name of your script in the nodemanager.properties file.

Node Manager sets the JAVA_VENDOR, JAVA_HOME, JAVA_OPTIONS, SECURITY_POLICY, CLASSPATH, and ADMIN_URL. It retrieves these values from the ServerMBean, ServerStartMBean, and SSLMBean when you use the Administration Console to start the server, or WLST connected to the Administration Server. When you use WLST connected directly to the Node Manager, you can specify the values; otherwise, they are left empty.

Node Manager combines all of the command line startup options (-D flags) that are specified in the ServerStartMBean Arguments attribute, as well as the SSLArguments into a single environmental variable called JAVA_OPTIONS. SSLArguments are retrieved from the values in the SSLMBean. The SSLMBean is inspected for ignoreHostnameVerification, HostnameVerifier, and ReverseDNSAllowed values, then those values are appended to the -D flags. All of those flags comprise the SSLArguments parameter. All of the values for SSLArguments as well as Arguments in the ServerStartMBean comprise the JAVA_OPTIONS environment variable that is defined for the start script. In addition, the script will append any of its own defined values onto this environment variable.

10.1.3 Reapplying Customizations to setDomainEnv.sh

If servers do not start, or they start in AdminMode, the cause is most likely that the setDomainEnv.sh changes from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.

To determine if this is the cause, compare the setDomainEnv file from your pre-upgrade backup to the new 12c setDomainEnv file. If there are differences, then make the same changes in the new setDomainEnv file.

10.1.4 Reapplying Customizations to XEngine Configuration Files

Any pre-upgrade changes made to the XEngine configuration files, such as SeverityConfig.xml, will be overwritten by new, regenerated configuration files during the domain reconfiguration process. Therefore, all customized settings used in the pre-upgrade configuration files will need to be reapplied after the upgrade.

For example, if you added a section for SNIP in the pre-upgrade XEngine configuration file, SeverityConfig.xml, the same section will have to be added to the new, post-upgrade SeverityConfig.xml file.

10.1.5 Copying Custom XPath Classes

If you modified the default XPath classes in your pre-upgrade environment, then after the upgrade you will need to copy the customized XPath classes to the new 12c Oracle home as shown in the example below:

Copy the custom XPath classes from your pre-upgrade backups. Classes are found in the following directory:

/11g_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

to the following 12c directory:

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

10.1.6 Recreating Partition-Specific Roles for Application Roles and Policies

After the upgrade, you will have to recreate any partition-specific roles used in your 11g environment.

Partition application roles for existing applications are not recreated by the 12c upgrade process. Instead, you must manually create these roles using the following WLST script:

sca_createDefaultPartitionAppRoles partition

10.1.7 Upgrading Business Process Management (BPM) Metadata

The Business Process Management metadata upgrade begins once you log into Business Process Composer 12c (12.2.1.2) for the first time (after a successful upgrade).

For more information on using Business Process Composer, see Developing Business Processes with Oracle Business Process Composer.

10.1.8 Configuring an Oracle Fusion Middleware 12c Audit Data Store

As a part of the overall upgrade process, you should have created the IAU schema in the database where your other Oracle Fusion Middleware schemas reside.

For more information about the main administration tasks and tools you use to manage the audit store, audit policies, and bus-stop files, see Managing the Audit Data Store in Securing Applications with Oracle Platform Security Services

10.1.9 Upgrading ServerSocket with Remote Clients

There is a change in behavior in which the ServerSocket is created when you upgrade from Oracle Release 11g to Release 12g. Because of this, remote clients might not able to connect to the ServerSocket when the hostname is configured as localhost. As a workaround, the localhost should be changed to hostname.

10.1.10 Reconfiguring Threads for SOA 12c

Starting in Oracle SOA Suite 12c (12.2.1.2), work managers handle most SOA-related work threads. The thread configurations you specified for SOA 11g will not apply to your upgraded SOA 12c environment. You will have to reconfigure the threads after upgrading to SOA 12c.

For more information on using the new threading model, see "Tuning the SOA Infrastructure" in Tuning Performance.

10.2 Verifying the Upgraded Components Work as Expected

After a successful upgrade, you should perform the following tasks to make sure that the components are still working as expected and that there are no issues with the new deployment.

- Starting Servers and Processes
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

- Verifying the Domain Component Configurations Upgrade

10.2.1 Starting Servers and Processes

After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

The components may be dependent on each other so they must be started in the correct order.

Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To start your Fusion Middleware environment, follow the steps below.

Step 1: Start the Administration Server

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start the Administration Server, use the startWebLogic script:

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

Step 2: Start Node Manager

To start Node Manager, use the startNodeManager script:

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

Step 3: Start Oracle Identity Management ComponentsStart any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

Step 4: Start the Managed Servers

To start a WebLogic Server Managed Server, use the startManagedWebLogic script:

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Start SOA servers and processes in this order:

1. Oracle Web Services Manager (OWSM) Managed Server

2. Service-Oriented Architecture (SOA) Managed Server

3. Oracle Service Bus (OSB) Managed Server

4. Business Activity Monitoring (BAM) Managed Server

Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

Step 5: Start System Components

To start system components, such as Oracle HTTP Server, use the startComponent script:

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

You can start system components in any order.

10.2.2 Verifying the Domain Component Configurations Upgrade

To verify that the domain component configurations upgrade was successful, log in to the Administration console and the Fusion Middleware Control using the following URLs, and verify the upgraded version numbers for each component:

Administration Console URL: http://administration_server_host:administration_server_port/console

Fusion Middleware Control URL: http://administration_server_host:administration_server_port/em

Note:

After the upgrade, you must run all of your administration tools from the new 12c (12.2.1.2) Oracle home and not from the 11g Oracle home.

A Troubleshooting the Upgrade

This appendix describes some common procedures for troubleshooting a failed upgrade, domain reconfiguration or server start issues.

- Reviewing the Release Notes

- Resolving Server Start Errors
If the administration or managed servers do not start after the upgrade, you may need to re-apply any customizations added to startup scripts, files and classes.

- Recovering From a Failed Upgrade

- OWSM Data Source Connection Failure During Upgrade from 12c (12.1.3 or 12.2.1.0) to 12c (12.2.1.2)

- Troubleshooting a Failed BAM Upgrade

- Reapplying an EDNTopic to SOA JMS Module After Upgrade

- Troubleshooting Oracle Service Bus

- Troubleshooting Oracle Managed File Transfer (MFT) Upgrade Issues
If you encounter an upgrade error while upgrading Oracle Managed File Transfer, refer to these troubleshooting tasks to correct the issue.

- Error Starting OWSM After Upgrading to 12c

- Encryption Issues During Upgrade

- Upgrading Unsupported Domains with the Upgrade Assistant

- Business Rules Audit Trail Not Showing After Instance Upgrade

- Resolving a Coherence Cache Exception

- WSDL Generated Missing Elements for Custom Exception

- Failure to Connect to the ServerSocket through Remote Clients

- Troubleshooting Invalid Objects in Schema Registry
Schemas with a post-upgrade status of INVALID may indicate a failed upgrade, but not in all situations.

A.1 Reviewing the Release Notes

Make sure that you review the release notes to determine if any known issues could be impacting your upgrade. You can find the release notes in the Oracle Fusion Middleware 12c (12.2.1.2) library.

A.2 Resolving Server Start Errors

If the administration or managed servers do not start after the upgrade, you may need to re-apply any customizations added to startup scripts, files and classes.

If servers do not start, or they start in AdminMode, the cause is most likely that changes to startup scripts or domain variables from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.

To determine if this is the cause, compare the pre-upgrade startup scripts or files from your backups to the new 12c scripts and files. If there are differences, then update files as described in the following procedures.

- Reapplying Customizations to setDomainEnv.sh

- Reapplying Start Script Properties for JVM

- Reapplying Customizations to XEngine Configuration Files

- Copying Custom XPath Classes

A.2.1 Reapplying Customizations to setDomainEnv.sh

If servers do not start, or they start in AdminMode, the cause is most likely that the setDomainEnv.sh changes from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.

To determine if this is the cause, compare the setDomainEnv file from your pre-upgrade backup to the new 12c setDomainEnv file. If there are differences, then make the same changes in the new setDomainEnv file.

A.2.2 Reapplying Start Script Properties for JVM

If you used a start script to specify required startup properties, or to perform any other work required at start up in your 11g environment, then you will need to reapply the properties post-upgrade.

Specifically, if you have configured JRockit JVM arguments in your 11g environment, then these configurations must be reapplied post-upgrade. Oracle recommends that you use either startup-plan.xml or startscript.xml for configuring JVM startup parameters.

Caution:

Failure to update the start script arguments may prevent you from starting the SOA and OSB servers after the upgrade.

To enable the scripts:

1. In the nodemanager.properties file, set the StartScriptEnabled property to true. (The default is false.) If your start script is named startWebLogic.sh or startWebLogic.cmd, Node Manager uses one of those scripts as the default.

2. If you want to specify a custom start script, set the StartScriptName property to the name of your script in the nodemanager.properties file.

Node Manager sets the JAVA_VENDOR, JAVA_HOME, JAVA_OPTIONS, SECURITY_POLICY, CLASSPATH, and ADMIN_URL. It retrieves these values from the ServerMBean, ServerStartMBean, and SSLMBean when you use the Administration Console to start the server, or WLST connected to the Administration Server. When you use WLST connected directly to the Node Manager, you can specify the values; otherwise, they are left empty.

Node Manager combines all of the command line startup options (-D flags) that are specified in the ServerStartMBean Arguments attribute, as well as the SSLArguments into a single environmental variable called JAVA_OPTIONS. SSLArguments are retrieved from the values in the SSLMBean. The SSLMBean is inspected for ignoreHostnameVerification, HostnameVerifier, and ReverseDNSAllowed values, then those values are appended to the -D flags. All of those flags comprise the SSLArguments parameter. All of the values for SSLArguments as well as Arguments in the ServerStartMBean comprise the JAVA_OPTIONS environment variable that is defined for the start script. In addition, the script will append any of its own defined values onto this environment variable.

A.2.3 Reapplying Customizations to XEngine Configuration Files

Any pre-upgrade changes made to the XEngine configuration files, such as SeverityConfig.xml, will be overwritten by new, regenerated configuration files during the domain reconfiguration process. Therefore, all customized settings used in the pre-upgrade configuration files will need to be reapplied after the upgrade.

For example, if you added a section for SNIP in the pre-upgrade XEngine configuration file, SeverityConfig.xml, the same section will have to be added to the new, post-upgrade SeverityConfig.xml file.

A.2.4 Copying Custom XPath Classes

If you modified the default XPath classes in your pre-upgrade environment, then after the upgrade you will need to copy the customized XPath classes to the new 12c Oracle home as shown in the example below:

Copy the custom XPath classes from your pre-upgrade backups. Classes are found in the following directory:

/11g_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

to the following 12c directory:

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

A.3 Recovering From a Failed Upgrade

Recovering from a failed upgrade depends on when the error(s) occurred. Review the following to determine how to recover:

- If there are errors while running the Upgrade Assistant to upgrade _SOAINFRA schema, you must fix the errors in the schema and rerun batch jobs.
Note that this recovery method only applies when you are running the Upgrade Assistant for the first time and you selected the Schema option.

- If there are errors while running the Reconfiguration Wizard, you must restore from source environment and restart the upgrade from the beginning.

- If there are errors while running the Upgrade Assistant to upgrade WebLogic Component Configurations option, then you can fix the errors and rerun the Upgrade Assistant. The second time you run the Upgrade Assistant there is no need to restore from backup and restart the upgrade process from the beginning. This process is reentrant.

- If there are errors while running the Upgrade Assistant to upgrade schemas, and the error occurs during the upgrade phase, you will have to restore from backup, correct the issues, and then restart the upgrade from the beginning. If the error occurs during the examine phase, however, you can correct the issues and restart the Upgrade Assistant. Errors that occur prior to the upgrade phase are reentrant.

For more information on troubleshooting your upgrade, see "General Troubleshooting Guidelines" in the Upgrading with the Upgrade Assistant.

Note:

If you received the CFGFWK-60950 error, rename the BAM templates as described in "Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas" and launch the Reconfiguration Wizard again.

If you received this error, you will need restore your entire pre-upgrade environment, perform the necessary pre-upgrade tasks and then perform the steps in the section listed above before you can attempt the reconfiguration process again.

For more information on resolving BAM-specific issues, see Recovering from a Failed Oracle BAM Upgrade.

A.4 OWSM Data Source Connection Failure During Upgrade from 12c (12.1.3 or 12.2.1.0) to 12c (12.2.1.2)

When you select All configurations used by the domain when running the Upgrade Assistant, the upgrade can fail at the examination phase with the WSMERROR-00015 error. This error can occur when the pre-upgrade domain is created with Multi-DataSource connection.

Error Message:

[2015-09-22T10:46:54.552-07:00] [WSM] [INCIDENT_ERROR] [upgrade.WSM.WSMPLUGIN]oracle.ias.update.exception.UpgradeException: WSMERROR-00015: Failed to read the Oracle WSM datasource connection details.at oracle.wsm.lifecycle.upgrade.impl.WSMUpgradePlugin.initializePluginData(WSMUpgradePlugin.java:396)

When upgrading to 12c (12.2.1.2), the Upgrade Assistant expects a generic datasource connection. Since this error is detected during the Examination phase, you can go back and correct the issue and continue with the upgrade without restoring from backup.

To complete the upgrade, complete the following steps:

1. Navigate back to the Datasource screen in the Upgrade Assistant.

2. Change the "mds-owsm" data source to be a generic data source.

3. Restart the Upgrade Assistant and, when prompted, select All configurations used by the domain.

4. After a successful upgrade, you can change the "mds-owsm" data source back to a multi-DS.

A.5 Troubleshooting a Failed BAM Upgrade

When upgrading a domain containing Oracle Business Activity Monitoring (BAM), note that there are additional BAM-specific troubleshooting procedures.

For more information, see Recovering from a Failed Oracle BAM Upgrade.

A.6 Reapplying an EDNTopic to SOA JMS Module After Upgrade

After upgrading to 12c (12.2.1.2), the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.

This is a known issue and can occur in both clustered and unclustered environments.

See the Administration Console online help for more information on reapplying the EDNTopic or contact Oracle Support.

A.7 Troubleshooting Oracle Service Bus

If you experience post-upgrade issues with Oracle Service Bus, review the troubleshooting procedures described in Troubleshooting Oracle Service Bus Upgrade.

A.8 Troubleshooting Oracle Managed File Transfer (MFT) Upgrade Issues

If you encounter an upgrade error while upgrading Oracle Managed File Transfer, refer to these troubleshooting tasks to correct the issue.

Some common upgrade error messages for Managed File Transfer are listed below:

SQLException: ORA-04020: deadlock detected while trying to lock object

Resolution: Make sure that you selected Managed File Transfer on the Available Components screen of the Upgrade Assistant. If you do not select Oracle Managed File Transfer, the upgrade will not include MFT schema.

Creating Backward Compatibility of SOAP Services

When upgrading from the 12.1.3.0 to 12.2.1.2 release, and you have Managed File Transfer-specific projects created in older versions using JDev, you must correct the WSDL definition of existing SOA/SOAP projects by opening them with JDev and redeploying the composite.

This is necessary when MFT is the target for SOA composite (not when it is a source for SOA).

A.9 Error Starting OWSM After Upgrading to 12c

If there was a custom trust keystore configured in Enterprise Manager 11g prior to the upgrade, you may encounter issues with starting the OWSM.

Specifically, if after upgrading an 11g domain running OWSM to 12c, you receive the following error in the OWSM server log (after the second startup), then you must manually correct this issue:

<Error> <HTTP> <srvgdysoap01.nov.com> <wls_wsm1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <26c804bb-15a7-46de-a81e-82565fcd2f28-00000004> <1418929621034> <BEA-101216> <Servlet: "PolicyManagerValidator" failed to preload on startup in Web application: "/wsm-pm".

If wsm-pm application will not start, you must perform the following steps:

1. Roll back the upgrade to 11g by restoring the backup files.

2. Complete the upgrade steps again using the Upgrade Assistant.

3. Start the OWSM server

Note:

It is very important to only start the OWSM server once and leave it running. If you stop and restart it then the NPE will present itself and you will have to roll back again

4. Execute the following WLST command against the running OWSM server from the <domain_home>/oracle_common/common/bin location:

exportMetadata('wsm-pm','<wsm server>','location to write the zip')

where <wsm_server> is the name of the WLS server running OWSM ('wsm_server1' for example)

5. Extract the MDS archive and go to /configuration/WLS/ and open the file there. The file name is the name of the domain.

6. Search for the property entries containing the string 'keystore.inst.0'. There are probably several of them in a row and they look like

<orares:property ........</orares:property>

7. Delete these properties from the file.

8. Rebuild the archive and import it back to the running server with the command:

importMetadata('wsm-pm','<wsm server>','location of zip')

9. Restart the servers.

A.10 Encryption Issues During Upgrade

If you received the following error message during the reconfiguration, you may need to apply additional policy files to the JDK and restart the upgrade from your backup:

JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation

To prevent this error from reoccurring, apply the policy files before the subsequent upgrade as described in:

- 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.

A.10.1 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. For more information, 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.

A.11 Upgrading Unsupported Domains with the Upgrade Assistant

If you receive an error from the Upgrade Assistant stating that the specified domain cannot be upgraded, then your domain configurations are not supported for this release. For more information on supported configurations and domain restrictions, see Understanding SOA Domain Upgrade Restrictions.

Do not attempt to upgrade or schemas or domain configurations in an unsupported domain.

A.12 Business Rules Audit Trail Not Showing After Instance Upgrade

The audit trail for upgraded 11g instances of the Decision Service Component will not be available post-upgrade. The audit trail for new 12c instances will continue to display.

A.13 Resolving a Coherence Cache Exception

If you see the following WebLogic Cache Provider Coherence exception then it is likely that you are not following an enterprise deployment topology recommendation to specify a specific ListenAddress.

When you see this exception, you must set the ListenAddress for your managed server as shown below:

Exception:

weblogic.cacheprovider.coherence.CoherenceException:
at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)
at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)
at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)
at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)

Resolution:

1. Log in to the WebLogic Server Console.

2. Navigate to Servers.

3. Locate the Managed Servers (SOA or OSB, for example).

4. Modify the Listen Address from localhost to 127.0.0.1 or provide the actual machine name.

A.14 WSDL Generated Missing Elements for Custom Exception

If your EJBs contain custom exceptions, and you export the Web Service Description Language (WSDL) file from your EJB business service, the generated WSDL file will not have the custom exception properties in it. You will need to manually edit the WSDL file to include these custom exception properties after the upgrade.

The issue is limited only to the WSDL generation part of the file. During runtime, the custom exception thrown from the EJB will be mapped to the respective elements in the SOAP fault. The response payload will have the elements populated corresponding to the properties of the custom exception.

A.15 Failure to Connect to the ServerSocket through Remote Clients

There is a change in behavior in which the ServerSocket is created when you upgrade from Oracle Release 11g to Release 12g. Because of this, remote clients might not able to connect to the ServerSocket when the hostname is configured as localhost. As a workaround, the localhost should be changed to hostname.

For more information, see "Configuring Oracle Socket Adapter" Understanding Technology Adapters.

A.16 Troubleshooting Invalid Objects in Schema Registry

Schemas with a post-upgrade status of INVALID may indicate a failed upgrade, but not in all situations.

If the post-upgrade schema status appears as INVALID, it may indicate that the schema update failed. You should examine the logs files to determine the reason for the failure.

EXCEPTION: Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID in the schema version registry table, but that does not indicate a failure. Synonym objects become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Pre-General Availability Draft Documentation Notice

If this document is in public or private pre-General Availability status:

This documentation is in pre-General Availability status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Pre-General Availability Draft Documentation Notice

If this document is in private pre-General Availability status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your pre-General Availability trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.