You can upgrade Oracle Fusion Middleware Infrastructure from Oracle Fusion Middleware Release 11g to 12c (12.2.1.2) .
Complete the steps in the following topics to perform the upgrade:
setDomainEnv
. During the upgrade, the scripts are overwritten with new 12c versions. You must manually reapply the custom configuration settings you had made in previous releases.Review the flowchart and roadmap for an overview of the upgrade process for Oracle Fusion Middleware Infrastructure from 11g to 12c.
Figure 3-1 Upgrade Process Flowchart for Oracle Fusion Middleware Infrastructure from 11g to 12c
Table 3-1 lists the high-level steps that you need to perform to upgrade to Oracle Fusion Middleware Infrastructure Release 12.2.1.2:
Table 3-1 Tasks for Upgrading Oracle Fusion Middleware Infrastructure from a 11g Release
Task | Description |
---|---|
Optional Learn about the interoperability and compatibility factors that could affect how you upgrade to Oracle Fusion Middleware Infrastructure 12.2.1.2. |
It is important to understand how two or more Oracle Fusion Middleware products of the same version or different versions work together (interoperate) in a supported Oracle Fusion Middleware configuration. You can learn more about interoperability and compatibility in Oracle® Fusion Middleware Understanding Interoperability and Compatibility. |
Required If you have not done so already, review the introductory topics in this guide and complete the required pre-upgrade tasks. |
The pre-upgrade tasks include cloning your production environment, verifying system requirements and certifications, purging unused data, and creating non-SYSDBA user. For a complete list of pre-upgrade tasks, see Oracle Fusion Middleware Pre-Upgrade Checklist. |
Required Download and install the 12.2.1.2 Fusion Middleware Infrastructure distribution. |
The Infrastructure distribution combines the WebLogic Server and the Java Required Files (JRF) that are required to set up the foundation to install other Fusion Middleware products. As per the upgrade topology defined in this guide, you must install the Infrastructure in a new Oracle home. Therefore, follow the procedure described in Installing Oracle Fusion Middleware Infrastructure. |
Required Create the required 12c schemas. |
If you are upgrading from 11g release, then you must create the required schemas with the RCU. Unlike Oracle Fusion Middleware 11g, you cannot configure an Oracle Fusion Middleware 12c domain without installing the required schemas in a supported database. |
Optional Run the Readiness Check. |
|
Required Stop the servers and processes. |
Before starting the upgrade process, stop all the servers, components, and processes. |
Required Reconfigure the 12.2.1.x domain with the Reconfiguration Wizard. |
When you run the Reconfiguration Wizard on your existing domain, it prepares your domain for upgrade by selecting and applying the recongifuration templates. It also tests the JDBC data sources and component schemas that are present within your domain. To reconfigure you domain, follow the procedure described in Reconfiguring the Domain. |
Required Upgrade the 12.2.1.x domain configurations with the Upgrade Assistant. |
After you have reconfigured your 12.2.1.x domain, you must run the Upgrade Assistant to upgrade all configurations used by your 12.2.1.x domain. You can see all the components within your domain that will be upgraded on the Component List screen when you run the Upgrade Assistant. For the complete procedure, see Upgrading Domain Component Configurations. |
Required Restart the servers and processes. |
The upgrade process is complete. You can now restart the servers, components, and processes. |
Required Perform the post-upgrade tasks. |
For a list of post-upgrade tasks, see Using the Upgrade Validation Checklist. |
Required only if your existing environment is a clustered configuration Pack the existing domain on the primary node. |
Run the |
Required only if your existing environment is a clustered configuration Copy the domain template.jar file on the secondary node. |
Copy the |
Required only if your existing environment is a clustered configuration Unpack the jar file on the secondary node |
Run the |
Required only if your existing environment is a clustered configuration Restart the servers and processes. |
The upgrade process is complete. You can now restart the servers, components, and processes. |
Installing Fusion Middleware Infrastructure creates an Oracle home directory and lays down supporting software to install other Fusion Middleware products.
Note:
If you are upgrading from a previous 12c release (12.1.3.0, 12.2.1.0 or 12.2.1.1), then you must install the12c (12.2.1.2) distributions into a new Oracle home. Do not attempt to reuse the existing Oracle home for this upgrade. Upgrading to 12c (12.2.1.2) is not a patch release.When upgrading from 11g, you must use the Repository Creation Utility (RCU) to create the required 12c schemas before you begin the upgrade.
Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.If you are upgrading from 11g, refer to the Pre-Upgrade Checklist to identify the existing schemas in your domain. The following schemas must exist before you upgrade to 12c:
Service Table schema (prefix_STB
). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas. Note: If the Service Table schema does not exist, you may encounter the error message UPGAST-00328 : The schema version registry table does not exist on this database. If that happens it is necessary to create the service table schema in order to run Upgrade Assistant
.
Oracle Platform Security Services (OPSS) schema (prefix_OPSS
). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically. Note: The 12c OPSS database schema is required so that you can reference the 12c schema during the reconfiguration of the domain. Your domain continues to use the OID-based security store after the upgrade is complete.
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 3-6 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 3-7 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.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 Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).
When you reconfigure a WebLogic Server domain, the following items are automatically updated, depending on the applications in the domain:
WebLogic Server core infrastructure
Domain version
Note:
Before you begin the domain reconfiguration, note the following limitations:
The Reconfiguration Wizard does not update any of your own applications that are included in the domain.
Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.
The domain version number in the config.xml
file for the domain is updated to the Administration Server's installed WebLogic Server version.
Reconfiguration templates for all installed Oracle products are automatically selected and applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version.
Start scripts are updated.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.
Note:
Once the domain reconfiguration process starts, it is irreversible. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. If an error or other interruption occurs while running the Reconfiguration Wizard, you must restore the domain by copying the files and directories from the backup location to the original domain directory. This is the only way to ensure that the domain has been returned to its original state before reconfiguration.Before running the Reconfiguration Wizard, create a backup copy of the domain directory.
To create a backup of the domain directory:
The Reconfiguration Wizard reconfigures the domain while retaining the location of the domain. Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing domain.
Important
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain as described in If Your Existing Environment is a Clustered Configuration....After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.
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 3-9 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 upgrade component configurations in the WebLogic domain.
After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.
To verify that the domain-specific-component configurations upgrade was successful, log in to the Administration console and the Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.
To log into the Administration Console, go to: http://administration_server_host:administration_server_port/console
To log into the Fusion Middleware Control, go to: http://administration_server_host:administration_server_port/em
Note:
After upgrade, make sure you run the administration tools from the new 12c Oracle home and not from the previous Oracle home.
During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.
The components may be dependent on each other so they must be started in the correct order.
Note:
The procedures in this section describe how to start servers and process using the WLST command line 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 start your Fusion Middleware environment, follow the steps below.
Step 1: Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start the Administration Server, use the startWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 2: Start Node Manager
To start Node Manager, use the startNodeManager
script:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Step 3: Start Oracle Identity Management Components
Start any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
Step 4: Start the Managed Servers
To start a WebLogic Server Managed Server, use the startManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.Step 5: Start System Components
To start system components, such as Oracle HTTP Server, use the startComponent
script:
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
You can start system components in any order.
After the upgrade, make sure that you can successfully complete the basic administration tasks, such as verifying whether you are able to start the Node Manager, Administration Server, Webtier, Administration Console, and Enterprise Manager Fusion Middleware Control.
Note:
The order in which you start the following servers is important and failure to start (or stop) them in the correct order can cause issues with the deployment.
For more information, see Starting and Stopping Servers in the Correct Order.
To complete the upgrade of your application environment to 12c it might be necessary to reapply any custom configuration settings to startup scripts, such as setDomainEnv
. During the upgrade, the scripts are overwritten with new 12c versions. You must manually reapply the custom configuration settings you had made in previous releases.
For more information, see Re-apply Customizations to Startup Scripts.
Note:
To prevent losing your custom configuration settings in a future upgrade, see Maintaining Your Custom setDomainEnv Settings.
If you were using a file-based audit store in your 11g deployment, then after the upgrade to Oracle Fusion Middleware 12c, you should enable the loading of audit data to a database-based Audit Data Store.
As a part of the overall upgrade process, you should have created the IAU schema in the database where your other Oracle Fusion Middleware schemas reside. For more information about using the Audit Data Store, see Configuring and Managing Auditing in Fusion Middleware Application Security Guide.
The introduction of global policy attachment support for Java EE web services and clients in 12c may impact the backwards compatibility of existing Java EE web services and clients (12.1.2 and earlier). If a Java EE web service or client endpoint that depends on the absence of a policy falls within the scope of a global policy attachment, the presence of the globally-attached policy can alter the security behavior of that endpoint.
Note:
In Fusion Middleware 12.1.2 and earlier, global policy attachments defined for SOAP Web Service and SOAP Web Service Client subject types were applicable to Oracle Infrastructure web services and clients only, and were ignored by Java EE web services and clients. After upgrading to 12c (12.2.1), the global policy attachments defined for these subject types apply to Java EE web services and clients, as well, and may alter the security behavior of existing Java EE web services and clients.
To maintain backwards compatibility, you can disable the global policy attachments for specific endpoints by attaching an OWSM no behavior policy to the service or client, such as no_authentication_service_policy
, no_authorization_service_policy
, or no_messageprotection_service_policy
. For more information, see Disabling a Globally Attached Policy in Oracle Fusion Middleware Securing Web Services and Managing Policies with Oracle Web Services Manager.
Note:
You can use the WebLogic Wssp1.5-No-Op.xml
no behavior policy. However, since WebLogic security policies can only be attached to web service clients programmatically, it requires code change. For more information, see Disabling a Globally Attached Policy in Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server
This topic provides a list of common administration tasks you likely want to perform after upgrading to Infrastructure 12c and associated documentation resources.
Table 5-1 lists some common administration tasks you will likely want to perform after upgrading to Infrastructure 12c.
Table 3-10 Basic Administration Tasks
Task | Description | More Information |
---|---|---|
Getting familiar with Fusion Middleware administration tools |
Get familiar with the various tools available which you can use to manage your environment. |
Overview of Oracle Fusion Middleware Administration Tools in Administering Oracle Fusion Middleware. |
Starting and stopping products and servers |
Learn how to start and stop Oracle Fusion Middleware, including the Administration Server, Managed Servers, and components. |
Starting and Stopping Oracle Fusion Middleware in Administering Oracle Fusion Middleware. |
Configuring Secure Sockets Layer (SSL) |
Learn how to set up secure communications among between Oracle Fusion Middleware components using SSL. |
Configuring SSL in Oracle Fusion Middleware in Administering Oracle Fusion Middleware. |
Monitoring Oracle Fusion Middleware |
Learn how to keep track of the status of Oracle Fusion Middleware components. |
Monitoring Oracle Fusion Middleware in Administering Oracle Fusion Middleware. |
Understanding Backup and Recovery Procedures |
Learn the recommended backup and recovery procedures for Oracle Fusion Middleware. |
Introducing Backup and Recovery in Administering Oracle Fusion Middleware. |
After you upgrade to Oracle Fusion Middleware 12c, the custom Java and Application Development Framework (ADF) you previously deployed on Oracle Fusion Middleware 11g work as they did in Oracle Fusion Middleware 11g. However, there are some new features and capabilities available in ADF 12c and in JDeveloper 12c.
The following sections provide some additional information about how you can migrate your applications to JDeveloper 12c:
Oracle ADF is an end-to-end Java EE framework that simplifies application development by providing out-of-the-box infrastructure services and a visual and declarative development experience.
Information about Oracle ADF can be found in the following Oracle Fusion Middleware 12c documentation library:
Overview of Oracle ADF in Oracle Fusion Middleware Understanding Oracle Application Development Framework
Oracle Application Development Framework (ADF) Common tasks page
Oracle JDeveloper is an integrated development environment that simplifies the development of Java-based applications addressing every step of the application lifecycle. JDeveloper offers complete end-to-end development for Oracle's platform and applications.
ojdeploy
command line tool to generate the required deployment descriptors in your deployment archive.Oracle JDeveloper provides an embedded version of Oracle WebLogic Server that can be used to locally test your applications.
To install Oracle JDeveloper 12c, see Installing the Oracle JDeveloper Software in Oracle Fusion Middleware Installing Oracle JDeveloper.
For more information about using JDeveloper to test your applications, see Deploying and Testing Applications Developed in Oracle JDeveloper in Oracle Fusion Middleware Installing Oracle JDeveloper.
After you install Oracle JDeveloper 12c, you can open your custom application projects in Oracle JDeveloper 12c and automatically migrate them to Oracle JDeveloper 12c.
For more information, see Migrating Oracle JDeveloper From a Previous Version in Oracle Fusion Middleware Installing Oracle JDeveloper.
If your application contains Application Development Framework Business Components (ADF BC) asynchronous Web Services, ensure that you rebuild it using Oracle JDeveloper or the ojdeploy
command line tool to generate the required deployment descriptors in your deployment archive.
For more information about developing asynchronous Web Services, see Introduction to Developing Asynchronous Web Services in Oracle Fusion Middleware Developing Oracle Infrastructure Web Services.
If your existing environment is a clustered configuration, then you must apply the changes to other cluster members in the domain by using the pack and unpack utilities.
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.
The components may be dependent on each other so they must be started in the correct order.
Note:
The procedures in this section describe how to start servers and process using the WLST command line 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 start your Fusion Middleware environment, follow the steps below.
Step 1: Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start the Administration Server, use the startWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password, and the URL of the Administration Server.
Step 2: Start Node Manager
To start Node Manager, use the startNodeManager
script:
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
Step 3: Start Oracle Identity Management Components
Start any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
Step 4: Start the Managed Servers
To start a WebLogic Server Managed Server, use the startManagedWebLogic
script:
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.Step 5: Start System Components
To start system components, such as Oracle HTTP Server, use the startComponent
script:
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
You can start system components in any order.