Exadata Storage Software has become a powerfull extension of the Oracle Database, not only leveraging performance but also offloading tasks from the database server, off to the storage server.
The span of this relationship is more visible when you have to patch the cells because of something happening at the database level. And since the Database Machine (DBM) works in grid, you’ll have three layers to patch: exadata cells, grid infrastructure and database. Let’s call them cell, grid and db.
To help you out in this task you have to make a favourite out of MOS Note 888828.1 that tells you exactly what patch Bundle you have to apply in each layer. The good thing is that cells work with a large set of versions at the grid and db level, but these last two have a more dependable patch tracking. Again, reading the referred note you ‘ll find what those combinations are.
So you have to be aware of the several tracks:
Exadata V1 – Has a track on it’s own, although you can install V2 software on it.
Exadata V2/X2-2 - These two share the same track. The oldest one beeing 11.2.1.x.x and the latest one beeing 11.2.2.x.x. When V2 was released it came out with 184.108.40.206.1, and when X2-2 was release it came out with 220.127.116.11.1.
This one is exclusive of the V2/X2-2 DBMs simply because they came with 11gR2 which created this aggregated layer of software that includes clusterware and ASM software, called Grid Infrastructure. In Exadata V2 onwards development decided that this layer would have a Bundle Patch (BP) on it’s own, and so you’ll have a special BP for Grid. This BP might need that you’ll have a minimum BP at the Database level, hence you have to check out note 888828.1 to see have is the latest combination, and the older ones, where one might be the fit for you.
This is the normal db patching, with the advantages of having a Bundle Patch that agregates: one-offs, PSUs and CPUs. All specific to the DBM platform. This is*not* a Patchset! Patchsets are a superset of BPs. So:
Exadata V2/X2-2 has two tracks:
18.104.22.168 (No Patchset) + Bundle Patch (the latest one is BP8)
22.214.171.124 (Patchset 1) + Bundle Patch (the latest one is BP2)
Putting it all together
Storage Nodes: here you can have the Exadata Cell Patch version you want. So there is no need to worry, just try to keep it to the latest since you can do it online.
At the database nodes: Patchset + Grid + Database Tracks have bundle combinations. This is “business-as-usual” patching that can be done in rolling fashion to avoid downtime. Some combinations require a specific version at the cell level so that’s why you should worry about having cells patched to the latest version.
ACME,co bought a Database Machine that came with 126.96.36.199.1 Exadata version at the cells and 188.8.131.52 at the database level without any bundle patching. Throughout 12 months this company only applied one-off patches for specific bugs but have never applied any Bundle Patch at the grid or db level, neither at the cell level.
This company chooses to have downtime and patch the whole infrastructure, so here’s the plan:
1st – Patch cells from a database node (so you can do them in parallel) to latest cell version. In this case going from 184.108.40.206.1 to 220.127.116.11.0 directly. Although it seems a great leap, it is possible.
2nd – From 18.104.22.168.x onwards the cell patches have a step that needs to be run at the db nodes
3rd – Patch db level to BP6
4th – Patch grid level to BP4
5th – Patch both db+grid to 22.214.171.124 (Patchset 1 – PS1)
6th – Patch db level to PS1-BP2
It seems complex but it works, it patches firmware, OS level, storage level, database level, EVERYTHING is patched in a certified way whereas if you had to do it with several teams and several manufacturers you would take months to plan, huge risk margin, and an enormous manpower effort to cary this on non-working hours. More expensive.
I hate to sound like a broken record, but Exadata is truely a game changer not only at the business and tech level, but also at the operational level.