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.4.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 calledFMW
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.
-
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 theSYSTEM.SCHEMA_VERSION_REGISTRY$
table or theFMWREGISTRY.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.
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.
# 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.
# 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.
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.
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.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;
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.4.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
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
- (UNIX)
- 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
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 |
---|---|---|
|
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 |
|
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. |
|
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). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
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)
(Windows)
|
|
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.
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 |
---|---|---|
|
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 |
|
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. |
|
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). |
|
Optional |
Performs the examine phase but does not perform an actual upgrade. Do not specify this parameter if you have specified the |
|
Optional |
Sets the logging level, specifying one of the following attributes:
The default logging level is Consider setting the |
|
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)
(Windows)
|
|
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.
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
|
The directory location of the generated log file. |
No action required. |
Domain Directory | Displays the domain location | No action required. |
Readiness report location
|
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 Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain
Starting readiness check of components.
Oracle Platform Security Services
Starting readiness check of Oracle Platform Security Services.
Schema User Name: DEV3_OPSS
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
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 that the schema does not contain any unexpected tables TEST_UNEXPECTED_TABLES
Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
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 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: SEQUENCE_TEST Test that the Oracle Platform Security Services schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
Finished readiness check of Oracle Platform Security Services with status: SUCCESS.
Oracle Audit Services
Starting readiness check of Oracle Audit Services.
Schema User Name: DEV3_IAU
Database Type: Oracle Database
Database Connect String:
VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0. Readiness checks will now be performed.
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
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_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_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 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_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_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 OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting schema test: SEQUENCE_TEST Test that the audit schema sequence and its properties are valid
Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
Starting schema test: SYNONYMS_TEST Test that the audit schema required synonyms are present
Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
Finished readiness check of Oracle Audit Services with status: FAILURE.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Schema User Name: DEV3_STB
Database Type: Oracle Database
Database Connect String:
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
Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables
Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views
Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns
Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade
INFO Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Oracle JRF
Starting readiness check of Oracle JRF.
Finished readiness check of Oracle JRF with status: SUCCESS.
System Components Infrastructure
Starting readiness check of System Components Infrastructure.
Starting config test: TEST_SOURCE_CONFIG Checking the source configuration.
INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.
Common Infrastructure Services
Starting readiness check of Common Infrastructure Services.
Starting config test: CIEConfigPlugin.readiness.test This tests the readiness of the domain from CIE side.
Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
Finished readiness check of Common Infrastructure Services with status: SUCCESS.
Finished readiness check of components.
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:
|
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:
|
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 Status Definitions:
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 component schemas. You must restart the Upgrade Assistant. The Upgrade Assistant logs are available at 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 Status Definitions:
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 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 upgraded applications |
Start your upgraded applications in the new environment to verify they are working as expected. |
|
Configuring Secure Sockets Layer (SSL) |
Set up secure communications among between Oracle Fusion Middleware components using SSL. |
|
Deploying Applications |
Deploy your applications to Oracle Fusion Middleware. |
|
Monitoring Oracle Fusion Middleware |
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 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 Coherence*Web with WebLogic Server in Administering HTTP Session Management with Oracle Coherence*Web. 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