Rollback of OMS from 13c to 12c

Start Here

Get in touch with a
TriCore Solutions specialist

Blog | Jan 17, 2017

Rollback of OMS from 13c to 12c


Post new technology upgrades in an environment, it is not easy to revert the changes without proper planning and can be daunting. However, with the above methodology you can best plan to revert changes with minimal impact. Oracle provides best service levels for traditional approach for cloud applications through business-driven monitoring application management.

Introduction:
Change can come in many forms in our lives. It might come forcefully like a tidal wave, or creep along incrementally like a glacier. Another important change that affects are our lives in a big way is in the form of technology.  However, even though change is often difficult, many times it’s also for the best. Accomplishing anything great requires significant effort to push us beyond our comfort zone. 
In many cases, new technology upgrades can bring changes in our life that can be just as excruciating. Some changes are inevitable no matter how much we resist and can give us positive results. In this blog, the change we are discussing is about OMS/OMR/Agent rollback/restoration and recovery rollback.

oracle it support

 oem13c upgrade support

Details:
Our scenario is that we have upgraded the OEM13c to new environment using the direct upgrade method.  After some time we feel the current OMS13c version is not stable and we experience some issues which we never faced on 12cR5.  So we decided to complete rollback to existing 12cR5 environment. 

We use the old OMR backup for repository restoration and for OMS we use the backup configuration file for OMS12c to roll back the changes.

We can achieve the task in three phases as discussed below:

  • Phase 1

Here we use RMAN to restore the approach. We need to restore the OMR backup which we have taken before 13c upgrade. Steps include: Configure listener, TNS alias and services as per our existing setup. 

Once we have restored the existing OMR backup, it has all configuration related to OMS like emkey…. etc.  The next step is to install the OMS 12cR5 binary and recover the OMS configuration via OMSCA to achieve the goal. 

After that we just need to repoint the centralized agent and deployed target agent on all server.

In this scenario we are using OMR and OMS on same server. We can change the repository server if we want.

Restoring Repository Database from Backup, we can choose any below mentioned approach as per our convenience. 

  1. RMAN Backup restoration and recovery
  2. Export and Import
  3. Data Guard with broker
  4. Cold Backup
     
  • Phase 2

OMS Movement and Configuration Agent to New Host 

Repository Configuration:

In new server we have to restore the OMR repository database and configure the listener and TNS alias/services. 

We ensure that latest and required plugins has been copied and installed and same directory structure has been created on new server. Because we are reverting the OMS then we choose the Installed Software Only. After binary installation run the orainstRoot.sh co complete the installation task. 

Copy the OMS Configuration backup file to this server. 

[oracle@oem251 ~]$ cp /ora_global_nfs/BACKUP/REPDB_BACKUP/opf_ADMIN_20160303_105032.bka /backup/opf_ADMIN_20160303_105032.bka 

Recreate the OMS with OMSCA 

Shutdown everything on your old 13c. 

Recovering/recreating OMS using backup configuration via omsca 

oms:/u02/app/oracle/Middleware/oms:N

REPDB:/u01/app/oracle/product/12.1.0.2/DB_1:N 

[oracle@oem251 ~]$ omsca recover -as -ms -nostart -backup_file /ora_global_nfs/BACKUP/REPDB_BACKUP/opf_ADMIN_20160303_105032.bka 

  • Phase 3 

Configure Central Agent on New Host 

[oracle@oem251 agent_inst]$ /u02/app/oracle/Agent12c/core/12.1.0.5.0/sysman/install/agentDeploy.sh

AGENT_BASE_DIR=/u02/app/oracle/Agent12c AGENT_INSTANCE_HOME=/u02/app/oracle/Agent12c/agent_inst AGENT_PORT=3872 -configOnly OMS_HOST=oem251.ora.com EM_UPLOAD_PORT=4903 AGENT_REGISTRATION_PASSWORD=******** 

Run the root.sh script to complete the central agent creation part. 

[oracle@oem251 agent_inst]$ sudo /u02/app/oracle/Agent12c/core/12.1.0.5.0/root.sh 

Login to OMS using emcli and sync the repository 

Relocate the repository target to the new OMS host. 

[oracle@oem251 agent_inst]$ emctl config emrep -agent oem251.ora.com:3872 

Repointing/Reconfiguring (Agent) deployed target from old host to new host 

Reconfigure existing agents to re-secure them against the new OMS.  Since it’s a large environment we can done via shall script. 

[oracle@vm212 bin]$ ./emctl secure agent -emdWalletSrcUrl "https://oem251.ora.com:4903/em" 

Step through each of your existing agents to re-secure them against the new OMS. If you have large environment then this can be done via shall script in one go. 

Validations:

Verify the agent status after the re-pointing to new host. Once all agents are repointing to new OMS, verify the details on EM web console. 

Also verify the migrated Administration group from OLD OMS to NEW OMS.

Conclusion:

Oracle Enterprise Manager12c provides the most comprehensive management solution for Oracle environments, including traditional as well as cloud computing architectures. It also provides the monitoring and administration.  

Post new technology upgrades in an environment, it is not easy to revert the changes without proper planning and can be daunting. However, with the above methodology you can best plan to revert changes with minimal impact. Oracle provides best service levels for traditional approach for cloud applications through business-driven monitoring application management.

In case you run into problems, you can contact Oracle Support and file service requests. For any questions of the topic click below. You can also leave a comment in the field below. 
Ask Amit