Best Practices for SOA Suite 11g to 12c Upgrade
By Jay.Kasi-Oracle on Aug 26, 2014
A lot of effort has been put in by Oracle to make this major upgrade as smooth and easy as possible. The basic approach is to install SOA Suite 12c in a new oracle home and upgrade the domain and schemas in place. Customers undertaking the upgrade are primarily interested in a smooth upgrade, minimizing the number of manual steps in the upgrade, reduce the down time to a minimum, and minimize or eliminate any changes to client apps that use SOA APIs or web interfaces.
The key to a successful and smooth upgrade experience are the preupgrade preparations that you perform. The upgrade must be planned carefully. If the preupgrade preparations are not performed, there is a possibility that upgrade will fail in the middle or the system does not behave properly post upgrade. The only recourse to a failed production system upgrade is to roll it back from a full backup.
If your SOA domain includes BAM, then the upgrade is more complex because BAM does not support inplace upgrade. Please read the documentation carefully. The basic idea is to migrate the whole BAM deployment to a seperate domain using export/import, remove BAM from the soa domain during upgrade, and upgrade your soa domain to interop with the bam 11g domain. Later slowly and carefully migrate to BAM 12c from BAM 11g.
There are six top steps that should be performed before upgrade of your production system as a best practice.
- Carefully review the prerequisites for upgrade in the documentation. Some of the prerequisites are checked upfront before we upgrade the schema in Upgrade Assistant but not all. Read all relevant upgrade documentation before starting on upgrade. Some of the key prerequisites are:
- Can only upgrade a domain that is 188.8.131.52 or 184.108.40.206. Migrate to a supported starting point before upgrade.
- Can only upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.
- Can only upgrade a production domain not using XE DB and is not an admin server only domain.
- Can only upgrade a domain using LDAP or DB OPSS policy store. Migrate file based policy store to DB or LDAP based policy store before upgrade.
- Can only upgrade a domain using a oracle DB of a version supported by the SOA Suite 12c certification matrix. Migrate to a supported DB version before upgrade.
- Can only upgrade a domain based on weblogic server.
- Can only upgrade a domain at this time with products deployed that were released in 12c. Example of products not released are OER, OSR, Webcenter, and SOA task UI exposed as portlets (which uses webcenter libraries).
- Cannot upgrade a domain at this time created with T2P or pack/unpack before SOA Suite 220.127.116.11.
Cannot upgrade a domain at this time with multiple products in 12c in separate unclustered managed servers using UMS. Examples are BAM, OSB and SOA. The reason is because after upgrade UMS configuration is at the domain level or the cluster level, but not at a unclustered managed server level.
Only JDK 7 is supported.
- Always test upgrade first before actually upgrading your production system. Test with a clone of your production system either created with T2P or test with a existing test environment which mirrors your production environment. T2P does not clone the transactional store. It only creates an environment that is identical in configuration to the source. If you create an environment by doing T2P of production, you will first need to populate that environment with sufficiently representative transactions. Documentation for T2P can be found here:
Oracle Fusion Middleware Administrator's Guide 11g
Release 1 (11.1.1)
Chapter 21 Moving from a Test to a Production Environment
- Use the upgraded test environment to test all the composites without redeploying, and to determine the performance tuning to be done to your production system post upgrade. Tuning in SOA Suite 12c is different than 11g. For example work managers are used extensively for threads in SOA Suite 12c.
- Always backup everything before upgrading your production system and test restoring from the backup in your test system. If the upgrade fails in the middle, you might have to restore the backup.
- Before upgrade of your production system, purge as many instances as possible that are not essential to keep to make the upgrade faster. Upgrade will upgrade all the open instances when running the Upgrade assistant and closed instances are upgraded lazily post schema upgrade in the background. This can take significant time and disk space. There is currently no estimation tool for amount of disk space or time, so be conservative so upgrade does not run out of disk space.
- Upgrade all your SOA projects in JDeveloper and test them on your upgraded test system. This is so there is no surprises later when you need to change the project to add a new feature or fix a bug. Currently though there is no tool to bulk upgrade a lot of JDeveloper projects in a script. We are exploring such a tool. However compile and deployment can be scripted.
Upgrade documentation and videos can be found at the following URLs.