Make sure that you review the release notes to determine if any known issues could be impacting your upgrade. You can find the release notes in the Oracle Fusion Middleware 12c (22.214.171.124) library.
If the administration or managed servers do not start after the upgrade, you may need to re-apply any customizations added to startup scripts, files and classes.
If servers do not start, or they start in AdminMode, the cause is most likely that changes to startup scripts or domain variables from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.
To determine if this is the cause, compare the pre-upgrade startup scripts or files from your backups to the new 12c scripts and files. If there are differences, then update files as described in the following procedures.
If servers do not start, or they start in AdminMode, the cause is most likely that the
setDomainEnv.sh changes from the previous environment were not reapplied to the newly configured 12c domain. During the upgrade process, startup scripts are replaced with the latest version. If you made any modifications to these files, then you will need to edit the new startup scripts with the same information.
To determine if this is the cause, compare the setDomainEnv file from your pre-upgrade backup to the new 12c setDomainEnv file. If there are differences, then make the same changes in the new setDomainEnv file.
If you used a start script to specify required startup properties, or to perform any other work required at start up in your 11g environment, then you will need to reapply the properties post-upgrade.
Specifically, if you have configured JRockit JVM arguments in your 11g environment, then these configurations must be reapplied post-upgrade. Oracle recommends that you use either
startscript.xml for configuring JVM startup parameters.
Failure to update the start script arguments may prevent you from starting the SOA and OSB servers after the upgrade.
To enable the scripts:
nodemanager.properties file, set the
StartScriptEnabled property to
true. (The default is
false.) If your start script is named
startWebLogic.cmd, Node Manager uses one of those scripts as the default.
If you want to specify a custom start script, set the
StartScriptName property to the name of your script in the
Node Manager sets the
ADMIN_URL. It retrieves these values from the
SSLMBean when you use the Administration Console to start the server, or WLST connected to the Administration Server. When you use WLST connected directly to the Node Manager, you can specify the values; otherwise, they are left empty.
Node Manager combines all of the command line startup options (-D flags) that are specified in the
Arguments attribute, as well as the
SSLArguments into a single environmental variable called
SSLArguments are retrieved from the values in the
SSLMBean is inspected for
ReverseDNSAllowed values, then those values are appended to the -D flags. All of those flags comprise the
SSLArguments parameter. All of the values for
SSLArguments as well as
Arguments in the
ServerStartMBean comprise the
JAVA_OPTIONS environment variable that is defined for the start script. In addition, the script will append any of its own defined values onto this environment variable.
Any pre-upgrade changes made to the XEngine configuration files, such as
SeverityConfig.xml, will be overwritten by new, regenerated configuration files during the domain reconfiguration process. Therefore, all customized settings used in the pre-upgrade configuration files will need to be reapplied after the upgrade.
For example, if you added a section for SNIP in the pre-upgrade XEngine configuration file,
SeverityConfig.xml, the same section will have to be added to the new, post-upgrade
If you modified the default XPath classes in your pre-upgrade environment, then after the upgrade you will need to copy the customized XPath classes to the new 12c Oracle home as shown in the example below:
Copy the custom XPath classes from your pre-upgrade backups. Classes are found in the following directory:
to the following 12c directory:
Recovering from a failed upgrade depends on when the error(s) occurred. Review the following to determine how to recover:
If there are errors while running the Upgrade Assistant to upgrade
_SOAINFRA schema, you must fix the errors in the schema and rerun batch jobs.
Note that this recovery method only applies when you are running the Upgrade Assistant for the first time and you selected the Schema option.
If there are errors while running the Reconfiguration Wizard, you must restore from source environment and restart the upgrade from the beginning.
If there are errors while running the Upgrade Assistant to upgrade WebLogic Component Configurations option, then you can fix the errors and rerun the Upgrade Assistant. The second time you run the Upgrade Assistant there is no need to restore from backup and restart the upgrade process from the beginning. This process is reentrant.
If there are errors while running the Upgrade Assistant to upgrade schemas, and the error occurs during the upgrade phase, you will have to restore from backup, correct the issues, and then restart the upgrade from the beginning. If the error occurs during the examine phase, however, you can correct the issues and restart the Upgrade Assistant. Errors that occur prior to the upgrade phase are reentrant.
For more information on troubleshooting your upgrade, see "General Troubleshooting Guidelines" in the Upgrading with the Upgrade Assistant.
If you received the CFGFWK-60950 error, rename the BAM templates as described in "Renaming the Oracle BAM Templates Before Upgrading the 11g Schemas" and launch the Reconfiguration Wizard again.
If you received this error, you will need restore your entire pre-upgrade environment, perform the necessary pre-upgrade tasks and then perform the steps in the section listed above before you can attempt the reconfiguration process again.
For more information on resolving BAM-specific issues, see Recovering from a Failed Oracle BAM Upgrade.
When you select All configurations used by the domain when running the Upgrade Assistant, the upgrade can fail at the examination phase with the WSMERROR-00015 error. This error can occur when the pre-upgrade domain is created with Multi-DataSource connection.
[2015-09-22T10:46:54.552-07:00] [WSM] [INCIDENT_ERROR]
oracle.ias.update.exception.UpgradeException: WSMERROR-00015: Failed to read the Oracle WSM datasource connection details.
When upgrading to 12c (126.96.36.199), the Upgrade Assistant expects a generic datasource connection. Since this error is detected during the Examination phase, you can go back and correct the issue and continue with the upgrade without restoring from backup.
To complete the upgrade, complete the following steps:
Navigate back to the Datasource screen in the Upgrade Assistant.
Change the "mds-owsm" data source to be a generic data source.
Restart the Upgrade Assistant and, when prompted, select All configurations used by the domain.
After a successful upgrade, you can change the "mds-owsm" data source back to a multi-DS.
When upgrading a domain containing Oracle Business Activity Monitoring (BAM), note that there are additional BAM-specific troubleshooting procedures.
For more information, see Recovering from a Failed Oracle BAM Upgrade.
After upgrading to 12c (188.8.131.52), the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.
This is a known issue and can occur in both clustered and unclustered environments.
See the Administration Console online help for more information on reapplying the EDNTopic or contact Oracle Support.
If you experience post-upgrade issues with Oracle Service Bus, review the troubleshooting procedures described in Troubleshooting Oracle Service Bus Upgrade.
If you encounter an upgrade error while upgrading Oracle Managed File Transfer, refer to these troubleshooting tasks to correct the issue.
Some common upgrade error messages for Managed File Transfer are listed below:
SQLException: ORA-04020: deadlock detected while trying to lock object
Resolution: Make sure that you selected Managed File Transfer on the Available Components screen of the Upgrade Assistant. If you do not select Oracle Managed File Transfer, the upgrade will not include MFT schema.
Creating Backward Compatibility of SOAP Services
When upgrading from the 184.108.40.206 to 220.127.116.11 release, and you have Managed File Transfer-specific projects created in older versions using JDev, you must correct the WSDL definition of existing SOA/SOAP projects by opening them with JDev and redeploying the composite.
This is necessary when MFT is the target for SOA composite (not when it is a source for SOA).
If there was a custom trust keystore configured in Enterprise Manager 11g prior to the upgrade, you may encounter issues with starting the OWSM.
Specifically, if after upgrading an 11g domain running OWSM to 12c, you receive the following error in the OWSM server log (after the second startup), then you must manually correct this issue:
<Error> <HTTP> <srvgdysoap01.nov.com> <wls_wsm1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <26c804bb-15a7-46de-a81e-82565fcd2f28-00000004> <1418929621034> <BEA-101216> <Servlet: "PolicyManagerValidator" failed to preload on startup in Web application: "/wsm-pm".
If wsm-pm application will not start, you must perform the following steps:
Roll back the upgrade to 11g by restoring the backup files.
Complete the upgrade steps again using the Upgrade Assistant.
Start the OWSM server
It is very important to only start the OWSM server once and leave it running. If you stop and restart it then the NPE will present itself and you will have to roll back again
Execute the following WLST command against the running OWSM server from the <domain_home>/oracle_common/common/bin location:
exportMetadata('wsm-pm','<wsm server>','location to write the zip') where <wsm_server> is the name of the WLS server running OWSM ('wsm_server1' for example)
Extract the MDS archive and go to /configuration/WLS/ and open the file there. The file name is the name of the domain.
Search for the property entries containing the string 'keystore.inst.0'. There are probably several of them in a row and they look like
Delete these properties from the file.
Rebuild the archive and import it back to the running server with the command:
importMetadata('wsm-pm','<wsm server>','location of zip')
Restart the servers.
If you received the following error message during the reconfiguration, you may need to apply additional policy files to the JDK and restart the upgrade from your backup:
JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation
To prevent this error from reoccurring, apply the policy files before the subsequent upgrade as described in:
If you plan to use enhanced encryption, such as Advanced Encryption Standard (AES) 256, in your upgraded environment. Oracle recommends that you apply the latest required policy files to the JDK before you upgrade.
The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code.
Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK. For more information, see Java Cryptography Architecture Oracle Providers Documentation.
Note:If you attempt to use enhanced encryption without applying these policy files to the JDK before you begin the upgrade, the upgrade can fail and you must restore the entire pre-upgrade environment and start the upgrade from the beginning.
If you receive an error from the Upgrade Assistant stating that the specified domain cannot be upgraded, then your domain configurations are not supported for this release. For more information on supported configurations and domain restrictions, see Understanding SOA Domain Upgrade Restrictions.
Do not attempt to upgrade or schemas or domain configurations in an unsupported domain.
The audit trail for upgraded 11g instances of the Decision Service Component will not be available post-upgrade. The audit trail for new 12c instances will continue to display.
If you see the following WebLogic Cache Provider Coherence exception then it is likely that you are not following an enterprise deployment topology recommendation to specify a specific ListenAddress.
When you see this exception, you must set the ListenAddress for your managed server as shown below:
weblogic.cacheprovider.coherence.CoherenceException: at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510) at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236) at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225) at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)
Log in to the WebLogic Server Console.
Navigate to Servers.
Locate the Managed Servers (SOA or OSB, for example).
Modify the Listen Address from
127.0.0.1 or provide the actual machine name.
If your EJBs contain custom exceptions, and you export the Web Service Description Language (WSDL) file from your EJB business service, the generated WSDL file will not have the custom exception properties in it. You will need to manually edit the WSDL file to include these custom exception properties after the upgrade.
The issue is limited only to the WSDL generation part of the file. During runtime, the custom exception thrown from the EJB will be mapped to the respective elements in the SOAP fault. The response payload will have the elements populated corresponding to the properties of the custom exception.
There is a change in behavior in which the ServerSocket is created when you upgrade from Oracle Release 11g to Release 12g. Because of this, remote clients might not able to connect to the ServerSocket when the
hostname is configured as localhost. As a workaround, the
localhost should be changed to hostname.
For more information, see "Configuring Oracle Socket Adapter" Understanding Technology Adapters.
Schemas with a post-upgrade status of
INVALID may indicate a failed upgrade, but not in all situations.
If the post-upgrade schema status appears as INVALID, it may indicate that the schema update failed. You should examine the logs files to determine the reason for the failure.
EXCEPTION: Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID in the schema version registry table, but that does not indicate a failure. Synonym objects become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.