1 About Upgrade Strategies
- A database
- An LDAP directory to store user information
- Oracle Access Manager for Authentication
- Oracle Identity Governance (formally Oracle Identity Manager) for provisioning
- Optionally, Oracle HTTP Server and Webgate securing access to Oracle Access Manager and Oracle Identity Governance
There are different upgrade strategies that you can employ for an upgrade of Oracle Internet Directory, Oracle Unified Directory, and Oracle Identity and Access Management. The strategy you choose will depend mainly on your business needs.
Note:
This guide provides you a high-level introduction to the different upgrade strategies. For detailed upgrade steps, see the component-specific upgrade guide for the release you want to upgrade.
This chapter includes the following topics:
About the In-Place Upgrade Strategy
The in-place upgrade allows you to take your existing deployment and upgrade it in situ.
When performing an upgrade, you should make as few changes as possible in each stage to ensure that the upgrade is successful.
For example, it is not recommended to perform multiple upgrade activities such as upgrading Oracle Identity and Access Management, changing the directory, updating the operating system, and so on, all at the same time.
If you want to perform such an upgrade, you must do it in stages. You must validate each stage before moving on to the next. The benefit of this approach is that it helps you to identify precisely where the issue occurred, and correct it or undo it before you continue the exercise.
Following are the topics covered in this section:
- Performing an In-Place Upgrade
- Advantages and Disadvantages of an In-Place Upgrade
- When is In-Place Upgrade Recommended?
Parent topic: About Upgrade Strategies
Performing an In-Place Upgrade
The in-place upgrade process is similar across all products.
To perform an in-place upgrade:
-
Take a backup of your existing environment.
-
Create a new binary installation.
-
Apply the pre-upgrade patches, if any, to the binaries.
-
Upgrade database objects.
-
Reconfigure the Domain.
-
Re-apply any customizations.
-
Start the component using the new version.
-
Take a backup on the new environment.
Parent topic: About the In-Place Upgrade Strategy
Advantages and Disadvantages of an In-Place Upgrade
Following table lists the advantages and disadvantages of an in-place upgrade:
Table 1-1 Advantages and Disadvantages of an In-Place Upgrade
Advantages | Disadvantages |
---|---|
|
|
Parent topic: About the In-Place Upgrade Strategy
When is In-Place Upgrade Recommended?
Following scenarios are suitable for an in-place upgrade:
-
Single instance deployments.
-
Deployments with no or very few customizations.
-
Resource constrained deployments (if you have the hardware limitations).
-
Non-integrated (loosely connected) environments.
Parent topic: About the In-Place Upgrade Strategy
About the Out-of-Place Upgrade Strategy
An out-of-place upgrade creates a second environment on a different hardware at the release you want to go to, and then migrates your data and configuration from your existing system to the new system.
After you migrate data and validate that the new system is working, you switch to the new system, and decommission the existing system.
Following topics are covered in this section:
- Performing an Out-of-Place Upgrade
- Advantages and Disadvantages of an Out-of-Place Upgrade
- When is Out-of-Place Upgrade Recommended?
Parent topic: About Upgrade Strategies
Performing an Out-of-Place Upgrade
The out-of-place upgrade process is similar across all products.
To perform an out-of-place upgrade:
-
Install your target version of Oracle Identity Management on new hardware.
-
Configure the new system by integrating components as necessary.
-
Apply customizations to the new environment.
-
Export your data from the existing system.
-
Load your data into the new system.
-
Verify the new system.
-
Take a backup on the new environment.
-
Switch over to the new system.
Parent topic: About the Out-of-Place Upgrade Strategy
Advantages and Disadvantages of an Out-of-Place Upgrade
Following table lists the advantages and disadvantages of an out-of-place upgrade:
Table 1-2 Advantages and Disadvantages of an Out-of-Place Upgrade
Advantages | Disadvantages |
---|---|
|
|
Parent topic: About the Out-of-Place Upgrade Strategy
When is Out-of-Place Upgrade Recommended?
Following scenarios are suitable for an out-of-place upgrade:
-
Complex installations with many customizations.
-
Complex HA installations that are tightly coupled.
-
When you want to run an old and new system in parallel.
Parent topic: About the Out-of-Place Upgrade Strategy
About the Out-of-Place Upgrade Strategy via Cloning
Upgrading via a cloned environment is a hybrid approach that involves cloning the existing system to a new set of hardware, and then performing an in-place upgrade on the cloned system. This approach can also be used to test the upgrade in a safe environment before doing it on your production environment.
Following are the topics covered in this section:
- Performing an Upgrade via a Cloned Environment
- Advantages and Disadvantages of Upgrading via a Cloned Environment
- Alternatives to Upgrading via a Cloned Environment
Parent topic: About Upgrade Strategies
Performing an Upgrade via a Cloned Environment
If something goes wrong during the upgrade of your existing deployment, you have to restore that deployment to the point it was prior to beginning the upgrade. An alternative approach is to take a copy of your existing environment, and then upgrade that. If something goes wrong, you have your existing environment as a fallback.
Parent topic: About the Out-of-Place Upgrade Strategy via Cloning
Host Names
The simplest method of cloning involves making no changes to the deployment
itself. The easiest way of achieving this is to ensure that your hostnames and site URLs
remain unchanged during the cloning process. This process follows the same approach as
Oracle recommends for Disaster recovery. Ideally you will have configured your source
environment using virtual host names rather than physical host names. For example,
oamhost1
rather than physhost1
. If you have done
this, then when cloning you just add the virtual hostname as an alias of the physical
hostname. However, if your source environment has not been configured to use virtual
hostnames, then you can can still use the same approach by aliasing your source
environment's physical hostname in your target environment.
For example, the goal is to have oamhost1
resolvable in
both your source and target environments but each resolving to an IP address appropriate
to the environment you are working. If you do this, then you need make no configuration
changes to your clone. If you must change the host names then this can still be achieved
but the cloning process becomes more complex and requires you to reconfigure the clone.
Parent topic: Performing an Upgrade via a Cloned Environment
Cloning the Database
The following methods are available to clone the database you use to host your application:
Option 1- Database Export Import
See Moving Data Using Data Pump and Export/Import.
Option 2 – Duplicate Database using RMAN
See Database Duplication.
Option 3 – Dataguard Database
See Data Guard Concepts and Administration.
The following table lists the advantages of above three options discussed:
Table 1-3 Advantages of using each method of cloning the database
Option 1 | Option 2 | Option 3 |
---|---|---|
|
|
|
Parent topic: Performing an Upgrade via a Cloned Environment
Cloning the Binaries
The Oracle binaries must be identical on both the source and target systems. They must be at the same patch level and in the same locations.
Following methods are available to achieve this:
Backup/Restore - Use your preferred backup tool to back up the
existing binary installation and restore it to the target system. Do not forget to
include the oraInventory
directory.
T2P- If your source environment is an 11g environment, you can use the Oracle Test to Production utility to replicate the binaries to a different set of hosts. For more information, see Moving from a Test to a Production Environment and Using the Movement Scripts in the Fusion Middleware Administrator's Guide.
Reinstallation- If you are confident you know all the patches and versions contained in your binary installation, then you can manually install them on your target system. For more information, see the Installing and Configuring Oracle Identity Management Guide for the release you are installing.
Note:
If you install your binaries locally, ensure that you do the same on your target system. If you use shared storage, then you only need to do the restore once to each shared storage location including any redundant copies you may have.Parent topic: Performing an Upgrade via a Cloned Environment
Cloning the Configuration
If you have kept your hostnames in sync across the source and target sites, then you can perform a simple backup and restore using your favourite backup and restore tool.
If your source environment is 11g, you can use the T2P utility to clone the configuration. This approach is more complex than a simple backup/restore, but it lets you change some values such as host names.
For more information, see Moving from a Test to a Production Environment and Using the Movement Scripts in the Fusion Middleware Administrator's Guide.
OIM also has a utility, which allows you to manually change the hostnames. For more information, see Doc ID 2621548.1.
Parent topic: Performing an Upgrade via a Cloned Environment
Upgrading the Domain
After cloning your installation, you can start upgrading the domain using the in-place instructions.
Parent topic: Performing an Upgrade via a Cloned Environment
Advantages and Disadvantages of Upgrading via a Cloned Environment
Following table lists the advantages and disadvantages of upgrading via a cloned environment:
Table 1-4 Advantages and Disadvantages of upgrading via a cloned environment
Advantages | Disadvantages |
---|---|
|
|
Parent topic: About the Out-of-Place Upgrade Strategy via Cloning
Alternatives to Upgrading via a Cloned Environment
Following are some alternatives you can use instead of upgrading via a cloned environment:
- If you have a Disaster Recovery (DR) system, you can upgrade the DR system instead of a clone.
- If you are using Oracle Unified Directory (OUD), you can create a replica of the existing site's Oracle Unified Directory instances using Oracle Unified Directory replication, and then upgrade the replica.
- If you are using Oracle Internet Directory (OID), you can create a
replica of the existing Oracle Internet Directory using OID replication, and
then upgrade the replica.
Note:
If you follow this mechanism when using OIG and OID, you will have to perform a full reconciliation on the new system before use.
- If you are using Oracle Access Manager, you can create a second deployment of Oracle Access Manager and synchronize it with the first using Oracle Access Manager Multi-Data Center technologies, and then upgrade the second site.
Parent topic: About the Out-of-Place Upgrade Strategy via Cloning
Assumptions
Following assumptions are applicable irrespective of which upgrade strategy you adopt:
- Each component directory, OAM, OIG, and Web Tier have dedicated binaries. This allows each product to be upgraded individually.
- Each component requiring a WebLogic domain (OAM, OIG, ODSM,
Adaptive Access Manager etc.) has a dedicated domain. For example, Oracle Access
Manager and Oracle Identity Governance are in different domains. This allows
each product to be upgraded individually.
Note:
If you are upgrading more than one component, you should first upgrade Oracle Internet Directory, Oracle Access Manager, upgrade the Oracle Identity Governance, and then do the reconfiguration.
Parent topic: About Upgrade Strategies