Operate an Exadata Database Machine means you have to manage the Lifecyle. One major task is the regular patching of the whole Exa Stack.
This blog article give you an overview about the Patching.
First remember which components are part of the lifecycle.
Following the component and the tool.
- GRID & RDBMS
- DB Node
- patchmgr (that’s new since Oct 2015)
- Storage Grid
Before starting the Patching you need to do a bullet proof planing otherwise you fail.
For a Quarter Rack with lets say 10 Production databases you need a planing phase of more or less 2-3 weeks.
How to setup a recommendation?
- Analyze your ORACLE_HOMES
- Check existing SR for every database
- Meet with your Application Manager
- Use Oracle Tools like exachk
- Use the conflict analyzer in MOS
exachk will be your best friend
Check the My Oracle Support Note 1070954.1 and install the latest version
First take a look of the table of contents
and one very important table is the recommended version overview
What will be the best recommendation?
It doesn’t give an easy answer while Oracle has a lot of possibilities for the Patching:
- the QFSDP the Quarterly Full Stack Download Patch
- or Standalone Patchsets for every Component like Infinband, Cell Server, DB-Node and so on
So the decision has to be taken by the whole team of Application Manager and Oracle DBA’s and System Administrator
Now it is time to setup a table with the details for every component
|KVM / PDU|
|Infiniband – Switche||2.1.8-1||yes|
|Security Patches||CVE Patches||yes|
|Security Patches||CVE Patches||yes|
|RDBMS & OJVM||184.108.40.206.160119||no||Java component|
|open issues||crontab SR 3-12121350751|
|custom rpm packages (TSM, X11, xterm, …)|
Next steps after finishing the planing of the patching process and downloading the software you can start with pre task also called
GRID & RDBMS - opatch (oplan) is the same as on every other Oracle Database DB Node (PSU Oct 2015) – patchmgr -dbnode dbnode_group -dbnode_precheck -dbnode_loc ./p22750145_121230_Linux-x86-64.zip -dbnode_version 220.127.116.11.0.160207.3 Storage Grid – patchmgr -cells cell_group -patch_check_prereq (–rolling) Network – patchmgr -ibswitches ib_group -upgrade -ibswitch_precheck
If all Pre-Checks finished with success you can prepare for the „final“ patching task.
Keep in mind that if you plan to do a rolling patching on the Cell Server that Oracle
recommend that the diskgroups should be configured as High Redundancy. If during the
patching one component will the damaged the data are lost.
Another solution could be that you have a second Exadata Machine which act’s as a DR System for
example via Data Guard. So you are able to do an Failover in case of an error.
„Final task Patching“
GRID & RDBMS - opatch (oplan) is the same as on every other Oracle Database DB Node (PSU Oct 2015) - OL5.x -> OL6.x Upgrades means that you have to deinstall all custom rpm packages for example TSM or other Backup Software - You need a lot of time may be also involve other groups to do these software deinstallation and installation after the patching - patchmgr –dbnode dbnode_group -dbnode_upgrade -dbnode_loc ./p21825906_121220_Linux-x86-64.zip -dbnode_version 18.104.22.168.0.150917 –rolling Storage Grid - Set ASM ‘disk_repair_time‘=‘24h‘ for example to 24 hours default is 3,6 hours – patchmgr -cells cell_group -patch_check_prereq (–rolling) Network – export EXADATA_IMAGE_IBSWITCH_ROLLBACK_VERSION=2.1.3-4 - patchmgr -ibswitches ib_group -upgrade
When you finish these tasks without an error you can go on with the installation and update of the
Grid & RDBMS Software.
I don’t describe this job here it is a normal DBA task …