Database Reference
In-Depth Information
System infrastructure components like disks, firmware, BIOS, and the operational system are patched first.
The “System Infrastructure” patching step requires full system downtime. All database instances and the Grid
Infrastructure processes are stopped during the patching.
Each quarterly release, the Oracle Database Appliance patch bundle may contain patches for different sets of
system infrastructures components. For example, a given release might contain patches for the Storage Expander,
ILOM, BIOS, and OVM. As mentioned, it is possible to skip some of the patch bundles. Helpfully, each of the Oracle
Database Appliances patch bundles is cumulative. An ODA customer may skip one or several patch bundles.
However, the number of system components to be patched in such a case is potentially higher than would be the case
when you patch each bundle. Patching downtime can increase depending on the number of system components to be
updated.
Based on our current experience, the total downtime for “System Infrastructure” patching generally falls between
45 and 80 minutes. The Oracle Database Appliance's nodes may be rebooted as part of the update of components like
OS, OVM, or storage. It is essential for critical systems to have a test run on a test environment to measure the total
downtime from the patch bundle and to verify whether node reboots are required.
After the system infrastructure is updated, the Grid Infrastructure needs to be patched. At the time of writing, all
Oracle Database Appliance patch bundles apply Grid Infrastructure updates in a rolling fashion. This means that one
of the two nodes is available during the update, and all the database services are up and running on the other node.
No downtime is involved.
The next and final stage is the databases upgrade. Several options are available for how to approach this task.
Some organizations may decide to skip the database-patching step each alternate quarter, and patch databases once
in six months, thus saving time on application testing while still keeping their system infrastructure up to date. Other
organizations may patch their databases at the same time as they apply infrastructure patches. Some organizations
may separate the infrastructure and databases updates. Such separation allows one to take the whole system down
for just the infrastructure patching, and then bring the system up and complete the remaining updates in a rolling
fashion. The ODA provides the flexibility, allowing you to choose your own approach to patching depending on your
organizational requirements.
Timing
There are two aspects to timing. The first is the question of how often to patch. We've touched on that already by
mentioning that some organizations apply only every alternating patch. The other aspect to consider is how long an
individual patch application takes. If one is to apply a patch, one should have an idea as to how long the target system
will be offline.
How Often to Patch
Oracle releases Patch Set Updates (PSU) and Security Patch Updates (SPU)—the SPUs are better known as Critical
Patch Updates (CPU)—for Oracle Database products on a quarterly basis. The SPU is a smaller set of changes
focused on critical issues only. PSUs include SPUs plus additional fixes. Oracle suggests choosing one of the following
practices:
•
Apply SPUs on top of a base release to minimize the amount of change applied between one
main release and the next.
•
Implement PSUs on a regular basis to make sure that all critical and security fixes are applied.
The Oracle Database Appliance adopts the PSU's patch cycle. An Oracle Database Appliance patch bundle is
released shortly after a PSU patch is released. It is worth mentioning that Oracle Database is just one component that
is included in the Oracle Database Appliance patch bundles. However, it is one of the main components. Therefore,
Oracle's adoption of the PSU patch cycle for the ODA makes a lot of sense.
