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

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.

.

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

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

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.

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

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.

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.

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.

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.

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:

• Documentation reference Rapid Platform Update
• Enterprise Manager 13.5 Main Release Update List (Includes Plug-ins) (Doc ID 2760230.2)
• Rapid Platform Update  overview video