Using the Upgrade Assistant to Perform an Upgrade

2 Using the Upgrade Assistant to Perform an Upgrade

The Upgrade Assistant is used in different ways to upgrade schemas, component configurations, and to perform a readiness check on your pre-upgrade environment.

Note:

This chapter provides a high-level overview of how to use the Upgrade Assistant to perform an Oracle Fusion Middleware upgrade. Use the component-specific upgrade guides when performing an actual upgrade.

Before You Use the Upgrade Assistant
Before beginning an upgrade with the Upgrade Assistant, you should create a complete backup and perform other pre-upgrade checks and tasks.
Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
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.
Understanding the Product Schemas Upgrade
Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.
Understanding the Component Configurations Upgrade
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.
Performing Post-Upgrade Procedures
Complete any additional post-upgrade configuration tasks after the upgrade to verify that your newly upgrade domain is functioning as expected. Perform only those tasks that apply to your domain configuration.

Before You Use the Upgrade Assistant

Before beginning an upgrade with the Upgrade Assistant, you should create a complete backup and perform other pre-upgrade checks and tasks.

Note:

You may be required to perform additional tasks before starting your actual upgrade process. Each of the component-specific upgrade guides provides a checklist that includes a complete list of a pre-upgrade tasks that must be performed before starting an upgrade.

Creating a Complete Backup
Before you start an upgrade, back up all system-critical files, including the databases that host your Oracle Fusion Middleware schemas.
Special Considerations for Online Backup and Recovery
Perform these additional backup tasks if your environment includes multiple middleware homes, and performing a full database restore after an upgrade failure is not a desirable option.
Checking for Invalid Database Objects Before an Upgrade
To identify invalid objects that may cause the upgrade to fail, recompile database objects before you run the Upgrade Assistant.
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.
Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

Creating a Complete Backup

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

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

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

See:

Backing Up Your Environment in Administering Oracle Fusion Middleware
Upgrading and Preparing Your Oracle Databases for 12c in Planning an Upgrade of Oracle Fusion Middleware

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

Parent topic: Before You Use the Upgrade Assistant

Backing Up the Schema Version Registry Table

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

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

Note:

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

Parent topic: Creating a Complete Backup

Maintaining Customized Domain and Environment Settings

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

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

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

The following example illustrates startup customizations in a setUserOverrides file:

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

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

Note:

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

Parent topic: Creating a Complete Backup

Special Considerations for Online Backup and Recovery

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

Understanding the Impact of a Full Database Restore

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

Is your database shared by production environments that must remain online when a single FMW home is being upgraded?
Does your database need to remain online when recovering from a failed upgrade?
Is performing a full database restore an undesirable solution for recovering from a failed upgrade?

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

Saving Grants on SYS Owned Objects
In the event of an upgrade failure, all grants to SYS owned objects will be lost when the schema is dropped. Oracle recommends that you create a script that can be used to re-apply the grants if necessary.
Exporting Schemas Before You Upgrade
Use data pump export to backup the schemas that will be upgraded.
Identifying Queue States Before an Upgrade
In the event of a an upgrade failure, the queues must be manually restarted. Take inventory of these queues to assist in restarting them.

Parent topic: Before You Use the Upgrade Assistant

Saving Grants on SYS Owned Objects

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

An example of how to create this script is shown below. Please note the following about the generated SQL script:

The spooled output will need to be edited before it can be executed by SQLPlus, the text of the SQL queries and the "spool off" command need to be removed from the spooled file.
Some of the grants may return errors when being applied after a drop/import of a schema. Some instances where this is not a fatal error are:
- The grant already exists

- The name of the grant object is dynamically generated when the schema is created. For example, advanced queueing views are named QTnnnnnnnn_BUFFER.

Sample SQLPlus commands to create a script for re-applying grants:

# The schema prefix in this example is "DEV"
$ORACLE_HOME/bin/sqlplus username/password
exec dbms_metadata.set_transform_param(dbms_metadata.SESSION_TRANSFORM,'SQLTERMINATOR',TRUE); 
set long 100000
set longchunksize 100000
set lines 1000
set termout off echo off newp 0 spa 0 pages 0 feed off head off trims on tab off
spool /tmp/create-grants.sql
select dbms_metadata.get_granted_ddl ('OBJECT_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('SYSTEM_GRANT',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS')
union all
select dbms_metadata.get_granted_ddl ('DEFAULT_ROLE',username) from all_users where username in ('DEV_MDS', 'DEV_IAU', 'DEV_IAU_APPEND', 'DEV_IAU_VIEWER', 'DEV_OPSS', 'DEV_UMS', 'DEV_WLS', 'DEV_SOAINFRA', 'DEV_STB', 'DEV_ESS');
spool off

Parent topic: Special Considerations for Online Backup and Recovery

Exporting Schemas Before You Upgrade

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

Refer to the Oracle Database Utilities guide for information on using Oracle Data Pump.

The following example shows a sample export:

# The schema prefix in this example is "DEV"
# The schemas being exported are for the SOA, BPM and ESS environments
$ORACLE_HOME/bin/sqlplus username/password
create directory data_pump_directory as '/scratch/db12cr2/export';
 
expdp username/password schemas=DEV_STB,DEV_SOAINFRA,DEV_IAU_VIEWER,DEV_MDS,DEV_IAU_APPEND,DEV_WLS,DEV_UMS,DEV_OPSS,DEV_IAU,DEV_ESS directory=data_pump_directory dumpfile=export.dmp compression=ALL

Parent topic: Special Considerations for Online Backup and Recovery

Identifying Queue States Before an Upgrade

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

The restoration of a single schema will not restart any queues that are imported. You will need to restart all of the enabled queues. The following example shows the SQL commands that can be used to generate a list of the queues that would need to be restarted in the event of a failed upgrade. Provide the correct schema prefix for each schema owner.

set pagesize 20;
set linesize 200;
COLUMN OWNER FORMAT A50
COLUMN NAME FORMAT A50
select owner,name,enqueue_enabled,dequeue_enabled from dba_queues where owner='DEV_SOAINFRA';

Parent topic: Special Considerations for Online Backup and Recovery

Checking for Invalid Database Objects Before an Upgrade

To identify invalid objects that may cause the upgrade to fail, recompile database objects before you run the Upgrade Assistant.

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 command from SQL*Plus to compile the database objects:

SQL> @oracle_home/software/rdbms/admin/utlrp.sql

Then, use the following query to ensure there are no invalid database objects:

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

If there are invalid objects, run the utlrp.sql command again. If the problem persists, you should file a service request.

Parent topic: Before You Use the Upgrade Assistant

Creating a Non-SYSDBA User to Run the Upgrade Assistant

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

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

Notes:

The non-SYSDBA user FMW is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW user. Note that privileges required for running the Upgrade Assistant may change from release to release.

By default, the v$xatrans$ table does not exist. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, the grant select privilege on thev$xatrans$ table is required only by Oracle Identity Governance. If you do not require Oracle Identity Governance for configuration, or if you do not have the v$xatrans$ table, then remove the following line from the script:

   grant select on v$xatrans$ to FMW with grant option;

In the example below, password is the password that you set for the FMW user. When granting privileges, make sure that you specify your actual password.

create user FMW identified by password;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to FMW with grant option;
grant select on sys.DBA_TABLESPACE_USAGE_METRICS to FMW with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

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

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

Parent topic: Before You Use the Upgrade Assistant

Stopping Servers and Processes

Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components 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 the existing, pre-upgrade servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager.

To stop your pre-upgrade Fusion Middleware environment, navigate to the pre-upgrade domain and follow the steps below:

Step 1: Stop System Components

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

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

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

When prompted, enter your user name and password.

Step 3: Stop Oracle Identity Management Components

Stop any Oracle Identity Management components, such as Oracle Internet Directory:

(UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) EXISTING_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) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

Step 5: Stop Node Manager

To stop Node Manager, close the command shell in which it is running.

Alternatively, after setting the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down. See stopNodeManager in WLST Command Reference for WebLogic Server.

Parent topic: Before You Use the Upgrade Assistant

Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.3.0). 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:

Note:

Before you start the Upgrade Assistant, make sure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

Go to the oracle_common/upgrade/bin directory:
- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
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

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

Upgrade Assistant Parameters

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

Table 2-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 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 creates log files and temporary files. The default locations are: (UNIX) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `NEW_ORACLE_HOME\oracle_common\upgrade\logs` `NEW_ORACLE_HOME\oracle_common\upgrade\temp`
`-help`	Optional	Displays all of the command-line options.

Parent topic: Starting the Upgrade Assistant

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 whether you need to take any action for a successful upgrade.

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

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 check during off-peak hours.

Parent topic: Running a Pre-Upgrade Readiness Check

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:

Go to the oracle_common/upgrade/bin directory:
- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
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

Parent topic: Running a Pre-Upgrade Readiness Check

Upgrade Assistant Parameters

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

Table 2-2 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 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 creates log files and temporary files. The default locations are: (UNIX) `NEW_ORACLE_HOME/oracle_common/upgrade/logs` `NEW_ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `NEW_ORACLE_HOME\oracle_common\upgrade\logs` `NEW_ORACLE_HOME\oracle_common\upgrade\temp`
`-help`	Optional	Displays all of the command-line options.

Parent topic: Starting 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.

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

To complete the readiness check:

On the Welcome screen, review information about the readiness check. Click Next.
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.
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 selected Domain Based: On the Component List screen, review the list of components that are present in your domain 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.
  
  Note:
  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 option and specify the Schema Password.
Click Next to start the readiness check.
On the Readiness Summary screen, review the summary of the readiness checks that will be 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.
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.
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.

Parent topic: Running a Pre-Upgrade Readiness Check

Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine whether 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 2-3 Readiness Report Elements

Report Information	Description	Required Action
Overall Readiness Status: SUCCESS or FAILURE	The top of the report indicates whether the 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 `NEW_ORACLE_HOME/oracle_common/upgrade/logs`	The directory location of the generated log file.	No action required.
Readiness report location `NEW_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, 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, 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, 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 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: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_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 11g (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.

Parent topic: Running a Pre-Upgrade Readiness Check

Understanding the Product Schemas Upgrade

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

The following table describes the basic Upgrade Assistant screens seen in most schema upgrades. Your components may include additional custom screens. These custom screens are documented in your product-specific upgrade documentation.

Note:

The Upgrade Assistant screens that display when you upgrade your schemas vary depending on the options you select and the contents of your pre-upgrade environment. Always use your component-specific upgrade guides to complete an upgrade.

Table 2-4 Upgrade Assistant Screens: Upgrading Product Schemas

Screen Title	Description
Welcome	Provides an overview of the Upgrade Assistant and information about important pre-upgrade tasks.
Schemas	Presents a choice of the schema upgrade operation to perform: Individually Selected Schemas All Schemas Used by a Domain
Available Components	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.
All Schema Component List	When you select All Schemas Used by a Domain, this read-only screen displays all the components and schemas in the specific domain directory that are included in the upgrade.
Prerequisites	Prompts for confirmation that all prerequisites have been met before you continue with the upgrade. Check the boxes before you continue. Note: The Upgrade Assistant does not verify that the prerequisites have been met. For example, the Upgrade Assistant cannot detect whether the servers and processes have been stopped as required.
Schema Credentials Screen The screen name changes based on the type of schema selected.	Allows you to enter the information needed to connect to the selected schema and the database that hosts the schema: Database Type The types of databases available in the menu varies depending on the schema you are about to upgrade. The database type chosen for upgrade must be identical to the database type that was selected when the RCU created the schema. If you select Oracle Edition-Based Redefinition (EBR) as the database type, the schema that you are upgrading also must have been created by the RCU using the EBR database type. For example, the Upgrade Assistant never converts schemas from one database type to another. Database Connect String The location of the database. For example, if you are selecting an Oracle database, you can use a URL in the following format: `host:port/db_service_name` If you are using a Microsoft SQL Server or IBM DB2 database, select the database type from the drop-down menu and review the text below the field, which provides the syntax required for each database type. Note: The Upgrade Assistant accepts other valid forms of connection strings. For example, the Oracle Database TNS style connection string may also be used. DBA User Name The database user name used to connect to the database. Note: The DBA user must have sufficient privileges to run the Upgrade Assistant, but the user does not have to have SYS or SYSDBA privileges. See Creating a Non-SYSDBA User to Run the Upgrade Assistant. On certain database platforms user names are case-sensitive, and the DBA user name may include lower case letters. The Upgrade Assistant connects to the name as entered and does not convert it to upper case. DBA Password The password associated with the specified DBA database user. Click Connect to connect to the database, then select the schema to be upgraded. If the schema that is to be upgraded was created by the RCU in a prior Fusion Middleware release, you see a drop-down menu listing the possible schema names. Note: The component ID or schema name changed for UCSUMS schema as of 12c (12.1.2.0), so the Upgrade Assistant does not automatically recognize the possible schemas and display them in a drop-down list. In the case, you must manually enter the name in the text field. The name can be either `prefix_ORASDPM` or `prefix_UMS`, depending on the starting point for the upgrade. Schema Owner The schema user name. For example, DEV11g_MDS. Note: All Oracle Fusion Middleware schema names consist solely of upper case characters on all database platforms. Also, all schema names are stored as upper case in the `schema_version_registry` table. If you type lower case letters in the Schema User Name field, the Upgrade Assistant converts the name to upper case. Schema Owner Password The password associated with the specified schema user name. Edition Name When Oracle Database enabled for edition-based redefinition is selected as the database type, you must specify the existing edition name. Note: Before upgrading an EBR-enabled schema from Fusion Middleware 11g release or from a previous 12c release, you must first connect to the database server and create an edition on the database server for 12c (12.2.1.3.0). The new edition for 12c (12.2.1.2) must be a child of your 11.1.1.7.0, 11.1.1.9.0, 12.1.2.0, 12.1.3.0, 12.2.1.0, or 12.2.1.1 edition. For more information on creating an edition on the server for edition-based redefinition, see Creating an Edition on the Server for Edition-Based Redefinitionin Planning an Upgrade of Oracle Fusion Middleware.
Create Schemas	This screen appears when the Upgrade Assistant detects that some component schemas may be missing and must be created before the upgrade. The Upgrade Assistant can create these schemas for you using the default tablespace and temporary tablespace settings. To customize these settings run the Repository Creation Utility to create the schemas. Create missing schemas for the specified domain By default this option is enabled. The Upgrade Assistant will attempt to create the missing schemas for the domain using the database connection details and schema owner name provided. If the same password is used for all schemas select Use same passwords for all schemas. Enter and confirm the password in the table. You only have to supply the password once. If you do not want the Upgrade Assistant to create these schemas for you, deselect this option and click Next. You will have to run the Repository Creation Utility to create the schemas.
Create Schemas Defaults	When using the Upgrade Assistant to create the missing schemas, the default schema settings are used. If you need to modify the size of the tablespace datafile ,or make any other changes to the default schema settings, use the Repository Creation Utility to create the schemas. You cannot modify the tablespace settings from the Upgrade Assistant. The default datafile size is listed for each component schema and auxiliary schema. If you need to add additional space, use the Repository Creation Utility.
Create Schemas Progress	Displays the status of the schema creation process. No action is required.
Examine	Displays the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade. The Upgrade Assistant examines each component to validate it meets a minimum set of criteria before you begin the upgrade process. If the information is listed in the schema version registry table, this screen displays the Source Version of the schema. If the schema was not created using RCU, or the source version cannot be found, the source version displays `unavailable`. Status Definitions: `in progress`: The Upgrade Assistant is examining the upgrade items for the component. `pending`: The component will be examined when the Upgrade Assistant finishes the preceding component. `failed`: Upgrade items were missing or did not meet the upgrade criteria. The Upgrade Assistant cannot upgrade the component until the issues have been resolved. Click View Log to troubleshoot the errors and then restart the Upgrade Assistant. `succeeded`: Upgrade items were found and are valid for upgrade. `canceled`: Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information that the Upgrade Assistant has collected must be collected again in a future upgrade session. `upgrade not necessary`: The component is already at the upgraded version or the component was upgraded in a previous run of the Upgrade Assistant. `skipped`: A dependent component has failed resulting in the examine of this component to be skipped. Note: Issues detected during the examination phase may be resolved and the Upgrade Assistant can be started again. However, once the upgrade phase has started, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.
Upgrade Summary	Displays a summary of the options that you have selected before you start the upgrade process. Expand and collapse the tree to show or hide details about the data provided in the wizard screens, such as schema details and Oracle WebLogic domain directory information. The Summary screen also displays the Source Version of the schema being upgraded and the resulting Target Version post upgrade. Make sure that both versions are correct before proceeding with the upgrade. Click Upgrade to start the upgrade process. If you are upgrading a schema, verify that you have a backup of the database that hosts the schema. Click Save Response File to create a file that can later be used as input to the Upgrade Assistant for a silent upgrade. A silent upgrade performs exactly the same function that the Upgrade Assistant wizard performs, but you do not have to manually enter the data again.
Upgrade Progress	Displays the status of the upgrade process. CAUTION: Do not cancel the upgrade process once it has started. Doing so may leave your components in an inconsistent state requiring a restore from backup.
Upgrade Success	Appears when the upgrade is successful. The Post-Upgrade Actions window describes the manual tasks that you must perform to make the component function in the new installation. Note, however, that there may be additional post-upgrade tasks to perform. Consult your upgrade documentation.
Upgrade Failure	Appears when the upgrade fails for the specified component schemas. 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 simply the issues and restart the Upgrade Assistant because the files were modified during this operation.

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

Understanding the Component Configurations Upgrade

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

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.

Note:

The Upgrade Assistant screens that display when you upgrade your component configurations vary depending on the options you select and the contents of your pre-upgrade environment. Always use your component-specific upgrade guides to complete an upgrade.

Table 2-5 Upgrade Assistant Screens: Upgrading Oracle WebLogic Component Configurations

Screen	Description
Welcome	Provides an overview of the Upgrade Assistant and information about important pre-upgrade tasks.
All Configurations Used by a Domain	When the upgrade type selected is All Configurations Used by a Domain, the Upgrade Assistant upgrades component configurations for a managed WebLogic Server domain. Configuration upgrades are performed offline. You must enter the domain directory for the domain that you are upgrading.
WebLogic Server Component List	When the upgrade type selected is All Configurations Used by a Domain, the Upgrade Assistant , 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.
Prerequisites	Prompts for confirmation that all prerequisites have been met before you continue with the upgrade. Check the boxes before you continue. Note: The Upgrade Assistant does not verify that the prerequisites have been met. For example, the Upgrade Assistant cannot detect whether the servers and processes have been stopped as required.
Examine	Displays the status of the Upgrade Assistant as it examines each component, verifying that the component is ready for upgrade. The Upgrade Assistant examines each component to validate it meets a minimum set of criteria before you begin the upgrade process. If the information is listed in the schema version registry table, this screen displays the Source Version of the schema. If the schema was not created using RCU, or the source version cannot be found, the source version displays `unavailable`. Status Definitions: `in progress`: The Upgrade Assistant is examining the upgrade items for the component. `pending`: The component will be examined when the Upgrade Assistant finishes the preceding component. `failed`: Upgrade items were missing or did not meet the upgrade criteria. The Upgrade Assistant cannot upgrade the component until the issues have been resolved. Click View Log to troubleshoot the errors and then restart the Upgrade Assistant. `succeeded`: Upgrade items were found and are valid for upgrade. `canceled`: Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information that the Upgrade Assistant has collected must be collected again in a future upgrade session. `upgrade not necessary`: The component is already at the upgraded version or the component was upgraded in a previous run of the Upgrade Assistant. `skipped`: A dependent component has failed resulting in the examine of this component to be skipped. Note: Issues detected during the examination phase may be resolved and the Upgrade Assistant can be started again. However, once the upgrade phase has started, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.
Upgrade Summary	Displays a summary of the options that you have selected before you start the upgrade process.
Upgrade Progress	Displays the status of the upgrade process. CAUTION: Do not cancel the upgrade process once it has started. Doing so may leave your components in an inconsistent state requiring a restore from backup.
Upgrade Success	Appears when the upgrade is successful. The Post-Upgrade Actions window describes the manual tasks that you must perform to make the component function in the new installation. Note, however, that there may be additional post-upgrade tasks to perform. Consult your upgrade documentation.
Upgrade Failure	Appears when the upgrade fails for the specified components. 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 simply the issues and restart the Upgrade Assistant because the files were modified during this operation.

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

Performing Post-Upgrade Procedures

Complete any additional post-upgrade configuration tasks after the upgrade to verify that your newly upgrade domain is functioning as expected. Perform only those tasks that apply to your domain configuration.

After a successful upgrade it is important to verify that the servers can be started, the schema versions have been updated in the registry table, and the component configurations are correct. In some cases you may need to perform additional post-upgrade tasks based on the contents of your domain. Review the entire list of tasks to determine which are applicable.

Note:

If you are unable to complete one or more of these tasks in your newly upgraded environment, see Troubleshooting Your Upgrade. Always refer to your component-specific upgrade documentation for more information on post-upgrade procedures.

Performing Basic Post-Upgrade Administrative Tasks
Review the list of post-upgrade tasks and perform those that apply to your upgraded environment and domain configurations.
Verifying a Successful Schema Upgrade
Checking for Invalid Database Objects After an Upgrade
If you are using an Oracle database, recompile database objects after running the Upgrade Assistant.

Parent topic: Using the Upgrade Assistant to Perform an Upgrade

Performing Basic Post-Upgrade Administrative Tasks

Review the list of post-upgrade tasks and perform those that apply to your upgraded environment and domain configurations.

These administrative tasks are optional, but Oracle strongly recommends that you verify your upgrade by performing the tasks.

Table 2-6 Basic Post-Upgrade Administration Tasks

Task	Description	More Information
Starting and stopping products and servers	Start and stop Oracle Fusion Middleware, including the Administration Server, Managed Servers, and components. Performing these tasks validates that the upgrade was successful.	Starting and Stopping Oracle Fusion Middleware
Starting and stopping upgraded applications	Start your upgraded applications in the new environment to verify they are working as expected.	Starting and Stopping Applications
Configuring Secure Sockets Layer (SSL)	Set up secure communications among between Oracle Fusion Middleware components using SSL.	Configuring SSL in Oracle Fusion Middleware
Deploying Applications	Deploy your applications to Oracle Fusion Middleware.	Deploying Applications
Monitoring Oracle Fusion Middleware	Keep track of the status of Oracle Fusion Middleware components.	Monitoring Oracle Fusion Middleware
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.	Installing and Configuring 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 in Administering Clusters for Oracle WebLogic Server. For information about tuning Coherence, see Administering Oracle Coherence. For information about storing HTTP session data in Coherence, see Using CoherenceWeb with WebLogic Server in Administering HTTP Session Management with Oracle CoherenceWeb. For more information about creating and deploying Coherence applications, see Developing Oracle Coherence Applications for Oracle WebLogic Server.

Parent topic: Performing Post-Upgrade Procedures

Verifying a Successful Schema Upgrade

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 ;

Make sure that the numbers in the VERSION column are updated. If no changes were required, some schemas may remain at their pre-upgrade version. For more information, see Table 1-1.

In the query results, the STATUS field is either UPGRADING or UPGRADED during the schema patching operation, and becomes VALID when the operation is finished.

If the status appears as INVALID, then the schema upgrade has failed. You can examine the log files to determine the reason for the failure.

Parent topic: Performing Post-Upgrade Procedures

Checking for Invalid Database Objects After an Upgrade

If you are using an Oracle database, recompile database objects after running the Upgrade Assistant.

To determine whether any database objects were corrupted during the upgrade, recompile the database objects that were upgraded by Upgrade Assistant by connecting to the database as SYS and running the following from SQL*Plus:

SQL> @oracle_home/software/rdbms/admin/utlrp.sql

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

Parent topic: Performing Post-Upgrade Procedures