By Jay.Kasi-Oracle on Apr 27, 2015
This article compares in-place upgrade with side by side upgrade to SOA 12c.What are the advantages and disadvantages? What are the prerequisites?
In in-place upgrade you install SOA 12c in a new oracle home and upgrade the domain and DB in-place. This is what is documented in the upgrade guide. In side by side upgrade, you install SOA 12c in a new oracle home and create a new SOA 12c domain and DB. You then deploy all the composites and configure the 12c domain fully. You then cut over from 11g to 12c.
Side by Side upgrade does not apply if you have long running instances and you cannot guarantee that all inbound messages have been drained and there are no active instances when you cut over to 12c. Even if this is not true, you could still keep the 11g system up (with no new messages) until all messages are drained and all active instances complete. We will briefly cover this option at the end but ignore it for the rest of the article.
The advantages of in-place upgrade over side by side are the following.
- You do not have to take the effort of configuring a new enterprise deployment which could take a long time. You do not have to replicate the SOA configuration after the upgrade. You do not have to configure your custom adapters, adapter configurations, JMS queues/topics, datasources, non SOA J2EE Apps, etc. All the configurations and deployments carries over. In side by side, all this configurations have to be done from scratch.
- Long running instances continue after upgrade where they left off.
- You retain the history of completed instances after upgrade.
- You don't need new licenses. You should check with Oracle if new licenses are needed if you don't put the 12c domain on the same CPUs as the 11g domain in a side by side upgrade.
- All inbound addresses are the same so clients don't need to be modified. This includes JMS queues/topics, file directories, etc. For side by side, inbound HTTP traffic can be redirected without impacting clients by switching at the load balancer, but others may require changes.
The disadvantages of in-place upgrade over side by side upgrade are the following.
- There are limitations and prerequisites documented in the upgrade guide for in-place upgrade. For example the starting version must be 184.108.40.206 or 220.127.116.11. IF you are not meeting these requirements, you have to fix it (for example upgrade to 18.104.22.168 first) before you start the 12c upgrade or not do the in-place upgrade since it is not supported with your current configuration (for example you created your production system with T2P before 22.214.171.124). For side by side, you can create the 12c domain and migrate your composites without this problem. If you are migrating from a version before 126.96.36.199, first migrate your jdeveloper projects to 188.8.131.52 then migrate the jdeveloper projects to 12c.
- The down time during upgrade could be quite long. You need to shut down your 11g production system, take a complete backup, perform the upgrade, and then test and tune your upgraded domain, before making it live. Cutting over to 12c for side by side could be fast with minimum down time since everything in 12c has been tested and tuned while the 11g system was live.
- If you have BAM in your domain, BAM does not support in-place upgrade and you have a much more complex in-place upgrade path. Creating a new 12c domain with SOA and BAM is straight forward.
- Doing an in-place upgrade is a very demanding requirement and Oracle has tested it thoroughly to provide a smooth experience. However there is a possibility that your particular special deployment encounters issues. This may cause delays in your testing of in-place upgrade. Issues are much less likely if you create a new domain.
- The focus of in-place upgrade is backwards compatibility and a silent automatic upgrade. Sometimes this means new 12c features may be disabled after upgrade and you may have to enable these gradually some time after going live on 12c. . For example the key store technology has changed from JKS to KSS. However after upgrade you are still left with JKS since it is not possible to auto migrate to KSS. Another example is the XML XDK is configured for backwards compatibility after upgrade disabling new features. This is not a problem with side by side. With side by side, you have plenty of time to modify your composites if you want to, to take advantage of new features.
- Rolling back the upgrade if you encounter problems during or after upgrade requires you to restore from full backup. With side by side, you would have had plenty of time to thoroughly test so it is very unlikely you have to go back to 11g.
If you continue running the 11g system after the 12c system goes live then things like Human Workflow approvals and EM management have to be done in two places, and clients sending messages to a running process may not work.