The screens listed in this topic are not necessarily in sequential order. Depending on the options you select or the schemas and configurations in your domain, you may not see all of the screens. See Using the Upgrade Assistant for general information on the screens that are used for each upgrade type.
The Upgrade Assistant can be run in two modes: upgrade and readiness (pre-upgrade.) The screens for each mode are described in the following sections:
This section describes all of the Upgrade Assistant screens.
Note:
The screens you will see while using the Oracle Fusion Middleware Upgrade Assistant vary depending upon the type of Oracle Fusion Middleware software you are upgrading. Not all screens will be shown to you.
The Oracle Fusion Middleware Upgrade Assistant is used to upgrade component schemas, component configurations, and standalone system component configurations from Fusion Middleware 11g and 12c releases to the latest Fusion Middleware 12c release.
Select Individually Selected Schemas to upgrade selected schemas for your installed components. The Upgrade Assistant will identify components that are candidates for a schema upgrade and then you can select which schemas to include in the upgrade
CAUTION: Upgrade only those schemas that will be used to support your 12.2.1.0.0 components. Do not upgrade schemas that are currently being used to support 11g or 12c components that are not included in the Oracle Fusion Middleware 12.2.1 release.
As of release 12.2.1, the Oracle Fusion Middleware Upgrade Assistant (UA) provides an option for upgrading all schemas used by a specified domain (sometimes referred to as Domain Assisted Schema Upgrade or DASU). When you select All Schemas Used By a Domain, the Upgrade Assistant discovers and selects all components that have schemas available to upgrade. In addition, where possible, the Upgrade Assistant pre-populates the connection information on schema input screens.
Also, you must browse and provide the 11g domain in the Domain Directory field.
Select the All Configurations Used by a Domain option to upgrade component configurations for a managed WebLogic Server domain. Click Browse and use the navigation tree to select a valid domain directory. A domain directory contains a config
directory, which contains a config.xml
file.
Select the Standalone System Component Configurations option when you will be upgrading a standalone system component, such as Oracle HTTP Server (OHS).
You will be prompted to select one of the following:
Option | Description |
---|---|
Create a New Domain |
Standalone system components will have a separate standalone domain in 12c. A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic domain, but it does not contain an Administration Server or Managed Servers. It can contain one or more instances of system components of the same type, such as Oracle HTTP Server, or a mix of types. Management tools, such as the Configuration Wizard, pack and unpack, WLST, and Node Manager can operate on standalone domains. |
Update an Existing Domain |
Once a standalone domain has been created for a system component, you can select this option to extend that domain for another standalone system component. This option is also used when upgrading from 12.1.2 or 12.1.3. You must provide the location of the existing 12c domain. |
If you selected the Individually Selected Schemas option in the previous screen to select individual schemas to be upgraded - instead of upgrading all schemas used by the domain - this screen displays the components with schemas that can be upgraded. If you select a component that requires another schema, the Upgrade Assistant will automatically select those schemas for you.
Figure A-2 List of Components with Schemas Available for Upgrade
If you selected All Schemas Used by the Domain, then this screen provides a list of schemas that will be included in the WebLogic domain upgrade. The names of the components are provided along with the schemas located within the domain.
Review the list carefully to verify that the correct schemas will be upgraded. If you do not see the components or schemas you want to upgrade, you may have selected the wrong domain. Use the Back button to specify a different domain.
If there are components or schemas listed that you do not want included, navigate back to the All Schemas screen and select Individually Selected Schemas instead of All Schemas Used by the Domain. The Individually Selected Schemas option allows you to select only those schemas you want included in the upgrade.
Figure A-3 Component List for All Schema Used by the Domain Upgrade
When All Configurations Used by a Domain is selected for upgrade, the domain's components are listed on this read-only screen. Review the list of components before you proceed.
Figure A-4 Component List for WebLogic Component Configurations
This screen requires you to acknowledge that all prerequisites have been met before you continue with the upgrade. You must check the boxes before you can continue.
WARNING:
The Upgrade Assistant will not verify that the prerequisites have been met.
Use this screen to select the child edition from edition drop down list for edition-based redefinition databases. You must create the child edition before starting the upgrade.
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 Planning an Upgrade of Oracle Fusion Middleware.
Use this screen to enter information required to connect to the selected schema and the database that hosts the schema. 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 as shown below. Click Connect to connect to the database then select the schema to be upgraded.
NOTE: Most schemas will have this information pre-populated. If, however, the Upgrade Assistant is unable to detect the connection details, then they must be entered manually as shown below.
Figure A-7 Select Schemas - Dropdown Menu
The following table describes the elements that appear on this screen.
Element | Description |
---|---|
Database Type |
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. In particular, Upgrade Assistant never converts schemas from one database type to another. |
Database Connect String |
Enter the location of the database. For example, if you are selecting an Oracle database, the following URL format could be used: host:port/db_service_name 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. |
DBA User Name |
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. 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. |
DBA Password |
Enter the password associated with the specified DBA database user. |
Schema User Name |
Select the schema user name from the drop-down list or enter the user name of the schema, for example, DEV_MDS. Note that 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 For WebLogic Server domain, UMS, and Veridata schemas you need to manually enter the 11g schema user name and password. |
Schema Password |
Enter the password associated with the specified schema user name. |
Edition Name |
When Oracle Database enabled for edition-based redefinition is selected as the database type, you must specify the existing edition name. NOTE: Before upgrading an EBR-enabled schema from Fusion Middleware 11g release or from a previous 12c release, you must first connect to the database server and create an edition on the database server for 12c (12.2.1). The new edition for 12.2.1 must be a child of your 11.1.1.6.0, 11.1.1.7.0, 12.1.2, or 12.1.3 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 Planning an Upgrade of Oracle Fusion Middleware. |
When upgrading system components, such as OHS, you must provide the directory locations of the 11g instances that will be used as a starting point for creating new 12c component instances.
Use the Add button to include more than one instance, if needed.
NOTE: You cannot use the Upgrade Assistant to upgrade Oracle 10g instances to Oracle 12c. You must first upgrade Oracle 10g instances to 11g. For more information on migrating 10g to 11g, see the 11g upgrade documentation for your components.
Use this screen to specify the credentials of the Node Manager that will be used to create a domain during the upgrade of standalone system components.
Note that the fields displayed in the screenshot may not appear during your upgrade. The conditions that trigger the fields to display are described in the table below.
The user name and password are only used to authenticate connections between Node Manager and clients. They are independent from the server Administrator ID and password.
Element | Description |
---|---|
User Name |
The user name used to access Node Manager. |
Password |
The password used to access Node Manager. You will need to re-enter the password for confirmation. |
Listen Address |
Enter the DNS name or IP address upon which Node Manager listens in the Listen Address field. |
Listen Port |
The listening port number of Node Manager. |
Provide the Oracle Traffic Director Information as presented on the screen (fields may vary):
Administration Server Host
The name of the host where the Traffic Director Administration Server is running. Search for a host by clicking the Search icon located at the end of the field.
Note: On selecting the host, the Agent URL field will be automatically populated.
Administration Server SSL Port
SSL Port of the Administration Server.
User Name
Name of the administrator allowed to access the Traffic Director Administration Server.
Password
Password of the administrator allowed to access the Traffic Director Administration Server.
SNMP Port
The port on which the SNMP agent is listening. All the SNMP agents on all Traffic Director instance hosts should be running on the same port.
Oracle Home
Directory where the Traffic Director binaries have been installed.
When you created the Master and Work repositories for ODI, the Repository Creation Utility prompted you to supply a password for the default SUPERVISOR account. On the ODI Supervisor screen, enter the following:
Element | Description |
---|---|
ODI Supervisor User Name |
Supervisor account name for the ODI repository to be upgraded. The Supervisor user should be |
ODI Supervisor Password |
Password that you created for the ODI Supervisor account. |
Figure A-11 Oracle Data Integrator (ODI) Supervisor
For 11g to 12c upgrades only. This screen generates a unique identifier or upgrade key to convert 11g IDs for repository objects into unique GUIDs. You can use the auto-generated upgrade key or you can specify your own key in the Upgrade Key field.
Consider the following two scenarios when selecting an upgrade key:
You know that an ID used in the 11g repository is the same as a project ID located in an XML file exported from the same repository. Use the Upgrade Key field to enter the project ID that was used in the 11g repository.
In this scenario, the upgrade key used to upgrade the repository should be the same as the upgrade key used to import the XML file into the upgraded 12c repository. This ensures that the project object in the import file will be properly matched with the project object in the repository (when using one of SYNONYM import modes).
You have 11g XML export file provided from a source containing objects created in another repository and you do not know which IDs were used. Use the auto-generated upgrade key or specify your own unique ID to avoid duplicate IDs.
In this scenario, there is a chance that the file may contain a project that has the same internal ID. To prevent erroneous object matching, which may corrupt the metadata, a different, custom upgrade key should be used when importing that file into the repository.
NOTE: When multiple copies of the same object exist (in a repository or exported in XML files), the same GUID should be produced for all copies of the object. For this reason, the same upgrade key must be used for all upgrade operations involving the copies of that particular object.
Figure A-12 Oracle Data Integrator (ODI) Upgrade Key
Use this screen to specify the OGGMON
schema prefix used when creating the Monitor schema with the Repository Creation Utility (RCU).
RCU requires that you supply a schema owner prefix for each schema you create. Provide the exact schema prefix used for the schema to be upgraded. The default prefix is DEV; as in DEV_OGGMON
.
Figure A-13 Oracle Golden Gate Monitor Schema Prefix
Use this screen to enter the location of the exisiting Veridata 11g home directory to be upgraded.
Click Browse and use the navigation tree to select the Veridata domain directory.
Use this screen to specify the VERIDATA
schema prefix used when creating the Veridata schema with the Repository Creation Utility (RCU).
RCU requires that you supply a schema owner prefix for each schema you create. Provide the exact schema prefix used for the schema to be upgraded. The default prefix is DEV; as in DEV_VERIDATA
.
Figure A-16 User Messaging Service Configuration
Use this screen to specify the login credentials of the remote managed servers hosting your UMS 11g configuration files. The Upgrade Assistant automatically copies remote configuration files if all necessary prerequisites are met and the required login information is provided as described in the table below.
If the UMS configuration files are not locally accessible on the machine where the upgrade is being executed, then you must manually enter the login credentials for each managed server (ums_server1,ums_server2 for example).
In some cases, the configuration files must be copied to the machine where the upgrade is being executed (in most cases to the AdminServer machine). The Upgrade Assistant will attempt to copy the files, but if it cannot locate them, then you will have to manually copy them to the Admin Server.
For more information, see "Copying UMS Configuration Files" in Upgrading to the Oracle Fusion Middleware Infrastructure.
You will only need to copy the files manually if you receive a message stating that the Upgrade Assistant is not able to copy the configuration files. Once you have copied the files, you can restart the Upgrade Assistant and proceed with the upgrade.
Element | Description |
---|---|
Username |
Provide the Operating System user who installed the product. This user will be used to fetch the remote configuration files. NOTE: This user must have permission to connect via The Username field is shown if:
|
Password |
Provide the password associated with this user. |
Managed Servers |
If the Upgrade Assistant was unable to automatically detect the managed servers, then you must provide a comma separated list containing the names of the remote managed servers that contain the configuration files. For example: ums_server1,ums_server2 |
Managed Servers Addresses |
Provide a comma separated list containing the complete hostnames or IP addresses for the nodes where the remote managed servers are running. The order of this list has to correspond with the list of managed server names provided above. For example:
where:
|
On the MapViewer Upgrade page, for File specify the mapViewerConfig.xml file of the old MapViewer deployment, .and click Next.
This file is needed for migrating its system configuration settings. From this file's location, the old MapViewer's deployment directories are also derived.
Figure A-17 MapViewer Configuration File Directory
The Upgrade Assistant examines each component to be sure it meets a minimum set of criteria before you begin the upgrade process.
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.
unavailable
.
Note:
Issues detected during the Examination phase may be resolved and the Upgrade Assistant can be started again. Once the Upgrade phase has started, however, you will need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.The description of the Status indicators for the components is listed in the following table:
Status | Description |
---|---|
in progress... |
The Upgrade Assistant is examining the upgrade items for the component. |
pending... |
The component will be examined when the Upgrade Assistant finishes the preceding component. |
failed |
Upgrade items were missing or did not meet upgrade criteria. The Upgrade Assistant cannot upgrade the component until the issues have been resolved. Click View Log to troubleshoot the errors and then restart the Upgrade Assistant. |
succeeded |
Upgrade items were found and are valid for upgrade. |
Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.
This dialog box appears when one of more of your components failed the examination phase and you selected to continue with the upgrade. If there was an examination failure, you should consider canceling the upgrade (click No) and review the log files.Since the upgrade has not yet started, you can resolve the issues detected during the examination phase and restart the Upgrade Assistant without restoring from backup.
UMS Upgrades Only:
During the configuration upgrade you can get this error during the examination phase. For User Messaging Service, the way to recover is to copy the UMS config files manually and restart the Upgrade Assistant.
If you can get an error during the upgrade phase , the way to recover is to restore backups and copy the config files manually and restart the Upgrade Assistant.
Reviewing the Upgrade Summary
Expand and collapse the tree to show or hide details about the data provided in the wizard screens, such as schema details, Oracle WebLogic Server connection details, and Oracle WebLogic domain directory information.
The Summary screen also displays the Source Version of the schema being upgraded and the resulting Target Version post upgrade. Make sure that both versions are correct before proceeding with the upgrade.
Starting the Upgrade Process
Click Upgrade to start the upgrade process.
If you are upgrading a schema, verify that you have a backup of the database that hosts the schema.
Save Response File
The Save Response File option creates a file that can be used as input to the Upgrade Assistant. The response file collects all the information that you have entered through the Upgrade Assistant's graphical user interface screens, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant wizard performs, but you do not have to manually enter the data again.
This screen shows the status of the current upgrade process and the projected Target Version of the component after a successful upgrade.
Note that the progress bar is NOT a measure of time remaining for the upgrade. The progress bar is a moving graphical display of completed upgrade steps for each component being upgraded. In some cases, the progress bar does not move at a steady pace. It might move very quickly over a certain portion of the progress bar, and move very slowly, or even appear to freeze, for another component that is performing a long-running database operation. That does not mean that the upgrade progress is stalled, it simply indicates that a long-running operation is being performed. Different upgrade operations, especially during a schema upgrade, will operate at different paces.
Caution: Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
The status of each component upgrade is indicated by one of the following messages that can appear next to the component name. The following table describes each status message.
Status | Description |
---|---|
in progress... |
The Upgrade Assistant is upgrading the component's upgrade items. |
pending... |
The component will be upgraded when the Upgrade Assistant finishes the preceding component. |
upgrade not necessary |
The component was upgraded previously by the Upgrade Assistant or the component was just installed and is already at the latest version. No action will be taken on this component. |
skipped |
The component is dependent on another component which has a status of "failed". When the status is "skipped" no upgrade is attempted for that component. |
failed |
Upgrade items were missing or did not meet upgrade criteria. The component cannot be upgraded. Click View Log to troubleshoot the errors. |
succeeded |
Upgrade items were upgraded successfully. |
If any components are not upgraded successfully, refer to the Upgrade Assistant log files for more information.
The upgrade was successful. The Post-Upgrade Actions window describes the manual tasks you must perform to make the component function in the new installation. This is an optional window that will only show up if a component has post-upgrade steps.
In addition, be sure to do the following:
View the postupgrade.txt
file in the Oracle home:
On Unix systems:
ORACLE_HOME/oracle_common/upgrade/logs
On Windows systems:
ORACLE_HOME\oracle_common\upgrade\logs
Review the upgrade topics specific to your Oracle Fusion Middleware environment for any additional post-upgrade tasks.
The upgrade of one or more components has failed. The component cannot be upgraded at this time. Click View Log to troubleshoot the errors.
You will have to fix the issues in the pre-upgrade environment before starting the Upgrade Assistant again. Restore your pre-upgrade environment from backup (making sure to keep the original backup files in a separate location), fix the issues, and restart the Upgrade Assistant.
You get the above Confirm Cancel screen when you click Cancel while the upgrade plugin is actively running (that is, you are on the Upgrade page and the progress bar is less than 100%).
You get the above Confirm Cancel screen on clicking Cancel when no upgrade plugins are actively running.
Important Note: If you cancel a schema upgrade, you must restore a backup of the database that hosts the schema and its environment (the pre-upgrade directory structure).
Click View Log from any of the screens to see the latest logged information.
The log file is managed by the command line options you set. See Starting the Upgrade Assistant with Additional Parameters (Optional) for more information.
This section describes the screens that are presented when running the Upgrade Assistant in -readiness mode.
The Upgrade Assistant can be run in -readiness
mode before you perform the actual upgrade to detect any potential problems with the pre-upgrade environment.
For more information, see Running a Pre-Upgrade Readiness Check .
The Upgrade Assistant Readiness Check performs a read-only, pre-upgrade review of your existing Oracle Fusion Middleware schemas and Oracle WebLogic component configurations.
The Readiness Check provides a formatted, time-stamped Readiness Report so you can address any issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process.
The Upgrade Assistant Readiness Check can be run with your existing 11g or 12c domain online or offline.
Note:
While readiness check ships with 12.2.1, it only checks supported pre-upgrade environments.The Readiness Check can be run any number of times before the actual upgrade is performed. However, do not run after the Readiness Check after an upgrade has been performed, as the report will not provide valid results.
Oracle recommends that you read this report thoroughly before performing an upgrade.
Figure A-28 Individually Selected Schemas
You have two options when running the readiness check:
Individually Selected Schemas
Domain Based
Select the Individually Selected Schemas option to limit the check to specific schemas. Click Next and you will be required to supply the schema credentials.
Readiness checks are performed on the schemas that you connect to. The readiness check report tells you whether a schems is supported for an upgrade, or where an upgrade is needed.
The Domain Based option is used to check all of the upgrade-eligible schemas and/or component configurations used by the domain. The Upgrade Assistant detects all of the schemas for you. You can check schemas and component configurations at the same time. Or, if you prefer, you can select one or the other. In either case, you must specify the Domain Directory that is to be reviewed.
You have several options when checking the WebLogic Server domain.
You can select one - or more - of the following options each time you run the Domain Based Readiness Check:
Include checks for all schemas
Select this option to enable the Upgrade Assistant to discover and review all components that have a schema available to upgrade.
Include checks for all configurations
Select this option to review component configurations for a managed WebLogic Server domain.
Perform online and offline readiness checks.
If you do not select this option your domain can be offline. You must provide the domain location that you plan to check.
Figure A-29 WebLogic Server Readiness Check Options
This screen appears if you select Individually Selected Schemas in the Schemas screen.
Figure A-30 Available Components
If you chose Individually Selected Schemas this screen lists the available components for which the schemas will be selected. If you select something here, readiness check will be performed on that component's schema. You must select one or more components from the list to perform readiness check on them.
Use this screen to enter information required to connect to the selected schema and the database that hosts the schema. If the schema that is to be reviewed was created by RCU in a prior Fusion Middleware release then you will see a drop-down menu listing the possible schema names as shown below.
Click Connect to connect to the database then select the schema to be reviewed. NOTE: Most schemas will have this information pre-populated. If, however, the Upgrade Assistant is unable to detect the connection details, then they must be entered manually as shown below.
If multiple components are selected, then the Schema Credential screens appear in dependency order.
Figure A-31 Schema Credentials
This screen provides a high-level overview of the readiness checks performed based on your selections.
For a detailed report, click View Log.
Figure A-32 Readiness Summary
This screen shows the overall progress and completion details of the running readiness check. If you are checking multiple components, then each gets component will have its own progress bar and will be checked in parallel. Once completed, click View Readiness Report to see the full text report.
CAUTION: If you are running the readiness check on your online production environment, Oracle recommends that you perform the check during off-peak hours to prevent performance degradation.
Click View Log from any of the screens to see the latest logged information.
The log file is managed by the command line options you set. See Starting the Upgrade Assistant with Additional Parameters (Optional) for more information.
Readiness success indicates that the readiness review was successfully completed.
Even with a successful completion of the review, you should still click View Readiness Report and review the Readiness Report before you perform the actual upgrade.
Figure A-35 End of Readiness: Readiness Success
A formatted Readiness Report is prepared for you after running the check. Make sure that you review the report and correct any issues before you start the actual upgrade. Use the Find option to search for a particular word within the report (such as a schema name or command, for example.)
The report also indicates where the completed Readiness Check Report file is located.