“Dumping current patch information” in Alert Log 12c can lead to a misinterpretation

Oracle Database 12.1 shows information on applied patches in the alert log during instance startup.

A question come up: The msg info in alert.log (below) is about patch applied on OH only or this information is related to patch applied on Database?

alert.log
...
2016-09-01 18:07:52.476000 -03:00
===========================================================
Dumping current patch information
===========================================================
Patch Id: 23144544
Patch Description: DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
Patch Apply Time: 2016-08-31 17:44:09 GMT-03:00
...

To get the answer I installed a OH 12.1 without create a database and apply the DATABASE BUNDLE PATCH: 12.1.0.2.160719.

I created a CDB database  with DBCA using template General purpose or transaction processing.

During a database creation  was looking at alert log and I noticed two things.

First the alert log show:

===========================================================
Dumping current patch information
===========================================================
No patches have been applied
===========================================================

Then at end of database creation  alert log show:

...
2016-09-01 18:07:52.476000 -03:00
===========================================================
Dumping current patch information
===========================================================
Patch Id: 23144544
Patch Description: DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
Patch Apply Time: 2016-08-31 17:44:09 GMT-03:00
...

The patch has been applied on my database during database creation?

The anwser is NO.
To my surprise, the “Dumping current patch information” is about Patches applied on OH only.

Why  “No Patches” the after some time “Show Patches”? 

The patch information is populated by calling DBMS_QOPATCH. It is populated if the database was started in a open mode, as it’s not possible to execute any package with database not opened in read-write.
At first moment database was started in a non-open mode , then NO PATCHES, when database was started in OPEN mode then alertlog was pouplated with the info.

Why this can lead a misinterpretation? 

DBMS_QOPATCH was introduced in 12c to query about Patch information  applied on database, but the info on alert.log is not about patch applied on database, the info is about patch applied on OH only, it can lead us to think wich database have listed patch on alertlog applied.

(I think this is some bug or something else, because it makes no sense to me)

What is the safe mode to check if database have a patch applied?

 

conn as sysdba

SQL> set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

PL/SQL procedure successfully completed.

No outuput then No Patch applied.

After create database I checked if patch was applied and none patch was applied, but the “Dumping current patch information”  show all applied patch in the alertlog at startup of instance.

 

How to apply a BP or PSU on Database 12c?

By executing datapatch utility.

./datapatch -h
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 19:35:49 2016
Copyright (c) 2016, Oracle. All rights reserved.

sqlpatch usage:
All arguments are optional, if there are no arguments sqlpatch
will automatically determine which SQL scripts need to be run in
order to complete the installation of any SQL patches.

Optional arguments:
-db <db name>
 Use the specified database rather than $ORACLE_SID
-bundle_series <bundle_series>
 Specify if the patch is a bundle patch
 Should also be accompanied by -force option
 if -bundle_series option is specified,only 1 patch will
 be considered by the -force command
-apply <patch1,patch2,...,patchn>
 Only consider the specified patch list for apply operations
-rollback <patch1,patch2,...,patchn>
 Only consider the specified patch list for rollback operations
-upgrade_mode_only
 Only consider patches that require upgrade mode
-force
 Run the apply and/or rollback scripts even if not necessary
 per the SQL registry
-pdbs <pdb1,pdb2,...,pdbn>
 Only consider the specified list of PDBs for patching. All
 other PDBs will not be patched
-prereq
 Run prerequisite checks only, do not actually run any scripts
-oh <oracle_home value>
 Use the specified directory to check for installed patches
-verbose
 Output additional information used for debugging
-help
 Output usage information and exit
-version
 Output build information and exit

Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
(Doc ID 1585822.1)

Let’s  apply the patch.

cd $ORACLE_HOME/OPatch
./datapatch -verbose

Suprise: When execute ./datapatch -verbose it has no warning or confirmation, the datapatch automatically  will apply patch in  all CDBs and in all opened PDBs of current OH environment.

The same concern that we have about “dd” command, we must have about datapatch command. Hope Oracle fix it.

Output:

./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 18:28:47 2016
Copyright (c) 2016, Oracle. All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/
sqlpatch_23003606_2016_09_01_18_28_47/sqlpath_invocation.log

Connecting to database...OK
Note: Datapatch will only apply or rollback SQL fixes for PDBs
 that are in an open state, no patches will be applied to closed PDBs.
 Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
 (Doc ID 1585822.1)
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Bundle series DBBP:
 ID 160719 in the binary registry and not installed in any PDB

Adding patches to installation queue and performing prereq checks...
Installation queue:
 For the following PDBs: CDB$ROOT PDB$SEED
 Nothing to roll back
 The following patches will be applied:
 23144544 (DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544))

Installing patches...
Patch installation complete. Total patches installed: 2

Validating logfiles...
Patch 23144544 apply (pdb CDB$ROOT): SUCCESS
 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_
PRDCDB_CDBROOT_2016Sep01_18_29_26.log (no errors)
Patch 23144544 apply (pdb PDB$SEED): SUCCESS
 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_
PRDCDB_PDBSEED_2016Sep01_18_32_36.log (no errors)
SQL Patching tool complete on Thu Sep 1 18:34:54 2016

datapatch always validate if a BP or PSU already was applied  as show below:

./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 18:35:21 2016
Copyright (c) 2016, Oracle. All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/
sqlpatch_23593462_2016_09_01_18_35_21/sqlpatch_invocation.log

Connecting to database...OK
Note: Datapatch will only apply or rollback SQL fixes for PDBs
 that are in an open state, no patches will be applied to closed PDBs.
 Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
 (Doc ID 1585822.1)
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Bundle series DBBP:
 ID 160719 in the binary registry and ID 160719 in PDB CDB$ROOT, 
 ID 160719 in PDB PDB$SEED

Adding patches to installation queue and performing prereq checks...
Installation queue:
 For the following PDBs: CDB$ROOT PDB$SEED
 Nothing to roll back
 Nothing to apply

SQL Patching tool complete on Thu Sep 1 18:35:53 2016

 

Checking what patches have been applied (or rolled back) on database

SQL> set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 23144544
 Action : APPLY
 Action Time : 01-SEP-2016 18:34:46
 Description : DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
 Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_PRDCDB_CDB
ROOT_2016Sep01_18_29_26.log
 Status : SUCCESS

PL/SQL procedure successfully completed.

 

Some notes:

  • Patch Information in Alert Log is about OH only
  • Creating a Database a CDB or Non-CDB database using a default Template it does not apply any Patch, you must apply patch manually after database creation.
  • datapatch utility is dangerous because has no warning or confirmation when executed.

 


What Patch to Apply? PSU ? GI PSU ? Proactive Bundle Patch?

For those who unfamiliar with Oracle Patch is little confusing what patch to apply when get  a table with different patch in the same version.

patch

I will try clarify some doubts.

Note: You must provide a valid My Oracle Support login name in order to access below Links.

Patch version numbering changed

In November 2015 the version numbering for new Bundle Patches, Patch Set Updates and Security Patch Updates for Oracle Database changed the format from  5th digit of the bundle version with a release date in the form “YYMMDD” where:

  • YY is the last 2 digits of the year
  • MM is the numeric month (2 digits)
  • DD is the numeric day of the month (2 digits)

More detail can be found here: Oracle Database, Enterprise Manager and Middleware – Change to Patch Numbering from Nov 2015 onwards (Doc ID 2061926.1)

 

Changes on Database Security Patching from 12.1.0.1 onwards

Starting with Oracle Database version 12.1.0.1 , Oracle will only provide Patch Set Update (PSU) patches to meet the Critical Patch Update (CPU) program requirements for security patching. SPU (Security Patch Update) patches will no longer be available. Oracle has moved to this simplified model due to the popularity of the PSU patches. PSUs are Oracle’s preferred proactive patching vehicle since their inception in 2009.

Database Security Patching from 12.1.0.1 onwards (Doc ID 1581950.1)

 

Where to find last Patches for Database?

Use the Patch Assistant: Assistant: Download Reference for Oracle Database PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)

 

What Patch to apply PSU, GI PSU,Proactive Bundle Patch, Bundle Patch (Windows 32bit & 64bit)?

When using the Patchset Assistant the assistant show below table:
In this case I search for last patch for 12.1.0.2.

PSU_Bundle_Patch

Understanding the Patch Nomenclature :
New Patch Nomenclature for Oracle Products (Doc ID 1430923.1)

Note: As of April 2016, the Database Patch for Engineered Systems and Database In-Memory has been renamed from “Bundle Patch (BP) ” to “Database Proactive Bundle Patch”.

Note: Windows Platform must use “Bundle Patch (Windows 32bit & 6bit)”.

Database patch content:

  • SPU contains only the CPU program security fixes
  • PSU contains the CPU program security fixes and additional high-impact/low-risk critical bug fixes
  • Proactive Bundle Patch (PBP) includes all PSU fixes along with fixes targeted at the specific Bundle Patch environment.

They are cumulatives,so  if you have a OH (12.1.0.2) in base release (i.e no fix)  and apply the last PSU or PBP it will fix all bugs from base release until current version of patch.

Where to apply each Patch?

  • PSU –  Can be applied on Database Servers, Client-Only and  Instant Client.
  • GI PSU – Can be applied on GI Home (Oracle Restart or Oracle Clusterware) in conjunction with RAC, RACOne,  Single Instance home, Client-Only and  Instant Client.
  • Proactive Bundle Patch – Can be applied on GI Home in conjunction with RAC, RACOne, or Single Instance home, Client-Only and  Instant Client.

 

An installation can only use one of the SPU, PSU or Proactive Bundle Patch patching methods.

 

How to choose between them?

The “Database Proactive Bundle Patch” requires a bit more testing than a Patch Set Update (PSU) as it delivers a larger set of fixes.

If you are installing a new fresh installation you should to apply Database Proactive Bundle Patch.

PSU is addressed to environments sensitive to changes, because it required less testing.

I have Applied “Database PSU” how to move to “Database Proactive Bundle Patch”? 

Moving from “Database PSU” to “Database Proactive Bundle Patch”

  • Back up your current setup
  • Fully rollback / deinstall “Database PSU”
    • If using OJVM PSU that is likely to require OJVM PSU to be rolled out too
  • Apply / install the latest “Database Proactive Bundle Patch”
  • Apply any interim patches also rolled out above (including OJVM PSU if that was installed)

Note from Oracle: It is not generally advisable to switch from “Database PSU” to “Database SPU” method.

The below note can clarify any doubt on this post.
Oracle Database – Overview of Database Patch Delivery Methods (Doc ID 1962125.1)

 

OPLAN Support

GI PSU and Proactive Bundle Patch are supported by OPlan.

OPlan is a utility that facilitates the patch installation process by providing you with step-by-step patching instructions specific to your environment.
In contrast to the traditional patching operation, applying a patch based on the README requires you to understand the target configuration and manually identify the patching commands relevant to your environment. OPlan eliminates the requirement of identifying the patching commands by automatically collecting the configuration information for the target, then generating instructions specific to the target configuration.

Oracle Software Patching with OPLAN (Doc ID 1306814.1)

Useful Notes:

Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1)

Frequently Asked Questions (FAQ): Patching Oracle Database Server (Doc ID 1446582.1)

12.1.0.2 Database Proactive Bundle Patches / Bundle Patches for Engineered Systems and DB In-Memory – List of Fixes in each Bundle (Doc ID 1937782.1)


Modifying Oracle Clusterware/Restart Binaries

Oracle Database 11.2 introduced a new security features that is lock the GRID_HOME after installation if is required to modify the binaries  GRID_HOME will be necessary to unlock to allow make changes on GRID_HOME .

This procedure must be performed especially when we need to patch GRID_HOME.

Do not force modify Oracle Clusterware/Restart binaries with root  user. This can leave your installation inconsistent.

Let’s do tests:

Upgrading OPatch from  version 11.2.0.1.1 to version 11.2.0.1.5.
The task is quite simple, just rename the directory $GRID_HOME/OPatch to $GRID_HOME/OPatch_old and unpack  new OPatch on  GRID_HOME.
 
[oracle@grid_server1 ~]$ echo $PATH
... :/u01/app/11.2.0/grid/bin:/u01/app/11.2.0/grid/OPatch:/u01/app/11.2.0/grid/jdk/bin...
[oracle@grid_server1 ~]$ echo $ORACLE_HOME
/u01/app/11.2.0/grid
OPatch version
 
[oracle@grid_server1 ~]$ opatch version
Invoking OPatch 11.2.0.1.1

OPatch Version: 11.2.0.1.1
OPatch succeeded.

Perfoming Upgrade of OPatch

As earlier version of Oracle
Unpack patch 6880880

[oracle@grid_server1 patch]$ unzip p6880880_112000_Linux-x86-64.zip
Archive:  p6880880_112000_Linux-x86-64.zip
   creating: OPatch/
   creating: OPatch/crs/
  inflating: OPatch/crs/patch112.pl
  inflating: OPatch/crs/s_crsconfig_defs
  inflating: OPatch/crs/oracss.pm
   creating: OPatch/crs/log/
 extracting: OPatch/crs/log/dummy
  inflating: OPatch/crs/crsconfig_lib.pm
  inflating: OPatch/crs/installPatch.excl
  inflating: OPatch/crs/auto_patch.pl
  inflating: OPatch/crs/s_crsconfig_lib.pm
  inflating: OPatch/crs/crspatch.pm
  inflating: OPatch/crs/crsdelete.pm
   creating: OPatch/jlib/
  inflating: OPatch/jlib/opatch.jar
  inflating: OPatch/jlib/opatchutil.jar
  inflating: OPatch/jlib/opatchext.jar
  inflating: OPatch/jlib/opatchactions.jar
  inflating: OPatch/jlib/opatchfmw.jar
  inflating: OPatch/jlib/opatchprereq.jar
  inflating: OPatch/emdpatch.pl
  inflating: OPatch/opatch.pl
   creating: OPatch/docs/
  inflating: OPatch/docs/Prereq_Users_Guide.txt
  inflating: OPatch/docs/Users_Guide.txt
  inflating: OPatch/docs/FAQ
   creating: OPatch/opatchprereqs/
   creating: OPatch/opatchprereqs/oui/
  inflating: OPatch/opatchprereqs/oui/knowledgesrc.xml
  inflating: OPatch/opatchprereqs/prerequisite.properties
   creating: OPatch/opatchprereqs/opatch/
  inflating: OPatch/opatchprereqs/opatch/opatch_prereq.xml
  inflating: OPatch/opatchprereqs/opatch/rulemap.xml
  inflating: OPatch/opatchprereqs/opatch/runtime_prereq.xml
  inflating: OPatch/opatch.ini
   creating: OPatch/fmw/
  inflating: OPatch/fmw/application.py
  inflating: OPatch/fmw/main_driver.py
  inflating: OPatch/fmw/init_def.py
  inflating: OPatch/fmw/node_manager.py
  inflating: OPatch/fmw/start_stop.py
  inflating: OPatch/fmw/prereq.py
  inflating: OPatch/opatch
  inflating: OPatch/README.txt
   creating: OPatch/ocm/
  inflating: OPatch/ocm/ocm_platforms.txt
   creating: OPatch/ocm/lib/
  inflating: OPatch/ocm/lib/log4j-core.jar
  inflating: OPatch/ocm/lib/http_client.jar
  inflating: OPatch/ocm/lib/emocmclnt.jar
  inflating: OPatch/ocm/lib/regexp.jar
  inflating: OPatch/ocm/lib/osdt_jce.jar
  inflating: OPatch/ocm/lib/jsse.jar
  inflating: OPatch/ocm/lib/osdt_core3.jar
  inflating: OPatch/ocm/lib/xmlparserv2.jar
  inflating: OPatch/ocm/lib/jnet.jar
  inflating: OPatch/ocm/lib/emocmclnt-14.jar
  inflating: OPatch/ocm/lib/emocmcommon.jar
  inflating: OPatch/ocm/lib/jcert.jar
   creating: OPatch/ocm/bin/
  inflating: OPatch/ocm/bin/emocmrsp
 extracting: OPatch/ocm/ocm.zip
  inflating: OPatch/opatch.bat

And moving OPatch directory to $GRID_HOME

[oracle@grid_server1 patch]$ mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_old
mv: cannot move `/u01/app/11.2.0/grid/OPatch/' to `/u01/app/11.2.0/grid/OPatch_old': Permission denied
[oracle@grid_server1 patch]$ mv OPatch/ $GRID_HOME/OPatch
mv: cannot move `/home/oracle/patch/OPatch/' to `/u01/app/11.2.0/grid/OPatch': Permission denied

So, now we need to unlock GRID_HOME to make the necessary changes.

To unlock GRID_HOME we need execute rootcrs.pl (to a clusterware installation) or roothas.pl (to Grid Standalone/Restart Installation). This files are in $GRID_HOME/crs/install/.

IMPORTANT: Executing rootcrs.pl or roothas.pl with -unlock option the ohasd daemon will be shutdown by rootcrs.pl/roothas.pl. That means that all Oracle services/instances/apps will be shut down on this Node.

With awareness that the environment will be turned off. Let’s do the job.

As root privileges

[oracle@grid_server1 ]$ cd /u01/app/11.2.0/grid/crs/install
[oracle@grid_server1 ]$ sudo perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'grid_server1'
CRS-2673: Attempting to stop 'ora.crsd' on 'grid_server1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'grid_server1'
CRS-2673: Attempting to stop 'ora.oc4j' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.DG_CRS_VOTE.dg' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.db11g.db' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.cvu' on 'grid_server1'
CRS-2677: Stop of 'ora.cvu' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.grid_server1.vip' on 'grid_server1'
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'grid_server1'
CRS-2677: Stop of 'ora.scan1.vip' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.grid_server1.vip' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.db11g.db' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.DG_DATA.dg' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.DG_FRA.dg' on 'grid_server1'
CRS-2677: Stop of 'ora.registry.acfs' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.oc4j' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.DG_FRA.dg' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.DG_DATA.dg' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.DG_CRS_VOTE.dg' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'grid_server1'
CRS-2677: Stop of 'ora.asm' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'grid_server1'
CRS-2677: Stop of 'ora.ons' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'grid_server1'
CRS-2677: Stop of 'ora.net1.network' on 'grid_server1' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'grid_server1' has completed
CRS-2677: Stop of 'ora.crsd' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.crf' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.ctssd' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.evmd' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.asm' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'grid_server1'
CRS-2677: Stop of 'ora.crf' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.asm' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'grid_server1'
CRS-2677: Stop of 'ora.evmd' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'grid_server1'
CRS-2677: Stop of 'ora.cssd' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'grid_server1'
CRS-2673: Attempting to stop 'ora.diskmon' on 'grid_server1'
CRS-2677: Stop of 'ora.diskmon' on 'grid_server1' succeeded
CRS-2677: Stop of 'ora.gipcd' on 'grid_server1' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'grid_server1'
CRS-2677: Stop of 'ora.gpnpd' on 'grid_server1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'grid_server1' has completed
CRS-4133: Oracle High Availability Services has been stopped.
Successfully unlock /u01/app/11.2.0/grid

Now we can make necessary changes.

[oracle@grid_server1 patch]$ mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch_old
[oracle@grid_server1 patch]$ mv OPatch/ $GRID_HOME/OPatch
[oracle@grid_server1 patch]$  ls -ltr $ORACLE_HOME/ |grep OP*
drwxrwxr-x  8 oracle oinstall  4096 Mar 23 08:24 OPatch
drwxr-xr-x  8 oracle oinstall  4096 Jun 22 17:38 OPatch_old

After finish Upgrade of OPatch we need relock the GRID_HOME and restart the cluster on this node.

To relock the GRID_HOME we need use the rootcrs.pl/roothas.pl with flag -patch. (Not exists the flag -lock)

To see the full manpage for rootcrs.pl/roothas.pl, execute:
perldoc rootcrs.pl
perldoc roothas.pl

[oracle@grid_server1 ]$ cd /u01/app/11.2.0/grid/crs/install
[oracle@grid_server1 ]$ sudo perl rootcrs.pl -patch -crshome /u01/app/11.2.0/grid
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
Undefined subroutine &main::read_file called at /u01/app/11.2.0/grid/crs/install/crspatch.pm line 86.

If you get error above, congratulation you have a Oracle bug.
This bug can be easily solved using MOS DOC.ID:
roothas.pl -patch or rootcrs.pl -patch Fails with ‘Undefined subroutine’ [ID 1268390.1]

Let’s solve with this workaround.

  Take a backup of the file /crs/install/crsconfig_lib.pm

# cd /crs/install
# cp crsconfig_lib.pm crsconfig_lib.pm.bak

Make the following change in that file crsconfig_lib.pm

From
     my @exp_func = qw(check_CRSConfig validate_olrconfig validateOCR
To
     my @exp_func = qw(check_CRSConfig validate_olrconfig validateOCR read_file

Execute relock:

[oracle@grid_server1 ]$ cd /u01/app/11.2.0/grid/crs/install
[oracle@grid_server1 ]$ sudo perl rootcrs.pl -patch -crshome /u01/app/11.2.0/grid
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
ACFS-9200: Supported
CRS-4123: Oracle High Availability Services has been started.

Testing if all services are online and GRID_HOME is LOCKED.

[oracle@grid_server1 ~]$ crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DG_CRS_VOTE.dg
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.DG_DATA.dg
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.DG_FRA.dg
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.LISTENER.lsnr
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.asm
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.gsd
               OFFLINE OFFLINE      grid_server1
               OFFLINE OFFLINE      grid_server2
ora.net1.network
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.ons
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
ora.registry.acfs
               ONLINE  ONLINE       grid_server1
               ONLINE  ONLINE       grid_server2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       grid_server1
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       grid_server2
ora.grid_server1.vip
      1        ONLINE  ONLINE       grid_server1
ora.cvu
      1        ONLINE  ONLINE       grid_server2
ora.db11g.db
      1        ONLINE  ONLINE       grid_server1                 Open
      2        ONLINE  ONLINE       grid_server2                  Open
ora.grid_server2.vip
      1        ONLINE  ONLINE       grid_server2
ora.oc4j
      1        ONLINE  ONLINE       grid_server1
ora.scan1.vip
      1        ONLINE  ONLINE       grid_server1
ora.scan2.vip
      1        ONLINE  ONLINE       grid_server2

 

[oracle@grid_server1 ~]$ mv /u01/app/11.2.0/grid/OPatch /u01/app/11.2.0/grid/OPatch_tst
mv: cannot move `/u01/app/11.2.0/grid/OPatch' to `/u01/app/11.2.0/grid/OPatch_tst': Permission denied

[oracle@grid_server1 ~]$ opatch version
Invoking OPatch 11.2.0.1.5

OPatch Version: 11.2.0.1.5
OPatch succeeded.

Enjoy

Reference:
Modifying Oracle Clusterware Binaries After Installation
http://download.oracle.com/docs/cd/E11882_01/install.112/e17210/postinst.htm#CWAIX311

Patch 11gR2 Grid Infrastructure Standalone Server [ID 1089476.1]
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ANNOUNCEMENT&id=1089476.1


Oracle Database 11g Release 2 (11.2.0.2) is available in the latest media pack

Oracle Database 11g Release 2 (11.2.0.2) is available in the latest media pack.

Patch Number10098816 Oracle Database Family: Patchset
11.2.0.2.0 PATCH SET FOR ORACLE DATABASE SERVER

..

Installation Type Zip File
Oracle Database (includes Oracle Database and Oracle RAC)

Note: you must download both zip files to install Oracle Database.

p10098816_112020_platform_1of7.zip

p10098816_112020_platform_2of7.zip

Oracle Grid Infrastructure (includes Oracle ASM, Oracle Clusterware, and Oracle Restart) p10098816_112020_platform_3of7.zip
Oracle Database Client p10098816_112020_platform_4of7.zip
Oracle Gateways p10098816_112020_platform_5of7.zip
Oracle Examples p10098816_112020_platform_6of7.zip
Deinstall p10098816_112020_platform_7of7.zip

Click here to download your Patch Set 11.2.0.2.0


Installing Oracle Database 11g Release 2 Patch Set 1

Oracle By Example

Installing Oracle Database 11g Release 2 Patch Set 1

Enjoy