1 About Upgrade Strategies

An Oracle Identity and Access Management deployment consists of a number of different components:

• 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
  
• About the Out-of-Place Upgrade Strategy
  
• About the Out-of-Place Upgrade Strategy via Cloning
  
• Assumptions
  

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?
  

Performing an In-Place Upgrade

The in-place upgrade process is similar across all products.

To perform an in-place upgrade:

1. Take a backup of your existing environment.

2. Create a new binary installation.

3. Apply the pre-upgrade patches, if any, to the binaries.

4. Upgrade database objects.

5. Reconfigure the Domain.

6. Re-apply any customizations.

7. Start the component using the new version.

8. Take a backup on the new environment.

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

Lets you perform the upgrade on your existing hardware and requires no additional hardware. Is highly automated and simplified. Reduced work compared to other strategies. Maintains the historical data. Maintains the existing passwords, policies, and questions/answers. Ensures no gaps in data. Requires no reconfiguration of external resources such as DNS or load balancers. Requires no reconfiguration of external dependencies and other systems utilizing the Identity Management functionality.

Requires downtime. Requires reapplication of customizations that may be lost. Requires you to perform an upgrade more than once if upgrading through multiple versions. Some components may not work well together in different versions. For example: OHS 12c does not work well with OAM 11g without modifications. If any issues are encountered, the actual downtime may be higher than the planned downtime.

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.

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?
  

Performing an Out-of-Place Upgrade

The out-of-place upgrade process is similar across all products.

To perform an out-of-place upgrade:

1. Install your target version of Oracle Identity Management on new hardware.

2. Configure the new system by integrating components as necessary.

3. Apply customizations to the new environment.

4. Export your data from the existing system.

5. Load your data into the new system.

6. Verify the new system.

7. Take a backup on the new environment.

8. Switch over to the new system.

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

Reduced downtime. Lower risk. Upgrade many components at the same time. Change the topology. Change the architecture. For example: Moving from Oracle RAC to Exadata. Clean data if required. Create customizations ahead of time. Update UI or customizations. Useful for customers requiring major changes to their system. Run old and new system in parallel. Resolve issues without affecting production.

Requires extra hardware/resources. If you plan to run the new and existing system in parallel, existing external resources will require configuration changes to use the new system. For example: The IDM agents such as webgates which can only point to one system at a time, or OIM reconciling from two different LDAP directories. If you run these systems in parallel, you will have to manually enter details into both systems in parallel until cutover. If you do not run the old and new systems in parallel, existing resources such as DNS and load balancers will need to be reconfigured to use the new environment. If you build the new system ahead of time and transfer the data, then you need a mechanism to keep the data in both systems in sync, until cut over. Time to unload or load data can be significant depending on data volume.

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.

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
  

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.

• Host Names
  
• Cloning the Database
  
• Cloning the Binaries
  
• Cloning the Configuration
  
• Upgrading the Domain
  

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.

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
Suitable for smaller sized databases. Allows movement between versions. For example, 12.1.0.3 to 19c. Allows movement into container databases / private databases. Is a complete copy. Redoing the exercise requires data to be deleted from the target each time. No on-going synchronization. During cut-over, the source system will need to be frozen for updates.	Suitable for any size of database. Takes a backup of an entire database. Database upgrades will need to be performed as a separate task CDB/PDB migration will have to be done after restoring. No ongoing synchronization. During cut-over, the source system will need to be frozen for updates.	Suitable for any size of database. Takes a backup of an entire database. Database upgrades will need to be performed as a separate task CDP/PDB migration will have to be done as a separate exercise.

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.

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.

Upgrading the Domain

After cloning your installation, you can start upgrading the domain using the in-place instructions.

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

Reduced downtime. Lower risk. Upgrade many components at the same time. Retain historical data. Reapply customizations ahead of time. Migrate to different hardware + (optionally, with newer OS levels). Do not have to reconfigure external dependent systems. Use it as a testing ground to get familiar with and validate the procedure before doing it for real as part of an in-place upgrade. Use it for practising the upgrade if used in a test environment. Learn about the time taken to perform the upgrade if used in a test environment. Uncover and provide solutions for any unexpected upgrade issues if used in a test environment.

Upgrading via a cloned environment requires extra hardware and resources. The new system must use the same host names and load balancer virtual hosts. Because the names are the same (unless you used virtual names), you cannot run both systems side by side Requires the reconfiguration of external resources (DNS/load balancers) to point to the new system when it is available. If you build the new system ahead of time and transfer the data, then you need a mechanism to keep the data in both systems in sync until the cut over. Note: Oracle recommends you to upgrade via a cloned environment only when you have to upgrade multiple components at a time, and have a ready-made fall back.

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.

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.