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:
The information in the following sections provides a high-level overview of how the Upgrade Assistant is used to perform an Oracle Fusion Middleware upgrade. The component-specific upgrade guides should be used when performing an actual upgrade.This section describes some of the procedures you must perform before you begin any upgrade with the Upgrade Assistant.
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.FMW
to run the Upgrade Assistant. This user has the privileges required to modify schemas, but does not have full administrator privileges.Back up all system-critical files including all of the databases that host your Oracle Fusion Middleware schemas before you start the upgrade.
The backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$
table so that you can restore the contents back to its pre-upgrade state if the upgrade fails.
The Upgrade Assistant Prerequisites screen prompts you to acknowledge that backups have been performed before you proceed with the actual upgrade. However, note that the Upgrade Assistant does not verify that a backup has been created.
Backing Up Your Environment in Oracle Fusion Middleware Administering Oracle Fusion Middleware
Upgrading and Preparing Your Oracle Databases for 12c in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware
In addition to creating a complete backup of your system, you must also create a backup of your schema version registry and any custom settings you want to use in your upgraded environment. See the following resources:
SYSTEM.SCHEMA_VERSION_REGISTRY$
table.Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$
table.
Each Fusion Middleware schema has a row in the SYSTEM.SCHEMA_VERSION_REGISTRY$
table. If you run the Upgrade Assistant to update an existing schema and it does not succeed, you must restore the original schema before you can try again. Make sure you back up your existing database schemas and the schema version registry before you run the Upgrade Assistant.
Note:
Performing these backups prior to performing a schema upgrade is a prerequisite for running the Upgrade Assistant. During the upgrade you will be required to acknowledge that backups have been performed.If you modified any domain generated or server startup scripts in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, domain upgrade, and reconfiguration operations.
Every domain installation includes dynamically-generated domain and server startup scripts, such as setDomainEnv
. These files are replaced by newer versions during the installation and upgrade process. To maintain your custom domain-level environment settings, Oracle recommends that you create a separate file to store the custom domain information before you upgrade, instead of modifying the scripts directly.
For example, if you want to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.cmd
(Windows) or setUserOverrides.sh
(UNIX) and configure it to add custom libraries to the WebLogic Server classpath, specify additional command-line options for running the servers, or specify additional environment variables. Any custom settings you add to this file are preserved during the domain upgrade operation and are carried over to the remote servers when using the pack and unpack commands.
setUserOverrides
file:
# add custom libraries to the WebLogic Server system claspath if [ "${POST_CLASSPATH}" != "" ] ; then POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar" export POST_CLASSPATH else POST_CLASSPATH="${HOME}/foo/fooBar.jar" export POST_CLASSPATH fi # specify additional java command line options for servers JAVA_OPTIONS="${JAVA_OPTIONS} -Dcustom.property.key=custom.value"
If the setUserOverrides
file exists during a server startup, the file is included in the startup sequence and any overrides contained within this file take effect. You must store the setUserOverrides
file in the domain_home/bin
directory.
Note:
If you are unable to create the setUserOverrides
script before an upgrade, you need to reapply your settings as described in Re-apply Customizations to Startup Scripts in Oracle Fusion Middleware Upgrading Oracle WebLogic Server.
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 from SQL*Plus:
SQL> @oracle_home/software/rdbms/admin/utlrp.sql
This compiles the database objects.
Then use the following query to ensure there are no invalid database objects:
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
None of the database objects should be invalid before you upgrade.
If there are any invalid objects, run the utlrp.sql
command again. If the problem persists, you should file a service request.
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
If you created the non-SYSDBA user FMW in a previous release, you must drop and recreate this user before starting the upgrade. Running the Upgrade Assistant with an older FMW user may lead to a failed upgrade as new privileges may have been added. Oracle recommends that you drop and recreate the user instead of modifying the existing FMW user.v$xatrans$
table does not exist. You must run the XAVIEW.SQL
script to create this table before creating the user. Moreover, the grant select privilege on v$xatrans$
table is required only for Oracle Identity Manager. If you do not require Oracle Identity Manager for configuration, or if you do not have the v$xatrans$
table, then remove the following line from the script:
grant select on v$xatrans$ to FMW with grant option;
welcome1
is the password. Make sure that you specify your actual password when granting privileges.
create user FMW identified by welcome1; grant dba to FMW; grant execute on DBMS_LOB to FMW with grant option; grant execute on DBMS_OUTPUT to FMW with grant option; grant execute on DBMS_STATS to FMW with grant option; grant execute on sys.dbms_aqadm to FMW with grant option; grant execute on sys.dbms_aqin to FMW with grant option; grant execute on sys.dbms_aqjms to FMW with grant option; grant execute on sys.dbms_aq to FMW with grant option; grant execute on utl_file to FMW with grant option; grant execute on dbms_lock to FMW with grant option; grant select on sys.V_$INSTANCE to FMW with grant option; grant select on sys.GV_$INSTANCE to FMW with grant option; grant select on sys.V_$SESSION to FMW with grant option; grant select on sys.GV_$SESSION to FMW with grant option; grant select on dba_scheduler_jobs to FMW with grant option; grant select on dba_scheduler_job_run_details to FMW with grant option; grant select on dba_scheduler_running_jobs to FMW with grant option; grant select on dba_aq_agents to FMW with grant option; grant execute on sys.DBMS_SHARED_POOL to FMW with grant option; grant select on dba_2pc_pending to FMW with grant option; grant select on dba_pending_transactions to FMW with grant option; grant execute on DBMS_FLASHBACK to FMW with grant option; grant execute on dbms_crypto to FMW with grant option; grant execute on DBMS_REPUTIL to FMW with grant option; grant execute on dbms_job to FMW with grant option; grant select on pending_trans$ to FMW with grant option; grant select on dba_scheduler_job_classes to fmw with grant option; grant select on SYS.DBA_DATA_FILES to FMW with grant option; grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option; grant select on v$xatrans$ to FMW with grant option; grant execute on sys.dbms_system to FMW with grant option; grant execute on DBMS_SCHEDULER to FMW with grant option; grant select on dba_data_files to FMW with grant option; grant execute on UTL_RAW to FMW with grant option; grant execute on DBMS_XMLDOM to FMW with grant option; grant execute on DBMS_APPLICATION_INFO to FMW with grant option; grant execute on DBMS_UTILITY to FMW with grant option; grant execute on DBMS_SESSION to FMW with grant option; grant execute on DBMS_METADATA to FMW with grant option; grant execute on DBMS_XMLGEN to FMW with grant option; grant execute on DBMS_DATAPUMP to FMW with grant option; grant execute on DBMS_MVIEW to FMW with grant option; grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option; grant select on dba_queue_subscribers to FMW with grant option; grant execute on SYS.DBMS_ASSERT to FMW with grant option; grant select on dba_subscr_registrations to FMW with grant option; grant manage scheduler to FMW;
Note:
Oracle Database 11.2.0.3 Database Users ONLY: You must apply Oracle Patch 13036331 before you begin the upgrade. Go to My Oracle Support to download the patch.
If you do not apply this patch, then you will have to grant additional privileges for some schemas.
Before running the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all processes and servers, including the Administration server and any managed servers.
An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other so they must be stopped in the correct order.
Note:
The procedures in this section describe how to stop servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.To stop your Fusion Middleware environment, follow the steps below.
Step 1: Stop System Components
To stop system components, such as Oracle HTTP Server, use the stopComponent
script:
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
You can stop system components in any order.
Step 2: Stop the Managed Servers
To stop a WebLogic Server Managed Server, use the stopManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Step 3: Stop Oracle Identity Management Components
Stop any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
Step 4: Stop the Administration Server
When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To stop the Administration Server, use the stopWebLogic
script:
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 5: Stop Node Manager
To stop Node Manager, close the command shell in which it is running.
Alternatively, after having set the nodemanager.properties
attribute QuitEnabled
to true
(the default is false
), you can use WLST to connect to Node Manager and shut it down. For more information, see stopNodeManager in Oracle Fusion Middleware WLST Command Reference for WebLogic Server.
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.
oracle_common/upgrade/bin
directory:
ORACLE_HOME/oracle_common/upgrade/bin
ORACLE_HOME\oracle_common\upgrade\bin
For information about other parameters that you can specify on the command line, such as logging parameters, see:
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 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 will create log files and temporary files. The default locations are: UNIX:
Windows:
|
|
Optional |
Displays all of the command line options. |
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.
-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. -readiness
parameter to start the Upgrade Assistant in readiness mode.You can run the Upgrade Assistant in -readiness
mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.
The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.
The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.
You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.
You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.
Note:
To prevent performance from being affected, Oracle recommends that you run the readiness checks during off-peak hours.
Use the -readiness
parameter to start the Upgrade Assistant in readiness mode.
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 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 will create log files and temporary files. The default locations are: UNIX:
Windows:
|
|
Optional |
Displays all of the command line options. |
Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.
After performing a readiness check for your domain, review the report to determine if you need to take any action for a successful upgrade.
The format of the readiness report file is:
readiness_timestamp.txt
where timestamp
indicates the date and time of when the readiness check was run.
A readiness report contains the following information:
Table 2-3 Readiness Report Elements
Report Information | Description | Required Action |
---|---|---|
Overall Readiness Status: SUCCESS or FAILURE | The top of the report indicates whether the Upgrade readiness check passed or completed with one or more errors. | If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade. |
Timestamp |
The date and time that the report was generated. |
No action required. |
Log file location
|
The directory location of the generated log file. |
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, then do not attempt an upgrade. |
Names of schemas that were checked |
The names and current versions of the schemas included in the check and status. |
Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, then do not attempt an upgrade. |
Individual Object Test Status: FAIL |
The readiness check test detected an issue with a specific object. |
Do not upgrade until all failed issues have been resolved. |
Individual Object Test Status: PASS |
The readiness check test detected no issues for the specific object. |
If your readiness check report shows only the PASS status, then you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade. |
Completed Readiness Check of <Object> Status: FAILURE | The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index or datatype. | Do not upgrade until all FAILED issues have been resolved. |
Completed Readiness Check of <Object> Status: SUCCESS | The readiness check test detected no issues. | No action required. |
Upgrade readiness check completed with one or more errors. This readiness check report was created on Tue May 30 11:15:52 EDT 2016 Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt Starting readiness check of components. Oracle Metadata Services Starting readiness check of Oracle Metadata Services. Schema User Name: DEV11_MDS Database Type: Oracle Database Database Connect String: machinename@yourcompany.com VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0. Readiness checks will now be performed. Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS Starting schema test: TEST_REQUIRED_PROCEDURES Test that the schema contains all the required stored procedures EXCEPTION Schema is missing a required procedure: GETREPOSITORYFEATURES Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS Starting index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS Starting index test for table MDS_COMPONENTS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS Starting schema test: TEST_REQUIRED_TRIGGERS Test that the schema has all the required triggers Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS Starting schema test: TEST_UNEXPECTED_PROCEDURES Test that the schema does not contain any unexpected stored procedures Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS Starting schema test: TEST_UNEXPECTED_VIEWS Test that the schema does not contain any unexpected views Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS Starting index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS Starting index test for table MDS_LARGE_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes Starting schema test: TEST_UNEXPECTED_TRIGGERS Test that the schema does not contain any unexpected triggers Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS Starting schema test: TEST_UNEXPECTED_COLUMNS Test that tables and views do not contain any unexpected columns Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS Starting datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS Starting datatype test for table MDS_COMPONENTS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade INFO Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS Finished readiness check of Oracle Metadata Services with status: FAILURE.
If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from an 11g release (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:
Starting index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is missing the required columns or index itself is missing. This maybe caused by a known issue, anyway, this missing index will be added in 12.2.2 upgrade. Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ FAIL
Note:
You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.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 component-specific upgrade documentation.
Note:
The Upgrade Assistant screens displayed 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 Upgrading Schemas: Navigating the Upgrade Assistant Screens
Screen Title | Description |
---|---|
Welcome |
This screen provides an overview of the Upgrade Assistant and information about important pre-upgrade tasks. |
Schemas |
This screen allows you to select the schema upgrade operation that you want to perform. The options change depending on which of the following options you select::
|
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 found in the specific domain directory that are included in the upgrade. |
Prerequisites |
This screen requires you to acknowledge that all prerequisites have been met before you continue with the upgrade. Check the boxes before you continue. NOTE: Thee Upgrade Assistant will not verify that the prerequisites have been met. For example, the Upgrade Assistant cannot detect if the servers and processes have been stopped as required. |
Schema Credentials Screen The screen name changes based on the type of schema selected ("MDS Schema", for example). |
This screen requires you to enter the information needed to connect to the selected schema and the database that hosts the schema on this screen. You will need to know the following:
Select the database type from the drop-down menu. 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 RCU originally 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 RCU using the EBR database type. For example, the Upgrade Assistant never converts schemas from one database type to another.
Enter the location of the database. For example, if you are selecting an Oracle database, the following URL format could be used:
If you are using a Microsoft SQL Server or IBM DB2 database, then 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.
Enter 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/SYSDBA privileges. A non-sysdba user can now be used. 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 might consist of lower case letters. The Upgrade Assistant connects to the name the user enters and does not convert the user name to upper case.
Enter 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 RCU in a prior Fusion Middleware release then you will see a drop-down menu listing the possible schema names. NOTE: The component ID or schema name changed for UCSUMS schema as of release 12.1.2.0, so the Upgrade Assistant does not automatically recognize the possible schemas and display them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_
Select the schema user name from the drop-down list or enter the user name of the schema, 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
Enter the password associated with the specified schema user 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.2). 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 Redefinition" in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware. |
Examine |
This screen 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 be sure it meets a minimum set of criteria before you begin the upgrade process. Upgrade Assistant displays the schema Source Version of the schema on this screen if the information is listed in the schema version registry table. If the schema was not created using RCU, or the source version cannot be found, the source version will display 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 will need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again. |
Upgrade Summary |
This screen allows you to review a summary of the options you have selected before you start the upgrade process.
|
Upgrade Progress |
This screen 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 |
This screen displays if the upgrade is successful. The Post-Upgrade Actions window describes the manual tasks you must perform to make the component function in the new installation. Note, however, that there may be additional post-upgrade tasks to perform. Consult your upgrade documentation. |
Upgrade Failure |
This screen displays if the upgrade failed for the specified component schema(s). 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 the issues and restart the Upgrade Assistant because the files were modified during this operation. |
Describes the basic Upgrade Assistant screens seen in most component configuration upgrades.
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.
Use the Upgrade Assistant to upgrade the component configurations as described in this section.
Note:
This topic should be used for reference only. The Upgrade Assistant screens displayed when you upgrade your component configurations will 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 |
This screen provides an overview of the Upgrade Assistant and some information about important pre-upgrade tasks. |
All Configurations Used by a Domain |
This screen appears when All Configurations Used by a Domain is selected as the upgrade type. The All Configurations Used by a Domain option is used to upgrade 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 |
This screen appears when the All Configurations Used by a Domain option is selected. This screen provides a list of components that will be included in the WebLogic domain's component configuration upgrade. The name of the domain is provided along with the list of components located within the domain. |
Prerequisites |
This screen requires you to acknowledge that all prerequisites have been met before you continue with the upgrade. Check the boxes before you continue. NOTE: The Upgrade Assistant will not verify that the prerequisites have been met. For example, the Oracle Fusion Middleware Upgrade Assistant cannot detect if the servers and processes have been stopped as required. |
Examine |
This screen 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 be sure it meets a minimum set of criteria before you begin the upgrade process. Upgrade Assistant displays the schema Source Version of the schema on this screen if the information is listed in the schema version registry table. If the schema was not created using RCU, or the source version cannot be found, the source version will display 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 will need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again. |
Upgrade Summary |
Use this screen to review a summary of the options you have selected and to start the upgrade process. |
Upgrade Progress |
This screen shows 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 |
This screen displays if the upgrade is successful. The Post-Upgrade Actions window describes the manual tasks you must perform to make the component function in the new installation. Note, however, that there may be additional post-upgrade tasks to perform. |
Upgrade Failure |
This screen displays if the upgrade failed for the specified component(s). 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 the issues and restart the Upgrade Assistant because the files are modified during this operation. |
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.
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 |
Learn how to start and stop Oracle Fusion Middleware, including the Administration Server, Managed Servers, and components. Performing these tasks will validate that the upgrade was successful. |
|
Starting and stopping upgraded applications. |
Learn how to start your upgraded applications in the new 12.2.1 environment to verify they are working as expected. |
|
Configuring Secure Sockets Layer (SSL) |
Learn how to set up secure communications among between Oracle Fusion Middleware components using SSL. |
|
Deploying Applications |
Learn how to deploy your applications to Oracle Fusion Middleware. |
|
Monitoring Oracle Fusion Middleware |
Learn how to keep track of the status of Oracle Fusion Middleware components. |
|
Adding a Web Tier front-end to your WebLogic domain |
Oracle Web Tier hosts Web pages (static and dynamic), provides security and high performance along with built-in clustering, load balancing, and failover features. In particular, the Web Tier contains Oracle HTTP Server. |
Oracle Fusion Middleware 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" For information about tuning Coherence, see Oracle Fusion Middleware Administering Oracle Coherence. For information about storing HTTP session data in Coherence, see "Using Coherence*Web with WebLogic Server". For more information about creating and deploying Coherence applications, see Oracle Fusion Middleware Developing Oracle Coherence Applications for Oracle WebLogic Server. |
You can use the following SQL command to verify that the schema version in schema_version_registry
has been properly upgraded:
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
Validate that the numbers in the "VERSION" column are updated. It is possible that some schemas will remain at their pre-upgrade version if there were no changes required. For more information, see Table 1-1.
In the query results, the STATUS field will be either "UPGRADING" or "UPGRADED" during the schema patching operation, and will become "VALID" when the operation is finished.
If the status appears as "INVALID" then the schema upgrade failed. You should examine the logs files to determine the reason for the failure.
If you are using an Oracle database, recompile database objects after running the Upgrade Assistant.
To determine if any database objects were corrupted during the upgrade, recompile the database objects by connecting to the database as SYS and running the following from SQL*Plus:
SQL> @oracle_home/software/rdbms/admin/utlrp.sql
This will compile the database objects that were upgraded by Oracle Fusion Middleware Upgrade Assistant.
Then issue the following query to ensure there are no longer any invalid database objects:
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
None of the database objects for the upgraded schema should be invalid at this point. If there are any, run the utlrp.sql
command again and check again. If the problem persists, you should file a service request.