Patching Strategy for CRS and ASM homes
zsysdbaOct 17 2010 — edited Oct 21 2010I'm fairly new to RAC/ASM and haven't performed any patch set upgrades yet. Back in the simple days when I wanted to apply a patch set to a database, say from 10.2.0.4 to 10.2.0.5, I would create a brand new Oracle home ahead of time and apply the patch set to it. I'd name my homes like this:
/opt/oracle/product/10.2.0.4/db1
/opt/oracle/product/10.2.0.5/db1
During the maintenance window I would change /etc/oratab to point the database to the new 10.2.0.5 and complete the database upgrade scripts. The advantages of this strategy:
1 - Less risk installing software as nothing uses the new home yet. If something goes wrong in the install, no big deal. Research the problem and try again without being under the stress of a defined maintenance window.
2 - No need to backup old home for back-out purposes.
3 - Less time required for database to be down during actual patch window since Oracle Installer does not need to run.
Now with CRS and ASM, is there a way to pre-stage a new home for those, but not have them "active" to the node until later during the maintenance window?
For ASM, it seems like it would be possible to treat the same way as database and simply update ASM SID in /etc/oratab
+ASM1:/opt/oracle/product/10.2.0.5/asm1
but I'm not totally confident in that as I'm afraid the CRS home may already have references to the ASM home in the cluster registry.
For CRS, it seems like the home is pretty well hard-wired into the node startup scripts and installing a brand new CRS home will probably disrupt the running CRS home.
Any thoughts about this?