Oracle releases Critical Patch Update every quarter for a year. CPU or PSU patches are not mandatory but its highly recommended to mitigate security issues. We will be in safer side if our databases are applied with latest CPU. Also its either DBA's decision or management to choose which release to be applied.
This article contains the few best approaching towards cpu patch activity. Basically all services should be down in order to test the CPU patch on database. Getting downtime is not an easiest option in critical environment. Also if we get the conflicts we may have to raise SR and wait for engineer's feedback. At this case we need multiple downtimes.
To overcome this scenario i have been following this method which does not need any downtime :
Mainly You don't need to shut down any services since our activity is going to affect only the binaries where no services are running.
Lets understand what opatch does. Basically opatch performs or modifies any libraries or binaries only on oracle home. Thus we dont need any services to be running under the oracle home when we apply opatch.
Lets see how can we achieve this method without having any services :
1) Copy the entire oracle home binaries to different location and place them adjacent to any of your test instance.
Test instance : /u01/clone/DEV/product
Dummy oracle home : /u01/clone//DEV/product/CPU_11204
2) Name it as you like. Usually if i am replicating DEV oracle home, i would name it DEVCPU
3) Create a dummy env file with new oracle home and new oracle sid
bash-3.2$ cat CPU_DEV.env
export ORACLE_HOME=/***/******/DEV/product/CPU_11204
export ORACLE_SID=DEVCPU
export PATH=$PATH:/***/******/DEV/product/CPU_11204/OPatch
4) Register the newly create oracle home to the inventory. Usually i hoot the duplicate oracle home to central inventory.
** source the dummy oracle home env file
bash-3.2$ cd $ORACLE_HOME/oui/bin
bash-3.2$ ./runInstaller -silent -attachHome -invPtrLoc /var/opt/oracle/oraInst.loc ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME=ORAHOME11Gr24CPU
Please read how to attach db oracle home to global inventory for detail steps.
5) Run opatch lsinventory and see you are able to see the global inventory and present patches in oracle home. You can verify at the values below
Oracle Home : /d01/oraclone/UAT/product/11204
Central Inventory : /u01/oracle/PROD/oraInventory
from : /d01/oraclone/UAT/product/11204/oraInst.loc
Please make sure the below values reflect the dummy oracle home and global inventory properly.
6) Test the CPU patch on duplicate oracle home.
7) If you are getting any conflicts, we can directly apply the patch.
8)If there are conflicts we need rollback the conflicts and then we need to apply the cpu patch. Finally we need to apply overlay patches (reverted patches)
** Its highly recommended to open service request if there are conflicts. Mainly SR engineer can help you with the overlay patches and the exact release which should be applied.
Steps are in detail :
step 1 : Rollback all the conflicts
step 2 : apply cpu patch
step 3 : Re-apply the overlay patches (rollbacked patches at step 1)
Once you are confident on the action plan you can get the down time and move the patches to instance by instance.
Hope this article helps!
Thanks!
~Sikky
Sikky,
ReplyDeleteThanks a ton for sharing.I will try this.
Can we do the same process for grid home also?pls advice
Thanks,