Applying Patches using OEM Oracle Enterprise
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
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
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.
Stage the selected patch in a
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.
Shut down the database.
Apply the database patch.
Execute any applicable root
Restart the database in the
upgrade or migrate mode.
Apply any applicable SQL script
in the case of a patch set or a CPU.
Apply a post-SQL script.
Shut down the database.
Restart the datasbase.
Apply additional SQL scripts as
Stop the Enterprise Manager
blackout for the database so that EM can begin raising alerts
Refresh the host configuration
These steps can be seen in the following
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.