Database Reference
In-Depth Information
4.
Do not update the standby database Oracle Home just yet. Instead, reestablish the redo log
application process.
5.
Switch your applications to use the secondary Oracle Database Appliance, thus switching
over to the standby database. At this point, the primary Oracle Database Appliance can be
taken offline to update infrastructure components.
6.
Update your database to the latest version using the rolling update approach. This way,
there is just a short switchover time when applications need to be repointed from the
primary to the secondary Oracle Database Appliance. There is no application downtime
associated with the infrastructure update activities.
Use of Data Guard as just described requires a bit more effort in planning, preparation, and implementation.
However, the Data Guard approach provides a minimal switchover time as opposed to the hours of downtime and limited
mode operations during the Grid Infrastructure and database patching steps when performed in their normal manner.
Virtual Oracle Database Appliance
We aren't going to spend too much time talking about the virtual machine (VM) option here. However, it is worth
mentioning that a VM environment isn't too different from a patching perspective. There is just one additional
component to patch during the System Infrastructure patching phase, and that is the Oracle VM Server.
If a patch bundle delivers an Oracle VM Server patch, then all virtual machines must be stopped, the main Oracle
VM Server host's (so-called Dom0 host) operational system must be patched, and the whole server must be restarted.
As with any patching, you should spend time carefully looking through the patch bundle's README file to make
sure that you complete all the additional steps related to VM configuration. Some of the earlier patch bundles came
with instructions for patching-related activities that are specific to the VM configuration.
The other important thing to know is that all patching activities—for example, patch staging, unpacking, apply,
and so forth—are to be executed from within the so-called Oracle Database Appliance Base Virtual Machine. Oracle
engineers carefully design VM patches to make sure that they can be successfully applied from a running VM before
restarting the Oracle VM Server.
The two items I've just mentioned are the only important differences between the bare metal patching process
and the VM configuration patching process. Keep in mind that the system requires a small amount of full downtime
for the System Infrastructure patching phase in either configuration. Therefore, there is no significant difference in
that regard. The VM option may require perhaps ten minutes more downtime than the bare metal option, because
the Oracle VM Server is an additional element that must be patched.
Preparation
The first step in the patching process is preparation. It's an important step unless you enjoy all-nighters. Don't
shortchange it. Among other generic activities associated with traditional system patching, the following are some
things to check, and then to do during the planning part of the ODA patching process.
