An Oracle SOA Suite - Team Blog
-
Tips & Tricks
|
August 27, 2014
Best Practices for SOA Suite 11g to 12c Upgrade
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 11.1.1.6 or 11.1.1.7. 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
11.1.1.6.
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.
Doc Link above doesn't work.. it says
404 Not Found!
Sorry, that page does not exist. Please try another location or you can search...
hi,
Is there already a tool for upgrade a lot of JDeveloper projects in a script?
Jan