Applying Patches using OEM Oracle Enterprise Manager

By Porus Homi Havewala

Enterprise Manager Grid Control Release 2 (10.2.0.2) formally introduced the Provisioning Pack, which allowed the DBA to provision and deploy Oracle software and databases located on a source “gold” server to another server using the cloning feature within the Provisioning Pack.

The Provisioning Pack was an optional, licensable feature within Grid Control and included the capability to patch Oracle databases and application servers. Later releases of Grid Control enhanced these capabilities to a high level of sophistication. The Provisioning Pack is now known as the Provisioning and Patch Automation Pack as a result.

These patching capabilities are one of the best advantages of Oracle Enterprise Manager Grid Control over third-party database management tools that have very limited capabilities in this regard. Also, using Oracle patching and provisioning products to patch and provision other Oracle products was ideal because third-party Vendors are not privy to the internal workings of the Oracle database machine.

The metadata of the latest patch advisories, products, and product versions that are available from the My Oracle Support. Internet site are downloaded each day by the My Oracle Support refresh job. The job also computes the targets for the most recent Critical Patch Updates (CPU).

Many companies restrict Internet access to production servers for security reasons. In such cases, the Oracle Enterprise Manager Grid Control site will not have a direct (or even proxy) Internet connection to the My Oracle Support site. Conveniently, Oracle allows you to perform offline updates to overcome this restriction. The official reference on how to achieve this is provided in FAQ #8, “How can I patch if my OMS [Oracle Management Service] is Offline or Disconnected from the Internet?”. This FAQ is in the Oracle Technical Network (OTN) Document “Achieving Grid Automation with Deployment Procedures”.

For the actual patching, we recommend the new and extremely powerful Deployment Procedures functionality in Oracle Enterprise Manager Grid Control that allows you access to a number of advanced features including multiple patch application, patch flow customization, sudo, and also pluggable authentication modules (PAM) support. These deployment procedures are based on best practices and Oracle experience over the years. Examples of the out-of-the box deployment procedures that Oracle provides are seen in the following screen shot:

As an example, the deployment procedure “Patch Oracle Database” performs the following actions in the following order:

1.      Upgrade the Oracle OPatch utility, which is the actual database-level mechanism for patching Oracle databases. This upgrade of OPatch is optional but is always recommended.

2.      Stage the selected patch in a staging location.

3.      Initiate a blackout for the database in Oracle Enterprise Manager – since this downtime has been planned in advance, no alerts should be raised when the database is brought down.

4.      Shut down the database.

5.      Apply the database patch.

6.      Execute any applicable root script.

7.      Restart the database in the upgrade or migrate mode.

8.      Apply any applicable SQL script in the case of a patch set or a CPU.

9.      Apply a post-SQL script.

10.  Shut down the database.

11.  Restart the datasbase.

12.  Apply additional SQL scripts as required.

13.  Stop the Enterprise Manager blackout for the database so that EM can begin raising alerts again.

14.  Refresh the host configuration collection.

These steps can be seen in the following screen shot:

In the book, we proceed to test this deployment procedure, observe a locking issue in Windows, and find a workaround. The workaround is then used in a customized deployment procedure to allow seamless patching of an Oracle database in Windows, thereby demonstrating the power of the customized deployment procedures.