“Dumping current patch information” in Alert Log 12c can lead to a misinterpretation
Posted: 01/09/2016 Filed under: Oracle, Oracle Installation, Patch Set | Tags: datapatch, Dumping current patch information, Levi Pereira, oracle Leave a commentOracle 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?
Posted: 23/08/2016 Filed under: 11g R2, 11g R2, 11g R2, 12c R1, 12c R1, 12c R1, Clusterware / Grid Infrastructure, Database, Grid Infrastructure Standalone, Oracle Installation, Patch Set Leave a commentFor those who unfamiliar with Oracle Patch is little confusing what patch to apply when get a table with different patch in the same version.
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.
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:
Frequently Asked Questions (FAQ): Patching Oracle Database Server (Doc ID 1446582.1)
Oracle Universal Installer (OUI) fails while extracting files…
Posted: 11/11/2011 Filed under: 10g R1, 10g R2, 11g R1, 11g R2, 9i, Database, Oracle Installation 1 CommentSeveral times I have faced problems like this. I know it’s a simple problem to solve, but I’ll leave this tip.
Recently installing Oracle 11.2.0.3 on an AIX environment I faced a problem during installation.
The error was: – Invalid distance code. What’s that????????????? Bug on 11.2.0.3? Maybe!!!
Neither at moon you can find the solution for this error.
So, I wasted no time trying debugging OUI, I realized that the error was raised during the extraction of binary installation, so I took a shortcut.
Cause:
In UNIX/Linux unzip utility extract files even if they are corrupted.
So, the installation files are corrupted and I did not heed it.
unzip -t p10404530_112030_AIX64-5L_1of7.zip |grep -v OK
Archive: p10404530_112030_AIX64-5L_1of7.zip
testing: database/stage/Components/oracle.nlsrtl.rsf/11.2.0.3.0/1/DataFiles/filegroup1.jar bad CRC 0e90be4a (should be d9efb175)
bad CRC 0e90be4a (should be d9efb175)
bad CRC 6c68df26 (should be 8a9ea9bb)
testing: database/stage/Components/oracle.sysman.oms.core/10.2.0.4.4/1/DataFiles/filegroup7.jar bad CRC 6c68df26 (should be 8a9ea9bb)
At least one error was detected in p10404530_112030_AIX64-5L_1of7.zip.
unzip -t p10404530_112030_AIX64-5L_2of7.zip |grep -v OK
Archive: p10404530_112030_AIX64-5L_2of7.zip
error: invalid compressed data to inflate
testing: database/stage/Components/oracle.rdbms.install.seeddb/11.2.0.3.0/1/DataFiles/Expanded/filegroup1/Seed_Database.dfb
error: invalid compressed data to inflate
At least one error was detected in p10404530_112030_AIX64-5L_2of7.zip.
Solution:
Always test your installation zip files, before extract it.
unzip -t p10404530_112030_AIX64-5L_1of7.zip |grep -v OK Archive: p10404530_112030_AIX64-5L_1of7.zip No errors detected in compressed data of p10404530_112030_AIX64-5L_1of7.zip. unzip -t p10404530_112030_AIX64-5L_2of7.zip |grep -v OK Archive: p10404530_112030_AIX64-5L_2of7.zip No errors detected in compressed data of p10404530_112030_AIX64-5L_2of7.zip.
I hope this helps.
Enjoy…
Modifying Oracle Clusterware/Restart Binaries
Posted: 01/07/2011 Filed under: 11g R2, BUG, Clusterware / Grid Infrastructure, Oracle, Oracle Installation, Oracle Restart, Patch Set 7 CommentsOracle 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/gridOPatch 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
Levi Pereira | Oracle Blog 