October 2014 GI OJVM Combo PSU - "opatch auto apply" does it not shut down DB instances?
( patch 19791428 / p19791428 )
Our process for patching Oracle 11.2.0.3 GI hasn't changed for many patch cycles. But I have some questions about the October 2014 "Combo" GI PSU process that includes OJVM. We'll test on lab instances first, but wanted to see if anyone has beaten us to applying this PSU and can share some insight.
Our environment:
Oracle 11.2.0.3.11 Grid Infrastructure (non-RAC; used only for ASM / Oracle Restart)
Multiple 11.2.0.3 database instances per single host (Redhat Linux x86-64)
We have always manually shut down EM agents then Changed Directory to the root level of the dir containing the unzipped PSU and run opatch auto--and run as root if the sysadmins grant us temp root privs on a given day. Then:
opatch auto /home/oracle/patches -ocmrf /u01/app/11.2.0/grid3/OPatch/ocm/bin/ocm.rsp
For Post-install, we shutdown, startup restrict, run catbundle.sql, then "alter system disable restricted session"
Fast forward to the October 2014 GI Combo PSU just released, README Section "2.4 Patch Installation".
Step 1: Bring down the database on all nodes using "svrctl stop database ...". Firstly, we never go that. Is this a RAC-only step? "opatch auto" always shuts down all necessary Oracle services for us, with the previously noted exception of the EM Agent. Do we skip this step for a GI but non-RAC configuration? Again, we only use GI for ASM.
Step 2: cd into a numbered patch directory (in this case, <patch home>/19791428). A little different than before but not puzzling.
Step 3: opatch auto apply -ocmrf <ocm response file full path>.
Any significance to the addition of "apply" here in the opatch auto syntax? Perhaps it's always been there, e.g. July 2014 patch cycle, and I've never noticed...
Step 4: cd to a subdirectory of numbered patch directory, e.g. to <patch home>/19791428/19282015
Step 5: Apply OJVM patch:
opatch apply -local
Must "opatch apply -local" also run as root?
Step 6: Repeat Step 2 to 5 on all nodes; since we're GI but non-RAC, so there are no other nodes.
Step 7: On last node, bring up dbs on all nodes via "svrctl start database". Believe we would skip because we're not RAC.
Skip to Section 2.5.2: Loading Modified SQL Files into the Database
1. Startup each instance then run @postinstall.sql - this is new. Also seems new to have to STARTUP each instance. During our last patch cycle "opatch auto" always brings up all Oracle services, including the instances. So before we run our catbundle.sql we typically shutdown, then startup restrict. Will "opatch" behave differently for us during this patch cycle, e.g. not restart all Oracle services when complete?
2. Run catbundle.sql for each instance; par for the course.
Thanks.
Dana