Note:
This guide is meant to be used as a reference tool for your upgrade. Always consult your comonent-specific upgrade documentation for detailed information about the supported upgrade starting points, as well as the prerequisites and upgrade paths for specific installation types.This section describes the following:
The Oracle Fusion Middleware Upgrade Assistant is used to upgrade supported 11g and 12c component schemas, component configurations, and standalone system component configurations to Fusion Middleware 12c (12.2.1.1). As of release 12c (12.2.1.1), the Upgrade Assistant can also be used to run a pre-upgrade readiness check.
oracle_common/upgrade/bin/ua
oracle_common\upgrade\bin\ua
When you run the Upgrade Assistant, it performs the following tasks:
—readiness mode, the Upgrade Assistant runs a pre-upgrade check on the schemas and component configurations associated with a domain. You must perform this check while the domain is online.Note:
Before you start the Upgrade Assistant, Oracle recommends that you create a non-SYSDBA user. See Creating a Non-SYSDBA UserThe Upgrade Assistant is used in conjunction with other Fusion Middleware tools and processes to complete an upgrade of supported Oracle Fusion Middleware 11g and 12c components to the latest release.
The 11g to 12c upgrade process is very different from previous releases. To understand how the Upgrade Assistant and the other upgrade tools are used in the upgrade process, see Understanding the 12c Upgrade Process
In a typical upgrade, the Upgrade Assistant may be used several times, as described below:
The Upgrade Assistant can be run in -readiness mode to identify potential upgrade issues before you perform an actual upgrade. The readiness check can be performed while the system is online. Readiness check is a read-only operation that scans your existing domain or database schemas and produces a text file with the results of the scan. Readiness check does not require schemas to be a part of any particular domain. If your pre-upgrade environment has issues, you can correct those issues and then rerun the readiness check before you upgrade..
Alternatively, you can run the Readiness Check in -response mode to perform a silent readiness check using a response file. For more information on using a response file with the Upgrade Assistant, see Starting the Upgrade Assistant in Response File Mode.
Understanding the difference between the Examine Phase and a Readiness Check
The Examine phase of the upgrade process is a separate operation from running a readiness check. Typically the readiness checks are more thorough than the checks performed during the Examine phase. The readiness check is a read-only process performed before you start the actual upgrade, while the Examine phase occurs just before you click Upgrade and identifies potential issues with the schemas and configuration data.
Note:
Run the readiness check before you start with an actual upgrade. If you have performed any of the upgrade steps, you should not run readiness check as the results can be invalid.CAUTION: If you perform an upgrade and encounter issues that prevent a successful upgrade, you may have to revert to your backed-up, pre-upgrade environment and start the upgrade again. Running the readiness check can help identify some of these issues and prevent extended system downtime.
The Upgrade Assistant provides two options for upgrading schemas: Individually Selected Schemas and All Schemas Used By a Domain.
Individually Selected Schemas
This option enables you to choose which component schemas to upgrade. Select this option when you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain..
For example, if you want to make a trial run of Upgrade Assistant by creating schemas with RCU that are outside the domain, and then use Upgrade Assistant to upgrade them.
All Schemas Used By a Domain
This option allows the Upgrade Assistant to detect all of the available schemas within the specified domain and to include them in the upgrade. This is also known as a domain assisted schema upgrade.
Review the list of available schemas before you begin the upgrade by querying the schema version registry.
This optional step can be used if you want to manually query the schema_version_registry table before you start the upgrade process. It is important to note that the Upgrade Assistant identifies all schemas that are available for an upgrade and allows you to select the individual schemas you want to upgrade or allow Upgrade Assistant to upgrade all of the schemas in the domain. In addition, when you run the Upgrade Assistant in —readiness mode, you will receive a report with all of the schemas and their current pre-upgrade versions.
If you are using an Oracle database, connect to the database as a user having Oracle DBA privileges, and run the following from SQL*Plus to get the current version numbers:
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
The following report is generated when saved to a SQL script, for example version.sql.
If the number in the "VERSION" is at 11.1.1.7.0 or higher, and the STATUS column is 'VALID', then the schema is supported for upgrade.
schema_version_registry table retains the schemas at their pre-upgrade version after the upgrade.
Tip:
Compare the information you collect from the schema version registry and the corresponding schemas to determine whether there are schemas in your domain that are not available for an upgrade yet.
Notes about the schemas that need to be upgraded
For most components, the only schema version starting points that are valid for upgrading are 11g Release 1 (1.1.1.7.0, 11.1.1.8.0, or 11.1.1.9.0) or 12c (12.1.2, 12.1.3, or 12.2.1.0). If your schemas are not at a supported version, then you must upgrade them before using the 12c (12.2.1.1) upgrade procedures.
Some components, such as Oracle Enterprise Data Quality and Oracle Golden Gate Veridata, support an upgrade from versions other than the standard Oracle Fusion Middleware supported versions.
Refer to your component-specific installation and upgrade documentation for additional information about the schemas that are required for your upgrade.
If you used an OID-based policy store in 11g, make sure that you create a new 12c (12.2.1.1) OPSS schema before you perform the upgrade. After the upgrade, the OPSS schema will still remain LDAP-based store.
You can only upgrade schemas for products that are available for upgrade in the Oracle Fusion Middleware 12c (12.2.1.1) release. Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.1).
When schemas are created in your database, the Repository Creation Utility (RCU) creates and maintains a table called schema_version_registry. Refer to this table before you perform an upgrade as some schemas may not require an upgrade.
NOTE: The Schema(s) column shows the default schema name format of prefix and schema name separated by an underscore (_) character. The default prefix is DEV, but you may have created new prefixes for your schemas while using the RCU.
Table 1-1 Schemas that can be upgraded to Oracle Fusion Middleware 12c (12.2.1.1)
| Component Name | Schema(s) | Schema Version Before Upgrade | Schema Version After Upgrade | Dependencies and Additional Information |
|---|---|---|---|---|
|
Audit Services1 |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
No dependencies. 12.2.1.0 is the latest version for this schema. |
|
Metadata Services |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
No dependencies. |
|
Platform Security Services2 |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
The 12.2.1.0 is the latest version for this schema. |
|
Common Infrastructure Services (LocalSvcTbl) |
|
12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
The |
|
User Messaging Service |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
When upgrading a system that is a new installation of 12.2.1 the schema name will be called |
|
WebLogic Diagnostic Framework |
|
11.1.1.7 12.1.2.0 12.2.1.0 |
12.2.1.1 |
|
|
Data Integrator (Master and Work Repository) |
|
11.1.1.7 11.1.1.9 12.1.2.0 12.1.3.0 12.2.1.0 |
12.2.1.1 |
None. |
|
SOA Infrastructure (including Oracle Business Activity Monitoring, Business Process Management, and Oracle Service Bus |
|
11.1.1.7 11.1.1.9 12.1.3 12.2.1.0 |
12.2.1.1 |
The |
|
Oracle Enterprise Scheduler |
|
11.1.1.7 11.1.1.9 12.1.3 12.2.1.0 |
12.2.1.1 |
|
|
Oracle Managed File Transfer |
|
12.1.3.0 12.2.1.0 |
12.2.1.1 |
The prefix_MDS, prefix_IAU, and prefix_UMS must also be upgraded. |
|
Oracle WebCenter Content Server |
|
11.1.1.7 11.1.1.83 11.1.1.9 12.2.1.0 |
12.2.1.1 |
The prefix_MDS schema must be upgraded first. |
|
Oracle WebCenter Enterprise Capture |
|
11.1.1.8 12.2.1.0 |
12.2.1.1 |
The prefix_MDS and prefix_OPSS schemas must be upgraded first. |
|
Oracle WebCenter Portal |
|
11.1.1.74 11.1.1.8 12.2.1.0 |
12.2.1.1 |
The prefix_MDS schema must be upgraded first.. |
| Oracle WebCenter Sites | prefix_SITES |
12.2.1.0 | 12.2.1.1 | |
|
Enterprise Data Quality |
|
11.1.1.7.3 12.1.3.0 12.2.1.0 |
12.2.1.0 |
12.2.1.0 is the latest version for this schema. |
|
Golden Gate Monitor |
|
11.1.1.7 12.1.3.0 12.2.1.0 |
12.2.1.0 |
12.2.1.0 is the latest version for this schema. |
| GoldenGate Studio | prefix_OGGSTUDIO |
12.2.1.0 | 12.2.1.1 | |
|
Veridata |
|
11.2.1.0 12.1.3.0 12.2.1.0 |
12.2.1.0 |
12.2.1.0 is the latest version for this schema. |
You can use the Upgrade Assistant to upgrade supported component configurations to 12c (12.2.1.1).
When you use the Upgrade Assistant to upgrade your configurations, it automatically determines the list of components that are configured and can be upgraded to the latest version. After you run the Upgrade Assistant for schema upgrades, you will use the Reconfiguration Wizard to reconfigure your domain. The Upgrade Assistant is used again, after the reconfiguration, to upgrade any remaining configuration properties.
You can use the Upgrade Assistant to upgrade the following component configurations to 12c (12.2.1.1):
CAUTION: Do not attempt an upgrade if you want to continue using existing Fusion Middleware 11g components that have been deprecated or not yet available for use in the 12.2.1.1 release.
Oracle Data Integrator (ODI)
Oracle Enterprise Data Quality (EDQ)
Oracle Forms
Oracle Reports
Oracle Golden Gate Monitor (OGGMON)
Oracle Golden Gate Veridata
Oracle HTTP Server (OHS)
JRF Infrastructure (WLS)
Oracle MapViewer
Oracle Managed File Transfer (MFT)
Oracle Traffic Director (OTD)
Oracle User Messaging Service (UMS)
Oracle WebCenter Content (WCC)
Oracle Web Services Manager
Note:
This is not a complete list of tasks you may be required to complete before starting your upgrade process. The Oracle Fusion Middleware Pre-Upgrade Checklist provides a list of all of the tasks that may be required for a successful upgrade. This checklist is located in the component-specific upgrade guides and should be reviewed before starting an upgrade.If you are using an Oracle database, you can recompile database objects before running the Upgrade Assistant by connecting to the database as SYS and running the following from SQL*Plus:
SQL>@/rdbms/admin/utlrp.sql
This will compile the database objects.
Then use the following query to ensure there are no invalid database objects:
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
None of the database objects should be INVALID before you upgrade.
If there are any invalid objects, run the utlrp.sql command again. If the problem persists, you should file a service request.
Before you install the new 12c (12.2.1.1) distributions and begin upgrading your existing Oracle Fusion Middleware deployment, be sure you have backed up all system-critical files; including all of the databases that host your Oracle Fusion Middleware schemas.
Performing a complete database backup prior to performing a schema upgrade is a prerequisite for running Upgrade Assistant. In the Upgrade Assistant prerequisites GUI screen, you will be required to acknowledge that backups have been performed, before proceeding with the actual upgrade.
For more information, see Backing Up Your Oracle Fusion Middleware Environment and Upgrading and Preparing Your Oracle Databases for 12c .
Note:
Your system backup must include theSYSTEM.SCHEMA_VERSION_REGISTRY$ table.SYSTEM.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 before you run the Upgrade Assistant.
Note:
Performing these backups prior to performing a schema upgrade is a prerequisite for running Upgrade Assistant. In the Upgrade Assistant prerequisites GUI screen, you will be required to acknowledge that backups have been performed, before proceeding with the actual upgrade.Before running Upgrade Assistant, shut down all Oracle Fusion Middleware Managed Servers, Administration Servers, and system components (such as OHS) that may be using the schemas or configuration data you want to upgrade.
In addition, the databases that contain Fusion Middleware database schemas must be quiesced before running Upgrade Assistant. You can either shutdown and restart the database server, or ensure that there are no other database users operating on the same database instance that will be upgraded by Upgrade Assistant. Failure to do so may result in an incomplete or failed upgrade.
If you are running Node Manager, you should also stop Node Manager. You can do this by closing the console window in which Node Manager is running, or by using the stopNodeManager WLST command.
Instructions for stopping an Oracle Fusion Middleware environment are provided in "Stopping an Oracle Fusion Middleware Environment".
Oracle recommends that you create a non-SYSDBA user called FMW to run the Upgrade Assistant. The FMW user has the privileges required to modify schemas, but does not have full administrator privileges.
Note:
Thev$xatrans$ table does not exist by default. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, grant 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;
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;
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.
You can use the optional command-line interface arguments, documented in this topic, to upgrade your Oracle Fusion Middleware components to the latest version. In addition, a response file can be generated to automate some of the upgrade tasks.
This topic contains the following sections:
The Upgrade Assistant is used to upgrade schemas, component configurations and standalone system components.
Note:
The Upgrade Assistant should be run by a non-SYSDBA user whenever possible. The steps to create a user who has the privileges required to upgrade the schemas are described in Creating a Non-SYSDBA User.Table 1-2 lists the command-line parameters you can use while running the Upgrade Assistant in the GUI mode. The following example shows the usage of these parameters on your respective operating system:
On UNIX operating systems:
Change directory to ORACLE_HOME/oracle_common/upgrade/bin
Enter the command: ./ua -help
On Windows operating systems:
Change directory to ORACLE_HOME\oracle_common\upgrade\bin
Enter the command: ua.bat -help
Note:
If you get an Xlib error when starting the Oracle Upgrade Assistant such as "Failed to connect to server", "Connection refused by server", or "Can't open display", then you must set the DISPLAY environment variable and restart the Upgrade Assistant as described in Setting the DISPLAY Environment Variable.Table 1-2 Upgrade Assistant GUI Command Line Parameters
| Parameter | Required or Optional Parameter? | Description |
|---|---|---|
|
|
Optional. |
Logging level. Select one of the following:
The default logging level is NOTIFICATION. Note: When troubleshooting, consider setting the-logLevel to TRACE so that more information will be logged. If additional information is not needed, change the logLevel as the Upgrade Assistant's log files can become very large when -logLevel TRACE is used.Note: TRACE messages are not included in the Upgrade Assistant Log File Viewer. To view TRACE messages you must use another tool. |
|
|
Optional. Note: If you have installed the Upgrade Assistant in a read-only directory, you must specify this parameter to ensure the log directory is writable. If the log directory is read-only, the Upgrade Assistant will fail. |
Change the default location of upgrade log files and temporary files. You must specify an existing, writable directory where Upgrade Assistant will create log files and temporary files. On UNIX operating systems, the default locations are: ORACLE_HOME/oracle_common/upgrade/logs ORACLE_HOME/oracle_common/upgrade/temp On Windows operating systems, the default locations are: ORACLE_HOME\oracle_common\upgrade\logs ORACLE_HOME\oracle_common\upgrade\temp |
|
|
Optional |
Identify 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. Default is 4 threads. |
|
|
Required for Readiness Check |
Performs the upgrade readiness check without performing any actual examines or upgrades. Schemas and configuration are checked. Note: -readiness option may not appear on the command line with -examine option.For more information, see Performing the Readiness Check |
|
|
Optional. |
Prints all the command-line options to the console. |
Silent or “hands free” upgrades can be performed using a response file. The response file can only be created after you have provided the information in the Upgrade Assistant screens.
The following topics describe how you can upgrade the supported Oracle Fusion Middleware components using a response file. The response file collects all the information that you have entered through the Upgrade Assistant's graphical user interface screens, and performs exactly the same function that the Upgrade Assistant wizard performs.
Note:
You must run the Upgrade Assistant in GUI mode first to generate the response file that will be used to complete your silent upgrade.The Save Response File option on the Upgrade Summary screen creates a file that uses the information you have already provided in the Upgrade Assistant screens. The response file enables you to use the saved information instead of manually entering data through the Upgrade Assistant wizard screens.
Once you select the Save Response File option, you will be prompted for a name and location where you want to create this response file. After it is created, you can use it exactly as-is to replicate the upgrade options on other systems, or modify it as needed.
For more information, see Using the Response File to Upgrade Fusion Middleware.
To perform upgrades using a response file from the command-line interface (CLI), use the following command:
On Unix operating systems:
Change directory to ORACLE_HOME/oracle_common/upgrade/bin
Execute the following:
./ua -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]On Windows operating systems:
Change directory to ORACLE_HOME\oracle_common\upgrade\bin
Execute the following:
ua.bat -response <response_file> [-examine] [-logLevel <log_level>] [-logDir <log_directory>] [-threads <number>]Table 1-3 Upgrade Assistant Response File Mode Command Line Parameters
| Parameter | Required or Optional Parameter? | Description |
|---|---|---|
|
|
Required for Readiness Check |
Performs the upgrade readiness check without performing any actual examines or upgrades. Schemas and configuration are checked. Note: Do not specify this parameter if you have specified the-examine parameter.For more information, see Performing the Readiness Check |
|
|
Optional |
Identify 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. Default is 4 threads. |
|
|
Required. |
File containing inputs required to perform an upgrade. This file can be generated from inputs entered when the Upgrade Assistant is run in graphical mode. |
|
|
Optional. |
If this option is present, Upgrade Assistant performs the examine phase but DOES NOT perform any actual upgrades. Note: Do not specify this parameter if you have specified the-readiness parameter. |
|
|
Optional. |
Logging level. Select one of the following:
The default logging level is NOTIFICATION. Note: Consider setting the-logLevel to TRACE so that more information will be logged. This will be useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used. |
|
|
Optional. |
Change the default location of upgrade log files and temporary files. You must specify an existing, writable directory where Upgrade Assistant will create log files and temporary files. On UNIX operating systems, the default locations are:
On Windows operating systems, the default locations are:
|
|
|
Optional. |
View all of the command line options. |
Use the Upgrade Assistant to upgrade supported schemas to this release of Oracle Fusion Middleware.
The screens that are displayed when you run the Upgrade Assistant to upgrade schemas vary depending on the options you select and the contents of your pre-upgrade environment.
Table 1-4 Upgrading Schemas: Navigating the Upgrade Assistant Screens
| Screen Title | When does the screen appear? | Description |
|---|---|---|
|
Always. |
This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks. |
|
|
Always. |
Select the schema upgrade operation that you want to perform on this screen. The options on the screens change depending on what you select from the following:
|
|
|
When you select Individually Selected Schemas. |
This screen provides a list of installed Oracle Fusion Middleware components that have schemas that can be upgraded. When you select a component, the schemas and any dependencies are automatically selected. |
|
|
When you select All Schemas Used by a Domain. |
This screen is read-only, and it displays all the components and schemas found in the specific domain directory that are included in the upgrade. |
|
|
Always. |
This screen requires you to acknowledge that all prerequisites have been met before you continue with the upgrade. Check the boxes before you continue. |
|
|
Always. |
Enter the information required to connect to the selected schema and the database that hosts the schema on this screen. The screen name changes based on the type of schema selected ("MDS Schema", for example). Since the component ID or schema name is changed for UCSUMS schema as of release 12.1.2, the Upgrade Assistant does not automatically recognize the possible schemas and display them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ |
|
|
Always. |
This screen displays the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade.
Note: Issues detected during the Examination phase can be fixed without restoring from backup. |
|
|
Always. |
Review a summary of the options you have selected and to start the upgrade process on this screen. |
|
|
Always. |
This screen displays the status of the upgrade process. |
|
|
When the upgrade is successful. |
The upgrade is successful. The Post-Upgrade Actions window describes the manual tasks you must perform to make the component function in the new installation. |
|
|
When the upgrade fails. |
The upgrade failed for the specified component(s). You must restart the Upgrade Assistant. The Upgrade Assistant 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 and then restart the Upgrade Assistant. You cannot fix the issues and restart the Upgrade Assistant because the files are modified during this operation. |
If you are running the Upgrade Assistant from an Oracle home that contains managed WebLogic domain components, then the All Configurations Used by a Domain upgrade option is available.
After upgrading the component schemas, you must run the Reconfiguration Wizard to reconfigure the domain. For more information, see "Reconfiguring an Oracle WebLogic Domain with the Reconfiguration Wizard". After the reconfiguring the domain, use the Upgrade Assistant again to upgrade the component configurations as described in this section.
The Upgrade Assistant will display the following screens when upgrading a WebLogic component configurations, such as Oracle Web Services Manager (OWSM).
Table 1-5 Upgrade Assistant Screens: Upgrading Oracle WebLogic Component Configurations
| Screen | When Screen Appears | Description |
|---|---|---|
|
Always. |
This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks. |
|
|
When All Configurations Used by a Domain is selected as the upgrade type, the screen name is WebLogic Components. |
Select the All Configurations Used by a Domain option to upgrade component configurations for a managed WebLogic Server domain. Configuration upgrades are offline in 12.2.1. You must enter the domain directory for the domain that you are upgrading now. |
|
|
Only when the All Configurations Used by a Domain option is selected. |
This screen provides a list of components that will be included in the WebLogic domain's component configuration upgrade. The name of the domain is provided along with the list of components located within the domain. |
|
|
Always. |
This screen requires you to acknowledge that all prerequisites have been met before you continue with the upgrade. You must check the boxes before you can continue. |
|
|
Only when there are remote managed servers hosting UMS 11g configuration files, that is, when the required configuration files are not locally accessible at the Administration Server. |
This screen specifies the login credentials of the remote managed servers hosting your UMS 11g configuration files. The Upgrade Assistant automatically copies remote configuration files if all necessary prerequisites are met and the required login information is provided. |
|
|
Always. |
This screen displays the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade. |
|
|
Always. |
Use this screen to review a summary of the options you have selected and to start the upgrade process. |
|
|
Always. |
This screen shows the status of the upgrade process. |
|
|
Or |
Always. |
The upgrade was successful. The Post-Upgrade Actions window describes the manual tasks you must perform to make the component function in the new installation. Or: The upgrade failed for the specified component(s) and Upgrade Assistant will have to be restarted. |
The following topics provide information about basic tasks performed after the upgrade is complete. Some of the tasks may not apply to your environment, as you may not be upgrading the products listed.
Always refer to your component-specific upgrade documentation for more information on post-upgrade procedures.
NOTE: You should be able to successfully complete the tasks described in this section after an upgrade. If you are unable to complete one or more of these tasks in your newly upgraded environment, see Troubleshooting Your Upgrade.
This section describes some common administration tasks you will likely want to perform on your newly upgraded domain.
NOTE: The administrative tasks in the table below are optional. Only perform those tasks that apply to your upgraded environment.
Table 1-6 Basic Post-Upgrade Administration Tasks
| Task | Description | More Information |
|---|---|---|
|
Starting and stopping products and servers |
Learn how to start and stop Oracle Fusion Middleware, including the Administration Server, Managed Servers, and components. Performing these tasks will validate that the upgrade was successful. |
|
|
Starting and stopping upgraded applications. |
Learn how to start your upgraded applications in the new 12.2.1 environment to verify they are working as expected. |
|
|
Configuring Secure Sockets Layer (SSL) |
Learn how to set up secure communications among between Oracle Fusion Middleware components using SSL. |
|
|
Deploying Applications |
Learn how to deploy your applications to Oracle Fusion Middleware. |
|
|
Monitoring Oracle Fusion Middleware |
Learn how to keep track of the status of Oracle Fusion Middleware components. |
|
|
Adding a Web Tier front-end to your WebLogic domain |
Oracle Web Tier hosts Web pages (static and dynamic), provides security and high performance along with built-in clustering, load balancing, and failover features. In particular, the Web Tier contains Oracle HTTP Server. |
|
|
Tuning and configuring Coherence for your topology. |
The standard installation topology includes a Coherence cluster that contains storage-enabled Managed Coherence Servers. This configuration is a good starting point for using Coherence, but depending upon your specific requirements, consider tuning and reconfiguring Coherence to improve performance in a production environment. |
For information about Coherence clusters, see "Configuring and Managing Coherence Clusters" For information about tuning Coherence, see Administering Oracle Coherence. For information about storing HTTP session data in Coherence, see "Using Coherence*Web with WebLogic Server". For more information about creating and deploying Coherence applications, see Developing Oracle Coherence Applications for Oracle WebLogic Server. |
You can use the following SQL command to verify that the schema version in schema_version_registry has been properly upgraded:
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 ;
All the numbers in the "VERSION" column should be the versions specified during your pre-upgrade check . For more information, see Identifying Schemas that Can be Upgraded with the Upgrade Assistant.
In the query results, the STATUS field will be either "UPGRADING" or "UPGRADED" during the schema patching operation, and will become "VALID" when the operation is finished.
If the status appears as "INVALID" then the schema upgrade failed. You should examine the logs files to determine the reason for the failure.
If you are using an Oracle database, you should recompile database objects after running the Upgrade Assistant by connecting to the database as SYS and running the following from SQL*Plus:
SQL>@/rdbms/admin/utlrp.sql
This will compile the database objects that were upgraded by Upgrade Assistant.
Then issue the following query to ensure there are no longer any invalid database objects:
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
None of the database objects for the upgraded schema should be invalid at this point. If there are any, run the utlrp.sql command again and check again. If the problem persists, you should file a service request.
When upgrading _IAU from 11g starting points, the Upgrade Assistant will update two auxilary schemas, IAU_APPEND and IAU_VIEWER and add them to the schema_version_registry for 12.2.1.1. These schemas were not part of the 11.1.1.7 schema_version_registry table.
As of release 11.1.1.7, OPSS audit data is stored in IAU common tables instead of the JPS table. When upgrading _OPSS schemas to 12.2..11 from 11.1.1.6, any existing data in the JPS table can remain unchanged for reporting or auditing purposes, and there is no need to upgrade JPS table with extra columns.
First release to support Edition-Based Redefinition (EBR) enabled schemas
First release to support Edition-Based Redefinition (EBR) enabled schemas