1.Download the OPatch utility to a temporary directory.

2.For each Oracle RAC database home and the GI home that arebeing patched, run the
following commands as the home owner toextract the OPatch utility.
$ unzip <OPATCH-ZIP> -d <ORACLE_HOME>
$ <ORACLE_HOME>/OPatch/opatch version

The version output of the previous command should be 12.2.0.1.12 or later.

For information about OPatch documentation, including any knownissues, see My

Oracle Support Document 293369.1 OPatchdocumentation list.

1.2.1.2 Validationof Oracle Inventory

Before beginning patch application, check the consistency ofinventory information

for GI home and each database home to bepatched. Run the following command as
respective Oracle home ownerto check the consistency.
$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>

If this command succeeds, it lists the Oracle components that areinstalled in the
home. Save the output so you have the statusprior to the patch apply.

If this command fails, contact Oracle Support Services forassistance.

1.2.1.3 Downloadand Unzip the Patch

To apply the patch, it must be accessible from all nodes in theOracle cluster.
Download the patch and unzip it to a sharedlocation, this is called the
<UNZIPPED_PATCH_LOCATION>.This directory must be empty and not be
/tmp.Additionally, the directory should have read permission for the ORA_INSTALL
group.
$ cd <UNZIPPED_PATCH_LOCATION>

Check that the directory is empty.

$ ls

Unzip the patch as grid home owner.

$ unzip p27967747_121020_<platform>.zip

1.2.2 One-offPatch Conflict Detection and Resolution

The fastest and easiest way to determine whether you have one-offpatches in the
Oracle home that conflict with the patch, and toget the necessary conflict
resolution patches, is to use the Patch Recommendations and PatchPlans features on
the Patches &Updates tab in My Oracle Support. These features work inconjunction
with the My Oracle Support Configuration Manager.Recorded training sessions on
these features can be found inDocument 603505.1.

However, if you are not using My Oracle Support Patch Plans, theMy Oracle Support
Conflict Checker tool enables you to upload anOPatch inventory and check the
patches that you want to apply toyour environment for conflicts.

If no conflicts are found, you can download the patches. Ifconflicts are found, the
tool finds an existing resolution todownload. If no resolution is found, it will
automatically requesta resolution, which you can monitor in the Plansand Patch
Requests region of the Patches& Updates tab.

For more information, see Knowledge Document 1091294.1, How to usethe My Oracle
Support Conflict Checker Tool.

Or, manually determine whether any currently installed one-offpatches conflict with
the PSU patch as follows:

�In the unzipped directory as described in Downloadand Unzip the Patch.

�The following commands check for conflicts in both the 12.1GI home and the 12.1 DB
homes.

�In case you are applying the patch, run this command:

Note:

1.7 DocumentationAccessibility

For information about Oracle's commitment to accessibility, visitthe Oracle

Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access toelectronic support
through My Oracle Support. For information,visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoor visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

Oracle Database Patch 27967747 - Grid Infrastructure Patch Set Update

12.1.0.2.180717

Copyright � 2018, Oracle and/or its affiliates.All rights reserved.

This software and related documentation are provided under alicense agreement
containing restrictions on use and disclosureand are protected by intellectual
property laws. Except asexpressly permitted in your license agreement or allowed by
law,you may not use, copy, reproduce, translate, broadcast, modify,license,
transmit, distribute, exhibit, perform, publish, ordisplay any part, in any form,
or by any means. Reverseengineering, disassembly, or decompilation of this
software,unless required by law for interoperability, is prohibited.

The information contained herein is subject to change withoutnotice and is not

warranted to be error-free. If you find anyerrors, please report them to us in
writing.

If this is software or related documentation that is delivered tothe U.S.

Government or anyone licensing it on behalf of the U.S.Government, then the
following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including anyoperating system,

integrated software, any programs installed onthe hardware, and/or documentation,
delivered to U.S. Governmentend users are "commercial computer software" pursuant
to theapplicable Federal Acquisition Regulation and agency-specificsupplemental
regulations. As such, use, duplication, disclosure,modification, and adaptation of
the programs, including anyoperating system, integrated software, any programs
installed onthe hardware, and/or documentation, shall be subject to licenseterms
and license restrictions applicable to the programs. Noother rights are granted to
the U.S. Government.

This software or hardware is developed for general use in avariety of information

management applications. It is notdeveloped or intended for use in any inherently
dangerousapplications, including applications that may create a risk ofpersonal
injury. If you use this software or hardware in dangerousapplications, then you
shall be responsible to take allappropriate fail-safe, backup, redundancy, and
other measures toensure its safe use. Oracle Corporation and its affiliatesdisclaim
any liability for any damages caused by use of thissoftware or hardware in
dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or itsaffiliates. Other
names may be trademarks of their respectiveowners.

Intel and Intel Xeon are trademarks or registered trademarks ofIntel Corporation.
All SPARC trademarks are used under license andare trademarks or registered
trademarks of SPARC International,Inc. AMD, Opteron, the AMD logo, and the AMD
Opteron logo aretrademarks or registered trademarks of Advanced Micro Devices.UNIX
is a registered trademark of The Open Group.

This software or hardware and documentation may provide access toor information
about content, products, and services from thirdparties. Oracle Corporation and its
affiliates are not responsiblefor and expressly disclaim all warranties of any kind
with respectto third-party content, products, and services unless otherwiseset
forth in an applicable agreement between you and Oracle.Oracle Corporation and its
affiliates will not be responsible forany loss, costs, or damages incurred due to
your access to or useof third-party content, products, or services, except as set
forthin an applicable agreement between you and Oracle.

Copyright � 2018, Oracle and/or itsaffiliates. All rights reserved.

Skip Headers

Oracle� Database Patch 27967747 - Grid Infrastructure Patch Set Update

12.1.0.2.180717

Oracle� Database

Patch 27967747 - Grid Infrastructure Patch Set Update 12.1.0.2.180717

From CPUJan2016 onwards, the 5th digit of the version number willbe changed to
reflect the release date in the format YYMMDD. SeeMy Oracle Support Document
2061926.1 for more information.

In this document Oracle Database Home refersto Enterprise Edition or Standard

Edition Database software. GIrefers to Grid Infrastructure and PSU refers to Patch
SetUpdate.

The GI System patch includes updates for both the Clusterwarehome and Database home
that can be applied in a rolling fashion.

This patch is Data Guard Standby First Installable - See InstallingDatabase PSU in
Standby-First Mode for more information.

This patch can be applied using Oracle Enterprise Manager (OEM)Cloud Control 12c.
OEM supportspatching a single cluster by using a Patch Plan based work flowand
multiple clusters by using fleet maintenance (introduced inOEM Cloud Control 12c
Release 4). ThePatch Plan method supports In-place and Out of Place patching.Fleet
maintenance employs Out of Place patching. (Out of placepatching enables lower
downtime compared to In-place.) Fleetmaintenance supports creating patched homes
locally on a cluster,or provisioning a gold image of the patched homes. See Oracle
Enterprise ManagerLifecycle Management Administrator's Guide for moreinformation
about both methodologies and additional OEMcapabilities.

This patch is supported by OPlan. OPlan is a utility thatfacilitates the patch

installation process by providing you withstep-by-step patching instructions
specific to your environment.The instructions cover both patch application and
patch rollbacksteps. The instructions also cover multiple patching optionsacross In
place and Outof Place methodologies. See My Oracle Support Note 1306814.1
OracleSoftware Patching with OPLAN for more detailedinformation.

This document is accurate at the time of release. For any changesand additional
information regarding GI PSU 12.1.0.2.180417,see these related documents that are
available at My OracleSupport (http://support.oracle.com/):

�Document 854428.1 Patch SetUpdates for Oracle Products

�Document 1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717

Known Issues

This document includes the following sections:

�PatchInformation

�PatchInstallation and Deinstallation

�KnownIssues

�References

�ManualSteps for Apply/Rollback Patch

�BugsFixed by This Patch

�DocumentationAccessibility

1.1 PatchInformation

GI System patches are cumulative and include the Database PSUcontent and associated
CPU program security content.

Table1-1 lists the various configurations and the applicable GISystem Patch that
should be used to patch that configuration.

Table 1-1 Configuration and PSU Mapping

Configuration

GIVersion

DatabaseVersions
GISystem Patch

OPatchCommand(1)

Comments

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

12.1.0.2

GI System Patch

opatchauto

GI Home and all the Database Homes will be patched

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

12.1.0.2 and prior versions

GI System Patch

opatchauto

GI Home and Database Home at 12.1.0.2 version will bepatched.

For Database home with version other than 12.1.0.2,apply the appropriate Database
PSU for that version. Forexample, apply 11.1.0.7.x PSU to Database
version11.1.0.7.0.

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

Versions prior to 12.1.0.2

GI System Patch

opatchauto

GI Home alone is patched.

For Database home, apply the appropriate Database PSUfor that version. For example,
apply 11.1.0.7.x PSU toDatabase version 11.1.0.7.0.

Oracle Restart Home

12.1.0.2

12.1.0.2
GI System Patch

opatchauto

GI Home and all the Database Homes will be patched.

Database Single Instance home

NA

12.1.0.2

Database PSU

opatch apply

None

Database Client home

NA

12.1.0.2

Database PSU

opatch apply

None

Footnote 1 Opatchautodoes not support patching in Data Guard environments.

SeeInstalling Database PSU in Standby-First Mode for moreinformation.

Table1-2 lists the various patches by patch number gettinginstalled as part of this
GI PSU patch.

Table 1-2 Patch Numbers Getting Installedas Part of this GI PSU Patch

PatchNumber

Description

ApplicableHomes

27547329

Database Patch Set Update 12.1.0.2.180717

Both DB Homes and Grid Home

27762253

OCW Patch Set Update 12.1.0.2.180717

Both DB Homes and Grid Home

27762277

ACFS Patch Set Update 12.1.0.2.180717Foot 2

Only Grid Home

26983807

DBWLM Patch Set Update 12.1.0.2.180116Footref 2

Only Grid Home

Footnote 2

ACFS and DBWLM these subpatches are not applicable to the HP-UXItanium and Linux on
IBM System z platforms.

1.2 PatchInstallation and Deinstallation

This section includes the following sections:

�PatchInstallation Prerequisites

�One-offPatch Conflict Detection and Resolution

�opatchautofor GI

�PatchInstallation

�InstallingDatabase PSU in Standby-First Mode

�PatchPost-Installation Instructions

�PatchDeinstallation

�PatchPost-Deinstallation Instructions

1.2.1 PatchInstallation Prerequisites

You must satisfy the conditions in the following sections beforeapplying the patch:

�OPatchUtility Information

�Validationof Oracle Inventory

�Downloadand Unzip the Patch

1.2.1.1 OPatchUtility Information

You must use the OPatch utility version 12.2.0.1.12or later to apply this patch.
The 12.2.0.1.5 release of OPatch isused for all releases 12.1.0.x and later. The
OPatch utility priorto 12.2.0.1.5 will prompt for your OCM (Oracle
ConfigurationManager) response file when it is run. You should enter a completepath
of OCM response file if you already have created this in yourenvironment. The OCM
response file is required for versions ofOPatch earlier than 12.2.0.1.5 and not
needed for later versions.Oracle recommends that you use the latest released OPatch
versionfor 12.1 releases, which is available for download from My OracleSupport
patch 6880880 by selecting ARU link for the12.1.0.1.0 release. When using OPatch
12.2.0.1.5 or later, thefollowing Opatch Option -ocmrf <ocmresponse file> does not
need to be provided.

It is recommended that you download the Opatch utility and thepatch in a shared
location to be able to access them from any nodein the cluster for the patch
application on each node.

When patching the GI Home, a shared location on ACFS only needsto be unmounted on
the node where the GI Home is being patched.

The new opatch utility should be updated in all the Oracle RACdatabase homes and
the GI home that are being patched.

To update Opatch, use the following instructions:

When using OPatch 12.2.0.1.5 or later, the followingOpatch Option -ocmrf

<ocmresponse file> does not need to be provided.
#GRID_HOME/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -analyze
-ocmrf <ocm response file>

�In case you are rolling back the patch, run this command:
#GRID_HOME/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -analyze

Note that Oracle proactively provides PSU one-off patches forcommon conflicts.

See My Oracle Support Document 1061295.1 Patch SetUpdates - One-off Patch Conflict
Resolution to determine,for each conflicting patch, whether a conflict resolution
patch isalready available, and if you need to request a new conflictresolution
patch or if the conflict may be ignored.

1.2.3 opatchautofor GI

The Opatch utility has automated the patch application for theOracle Grid
Infrastructure (GI) home and the Oracle RAC databasehomes. It operates by querying
existing configurations andautomating the steps required for patching each Oracle
RACdatabase home of same version and the GI home.

The utility must be executed by an operating system (OS) userwith root privileges,
and it must beexecuted on each node in the cluster if the GI home or Oracle
RACdatabase home is in non-shared storage. The utility should not berun in parallel
on the cluster nodes.

Depending on command line options specified, one invocation ofopatchauto can patch
the GI home, Oracle RAC database homes, orboth GI and Oracle RAC database homes of
the same Oracle releaseversion as the patch. You can also roll back the patch with
thesame selectivity.

Add the directory containing the opatchauto to the $PATHenvironment variable. For
example:
# export PATH=$PATH:<GI_HOME>/OPatch

To patch the GI home and all Oracle RAC database homes of thesame version:
# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747

To patch only the GI home:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh <GI_HOME>

To patch one or more Oracle RAC database homes:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<oracle_home1_path>,<oracle_home2_path>

To roll back the patch from the GI home and each Oracle RACdatabase home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

To roll back the patch from the GI home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh <path to GI home>

To roll back the patch from the Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<oracle_home1_path>,<oracle_home2_path>

For more information about opatchauto,see Oracle� OPatch User's Guide.

For detailed patch installation instructions, see PatchInstallation.

1.2.4 PatchInstallation
The patch instructions will differ based on the configuration ofthe Grid
infrastructure and the Oracle RAC database homes.Patching instructions for Oracle
RAC Database Homes and GItogether are listed below.

The most common configurations are listed as follows:

�Case1: GI Home and the Database Homes That Are Not Shared andACFS File System Is
Not Configured

� Case2: GI Home is Not Shared, Database Home Is Shared, ACFS MayBe Used

For other configurations listed below, see My Oracle SupportDocument 1591616.1:

�GI Home is not shared, the Database Home is not shared, ACFSmay be used.

�Patching Oracle RAC Database Homes.

�Patching GI Home alone.

�Patching Oracle Restart Home.

�Patching a software only GI Home installation or before theGI Home is configured.

Patching Oracle RAC Database Homes and GITogether

Case 1: GI Home and the Database Homes ThatAre Not Shared and ACFS File System Is
Not Configured

As root user, execute the following command on each node of thecluster:

# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747

Case 2: GI Home is Not Shared, Database HomeIs Shared, ACFS May Be Used

Patching instructions:

1.From the Oracle database home, make sure to stop the OracleRAC databases running
on all nodes. Asthe database home owner execute:
$ <ORACLE_HOME>/bin/srvctl stop database .d <db-unique-name>

2.On the 1st node, unmount the ACFS file systems. See MyOracle Support Document
1494652.1 for unmounting ACFS filesystems.

3.On the 1st node, apply the patch to the GI Home using the opatchauto command.
Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>

4.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

5.On the 1st node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

6.On the 1st node, apply the patch to the Database home usingthe opatchauto
command. Sincethe Database home is shared, this operation will patch theDatabase
home across the cluster. Note that a USM only patchcannot be applied to a database
home. Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<ORACLE_HOME>

7.On the 1st node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

8.On the 2nd (next) node, unmount the ACFS file systems. SeeMy Oracle Support
Document 1494652.1 for unmounting ACFS filesystems.

9.On the 2nd node, apply the patch to GI Home using the opatchauto command. Asroot
user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>

10.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

11.On the 2nd node, running the opatchautocommand in Step 9will restart the stack.

12.On the 2nd node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

13.On the 2nd node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>
14.Repeat Steps 8through 13for all remaining nodes of the cluster.

1.2.5 InstallingDatabase PSU in Standby-First Mode

For Data Guard Standby-First patching, see My Oracle SupportDocument 1265700.1. For
Standby-First patching forOracle Database PSU 12.1 and higher, the following points
need tobe considered:

1.The Database PSU must be applied to the Data Guard standbyusing Opatch.

2.Datapatch must not be invoked on the Data Guard standbyenvironment to apply post
patch SQL actions for the DatabasePSU. If datapatch is run on a standby, it will
error whiletrying to call the SYS.DBMS_QOPATCHinterface. For more details about
this error, see My OracleSupport Document 1599479.1.

3.Datapatch must be invoked on the primary database after allthe databases, that is
primary and Data Guard, are patched andpatch deployment of the Database PSU is
complete for thesetup.

1.2.6 PatchPost-Installation Instructions

Note:

The step "Loading Modified SQL Files into the Database" hasbeen removed from this
section as the execution of opatchautoautomatically performs the load of the
modified SQL files intothe Database.

After installing the patch, perform the following actions:

1.Apply conflict resolution patches as explained in ApplyingConflict Resolution

Patches.

2.This patch now includes the OJVM Mitigation patch(Patch:19721304). If an OJVM PSU
is installed or planned to beinstalled, no further actions are necessary.
Otherwise, theworkaround of using the OJVM Mitigation patch can beactivated. As
SYSDBA do thefollowing from the admindirectory:
SQL > @dbmsjdev.sql
SQL > exec dbms_java_dev.disable

For more information on the OJVM mitigation patch, seeDocument 1929745.1

OracleRecommended Patches -- "Oracle JavaVM Component Database PSUand RU" (OJVM PSU
and OJVM RU) Patches.

3.The MD5 hash is no longer considered sufficiently secure, see MD5 HashIs No
Longer Considered Sufficiently Secure.
1.2.6.1 ApplyingConflict Resolution Patches

Apply the patch conflict resolution one-off patches that weredetermined to be

needed when you performed the steps in One-offPatch Conflict Detection and
Resolution.

1.2.6.2 MD5Hash Is No Longer Considered Sufficiently Secure

It has been determined that MD5 hash is no longer consideredsufficiently secure.

After this patch is applied, user creation ischanged so that the MD5 hash is no
longer generated by default.This only applies to users created after this patch is
applied;existing users will not be changed. Review the following note todetermine
if you need to take further actions.

The MD5 hash is no longer considered sufficiently secure, see MyOracle Support
Document 2194116.1 for more information.

1.2.7 PatchDeinstallation

Datapatch is run to complete the post-deinstall SQL deploymentfor the PSU. For
further details about Datapatch, including KnownIssues and workarounds to common
problems, see: Database12c Post Patch SQL Automation (Doc ID 1585822.1).

The patch rollback instructions will differ based on theconfiguration of the Grid
infrastructure and the Oracle RACdatabase homes. Roll Back instructions for Oracle
RAC DatabaseHomes and GI are listed below.

The most common configurations are listed as follows:

�Case1: GI Home and Database Homes That Are Not Shared and ACFSFile System Is Not
Configured.

�Case2: GI Home Is Not Shared, Database Home Is Shared and ACFSMay Be Used.

For other configurations listed below, see My Oracle SupportDocument 1494646.1:

�GI Home is not shared, the Database Home is not shared, ACFSmay be used.

�Rolling back from Oracle RAC Database Homes.

�Rolling back from GI Home alone.

�Rolling back the patch from Oracle Restart Home.

�Rolling back the patch from a software only GI Homeinstallation or before the GI
Home is configured.
Roll Back the Oracle RAC Database Homes and GITogether

Case 1: GI Home and Database Homes That AreNot Shared and ACFS File System Is Not
Configured.

As root user, execute the following command on each node of thecluster.

# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

If the message, "A system reboot is recommended before usingACFS" is shown, then a
reboot must be issued before continuing.Failure to do so will result in running
with an unpatchedACFS\ADVM\OKS driver.

Case 2: GI Home Is Not Shared, Database HomeIs Shared and ACFS May Be Used.

1.From the Oracle database home, make sure to stop the OracleRAC databases running
on all nodes. Asthe database home owner execute:
$ <ORACLE_HOME>/bin/srvctl stop database .d <db-unique-name>

2.On the 1st node, unmount the ACFS file systems. See MyOracle Support Document
1494652.1 for unmounting ACFS filesystems.

3.On the 1st node, roll back the patch from the GI Home usingthe opatchauto
command. As root user, execute the following command:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>

4.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

5.On the 1st node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

6.On the 1st node, roll back the patch to the Database homeusing the opatchauto
command.This operation will rollback the patch to the Database homeacross the
cluster given that it is a shared ACFS home. Notethat a USM only patch cannot be
applied to a Database home. As root user, execute the followingcommand:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

7.On the 1st node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>
8.On the 2nd (next) node, unmount the ACFS file systems. SeeMy Oracle Support
Document 1494652.1 for unmounting ACFS filesystems.

9.On the 2nd node, roll back the patch to GI Home using the opatchauto command.
Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

10.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

11.On the 2nd node, running the opatchautocommand in Step 9will restart the stack.

12.On the 2nd node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

13.On the 2nd node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

14.Repeat Steps 8through 13for all remaining nodes of the cluster.

1.2.8 PatchPost-Deinstallation Instructions

Perform the following step:

1.Check the following log files in $ORACLE_HOME/sqlpatch/27547329/ forerrors:

27547329_rollback_<database SID>_<CDB name>_<timestamp>.log

where database SIDis the database SID, CDBname is the name of the
multitenantcontainer database, and timestampis of the form YYYYMMMDD_HH_MM_SS.

1.3 KnownIssues

For issues documented after the release of this PSU, see MyOracle Support Document
1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717 Known Issues.

This section includes the following known issues:

Issue1
Running datapatch may cause the following error: CATCONINITFAILED, when applying a
patch in a multi-databaseenvironment.

Symptom:
Datapatch may fail with the following error:
/scratch/racusr/app/racusr/product/12.1.0/dbhome_1/OPatch/datapatch'
SQL Patching tool version 12.2.0.0.0 on Thu Sep 11 11:34:22 2014
Copyright (c) 2014, Oracle. All rights reserved.

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)
catcon: ALL catcon-related output will be written to
/tmp/sqlpatch_catcon__catcon_22173.lst
catcon: See /tmp/sqlpatch_catcon_*.log files for output generated by scripts
catcon: See /tmp/sqlpatch_catcon__*.lst files for spool files, if any
start_processes: failed to open STDOUT (1)

catconInit failed, exiting

See My Oracle Support Document 1609718.1 for information on how toresolve this
error.

Cause:

Bug 19603117 - 121021gipsu:hit "catconinit failed" when applydbbp in different user

env

Workaround:

This problem happens because of multiple OS users havingownership of multiple

databases in the environment. These OSusers do not have write privileges on each
other's files andas a result, datapatch fails while trying to open catconlog files.
The workaround is to delete files under: /tmp/sqlpatch_*and re-run datapatch for
the affected database.
Issue2
Symptom: Increasing the NPROC limitusing the fix for bug 19680763 is not effective.

Cause: BUG 19680763 - INCREASEDEFAULT FOR CRS_LIMIT_NPROC

INS_CRSCONFIG_<NODENAME>_ENV.TXT

Workaround or Fix: It is notsupported to modify this file during patching since the
usercan modify this file with their own settings and patching isnot expected to
override them. Oracle supplies defaults duringinstall and upgrade.
Issue3
Rapid Home Provisioning (RHP) images import may fail.

Symptom: RHP Import image failed inSolaris for 11204 and 11203 version

Cause: Bug 19609388 - RHP IMPORT11203/11204 IMAGE FAILED

Fix: Apply the patch for bug19609388

Issue4
It is possible for prior versions of datapatch to not fullyinstall the SQL portion
of the GI PSU patch when run in amulti node Oracle RAC environment using
Opatchauto. See MyOracle Support Document 2069046.1 Datapatchmay skip the
application of SQL payload for certain patchesincluded in a given bundle in a RAC
environment, formore details including a validation SQL script to check ifthis
issue has occurred on a given system and remediationsteps. This issue is fixed from
this GI PSU patch versiononwards.
Issue5
Rollback Failing Due to Improper Permission of osdbagrp

Symptom: While doing rollback ofpatch, rollback failed with the following errors:
CRS-5013: Agent "ORAROOTAGENT" failed to start process
"/u01/app/12.1.0/grid_1/bin/osdbagrp" for action "start": details at
"(:CLSN00008:)"
in "/u01/app/oracle/diag/crs/node1/crs/trace/crsd_orarootagent_root.trc"
CRS-2680: Clean of 'ora.ASMU03.ASMU03.advm' on 'node1' failed
CRS-2799: Failed to shut down resource 'ora.ASMU03.ASMU03.advm' on 'node1'
CRS-2794: Shutdown of Cluster Ready Services-managed resources on 'node1' has
failed
CRS-2675: Stop of 'ora.crsd' on 'node1' failed
CRS-2799: Failed to shut down resource 'ora.crsd' on 'node1'
CRS-2795: Shutdown of Oracle High Availability Services-managed resources on
'node1' has failed

Cause: Improper permission ofosdbagrp

Fix: See My Oracle Support Document 2010324.1 RollbackFailing Due to Improper

Permission of osdbagrp.
Issue6
rootcrs.pl -postpatch/-patch hangs as"acfsroot install" stalls (My Oracle Support
DocumentID 2037801.1

Symptom: opatchauto/"opatch auto"hangs when applying Grid Infrasturcture patch

including PSUduring patch/postpatch phase showing the following:
/oracle/crs/12102/grid/crs/install/rootcrs.pl -postpatch <<<<<<<<< is hanging

crspatch_<node>_<time>.log shows

2015-07-22 14:42:40: acfs is supported

2015-07-22 14:42:40: Executing cmd: /oracle/crs/12102/grid/bin/crsctl stat res
ora.drivers.acfs -init
2015-07-22 14:42:40: Command output:
> CRS-4639: Could not contact Oracle High Availability Services
> CRS-4000: Command Status failed, or completed with errors.
>End Command output
2015-07-22 14:42:40: Executing '/oracle/crs/12102/grid/bin/acfsroot install'
2015-07-22 14:42:40: Executing cmd: /oracle/crs/12102/grid/bin/acfsroot install

Cause: HP Openview/glanceperfd/scopeux blocking ACFS driver from being unloaded.

Fix: See My Oracle Support Document 2037801.1 rootcrs.pl-postpatch/-patch hangs as

"acfsroot install" stalls.
Issue7
In environments running 11.2 databases with a 12.1.0.2 GIhome managed by Enterprise
Manager, multiple java CORE filesare produced under 11.2
$DB_HOME/<hostname>_<dbname>/sysman/emdafter applying the 12.1.0.2 April 2016 GI
PSU.

Fix: See My Oracle Support Document 2193412.1 12.1 GI:Multiple Java Core Files
Generated Under 11.2 DB Homesysman/emd.
Issue8
Problem: While running Datapatch,an error from SYS.DBMS_QOPATCH isreported with the
following message:
.input source is empty", .Error occurred in XML processing"

Or, the ORA:20001 error isreturned.

Workaround: Follow these steps:

1.Go to the $ORACLE_HOME/QOpatchfolder.

2.Check if there are xml_file.xmland stout.txt files in thefolder.

3.If they exist, these files should be deleted.

4.Rerun Datapatch.

Issue9
Problem: An ORA-04068error may appear in the Database alert log file when
datapatchis run.

During a successful run of the datapatch toolwith no errors indicated, an ORA-

04068error may appear in the Database alert log file: ORA-04068: existing state of
packages has been discarded

Workaround: This is a retryableerror in datapatch itself. If a patch installation

receivesit, then datapatch will automatically retry the operationonce, before
reporting it as a failure. The fact thatdatapatch did not report the retry and ran
successfully withno errors confirms that the patch was successfully installed,and
that another Oracle background process received the error.The ORA-04068 error
should beignored as long as datapatch runs successfully with no errorsindicated
(possibly after an automatic retry).
Issue10
Problem: You can receive errorsduring datapatch -prereq phaseexecuted by
opatchauto. Knownerrors include ORA-6502 whenquerying the opatch inventory, or
timeouts and compilationerrors during the bootstrap phase of running
datapatch.However, the final invocation of datapatch without -prereqto install the
patches is successful. This issue is mostlikely to occur if you are installing the
current bundle ontop of a release prior to January 2017.

Workaround: This issue occursbecause opatchauto invokes the datapatch -prereq phase
beforeperforming the binary patching, and thus the fixes for theseissues are not
present. As long as the final invocation ofdatapatch, which actually performs the
patching is successful,errors that occurred during the datapatch-prereq phase or on
prior nodes can be ignored.

1.4 References

The following documents are references for this patch.

Document 1591616.1 PatchInstallation and Deinstallation for 12.1.0.1.x GI PSU

Document 1494652.1 Instructionsfor Mounting/Unmounting ACFS File Systems

Document 1585822.1 Database 12cPost Patch SQL Automation

Document 854428.1 Patch SetUpdates for Oracle Products

Document 360870.1 Impact ofJava Security Vulnerabilities on Oracle Products

Document 340978.1 Genclntsh:Could Not Locate $ORACLE_HOME/network/admin/shrept.lst

Document 468959.1 EnterpriseManager Grid Control Known Issues

Document 1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717

Known Issues

Oracle� OPatch User's Guide

1.5 ManualSteps for Apply/Rollback Patch

See My Oracle Support Document 1591616.1 Section 5 for cases where opatchautocannot
be used.

1.6 BugsFixed by This Patch

See My Oracle Support Document 1928853.1.

1.7 DocumentationAccessibility

For information about Oracle's commitment to accessibility, visitthe Oracle

Accessibility Program website at http://www.oracle.com/pls/topic/lookup?
ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access toelectronic support
through My Oracle Support. For information,visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoor visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

Oracle Database Patch 27967747 - Grid Infrastructure Patch Set Update

12.1.0.2.180717

Copyright � 2018, Oracle and/or its affiliates.All rights reserved.

This software and related documentation are provided under alicense agreement
containing restrictions on use and disclosureand are protected by intellectual
property laws. Except asexpressly permitted in your license agreement or allowed by
law,you may not use, copy, reproduce, translate, broadcast, modify,license,
transmit, distribute, exhibit, perform, publish, ordisplay any part, in any form,
or by any means. Reverseengineering, disassembly, or decompilation of this
software,unless required by law for interoperability, is prohibited.

The information contained herein is subject to change withoutnotice and is not

warranted to be error-free. If you find anyerrors, please report them to us in
writing.

If this is software or related documentation that is delivered tothe U.S.

Government or anyone licensing it on behalf of the U.S.Government, then the
following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including anyoperating system,

integrated software, any programs installed onthe hardware, and/or documentation,
delivered to U.S. Governmentend users are "commercial computer software" pursuant
to theapplicable Federal Acquisition Regulation and agency-specificsupplemental
regulations. As such, use, duplication, disclosure,modification, and adaptation of
the programs, including anyoperating system, integrated software, any programs
installed onthe hardware, and/or documentation, shall be subject to licenseterms
and license restrictions applicable to the programs. Noother rights are granted to
the U.S. Government.

This software or hardware is developed for general use in avariety of information

management applications. It is notdeveloped or intended for use in any inherently
dangerousapplications, including applications that may create a risk ofpersonal
injury. If you use this software or hardware in dangerousapplications, then you
shall be responsible to take allappropriate fail-safe, backup, redundancy, and
other measures toensure its safe use. Oracle Corporation and its affiliatesdisclaim
any liability for any damages caused by use of thissoftware or hardware in
dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or itsaffiliates. Other
names may be trademarks of their respectiveowners.

Intel and Intel Xeon are trademarks or registered trademarks ofIntel Corporation.
All SPARC trademarks are used under license andare trademarks or registered
trademarks of SPARC International,Inc. AMD, Opteron, the AMD logo, and the AMD
Opteron logo aretrademarks or registered trademarks of Advanced Micro Devices.UNIX
is a registered trademark of The Open Group.

This software or hardware and documentation may provide access toor information
about content, products, and services from thirdparties. Oracle Corporation and its
affiliates are not responsiblefor and expressly disclaim all warranties of any kind
with respectto third-party content, products, and services unless otherwiseset
forth in an applicable agreement between you and Oracle.Oracle Corporation and its
affiliates will not be responsible forany loss, costs, or damages incurred due to
your access to or useof third-party content, products, or services, except as set
forthin an applicable agreement between you and Oracle.
Copyright � 2018, Oracle and/or itsaffiliates. All rights reserved.

Skip Headers

Oracle� Database Patch 27967747 - Grid Infrastructure Patch Set Update

12.1.0.2.180717

Oracle� Database

Patch 27967747 - Grid Infrastructure Patch Set Update 12.1.0.2.180717

From CPUJan2016 onwards, the 5th digit of the version number willbe changed to
reflect the release date in the format YYMMDD. SeeMy Oracle Support Document
2061926.1 for more information.

In this document Oracle Database Home refersto Enterprise Edition or Standard

Edition Database software. GIrefers to Grid Infrastructure and PSU refers to Patch
SetUpdate.

The GI System patch includes updates for both the Clusterwarehome and Database home
that can be applied in a rolling fashion.

This patch is Data Guard Standby First Installable - See InstallingDatabase PSU in
Standby-First Mode for more information.

This patch can be applied using Oracle Enterprise Manager (OEM)Cloud Control 12c.
OEM supportspatching a single cluster by using a Patch Plan based work flowand
multiple clusters by using fleet maintenance (introduced inOEM Cloud Control 12c
Release 4). ThePatch Plan method supports In-place and Out of Place patching.Fleet
maintenance employs Out of Place patching. (Out of placepatching enables lower
downtime compared to In-place.) Fleetmaintenance supports creating patched homes
locally on a cluster,or provisioning a gold image of the patched homes. See Oracle
Enterprise ManagerLifecycle Management Administrator's Guide for moreinformation
about both methodologies and additional OEMcapabilities.

This patch is supported by OPlan. OPlan is a utility thatfacilitates the patch

installation process by providing you withstep-by-step patching instructions
specific to your environment.The instructions cover both patch application and
patch rollbacksteps. The instructions also cover multiple patching optionsacross In
place and Outof Place methodologies. See My Oracle Support Note 1306814.1
OracleSoftware Patching with OPLAN for more detailedinformation.

This document is accurate at the time of release. For any changesand additional
information regarding GI PSU 12.1.0.2.180417,see these related documents that are
available at My OracleSupport (http://support.oracle.com/):

�Document 854428.1 Patch SetUpdates for Oracle Products

�Document 1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717

Known Issues

This document includes the following sections:

�PatchInformation

�PatchInstallation and Deinstallation

�KnownIssues

�References

�ManualSteps for Apply/Rollback Patch

�BugsFixed by This Patch

�DocumentationAccessibility

1.1 PatchInformation

GI System patches are cumulative and include the Database PSUcontent and associated
CPU program security content.

Table1-1 lists the various configurations and the applicable GISystem Patch that
should be used to patch that configuration.

Table 1-1 Configuration and PSU Mapping

Configuration

GIVersion

DatabaseVersions

GISystem Patch
OPatchCommand(1)

Comments

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

12.1.0.2

GI System Patch

opatchauto

GI Home and all the Database Homes will be patched

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

12.1.0.2 and prior versions

GI System Patch

opatchauto

GI Home and Database Home at 12.1.0.2 version will bepatched.

For Database home with version other than 12.1.0.2,apply the appropriate Database
PSU for that version. Forexample, apply 11.1.0.7.x PSU to Database
version11.1.0.7.0.

GI Home in conjunction with RAC, RACOne, or SingleInstance home

12.1.0.2

Versions prior to 12.1.0.2

GI System Patch

opatchauto

GI Home alone is patched.

For Database home, apply the appropriate Database PSUfor that version. For example,
apply 11.1.0.7.x PSU toDatabase version 11.1.0.7.0.

Oracle Restart Home

12.1.0.2

12.1.0.2

GI System Patch
opatchauto

GI Home and all the Database Homes will be patched.

Database Single Instance home

NA

12.1.0.2

Database PSU

opatch apply

None

Database Client home

NA

12.1.0.2

Database PSU

opatch apply

None

Footnote 1 Opatchautodoes not support patching in Data Guard environments.

SeeInstalling Database PSU in Standby-First Mode for moreinformation.

Table1-2 lists the various patches by patch number gettinginstalled as part of this
GI PSU patch.

Table 1-2 Patch Numbers Getting Installedas Part of this GI PSU Patch

PatchNumber

Description

ApplicableHomes

27547329

Database Patch Set Update 12.1.0.2.180717

Both DB Homes and Grid Home

27762253
OCW Patch Set Update 12.1.0.2.180717

Both DB Homes and Grid Home

27762277

ACFS Patch Set Update 12.1.0.2.180717Foot 2

Only Grid Home

26983807

DBWLM Patch Set Update 12.1.0.2.180116Footref 2

Only Grid Home

Footnote 2

ACFS and DBWLM these subpatches are not applicable to the HP-UXItanium and Linux on
IBM System z platforms.

1.2 PatchInstallation and Deinstallation

This section includes the following sections:

�PatchInstallation Prerequisites

�One-offPatch Conflict Detection and Resolution

�opatchautofor GI

�PatchInstallation

�InstallingDatabase PSU in Standby-First Mode

�PatchPost-Installation Instructions

�PatchDeinstallation

�PatchPost-Deinstallation Instructions

1.2.1 PatchInstallation Prerequisites

You must satisfy the conditions in the following sections beforeapplying the patch:

�OPatchUtility Information

�Validationof Oracle Inventory

�Downloadand Unzip the Patch

1.2.1.1 OPatchUtility Information

You must use the OPatch utility version 12.2.0.1.12or later to apply this patch.
The 12.2.0.1.5 release of OPatch isused for all releases 12.1.0.x and later. The
OPatch utility priorto 12.2.0.1.5 will prompt for your OCM (Oracle
ConfigurationManager) response file when it is run. You should enter a completepath
of OCM response file if you already have created this in yourenvironment. The OCM
response file is required for versions ofOPatch earlier than 12.2.0.1.5 and not
needed for later versions.Oracle recommends that you use the latest released OPatch
versionfor 12.1 releases, which is available for download from My OracleSupport
patch 6880880 by selecting ARU link for the12.1.0.1.0 release. When using OPatch
12.2.0.1.5 or later, thefollowing Opatch Option -ocmrf <ocmresponse file> does not
need to be provided.

It is recommended that you download the Opatch utility and thepatch in a shared
location to be able to access them from any nodein the cluster for the patch
application on each node.

When patching the GI Home, a shared location on ACFS only needsto be unmounted on
the node where the GI Home is being patched.

The new opatch utility should be updated in all the Oracle RACdatabase homes and
the GI home that are being patched.

To update Opatch, use the following instructions:

1.Download the OPatch utility to a temporary directory.

2.For each Oracle RAC database home and the GI home that arebeing patched, run the
following commands as the home owner toextract the OPatch utility.
$ unzip <OPATCH-ZIP> -d <ORACLE_HOME>
$ <ORACLE_HOME>/OPatch/opatch version

The version output of the previous command should be 12.2.0.1.12 or later.

For information about OPatch documentation, including any knownissues, see My

Oracle Support Document 293369.1 OPatchdocumentation list.

1.2.1.2 Validationof Oracle Inventory

Before beginning patch application, check the consistency ofinventory information

for GI home and each database home to bepatched. Run the following command as
respective Oracle home ownerto check the consistency.
$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>

If this command succeeds, it lists the Oracle components that areinstalled in the
home. Save the output so you have the statusprior to the patch apply.

If this command fails, contact Oracle Support Services forassistance.

1.2.1.3 Downloadand Unzip the Patch

To apply the patch, it must be accessible from all nodes in theOracle cluster.
Download the patch and unzip it to a sharedlocation, this is called the
<UNZIPPED_PATCH_LOCATION>.This directory must be empty and not be
/tmp.Additionally, the directory should have read permission for the ORA_INSTALL
group.
$ cd <UNZIPPED_PATCH_LOCATION>

Check that the directory is empty.

$ ls

Unzip the patch as grid home owner.

$ unzip p27967747_121020_<platform>.zip

1.2.2 One-offPatch Conflict Detection and Resolution

The fastest and easiest way to determine whether you have one-offpatches in the
Oracle home that conflict with the patch, and toget the necessary conflict
resolution patches, is to use the Patch Recommendations and PatchPlans features on
the Patches &Updates tab in My Oracle Support. These features work inconjunction
with the My Oracle Support Configuration Manager.Recorded training sessions on
these features can be found inDocument 603505.1.

However, if you are not using My Oracle Support Patch Plans, theMy Oracle Support
Conflict Checker tool enables you to upload anOPatch inventory and check the
patches that you want to apply toyour environment for conflicts.

If no conflicts are found, you can download the patches. Ifconflicts are found, the
tool finds an existing resolution todownload. If no resolution is found, it will
automatically requesta resolution, which you can monitor in the Plansand Patch
Requests region of the Patches& Updates tab.

For more information, see Knowledge Document 1091294.1, How to usethe My Oracle
Support Conflict Checker Tool.

Or, manually determine whether any currently installed one-offpatches conflict with
the PSU patch as follows:

�In the unzipped directory as described in Downloadand Unzip the Patch.

�The following commands check for conflicts in both the 12.1GI home and the 12.1 DB
homes.

�In case you are applying the patch, run this command:

Note:

When using OPatch 12.2.0.1.5 or later, the followingOpatch Option -ocmrf

<ocmresponse file> does not need to be provided.
#GRID_HOME/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -analyze
-ocmrf <ocm response file>

�In case you are rolling back the patch, run this command:
#GRID_HOME/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -analyze

Note that Oracle proactively provides PSU one-off patches forcommon conflicts.

See My Oracle Support Document 1061295.1 Patch SetUpdates - One-off Patch Conflict
Resolution to determine,for each conflicting patch, whether a conflict resolution
patch isalready available, and if you need to request a new conflictresolution
patch or if the conflict may be ignored.

1.2.3 opatchautofor GI

The Opatch utility has automated the patch application for theOracle Grid
Infrastructure (GI) home and the Oracle RAC databasehomes. It operates by querying
existing configurations andautomating the steps required for patching each Oracle
RACdatabase home of same version and the GI home.

The utility must be executed by an operating system (OS) userwith root privileges,
and it must beexecuted on each node in the cluster if the GI home or Oracle
RACdatabase home is in non-shared storage. The utility should not berun in parallel
on the cluster nodes.

Depending on command line options specified, one invocation ofopatchauto can patch
the GI home, Oracle RAC database homes, orboth GI and Oracle RAC database homes of
the same Oracle releaseversion as the patch. You can also roll back the patch with
thesame selectivity.

Add the directory containing the opatchauto to the $PATHenvironment variable. For
example:
# export PATH=$PATH:<GI_HOME>/OPatch

To patch the GI home and all Oracle RAC database homes of thesame version:
# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747

To patch only the GI home:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh <GI_HOME>
To patch one or more Oracle RAC database homes:
# opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<oracle_home1_path>,<oracle_home2_path>

To roll back the patch from the GI home and each Oracle RACdatabase home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

To roll back the patch from the GI home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh <path to GI home>

To roll back the patch from the Oracle RAC database home:
# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<oracle_home1_path>,<oracle_home2_path>

For more information about opatchauto,see Oracle� OPatch User's Guide.

For detailed patch installation instructions, see PatchInstallation.

1.2.4 PatchInstallation

The patch instructions will differ based on the configuration ofthe Grid
infrastructure and the Oracle RAC database homes.Patching instructions for Oracle
RAC Database Homes and GItogether are listed below.

The most common configurations are listed as follows:

�Case1: GI Home and the Database Homes That Are Not Shared andACFS File System Is
Not Configured

� Case2: GI Home is Not Shared, Database Home Is Shared, ACFS MayBe Used

For other configurations listed below, see My Oracle SupportDocument 1591616.1:

�GI Home is not shared, the Database Home is not shared, ACFSmay be used.

�Patching Oracle RAC Database Homes.

�Patching GI Home alone.

�Patching Oracle Restart Home.

�Patching a software only GI Home installation or before theGI Home is configured.

Patching Oracle RAC Database Homes and GITogether

Case 1: GI Home and the Database Homes ThatAre Not Shared and ACFS File System Is
Not Configured

As root user, execute the following command on each node of thecluster:

# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747

Case 2: GI Home is Not Shared, Database HomeIs Shared, ACFS May Be Used

Patching instructions:

1.From the Oracle database home, make sure to stop the OracleRAC databases running
on all nodes. Asthe database home owner execute:
$ <ORACLE_HOME>/bin/srvctl stop database .d <db-unique-name>

2.On the 1st node, unmount the ACFS file systems. See MyOracle Support Document
1494652.1 for unmounting ACFS filesystems.

3.On the 1st node, apply the patch to the GI Home using the opatchauto command.
Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>

4.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

5.On the 1st node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

6.On the 1st node, apply the patch to the Database home usingthe opatchauto
command. Sincethe Database home is shared, this operation will patch theDatabase
home across the cluster. Note that a USM only patchcannot be applied to a database
home. Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<ORACLE_HOME>

7.On the 1st node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

8.On the 2nd (next) node, unmount the ACFS file systems. SeeMy Oracle Support
Document 1494652.1 for unmounting ACFS filesystems.
9.On the 2nd node, apply the patch to GI Home using the opatchauto command. Asroot
user, execute the following command:
# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>

10.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

11.On the 2nd node, running the opatchautocommand in Step 9will restart the stack.

12.On the 2nd node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

13.On the 2nd node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

14.Repeat Steps 8through 13for all remaining nodes of the cluster.

1.2.5 InstallingDatabase PSU in Standby-First Mode

For Data Guard Standby-First patching, see My Oracle SupportDocument 1265700.1. For
Standby-First patching forOracle Database PSU 12.1 and higher, the following points
need tobe considered:

1.The Database PSU must be applied to the Data Guard standbyusing Opatch.

2.Datapatch must not be invoked on the Data Guard standbyenvironment to apply post
patch SQL actions for the DatabasePSU. If datapatch is run on a standby, it will
error whiletrying to call the SYS.DBMS_QOPATCHinterface. For more details about
this error, see My OracleSupport Document 1599479.1.

3.Datapatch must be invoked on the primary database after allthe databases, that is
primary and Data Guard, are patched andpatch deployment of the Database PSU is
complete for thesetup.

1.2.6 PatchPost-Installation Instructions

Note:

The step "Loading Modified SQL Files into the Database" hasbeen removed from this
section as the execution of opatchautoautomatically performs the load of the
modified SQL files intothe Database.

After installing the patch, perform the following actions:

1.Apply conflict resolution patches as explained in ApplyingConflict Resolution

Patches.

2.This patch now includes the OJVM Mitigation patch(Patch:19721304). If an OJVM PSU
is installed or planned to beinstalled, no further actions are necessary.
Otherwise, theworkaround of using the OJVM Mitigation patch can beactivated. As
SYSDBA do thefollowing from the admindirectory:
SQL > @dbmsjdev.sql
SQL > exec dbms_java_dev.disable

For more information on the OJVM mitigation patch, seeDocument 1929745.1

OracleRecommended Patches -- "Oracle JavaVM Component Database PSUand RU" (OJVM PSU
and OJVM RU) Patches.

3.The MD5 hash is no longer considered sufficiently secure, see MD5 HashIs No
Longer Considered Sufficiently Secure.

1.2.6.1 ApplyingConflict Resolution Patches

Apply the patch conflict resolution one-off patches that weredetermined to be

needed when you performed the steps in One-offPatch Conflict Detection and
Resolution.

1.2.6.2 MD5Hash Is No Longer Considered Sufficiently Secure

It has been determined that MD5 hash is no longer consideredsufficiently secure.

After this patch is applied, user creation ischanged so that the MD5 hash is no
longer generated by default.This only applies to users created after this patch is
applied;existing users will not be changed. Review the following note todetermine
if you need to take further actions.

The MD5 hash is no longer considered sufficiently secure, see MyOracle Support
Document 2194116.1 for more information.

1.2.7 PatchDeinstallation

Datapatch is run to complete the post-deinstall SQL deploymentfor the PSU. For
further details about Datapatch, including KnownIssues and workarounds to common
problems, see: Database12c Post Patch SQL Automation (Doc ID 1585822.1).

The patch rollback instructions will differ based on theconfiguration of the Grid
infrastructure and the Oracle RACdatabase homes. Roll Back instructions for Oracle
RAC DatabaseHomes and GI are listed below.

The most common configurations are listed as follows:

�Case1: GI Home and Database Homes That Are Not Shared and ACFSFile System Is Not
Configured.

�Case2: GI Home Is Not Shared, Database Home Is Shared and ACFSMay Be Used.

For other configurations listed below, see My Oracle SupportDocument 1494646.1:

�GI Home is not shared, the Database Home is not shared, ACFSmay be used.

�Rolling back from Oracle RAC Database Homes.

�Rolling back from GI Home alone.

�Rolling back the patch from Oracle Restart Home.

�Rolling back the patch from a software only GI Homeinstallation or before the GI
Home is configured.

Roll Back the Oracle RAC Database Homes and GITogether

Case 1: GI Home and Database Homes That AreNot Shared and ACFS File System Is Not
Configured.

As root user, execute the following command on each node of thecluster.

# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

If the message, "A system reboot is recommended before usingACFS" is shown, then a
reboot must be issued before continuing.Failure to do so will result in running
with an unpatchedACFS\ADVM\OKS driver.

Case 2: GI Home Is Not Shared, Database HomeIs Shared and ACFS May Be Used.

1.From the Oracle database home, make sure to stop the OracleRAC databases running
on all nodes. Asthe database home owner execute:
$ <ORACLE_HOME>/bin/srvctl stop database .d <db-unique-name>

2.On the 1st node, unmount the ACFS file systems. See MyOracle Support Document
1494652.1 for unmounting ACFS filesystems.

3.On the 1st node, roll back the patch from the GI Home usingthe opatchauto
command. As root user, execute the following command:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747 -oh
<GI_HOME>
4.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

5.On the 1st node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

6.On the 1st node, roll back the patch to the Database homeusing the opatchauto
command.This operation will rollback the patch to the Database homeacross the
cluster given that it is a shared ACFS home. Notethat a USM only patch cannot be
applied to a Database home. As root user, execute the followingcommand:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

7.On the 1st node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

8.On the 2nd (next) node, unmount the ACFS file systems. SeeMy Oracle Support
Document 1494652.1 for unmounting ACFS filesystems.

9.On the 2nd node, roll back the patch to GI Home using the opatchauto command.
Asroot user, execute the following command:
# <GI_HOME>/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/27967747

10.If the message, "A system reboot is recommended beforeusing ACFS" is shown, then
a reboot must be issued beforecontinuing. Failure to do so will result in running
with anunpatched ACFS\ADVM\OKS driver.

11.On the 2nd node, running the opatchautocommand in Step 9will restart the stack.

12.On the 2nd node, remount ACFS file systems. See My OracleSupport Document
1494652.1 for mounting ACFS filesystems.

13.On the 2nd node only, restart the Oracle instance, whichyou have previously
stopped in Step 1. As the database home owner execute:
$ <ORACLE_HOME>/bin/srvctl start instance .d <db-unique-name> -n <nodename>

14.Repeat Steps 8through 13for all remaining nodes of the cluster.

1.2.8 PatchPost-Deinstallation Instructions

Perform the following step:

1.Check the following log files in $ORACLE_HOME/sqlpatch/27547329/ forerrors:

27547329_rollback_<database SID>_<CDB name>_<timestamp>.log

where database SIDis the database SID, CDBname is the name of the
multitenantcontainer database, and timestampis of the form YYYYMMMDD_HH_MM_SS.

1.3 KnownIssues

For issues documented after the release of this PSU, see MyOracle Support Document
1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717 Known Issues.

This section includes the following known issues:

Issue1
Running datapatch may cause the following error: CATCONINITFAILED, when applying a
patch in a multi-databaseenvironment.

Symptom:

Datapatch may fail with the following error:

/scratch/racusr/app/racusr/product/12.1.0/dbhome_1/OPatch/datapatch'
SQL Patching tool version 12.2.0.0.0 on Thu Sep 11 11:34:22 2014
Copyright (c) 2014, Oracle. All rights reserved.

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)
catcon: ALL catcon-related output will be written to
/tmp/sqlpatch_catcon__catcon_22173.lst
catcon: See /tmp/sqlpatch_catcon_*.log files for output generated by scripts
catcon: See /tmp/sqlpatch_catcon__*.lst files for spool files, if any
start_processes: failed to open STDOUT (1)

catconInit failed, exiting

See My Oracle Support Document 1609718.1 for information on how toresolve this
error.

Cause:

Bug 19603117 - 121021gipsu:hit "catconinit failed" when applydbbp in different user

env

Workaround:

This problem happens because of multiple OS users havingownership of multiple

databases in the environment. These OSusers do not have write privileges on each
other's files andas a result, datapatch fails while trying to open catconlog files.
The workaround is to delete files under: /tmp/sqlpatch_*and re-run datapatch for
the affected database.
Issue2
Symptom: Increasing the NPROC limitusing the fix for bug 19680763 is not effective.

Cause: BUG 19680763 - INCREASEDEFAULT FOR CRS_LIMIT_NPROC

INS_CRSCONFIG_<NODENAME>_ENV.TXT

Workaround or Fix: It is notsupported to modify this file during patching since the
usercan modify this file with their own settings and patching isnot expected to
override them. Oracle supplies defaults duringinstall and upgrade.
Issue3
Rapid Home Provisioning (RHP) images import may fail.

Symptom: RHP Import image failed inSolaris for 11204 and 11203 version

Cause: Bug 19609388 - RHP IMPORT11203/11204 IMAGE FAILED

Fix: Apply the patch for bug19609388

Issue4
It is possible for prior versions of datapatch to not fullyinstall the SQL portion
of the GI PSU patch when run in amulti node Oracle RAC environment using
Opatchauto. See MyOracle Support Document 2069046.1 Datapatchmay skip the
application of SQL payload for certain patchesincluded in a given bundle in a RAC
environment, formore details including a validation SQL script to check ifthis
issue has occurred on a given system and remediationsteps. This issue is fixed from
this GI PSU patch versiononwards.
Issue5
Rollback Failing Due to Improper Permission of osdbagrp

Symptom: While doing rollback ofpatch, rollback failed with the following errors:
CRS-5013: Agent "ORAROOTAGENT" failed to start process
"/u01/app/12.1.0/grid_1/bin/osdbagrp" for action "start": details at
"(:CLSN00008:)"
in "/u01/app/oracle/diag/crs/node1/crs/trace/crsd_orarootagent_root.trc"
CRS-2680: Clean of 'ora.ASMU03.ASMU03.advm' on 'node1' failed
CRS-2799: Failed to shut down resource 'ora.ASMU03.ASMU03.advm' on 'node1'
CRS-2794: Shutdown of Cluster Ready Services-managed resources on 'node1' has
failed
CRS-2675: Stop of 'ora.crsd' on 'node1' failed
CRS-2799: Failed to shut down resource 'ora.crsd' on 'node1'
CRS-2795: Shutdown of Oracle High Availability Services-managed resources on
'node1' has failed

Cause: Improper permission ofosdbagrp

Fix: See My Oracle Support Document 2010324.1 RollbackFailing Due to Improper

Permission of osdbagrp.
Issue6
rootcrs.pl -postpatch/-patch hangs as"acfsroot install" stalls (My Oracle Support
DocumentID 2037801.1

Symptom: opatchauto/"opatch auto"hangs when applying Grid Infrasturcture patch

including PSUduring patch/postpatch phase showing the following:
/oracle/crs/12102/grid/crs/install/rootcrs.pl -postpatch <<<<<<<<< is hanging

crspatch_<node>_<time>.log shows

2015-07-22 14:42:40: acfs is supported

2015-07-22 14:42:40: Executing cmd: /oracle/crs/12102/grid/bin/crsctl stat res
ora.drivers.acfs -init
2015-07-22 14:42:40: Command output:
> CRS-4639: Could not contact Oracle High Availability Services
> CRS-4000: Command Status failed, or completed with errors.
>End Command output
2015-07-22 14:42:40: Executing '/oracle/crs/12102/grid/bin/acfsroot install'
2015-07-22 14:42:40: Executing cmd: /oracle/crs/12102/grid/bin/acfsroot install

Cause: HP Openview/glanceperfd/scopeux blocking ACFS driver from being unloaded.

Fix: See My Oracle Support Document 2037801.1 rootcrs.pl-postpatch/-patch hangs as

"acfsroot install" stalls.
Issue7
In environments running 11.2 databases with a 12.1.0.2 GIhome managed by Enterprise
Manager, multiple java CORE filesare produced under 11.2
$DB_HOME/<hostname>_<dbname>/sysman/emdafter applying the 12.1.0.2 April 2016 GI
PSU.

Fix: See My Oracle Support Document 2193412.1 12.1 GI:Multiple Java Core Files
Generated Under 11.2 DB Homesysman/emd.
Issue8
Problem: While running Datapatch,an error from SYS.DBMS_QOPATCH isreported with the
following message:
.input source is empty", .Error occurred in XML processing"

Or, the ORA:20001 error isreturned.

Workaround: Follow these steps:

1.Go to the $ORACLE_HOME/QOpatchfolder.

2.Check if there are xml_file.xmland stout.txt files in thefolder.

3.If they exist, these files should be deleted.

4.Rerun Datapatch.

Issue9
Problem: An ORA-04068error may appear in the Database alert log file when
datapatchis run.

During a successful run of the datapatch toolwith no errors indicated, an ORA-

04068error may appear in the Database alert log file: ORA-04068: existing state of
packages has been discarded

Workaround: This is a retryableerror in datapatch itself. If a patch installation

receivesit, then datapatch will automatically retry the operationonce, before
reporting it as a failure. The fact thatdatapatch did not report the retry and ran
successfully withno errors confirms that the patch was successfully installed,and
that another Oracle background process received the error.The ORA-04068 error
should beignored as long as datapatch runs successfully with no errorsindicated
(possibly after an automatic retry).
Issue10
Problem: You can receive errorsduring datapatch -prereq phaseexecuted by
opatchauto. Knownerrors include ORA-6502 whenquerying the opatch inventory, or
timeouts and compilationerrors during the bootstrap phase of running
datapatch.However, the final invocation of datapatch without -prereqto install the
patches is successful. This issue is mostlikely to occur if you are installing the
current bundle ontop of a release prior to January 2017.

Workaround: This issue occursbecause opatchauto invokes the datapatch -prereq phase
beforeperforming the binary patching, and thus the fixes for theseissues are not
present. As long as the final invocation ofdatapatch, which actually performs the
patching is successful,errors that occurred during the datapatch-prereq phase or on
prior nodes can be ignored.

1.4 References

The following documents are references for this patch.

Document 1591616.1 PatchInstallation and Deinstallation for 12.1.0.1.x GI PSU

Document 1494652.1 Instructionsfor Mounting/Unmounting ACFS File Systems

Document 1585822.1 Database 12cPost Patch SQL Automation

Document 854428.1 Patch SetUpdates for Oracle Products

Document 360870.1 Impact ofJava Security Vulnerabilities on Oracle Products

Document 340978.1 Genclntsh:Could Not Locate $ORACLE_HOME/network/admin/shrept.lst

Document 468959.1 EnterpriseManager Grid Control Known Issues

Document 1227443.1 Oracle Grid Infrastructure Patch Set Update 12.1.0.2.180717

Known Issues

Oracle� OPatch User's Guide

1.5 ManualSteps for Apply/Rollback Patch

See My Oracle Support Document 1591616.1 Section 5 for cases where opatchautocannot
be used.

1.6 BugsFixed by This Patch

See My Oracle Support Document 1928853.1.