Maintain Critical Monitoring and Alerting During Oracle Enterprise Manager Maintenance Using the Rapid Platform Update capability

March 30, 2022 | 6 minute read
Sumesh Balakrishnan
Principal Product Manager
Text Size 100%:

In Part 1 of this two-part blog we overviewed what Rapid Platform Update is and how it helps you to reduce maintenance windows and maintain monitoring continuity during EM updates.

Now in Part 2 on Oracle Enterprise Manager (EM) Rapid Platform Update (RPU), we will dive into the details of its 4 stages: Analyze, Deploy, Update and Verify. You will also see the benefits of RPU patching and a user experience comparison of traditional patching and the Rapid Platform Update.


Figure 1: 4 Stages of Rapid Platform Update Patching


Stage 1 – Analyze or Prepare [online phase]

Preparing to apply an RU is an important step in the entire patching process. Before you initiate the patching

  • Ensure a backup of the repository database and OMS have been performed
  • Download the respective OMSPatcher version from My Oracle Support (MOS) for a given RU as required by the patch
  • If required by the patch, update the OPatch and OMSPatcher on the OMS
  • Execute the ‘omspatcher deploy - analyze’ command to ensure there are no patch conflicts
Figure 2: Sample omspatcher deploy analyze command and output


Stage 2. - Deploy [online phase]

During the deploy phase the omspatcher utility orchestrates deploying the patch contents into the repository and OMS layer. During the deploy phase, the OMS  is up and running.  When the command ‘omspatcher deploy’ is executed, the following actions are executed internally.

  • Omspatcher utility creates a clone of an existing middleware home. The clone home is used for applying the Java changes in the patch
  • A new edition is created on the repository and all the SQL changes are applied on the newly created edition
  • The omspatcher utility registers the SQL in the new edition
Figure 3: Sample omspatcher deploy command and output


Once the ‘Deploy’ action is complete, run the ‘omspatcher status’ command to see what action is pending for the patch to complete.

Below is an example that shows ‘Deploy’ is complete and ‘Update’ operation is pending.

Figure 4: Sample omspatcher status command and output


Stage 3. - Update [downtime phase]

As part of the flexible patching strategy, you can execute the update phase whenever you have a scheduled maintenance window or during non-peak hours. Until that time the OMS will be up and monitoring critical targets.  With a scheduled maintenance window you can notify teams that EM will be down for patching, and start with the ‘update’ phase. There is no need to stop the OMSs before running the ‘omspatcher update’ command, the update command will internally stop the OMS.

On a high-level, the ‘update’ command will internally perform the activities below:

  • Execute the patch pre-requisite checks
  • Stop the primary OMS and any additional OMS’s that are up and running
  • It will prompt you to backup the repository database. Once you are done with the backup, you continue with the patching
  • During the database backup prompt, if you think back of the database backup will take longer than expected:  enter ‘N (No)’ and the omspatcher will exit and will provide the options to either resume patching after the database is backed up or provide the steps to revert the changes from the deploy command
  • When backup of the database is complete and you want to continue with patching, then run the ‘omspatcher resume’ command to resume the ‘update’ operation and it will complete the patching
  • Once you have completed backup of the database, enter ‘Y (yes)’ to continue with the patching. Then execute the update operation to execute the MRSs (Metadata Registration Service), change the edition, activate the MRSs, and then start the primary OMS.

Below is an example

Figure 5: Sample omspatcher update command and output


For a multi-OMS environment, the omspatcher utility will submit the job from the primary OMS to patch the additional OMS instances.  At the end of primary OMS patching the omspatcher utility will submit a job with name ‘MulitOMS_Patching_apply_<timestamp>. The EM console continues to be accessible so you can monitor the multi-OMS patching job status.

Below is sample output of the primary OMS patching specific to an multi-OMS patching job.


Multi-OMS Patching Job successfully submitted. Job details below:

The job name is MultiOMS_Patching_apply_2022-02-10_02-32-59

Execute the command: emcli get_jobs -name="MultiOMS_Patching_apply_2022-02-10_02-32-59" to check the status of the job.

Figure 6: Multi-OMS Patching Jobs status from Job Activity page


Stage 4: - Verify Patches

The final phase is to verify the patch applied on the OMS. Execute the ‘omspatcher lspatches’ command and verify that a patch applied displays in the list.


Differences between traditional patching and RPU patching

So, let’s finish up the blog by comparing traditional patching which is a full downtime operation with Rapid Platform Update patching.

This comparison will show the administrator interaction and user experience during patching in RPU mode.

Figure 7: User experience comparison during patching


You now see how Enterprise Manager downtime is reduced during patching using the Rapid Update capability

With upwards of a 90% reduction in downtime during EM patching here is a visual comparison.

Figure 8: Patching comparison with normal patching and RPU patching


You no longer have to wait or secure large maintenance windows.

Using the Rapid Update Patching capability you better plan and apply them as your business needs them.

Figure 9: Rapid Platform Update Summary


The Rapid Platform Update (RPU) is a paradigm shift in patching for Enterprise Manager users.  RPU introduces the ability to keep your EM system up and running while it is getting patched so you can continue to get monitoring insights on critical targets and meet SLAs during planned maintenance. The RPU capability is agile and enables administrators to quickly adopt new features and bug fixes while improving product quality, performance and availability.  Adopt it with confidence today for a stress-free patching tomorrow.

Learn more from these EM Rapid Platform Update Resources:

Sumesh Balakrishnan

Principal Product Manager

Enterprise and Cloud Manageability

Previous Post

Alert and analyze Oracle GoldenGate logs to locate issues faster with OCI Logging, Notifications and Logging Analytics

Vishak Chittuvalapil | 18 min read

Next Post

Rapid Platform Update: Reduce Maintenance Windows and Maintain Monitoring Continuity during Updates

Sumesh Balakrishnan | 5 min read