How to patch an exadata (part 6) - timing

6: Timing
Now that we know how to patch every component and the different options available to do so (rolling, non-rolling), which one is the best? How much time does it take? The answer is obviously " it depends" but I will try to bring few insights so you can have a bright answer when your manager inevitably asks you " How long will that patch be? I need to negotiate the window maintenance with the business... they aren't happy..." ;) Here is a summary of the length of the patch application in a Rolling fashion and in a Non-Rolling fashion (as well as the downtime for each method). Please note that I put in green what I recommend. Cells- Rolling : 1h30 x number of cells
- Rolling downtime : 0 minute
- Non-rolling : 2h (1h30 to patch a cell + 30 minutes to stop and start everything before and after the patch)
- Non-rolling downtime : 2h
- Rolling : 45 minutes per switch then 1h30 total
- Rolling downtime : 0 minute
- Non-rolling : not available
- Non-rolling downtime : not available
- Rolling : 1h per node
- Rolling downtime : It can be 0 minutes if you make a good use of the Oracle services (as described here for the Grid patching. You can apply the same concept for the database servers patching as well)
- Non-rolling : 1h
- Non-rolling downtime : 1h
- Rolling : 30 - 45 minutes per node
- Rolling downtime: Can be 0 minute if you make a good use of the Oracle services as described in this paragraph
- Non-rolling : 30 - 45 minutes
- Non-rolling downtime : 30 - 45 minutes for all the instances running on the node you patch
-
- Rebalance the services away from node 1
-
- Patch the node 1
-
- Verify that everything is well restarted on the node 1
-
- Move all the services to the node 1 (if it is possible that only one node can handle the whole activity - but usually we patch during a quiet period)
-
- Apply the patch in a non-rolling method (for the Grid it means launching the patch manually in parallel on the remaining nodes)
-
- Once the grid has been patched on all the nodes, restart all the services as they were before the patch
-
- Rolling: 20 - 30 minutes per node + ~ 20 minutes per database for the post installation steps
- Rolling downtime:- Can be 0 minute if you rebalance the services before patching a node (as described here for the Grid patching, you can apply the same concept for the database patching as well) + ~ 20 minutes per database for the post installation steps. Please note that if you have 30 databases sharing the same ORACLE_HOME, you won't be able to easily apply 30 post-install steps at the same time then the 30th database will suffer a bigger outage than the 1st one you restart on the patched ORACLE_HOME. This is why I strongly recommend the use of this quicker method. - An ~ 20 minutes downtime per database you can chose when using the quicker way !
- Non-rolling: 20 - 30 minutes
- Non-rolling downtime: 20 - 30 minutes for all the databases running on the patched Oracle home + ~ 20 minutes per database for the post installation steps. Note that if you have 30 databases sharing the same ORACLE_HOME, you won't be able to apply 30 post-install steps at the same time then the 30th database will suffer a bigger outage than the 1st one you restart on the patched ORACLE_HOME.