Skip navigation.

Pakistan's First Oracle Blog

Syndicate content
I Love What I do i.e. Oracle DBA: Blog By Fahd Mirza Chughtai
Updated: 5 hours 23 min ago

Opatchauto Session failed: Parameter validation failed

Wed, 2016-02-10 20:12
While applying PSU on Grid Home in 12c, due to the patch conflict, you might have to rollback few patches before you could apply the PSU.

After rolling back the patches from grid home, when you try to run the opatch analyze command again, you might encounter following error:





[root ~]# $Grid_Home/OPatch/opatchauto apply /stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rsp
OPatch Automation Tool
Copyright (c)2014, Oracle Corporation. All rights reserved.OPatchauto Version : 12.1.0.1.10OUI Version        : 12.1.0.2.0Running from       : $Grid_Home
opatchauto log file: $Grid_Home/cfgtoollogs/opatchauto/22191349/opatch_gianalyze.logNOTE: opatchauto is running in ANALYZE mode. There will be no change to your system.OCM RSP file has been ignored in analyze mode. 
Clusterware is either not running or not configured. You have the following 2 options:1. Configure and start the Clusterware on this node and re-run the tool2. Run the tool with '-oh ' to first patch the Grid Home, then invoke tool with '-database ' or '-oh ' to patch the RAC homeParameter Validation: FAILED
Opatchauto Session failed: Parameter validation failedException in thread "main" java.lang.RuntimeException: java.io.IOException: Stream closed                at oracle.opatchauto.gi.GILogger.writeWithoutTimeStamp(GILogger.java:432)                at oracle.opatchauto.gi.GILogger.printStackTrace(GILogger.java:447)                at oracle.opatchauto.gi.OPatchauto.main(OPatchauto.java:97)Caused by: java.io.IOException: Stream closed                at java.io.BufferedWriter.ensureOpen(BufferedWriter.java:98)                at java.io.BufferedWriter.write(BufferedWriter.java:203)                at java.io.Writer.write(Writer.java:140)                at oracle.opatchauto.gi.GILogger.writeWithoutTimeStamp(GILogger.java:426)                ... 2 more
opatchauto failed with error code 1.
Then if you try to start the has services, you get following error:
 [root ~]# $Grid_Home/bin/crsctl start hasCRS-6706: Oracle Clusterware Release patch level ('3749979535') does not match Software patch level ('2278979115'). Oracle Clusterware cannot be started.CRS-4000: Command Start failed, or completed with errors.
SOLUTION:
So in order to resolve this, you need to issue following command as root user:$ORA_GI_HOME/crs/install/roothas.pl –postpatch
It will start the has services too.
Then again run the analyze command as given above and it will work. 



Categories: DBA Blogs

Step by Step Jan 2016 PSU Patch Apply on 12c Grid and RDBMS Homes in Linux

Tue, 2016-02-09 20:05

Following step by step action plan is for single instance database stored on ASM in 12.1.0.2 on Linux (OEL 6 64 bit in this case.)






Step Description ETA 1 Update the OPATCH utility:
For Database home:
$ unzip p6880880_121010_LINUX.zip -d /u01/app/oracle/product/12.1.0/db_1$ /u01/app/oracle/product/12.1.0/db_1/OPatch/opatch version
For Grid home:
$ unzip p6880880_121010_LINUX.zip -d /u01/app/oracle/12.1.0.2/grid$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch version 15 min 2 Create ocm.rsp file:
Note: Press Enter/Return key and don't provide any input and say Yes.
$ export ORACLE_HOME=/u01/app/oracle/12.1.0.2/grid$ $ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output /stage/ocm.rsp 5 min 3 Validation of Oracle Inventory
Before beginning patch application, check the consistency of inventory information for GI home and each database home to be patched. Run the following command as respective Oracle home owner to check the consistency.
For database home:
$ /u01/app/oracle/product/12.1.0/db_1/OPatch/opatch lsinventory -detail -oh /u01/app/oracle/product/12.1.0/db_1
For Grid home:
$ /u01/app/oracle/12.1.0.2/grid/OPatch/opatch lsinventory -detail -oh /u01/app/oracle/12.1.0.2/grid
If this command succeeds, it lists the Oracle components that are installed in the home. Save the output so you have the status prior to the patch apply. 5 min 4 Stage the Patch:
$ mkdir /stage/PSUpatch$ cp /stage/p22191349_121020_Linux-x86-64.zip /stage/PSUpatch
Check that the directory is empty.$ cd /stage/PSUpatch$ ls
Unzip the patch as grid home owner.
$ unzip p22191349_121020_.zip 5 min 5 One-off Patch Conflict Detection and Resolution:
Run it with root user:
/u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply /stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rsp
It will ask to rollback identical patches like this:
Analyzing patch(es) on "/u01/app/oracle/12.1.0.2/grid" ...Patch "/stage/PSUpatch/22191349/21436941" is already installed on "/u01/app/oracle/12.1.0.2/grid". Please rollback the existing identical patch first.Patch "/stage/PSUpatch/22191349/21948341" is already installed on "/u01/app/oracle/12.1.0.2/grid". Please rollback the existing identical patch first.Patch "/stage/PSUpatch/22191349/21948344" is already installed on "/u01/app/oracle/12.1.0.2/grid". Please rollback the existing identical patch first.Patch "/stage/PSUpatch/22191349/21948354" is already installed on "/u01/app/oracle/12.1.0.2/grid". Please rollback the existing identical patch first.
So first rollback above 4 patches by going to their directory and issuing with grid owner from grid home:
opatch rollback -id 21948354 -local -oh /u01/app/oracle/12.1.0.2/grid (Repeat for all 4 patches)
Note: In some cases, weirdly, I had to shutdown the has services with root user before patch rollback by using:
/u01/app/oracle/12.1.0.2/grid/bin/crsctl stop has -f
After this again run:
/u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply /stage/PSUpatch/22191349 -analyze -ocmrf /stage/ocm.rsp
If analyze command fail then use this with root user:
$ORA_GI_HOME/crs/install/roothas.pl –postpatch
It will start the has services too.
Then again run the analyze command as given above:
It will show something like:
Analyzing patch(es) on "/u01/app/oracle/12.1.0.2/grid" ...Patch "/stage/PSUpatch/22191349/21436941" successfully analyzed on "/u01/app/oracle/12.1.0.2/grid" for apply.Patch "/stage/PSUpatch/22191349/21948341" successfully analyzed on "/u01/app/oracle/12.1.0.2/grid" for apply.Patch "/stage/PSUpatch/22191349/21948344" successfully analyzed on "/u01/app/oracle/12.1.0.2/grid" for apply.Patch "/stage/PSUpatch/22191349/21948354" successfully analyzed on "/u01/app/oracle/12.1.0.2/grid" for apply.
Now you are good to apply the patch. Proceed to next step.



10 min 6 Apply the Patch: (Note: This should apply patch in both GI and RDBMS Home but its unreliable in that sense so after this completes, we need to check opatch lsinventory to make sure that it also applied patches in RDBMS Home)
As root user, execute the following command:
# /u01/app/oracle/12.1.0.2/grid/OPatch/opatchauto apply /stage/PSUpatch/22191349 -ocmrf /stage/ocm.rsp
In case if it doesn’t apply in RDBMS Home, then run:
/u01/app/oracle/product/12.1.0/db_1/OPatch/opatchauto apply /stage/PSUpatch/22191349 -oh /u01/app/oracle/product/12.1.0/db_1 -ocmrf /stage/ocm.rsp
Make sure the above applies both OCW and PSU patches. You can verify that from opatch lsinventory. If only OCW patch is present in output and no PSU (which is likely the case), then issue following from Oracle home with oracle database owner after shutting down database:
/u01/app/oracle/product/12.1.0/db_1/OPatch/opatch apply -oh /u01/app/oracle/product/12.1.0/db_1 -local /stage/PSUpatch/22191349/21948354 60 min 7 Loading Modified SQL Files into the Database:
% sqlplus /nologSQL> Connect / as sysdbaSQL> startupSQL> quit% cd $ORACLE_HOME/OPatch% ./datapatch -verbose 60 min 8 Check for the list of patches applied to the database.
SQL> select action_time, patch_id, patch_uid, version, status, bundle_series, description from dba_registry_sqlpatch; 5 min
Categories: DBA Blogs