April PSU for 11.2 also follows the same pattern as the January PSU when it comes to manual steps for applying the patch. The document ID listed for manual steps (1494646.1) is same one listed for January PSU and it is not updated with the information for the April PSU. This leaves the question of identifying which is the "GI_Components_number" and which is the "DB_PSU_number". There's no information in the GI PSU read me file to help with this fact. However there are indirect ways of identifying the GI component number and the DB PSU number.
1. When the April GI PSU (16083653 - 11.2.0.6) is extracted it will have two patch directories (16056266 and 16315641). One will have the same ID as the (unbundled) April DB PSU (16056266 - 11.2.0.6). Once this is identified then the other one is the GI component number (in this case it is 16315641). For this approach before manually applying the GI PSU one must also refer the unbundled DB PSU to get the DB PSU number (even though this is not needed in GI environment as it's bundled with the GI PSU patch).
2. Another method is to useopatch query -get_base_bug to identify the GI PSU component. This command only works with the GI component part of the patch and will return an error with the DB portion of the patch. For example running against the DB portion of the patch
Related Post
January 2013 PSU (11.2.0.3) Manual Steps for Apply/Rollback Patch vs OPatch Auto
1. When the April GI PSU (16083653 - 11.2.0.6) is extracted it will have two patch directories (16056266 and 16315641). One will have the same ID as the (unbundled) April DB PSU (16056266 - 11.2.0.6). Once this is identified then the other one is the GI component number (in this case it is 16315641). For this approach before manually applying the GI PSU one must also refer the unbundled DB PSU to get the DB PSU number (even though this is not needed in GI environment as it's bundled with the GI PSU patch).
2. Another method is to useopatch query -get_base_bug to identify the GI PSU component. This command only works with the GI component part of the patch and will return an error with the DB portion of the patch. For example running against the DB portion of the patch
$ORACLE_HOME/OPatch/opatch query -get_base_bug /usr/local/patches/16056266/However running against the GI component part of the patch will give the GI component number.
Oracle Interim Patch Installer version 11.2.0.3.4
...
Failed to load the patch object. Possible causes are:
The specified path is not an interim Patch shiphome
Meta-data files are missing from the patch area
Patch location = /usr/local/patches/16056266/
Details = Input metadata files are missing.
Patch Location "/usr/local/patches/16056266/" doesn't point to a valid patch area.
OPatch failed with error code 75
$ORACLE_HOME/OPatch/opatch query -get_base_bug /usr/local/patches/16315641Once the GI component is known the remaining directory's number is the DB PSU number.
Oracle Interim Patch Installer version 11.2.0.3.4
...
--------------------------------------------------------------------------------
List of bugs to be fixed:
16315641: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.6 (GI COMPONENTS)
15876003: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.5 (GI COMPONENTS)
14275572: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.4 (INCLUDES DB PSU 11.2.0.3.4)
13919095: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.3 (INCLUDES DB PSU 11.2.0.3.3)
13696251: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.2 (INCLUDES DB PSU 11.2.0.3.2)
13348650: GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.1 (INCLUDES DB PSU 11.2.0.3.1)
12659561: INSTANCE DOES NOT REGISTER SERVICES WHEN SCAN FAILOVERED
14305980: IMPROVE CRSD RESOURCE AUTO START PROCESSING
14277586: INCORRECT SHUTDOWN REASON CODE IN FAN EVENTS - BREAKING CLIENTS
...
...
Related Post
January 2013 PSU (11.2.0.3) Manual Steps for Apply/Rollback Patch vs OPatch Auto