Databases Reference
In-Depth Information
[INFO] SUCCESS All switches have correct opensm configuration:
controlled_handover=TRUE polling_retry_number=5 routing_engine=ftree
sminfo_polling_timeout=1000 sm_priority=5 for non spine and 8
for spine switch5
[root@cm01cel01 ~]#
How It Works
Exadata Storage Servers are patched using the
patchmgr
utility.
patchmgr
is included with each storage server patch
and is located in the
<staging directory>/Infrastructure/ExadataStorageServer/<version>/patch_<version>
directory.
Prior to applying Exadata Storage Server patches, you typically need to perform a few prerequisite tasks,
including the following:
1.
Starting an ILOM console on each storage cell
2.
Running
ipconf -verify
to validate your storage cell network configuration
3.
Establishing SSH user equivalence between
root
on your compute node and
root
on each
storage cell
4.
Running
patchmgr
with the
-check_prereq -rolling
option to ensure that your cells can
be patched in a rolling manner
5.
Adjusting your ASM disk group's
disk_repair_time
attribute
Applying the Exadata Storage Server patches on the storage cells is performed using the
patchmgr
utility, as
presented in the solution of this recipe. As the storage servers are patched, Oracle will first apply the patch to the
inactive system partition, which is part of Exadata's System Area or system volumes. If the patch fails for whatever
reason, the cells are still bootable from the active, unpatched partition. If a patch succeeds, the inactive partition,
patched via
patchmgr
, is made the active partition and the active partition that holds the previous image is swapped
to the active partition.
patchmgr
performs these tasks automatically and also performs one or more reboots during the
process.
Not
■
in the
README
for each storage server patch, Oracle provides detailed rollback instructions that are to be
followed in the event of a patch failure. We will not discuss these steps in this recipe, as the nature of the failure could
vary from one patch to the next. Our recent experience has shown that it is becoming increasingly rare for a storage
server patch to fail.
The steps in this recipe have only covered the storage cell components of an Exadata Storage Server patch. When
storage cells are patched, there is almost always a set of storage server patches that need to be applied to the Exadata
Compute Nodes as well. Historically, these were called “minimal packs,” but recent improvements to the compute
node patching process deliver these updates using yum channels on Oracle's Unbreakable Linux Network (ULN).
Regardless, these patches on the compute nodes update software binaries and libraries, RPMs, and install a new
image on the compute node that is certified with the images on the storage cells. When patching a storage server,
always make sure you understand the compute node patching requirements and apply accordingly. Recipe 11-4
presents details on how to patch Exadata Compute Nodes using yum and Oracle's ULN.
Search WWH ::
Custom Search