Patching is one of the important phases of the product lifecycle that enables you to keep your software product updated with bug fixes. Oracle releases several types of patches periodically to help you maintain your product. However, patching has always been the most challenging phase of the lifecycle because it is complex, risky, time consuming, and involves downtime. Although you can use several approaches to identify the patches and patch your databases, the challenges still remain the same, unfortunately.

This chapter describes how Oracle Enterprise Manager Cloud Control's (Cloud Control) new patch management solution addresses these patch management challenges. In particular, this chapter covers the following:

42.1 Overview of the New Patch Management Solution

This section describes the following:

42.1.1 Overview of the Current Patch Management Challenges

Jun 20, 2015  How to Download Oracle Software Using WGET Sometimes we need to download Oracle patches or software from a sever where we do not have GUI environment. Oracle provides wget utility for downloading the patches remotely. How to Download Oracle Software Using WGET Sometimes we need to download Oracle patches or software from a sever where we do not have GUI environment. Oracle provides wget utility for downloading the patches remotely. So, one of the things a command line experienced user hates is to have to go to a browser to download a piece of software. I also dislike it 🙂 a lot! I like WGET i mean I love it. So for everyone of you that rely on WGET to download Oracle Software from OTN, this will surelly be a huge hint.

Before you understand the new patch management solution offered by Cloud Control, take a moment to review some of the tools you might be using currently to patch your databases, and the challenges you might be facing while using them (Table 42-1).

Table 42-1 Current Patch Management Tools and Challenges

Approach	Description	Challenges
OPatch	Oracle proprietary tool that is installed with Oracle products like Oracle Database, Management Agent, SOA, and so on.	Difficult to identify the patches to be rolled out Patches only one Oracle home at a time Offers limited support to handle pre and post-patching scripts
Custom Scripts	User-created scripts developed around OPatch, SQLPlus, and so on.	Difficult to identify the patches to be rolled out Can be used only on a single server Requires significant maintenance overhead to meet the new version and configuration needs
Deployment procedures	Default procedures offered by Cloud Control for automating the patching operations	Confusion over which deployment procedure to select Limited scope for validating the patches and targets selected in a deployment procedure Separate deployment procedures for patching in rolling and parallel mode Difficult to handle patch conflicts

42.1.2 About the New Patch Management Solution

Cloud Control addresses the challenges described in Section 42.1.1 with its much-improved patch management solution that delivers maximum ease with minimum downtime. The new patch management solution offers the following benefits:

• Integrated patching workflow with My Oracle Support (MOS), therefore, you see recommendations, search patches, and roll out patches all using the same user interface.

  However, Cloud Control does not upload any data to MOS. It only uses MOS to download the latest updates.

• Complete, end-to-end orchestration of patching workflow using Patch Plans, including automated selection of deployment procedures and analysis of the patch conflicts, therefore, there is minimal manual effort required. For more information on patch plans, see Section 42.1.3.

• Clear division of responsibilities between designers and operators. Designers can focus on creating patch plans, testing them on a test system, and saving them as patch templates. Operators can focus on creating patch plans out of the template for rolling out the patches on a production system.

• Easy review of patches for applicability in your environment, validation of patch plans, and automatic receipt of patches to resolve validation issues.

• Saving successfully analyzed or deployable patch plans as patch templates, which contain a predetermined set of patches and deployment options saved from the source patch plan.

• Out-of-place patching for standalone (single-instance) database targets, Oracle Real Application Clusters (RAC) targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata).

  Note:

  • Out-of-place patching is supported for RAC targets and Oracle Grid Infrastructure targets that are not a part of Oracle Exadata, only if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed.

  • Out-of-place patching is supported for Oracle Data Guard targets, only if you have the 12.1.0.6 Enterprise Manager for Oracle Database plug-in deployed.

• Flexible patching options such as rolling and parallel, both in offline and online mode.

Figure 42-1 shows you how you can access the Patches and Updates screen from within Cloud Control console.

Figure 42-1 Accessing the Patches & Updates Screen

42.1.3 Overview of Patch Plans

This section describes the following:

42.1.3.1 About Patch Plans

Download Oracle Patch

Patch plans help you create a consolidated list of patches you want to apply as a group to one or more targets. Patch plans have states (or status) that map to key steps in the configuration change management process. Any administrator or role that has view privileges can access a patch plan.

Patch plan supports the following types of patches:

• Patch Sets

  Note:

  • Patch Sets are available for Oracle Database 10g Release 2 (10.2.0.x) and Oracle Database 11g Release 1 (11.1.0.x). You can apply these patches using a patch plan. However, Patch Sets for Oracle Database 11g Release 2 (11.2.0.x) are complete installs (full releases), and you must use the Database Upgrade feature to apply them. The Database Upgrade feature follows the out-of-place patching approach.

  • Patch Sets are not supported on Oracle WebLogic Server targets, Oracle Fusion Application targets, and Oracle SOA Infrastructure targets.

• Patches (One-Off)

  • Interim Patches that contain a single bug fix or a collection of bug fixes provided as required. Also include one-offs for customer-specific security bug fixes.

  • Diagnostic Patches, intended to help diagnose or verify a fix or a collection of bug fixes.

  • Patch Set Updates (PSU), contain a collection of high impact, low risk, and proven fixes for a specific product or component.

  • Critical Patch Updates (CPU), contain a collection of security bug fixes.

Note:

You cannot add both patch sets and patches to a patch plan. Instead, you can have one patch plan for patch sets, and another patch plan for patches.

A patch can be added to a target in a plan only if the patch has the same release and platform as the target to which it is being added. You will receive a warning if the product for the patch being added is different from the product associated with the target to which the patch is being added. The warning does not prevent you from adding the patch to the plan.

You can include any patch for any target in a plan. The plan also validates Oracle Database, Fusion Middleware, and Cloud Control patches against your environment to check for conflicts with installed patches.

The patch plan, depending on the patches you added to it, automatically selects an appropriate deployment procedure to be used for applying the patches. For information on the patching deployment procedures used for various database target types, see Table 42-2.

Note:

• Patch plans are currently not available for hardware or operating system patching.

• Any administrator or role that has view privileges can access a patch plan. For information on roles and privileges required for patch plans and patch templates, see Section 42.2.2.

42.1.3.2 About Types of Patch Plans

This section describes the types of patch plans. It consists of the following:

Deployable and Non Deployable Plans

A patch plan can be either deployable or nondeployable.

• A patch plan is deployable when:

  • It contains only patches of the same type (homogenous patches).

  • It contains targets that are supported for patching, similarly configured, and are of the same product type, platform, and version (homogeneous targets).

  • There are no other conflicts within the plan.

• A patch plan that does not meet any of the conditions listed for a deployable plan is a nondeployable plan. If your patch plan is not deployable, you cannot deploy the patches using the patch plan, but you can perform some analysis and checks, download the patches, and manually apply the them.

Error Plans

If your patch plan consists of Oracle Management Agent (Management Agent) targets and patches, and the analysis fails on some Management Agents, then the patch plan is split into two plans. The Management Agents and their associated patches on which the analysis was successful are retained in the original plan. The failed targets and their associated patches are moved to a new error plan. The deployment options are also copied into the error plan. The error plan is accessible from the Patches & Updates page.

42.1.3.3 About the Create Plan Wizard

Figure 42-2 shows the Create Plan Wizard that enables you to create, view, and modify patch plans.

The wizard has the following screens:

Screen 1: Plan Information

Enables you to provide basic information about the plan, such as a unique name for the plan, a planned deployment date, a brief description. Also enables you to add an administrator or a role that can access the patch plan.

Screen 2: Patches

Enables you to view the patches already part of the patch plan, and manually add additional patches to the plan and associate targets that need to be patched.

Screen 3: Deployment Options

Enables you to configure the patch plan with deployment options that suit your needs. Although this step is common for all target types, the deployment options offered by this step depend on the target types selected in the patch plan.

For all target types, you can select a customized deployment procedure for deploying the patches, and specify the credentials to be used. For database targets, you can specify a nondefault staging location for storing patches and skip the staging process if the patches are already staged. For standalone (single-instance) database targets, Oracle RAC database targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata), you can choose between out-of-place patching and in-place patching. For Oracle RAC database targets and Oracle Grid Infrastructure targets, you can choose to apply the patches in rolling or parallel mode in order to control the downtime of the system.

Screen 4: Validation

Enables you to validate the patch plan and determine whether the patches can be rolled out without any problems. Essentially, it enables you to perform the following checks using the patch information from Oracle, the inventory of patches on your system (gathered by the configuration manager), and the information from candidate patches.

• Patch Conflict Checks

  • Conflict between the patches added to the patch plan and the patches already present in the Oracle home

  • Conflict among patches within the patch plan

• Target Sanity Checks

  • Target status and configuration checks

  • OPatch and OUI checks

  • Inventory sanity checks, such as locks, access, and so on

  • Hard disk space checks

  • Cluster verification checks (cluvfy, srvctl config)

  • SQLPlus checks (with sample SQL)

  Note:

  For Oracle WebLogic targets, instead of the OPatch and OUI check, you must perform the SmartUpdate version check.

In addition to checking for conflicts, it enables you to check for patch conflicts between the patches listed in the plan.

Screen 5: Review & Deploy

Enables you to review the details you have provided for the patch plan, and then deploy the plan. The page also enables you to review all the impacted targets so that you understand what all targets are affected by the action you are taking.

42.1.4 Overview of Patch Templates

This section describes the following:

42.1.4.1 About Patch Templates

Patch templates are another important aspect of the patch management solution. Patch templates help you create predesigned plans based on an existing successfully analyzed or deployable patch plan, however without any targets selected. A patch template contains a predetermined set of patches and deployment options saved from the source patch plan, and enables you to select a completely new set of targets.

This way, as a Patch Designer, you can create a patch plan with a set of patches, test them in your environment, save the successfully analyzed patch plan as a patch template, and publish them to Patch Operators. As a Patch Operator, who can create patch plans out of the templates, add another set of targets, and roll out the patches to the production environment in a recursive manner.

This way, you reduce the time and effort required to create new patch plans, and as a Patch Designer, you expose only the successfully analyzed and approved plans to Patch Operators.

Note:

An administrator or role that has the privileges to create a patch template and view a patch plan, which is being used to create a template, can create a patch template.

42.1.4.2 About the Edit Template Wizard

Figure 42-3 shows the Edit Template Wizard that enables you to view the contents of a patch plan template and modify its description.

When you view or modify a patch plan template, the Edit Template Wizard opens. This wizard has the following screens:

Screen 1: Plan Information

Enables you to view general information about the template, and modify the description and the deployment date.

Screen 2: Patches

Enables you to view a list of patches part of the patch plan template. The patches listed here are the patches copied from the source patch plan that you selected for creating the template.

Screen 3: Deployment Options

Enables you to view the deployment options configured in the patch plan template.

42.1.5Supported Targets, Releases, and Deployment Procedures for Patching

Table 42-2 lists the targets and their releases you can patch on different platforms using the new patch management solution, and the default deployment procedures that the patch plans automatically select depending on the target type. The deployment procedures are supported only through patch plans. Although they are exposed in the Deployment Procedure Manager page, you cannot select and run them independently; you must always create a patch plan to run them.

Note:

You need to meet the following prerequisites before patching Oracle WebLogic Server targets:

1. Ensure that you have applied the Enterprise Manager for My Oracle Support 12.1.0.5 plug-in on the OMS. This must be applied to all of the OMS instances in a multi-OMS environment.

2. Ensure that you have applied the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in on the OMS and the Management Agent monitoring the Oracle WebLogic Server targets.

Table 42-2 Supported Targets and Releases for Patching

Supported Target Type	Supported Targets and Releases	Supported Platform	Supported Default Deployment Procedure
Oracle Database	Oracle Database (standalone) 10g Release 1 to 11g Release 2	All Platforms	Patch Oracle Database
	Oracle Automated Storage Management (Oracle ASM) 10g Release 1 to 11g Release 2	All Platforms	Patch Standalone Oracle ASM
	Oracle Real Application Cluster (Oracle RAC) 10g Release 1 to 11g Release 2	All Platforms	Patch Oracle RAC Database - Rolling Patch Oracle RAC Database - All Nodes
	Oracle RAC One Node 10g Release 1 to 11g Release 2	All Platforms	Patch Oracle RAC Database - Parallel
	Oracle Exadata RAC DatabasesFoot 1 11g Release 2 (11.2.0.1, 11.2.0.2, and 11.2.0.3)	All Platforms	No default deployment procedure; it is built dynamically
	Oracle Restart 10g Release 1 to 11g Release 2	All Platforms	Patch Oracle Restart
	Oracle Clusterware 10g Release 1 to 11g Release 1	All platforms except for Microsoft Windows	Patch Oracle Clusterware - Rolling Patch Oracle Clusterware - All Nodes
	Oracle Grid Infrastructure 11g Release 2	All platforms except for Microsoft Windows	Patch Oracle Clusterware - Rolling Patch Oracle Clusterware - All Nodes
Oracle Database 12c Multitenant Database (Container and Pluggable Databases)	All Platforms	No default deployment procedure; it is invoked internally
Oracle WebLogic Server	Oracle WebLogic Server 10g Release 3 (10.3.1), (10.3.2), (10.3.3), (10.3.4), (10.3.5), (10.3.6), and 12c Release 1 (12.1.1), (12.1.2), (12.1.3)	All Platforms	Patch Oracle WebLogic Server In Parallel Mode Patch Oracle WebLogic Server In Rolling Mode
Oracle Fusion Applications	Oracle Fusion Applications 11g Release 1 (11.1.1.5.1) and (11.1.2.0.0) (RUP1)	All Platforms	Patch Oracle Fusion Applications
Oracle Application Server	Oracle Application Server 10g Release 1	All Platforms	Patch Application Server
Oracle SOA Infrastructure	Oracle SOA Infrastructure 11g Release 1 (11.1.1.1.0 - 11.1.1.7.0), and 12c Release 1 (12.1.3.0.0)	All Platforms	Patch Oracle SOA Infrastructure In Parallel Mode Patch Oracle SOA Infrastructure In Rolling Mode
Oracle Identity Management (only Oracle Access Management Server and Oracle Identity Management Server targets are supported)	Oracle Identity Management 11g Release 2 (11.1.2.2.0)	All Platforms	Patching IDM
Oracle Siebel (only Siebel Server and Siebel Gateway Server targets are supported)	Oracle Siebel 8.1.1.9, 8.1.1.10, 8.1.1.11, and 8.2.x	All Platforms	Patching Siebel Targets

^{Footnote 1} Exclusively tested for Oracle Exadata Database Machine recommended bundle patches.

Note:

• You can also patch primary and standby databases configured with Oracle Data Guard. For information on how to patch these targets, see Section 42.4.9.

• Patching an Oracle database whose listener was started by a user different from the Oracle database home owner is not supported. To patch such a database, stop the database listener, restart it as the database home owner, then apply the required patch using a patch plan.

42.1.6 Overview of Supported Patching Modes

This section describes the following patching modes:

42.1.6.1 Overview of Patching in Online and Offline Mode

You have the flexibility to choose between Online and Offline modes of patching.

Online Mode

Online mode is useful when Cloud Control can connect to My Oracle Support (MOS) using an Internet connection. Using this mode, you can see recommendations from Oracle for the patches to be applied, and manually search patches directly on MOS and add them to your patch plan. In addition, you can access community information, knowledge articles, service requests, and so on, and also automatically resolve patch conflicts with a merge patch directly from MOS.

Note that Cloud Control does not upload any data to MOS. It only uses MOS to download the latest updates.

Offline Mode

Offline mode is useful when Cloud Control cannot connect to My Oracle Support. Using this mode, you can search patches that were manually uploaded to the Software Library, and add them to your patch plan. In offline mode, you cannot do the following:

• Search and download patches from My Oracle Support

• View additional information about the patch

• Access community information, knowledge articles, service requests

• View the Related Activity region

Note:

By default, the patching mode is set to online. If you want to switch the mode to offline, then from the Setup menu, select Provisioning and Patching, then select Offline Patching. For connection, select Offline.

42.1.6.2 Overview of Patching in In-Place and Out-of-Place Mode

You have the flexibility to choose between in-place and out-of-place patching modes.

In-Place Mode

In-place mode of patching is a patching mechanism where you directly patch the database home. In this mode, before applying the patch, you bring down all the database instances running out of that database home. Thus, there is downtime. After applying the patch, you restart all the database instances. All the database instances are patched in the same manner. Note that in this mode, recovery takes longer if there is a problem, because the Oracle home that you patched is the original database home, and not a copy.

Figure 42-4 illustrates how multiple database instances running from an Oracle home get patched in in-place patching mode.

Out-of-Place Mode

Out-of-place mode of patching is a patching mechanism that clones the existing database home, and patches the cloned home instead of the original home. Once the cloned home is patched, you can migrate the database instances to run from the cloned home, which ensures minimal downtime.

Important:

• Out-of-place patching is supported for standalone (single-instance) database targets, Oracle RAC Database targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata).

  The 12.1.0.5 Enterprise Manager for Oracle Database plug-in is required for patching Oracle RAC Database targets and Oracle Grid Infrastructure targets that are not a part of Oracle Exadata, in out-of-place mode. The 12.1.0.6 Enterprise Manager for Oracle Database plug-in is required for patching Oracle Data Guard targets in out-of-place mode.

• If the cloned home contains certain additional patches (that are not added to the patch plan) that include SQL statements, the SQL statements for these patches are not executed automatically when the database instance is migrated to the cloned home. For these patches, you must execute the SQL statements manually.

While migrating the database instances, you can choose to migrate all the instances, or only some of them, depending on the downtime you can afford to have in your data center. If you choose to migrate only a few instances in one session, then ensure that you migrate the rest in the next session. This way, you can control the downtime in your data center as you divide the migration activity. This is particularly useful when you have multiple database instances running out of an Oracle home.

Note:

You select the database instances that you want to migrate, while creating the patch plan using the Create Plan Wizard. The selected database instances are migrated when the patch plan is in the Deploy state. If you selected only a few database instances for migration, create another patch plan to migrate the remaining instances. On the Deployment Options page, select the existing home, then select the remaining database instances that need to be migrated.

Oracle always recommends out-of-place patching because downtime is minimal and recovery in case of a problem is easy; you can always switch back to the original database home in case of a problem with the clone home.

Note:

If you patched an Oracle RAC target, an Oracle single-instance database target, or an Oracle Grid Infrastructure target (that may or may not be a part of Oracle Exadata), in out-of-place patching mode, then you can switch back to the original home directly from the Create Plan Wizard—the wizard provides a Switchback button that enables you to perform the operation. However, you cannot perform this operation for any other target type.

Figure 42-5 illustrates how multiple database instances running from an Oracle home get patched in out-of-place patching mode.

Note:

Alternatively, to obtain a new Oracle home that has the required patches, you can provision it directly from a software image (that has the required patches) using provisioning deployment procedures, and then use a patch plan for the analysis and post patching steps. For information on how to do this, see Section 42.4.3.

42.1.6.3 Overview of Patching in Rolling and Parallel Mode

While patching Oracle Real Application Cluster (Oracle RAC) targets, Oracle Grid Infrastructure targets (whether or not they are part of Oracle Exadata), Oracle Data Guard targets, Oracle WebLogic Server targets, Oracle Fusion Application targets, or Oracle SOA Infrastructure targets you can choose to patch the instances of the cluster either in rolling or parallel mode.

Rolling Mode

Rolling Mode refers to the patching methodology where the nodes of the cluster are patched individually, that is, one by one. For example, if you are patching a clusterware target that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node until all the nodes are patched successfully.

Note:

The ReadMe of the patch clearly states whether or not you can use the Rolling Mode to apply your patches. Therefore, use this mode only if it is stated in the ReadMe.

Figure 42-6 illustrates how a two-node Oracle RAC target gets patched when rolling mode is used.

Parallel Mode

Parallel Mode refers to the patching methodology where all the nodes are patched at a time, collectively. In this methodology, all the nodes are shut down and the patch is applied on all of them at the same time.

Figure 42-7 illustrates how a two-node Oracle RAC target gets patched when parallel mode is used.

Figure 42-7 Parallel Mode of Patching

42.1.7 Understanding the Patching Workflow

The following illustration describes the overall workflow of the patch management solution offered through the integrated functionality within the Cloud Control console.

Step	Step Name	Description	Reference Links
Step 1	Set Up Infrastructure	Meet the prerequisites and set up the infrastructure for rolling out patches. Essentially, create admin roles for creating Patch Plans and Patch Templates, meet other mandatory and optional prerequisites, make online or offline patching settings.	Section 42.2, 'Setting Up Infrastructure for Patching'
Step 2	Identify the Patches	View the recommendations made by Oracle on the patches to be applied, and identify the ones you want to apply. Access community information (from innumerous customers).	Section 42.3, 'Identifying Patches to Be Applied'
Step 3	Apply Patches	Create patch plans with patches and associated targets, perform prerequisite checks, analyze the patches for conflicts and resolve the issues, and then save the successfully analyzed plan as a patch template. Then, create a new patch plan out of the patch template and use that to deploy the patches in your environment.	Section 42.4, 'Applying Patches'

42.2 Setting Up Infrastructure for Patching

This section describes how you can set up the infrastructure for patching. Meet these prerequisites before you start rolling out the patches.

This section is mainly for Patch Administrators or Patch Designers who want to keep the infrastructure ready for rolling out patches. This is mostly a one-time task if you have decided on the way (online or offline) you want to patch.

This section covers the following:

42.2.1 Meeting Basic Infrastructure Requirements for Patching

Meet the basic infrastructure requirements as described in Chapter 2. The chapter describes both mandatory and optional requirements.

Note:

If the targets that you want to patch are deployed on Microsoft Windows hosts, you must ensure that Cygwin is installed on the target hosts, before patching the targets.

For information on how to install Cygwin on a host, see Enterprise Manager Cloud Control Basic Installation Guide.

42.2.2 Creating Administrators with the Required Roles for Patching

Table 42-3 describes the roles and the minimum privileges required for using patch plans and patch templates. These roles are default roles available in Cloud Control. You need not create them, but you must explicitly create administrators based on these roles. For instructions, see Section 2.4.

Table 42-3 Roles and Privileges for Using Patch Plans and Patch Templates

Role	Patch Plan Scope	Patch Template Scope	Patch Plan and Patch Templates Privileges	Target Privileges	Resource Privileges	Implementation Recommendation
Patch Administrator	Create, View, Modify, Delete	Create, View, Modify, Delete	FULL_ANY_PATCH_PLAN FULL_ANY_PLAN_TEMPLATE GRANT_PRIV_PATCH_PLAN	Operator any Target (alternatively, you can select a particular target you want to patch and grant operator privilege to it)	Resource Type: deployment procedure Privilege: Create Resource Type: Job System Privilege: Create Resource Type: Software Library Entity Privilege: Manage Any Software Library Entity	Required if you want to create and manage Patch Designer and Patch Operator roles. You can also create these roles directly as a SUPER ADMIN or SYSMAN.
Patch Designer	Create, View	Create, View	FULL_PATCH_PLAN FULL_PLAN_TEMPLATE	- do -	- do -	Required when you want to grant the access and also have restrictions. Alternatively, you can create an EM user with Patch Designer role.
Patch Operator	Create	View	CREATE_PATCH_PLAN VIEW_ANY_PLAN_TEMPLATE	- do -	- do -	- do -

42.2.3 Setting Up Infrastructure for Patching in Online Mode (Connected to MOS)

If you choose to patch your targets when Cloud Control is online, that is, when it is connected to MOS, then meet the following setup requirements:

42.2.3.1Enabling Online Mode for Patching

Note:

• This is the default mode for patching in Cloud Control. Therefore, you do not have to manually set this up the first time. However, if you have set it to Offline mode for a particular reason, and if you want to reset it to Online mode, then follow the steps outlined in this section.

• Cloud Control does not upload any data to MOS. It only uses MOS to download the latest updates.

To patch the targets in Online mode, you must set the connection setting in Cloud Control to Online mode. To do so, log in as a user that has the Patch Administrator role, then follow these steps:

1. From the Setup menu, select Provisioning and Patching, then select Offline Patching.

2. For Connection, select Online.

42.2.3.2 Registering the Proxy Details for My Oracle Support

In Online mode, Cloud Control connects to MOS to download patches, patch sets, ARU seed data such as products, platforms, releases, components, certification details, and patch recommendations. For this purpose, Cloud Control uses the Internet connectivity you have on the OMS host to connect to MOS. However, if you have a proxy server set up in your environment, then you must register the proxy details. You can register the proxy details for MOS using the My Oracle Support Proxy Settings page.

Note:

Beginning with Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3), My Oracle Support accesses support.oracle.com directly. This means that you must provide network access to this URL, or grant proxy access to it from any client that will access My Oracle Support.

To register the proxy details for My Oracle Support (MOS), follow these steps:

1. From the Setup menu, select Proxy Settings, then select My Oracle Support.

2. If you want the OMS to connect to MOS directly, without using a proxy server, follow these steps:

   1. Select No Proxy.

   2. Click Test to test if the OMS can connect to MOS directly.

   3. If the connection is successful, click Apply to save the proxy settings to the repository.

3. If you want the OMS to connect to MOS using a proxy server, follow these steps:

   1. Select Manual proxy configuration.

   2. Specify the proxy server host name for HTTPS and an appropriate port value for Port.

   3. If the specified proxy server has been configured using a security realm, login credentials, or both, select Password/Advanced Setup, then provide values for Realm, User Name, and Password.

   4. Click Test to test if the OMS can connect to MOS using the specified proxy server.

   5. If the connection is successful, click Apply to save the proxy settings to the repository.

Note:

• If you are using a proxy server in your setup, ensure that it allows connectivity to aru-akam.oracle.com, ccr.oracle.com, login.oracle.com, support.oracle.com, and updates.oracle.com.

  NTLM (NT LAN Manager) based Microsoft proxy servers are not supported. If you are using an NTLM based Microsoft proxy server, to enable access to the above sites, add the above URLs to the Unauthenticated Sites Properties of the proxy server.

• The MOS proxy server details specified on the MOS Proxy Settings page apply to all OMSes in a multi-OMS environment.

42.2.4 Setting Up Infrastructure for Patching in Offline Mode (Not Connected to MOS)

If you choose to patch your targets when Cloud Control is offline, that is, when it is not connected to My Oracle Support, then meet the following setup requirements:

42.2.4.1Enabling Offline Mode for Patching

To patch the targets in offline mode, you must set the connection setting in Cloud Control to offline mode. To do so, follow these steps:

1. From the Setup menu, select Provisioning and Patching, then select Offline Patching.

2. For Connection, select Offline.

Note:

Once Cloud Control is running in offline mode, you must download the latest Enterprise Manager catalog file from a host that has internet connectivity, transfer the catalog file to your local host, then upload the catalog file to the Management Repository. For information on how to do this, see Section 42.2.4.2 and Section 42.2.4.3.

42.2.4.2Downloading Enterprise Manager Catalog Zip File From Another Host With Internet Connectivity

In Offline mode, you must use another host that has an Internet connection, and manually download the em_catalog.zip file from My Oracle Support. Use the following URL to download the latest catalog file:

https://updates.oracle.com/download/em_catalog.zip

Information about the targets affected by the latest patches, the patches that you have to download manually, and so on is available in the catalog zip file.

42.2.4.3Uploading Enterprise Manager Catalog Zip File from your Host With No Internet Connectivity

After downloading the catalog zip file as described in the preceding section, ensure that you transfer the latest downloaded em_catalog.zip file back to your local host using FTP or any other file transfer methodology. Then, from your local host, you can log in to Cloud Control to upload the zip file. To do so, follow these steps:

1. From the Setup menu, select Provisioning and Patching, then select Offline Patching.

2. Click Browse to specify the location of the latest em_catalog.zip file.

3. Click Upload to upload the file to the Management Repository.

   On clicking Upload, a Refresh From My Oracle Support job is created and submitted to the Enterprise Manager job system.

42.2.4.4Uploading Patches to Oracle Software Library

For patching targets in offline mode, you must have already stored the patches and their metadata files in Software Library so that they can be searched, selected, and added to the patch plans from Software Library. For this purpose, you must first manually download the patches and their metadata files from My Oracle Support, and then upload them to the Software Library.

This section describes the following:

Downloading a Patch from My Oracle Support

To download a patch and its metadata file from My Oracle Support, follow these steps:

1. Log in to My Oracle Support (https://support.oracle.com/), then click the Patches & Updates tab.

2. On the Patches & Updates page, in the Patch Search section, enter the patch number you want to search for as shown in Figure 42-8, then click Search.

3. On the Patch Simple Search Results page, select the row that has the patch that you want to download. Click Download. In the File Download dialog, click the name of the patch zip file to download it to your local host. Click Download Patch Metadata, and then in the Download Patch Metadata dialog, click Download to download the patch metadata file. This step is described in Figure 42-9.

   Note:

   Oracle recommends that you transfer the patch ZIP file and the metadata XML file to the Management Agent host, where the Management Agent could be an agent on an OMS machine, or on the target host. Upload these files from the Management Agent host to Software Library.

   Figure 42-9 Downloading Patches from My Oracle Support

   
   

Uploading Patches to Software Library Using the Cloud Control Console

Using this method, you can upload only a single patch at a time. Therefore, use this method only when you want to upload a few patches. Also, use this method when the sizes of the patches that you want to upload are small.

To upload a patch to Software Library using the Cloud Control console, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Saved Patches.

2. Click Upload.

3. For Patch Zip File, specify the location of the patch zip file you downloaded onto your local host. If the patch zip file you downloaded contains the PatchSearch.xml file (a file containing patch metadata information such as patch ID, product, platform, language etc.), you do not need to specify a value for Patch Metadata. However, if the patch zip file you downloaded does not contain the PatchSearch.xml file, and you downloaded the patch metadata file onto your local host separately, for Patch Metadata, specify the location of the patch metadata file.

   On a Unix based operating system, run the following command to verify whether the PatchSearch.xml file is contained within a patch zip file:

   unzip -l <patch zip file path> | grep PatchSearch.xml

   For information on how to download the patch metadata file of a patch, refer Section 42.2.4.4.

4. Click Upload to upload the patch to Software Library.

These steps are displayed in Figure 42-10.

Figure 42-10 Uploading a Patch to Software Library

Note:

If you encounter an error mentioning that the patch could not be uploaded as it is too large, either use EM CLI to upload the patch (as described in Section 42.2.4.4), or run the following command, restart the OMS, then retry the patch upload:

emctl set property -name 'oracle.sysman.emSDK.ui.trinidad.uploadedfilemaxdiskspace' -sysman_pwd sysman -value 2589934592

Ensure that the value you specify for -value is in bytes, and is larger than the size of the patch that you want to upload.

Uploading Patches to Software Library Using EM CLI

Using this method, you can perform a batch upload of multiple patches. Also, this method is faster than using the Cloud Control console to upload patches. Hence, use this method when you want to upload multiple patches at one time, or the sizes of the patches that you want to upload are large.

To upload patches to Software Library using EM CLI, follow these steps:

1. Set up EM CLI on the host on which the downloaded patch files that you want to upload are located.

   EM CLI is set up by default on every OMS host. For information on how to set up EM CLI on a host that is not running the OMS, refer the Command Line Interface Concepts and Installation chapter of Oracle Enterprise Manager Command Line Interface.

2. From the EM CLI install location, log in to EM CLI:

   For example,

   <emcli_install_location>/emcli login -username=sysman -password=2benot2be

   Note:

   Ensure that the EM CLI log in user has the ADD_TARGET privilege.

3. Synchronize EM CLI:

4. Run the upload_patches verb to upload the required patches to Software Library:

   The parameters mentioned in [ ] are optional.

   Use the -from_host option to specify the host on which the downloaded patch zip files and metadata files are present. You can use the -location option to specify the location of the downloaded patch files on the host you specified using -from_host. When you specify -location, all the patch zip files and metadata files present at the specified location are uploaded to Software Library. Hence you can use this option to perform a batch upload of multiple patches to Software Library. For example:

   This example uploads all the patch zip files and patch metadata files present at /scratch/aime/patches on the h1.example.com host to Software Library.

   Use the -patch_files option to provide the absolute path of a patch zip file and its patch metadata file. If you use this option, you can specify only one patch zip file. Hence, you can use this option to upload only a single patch at a time. Also, use the -cred_name option to specify the named credentials that must be used to access the specified host, and the -cred_owner option to specify the owner of the specified named credential. If you do not specify the -cred_name option, the preferred normal credentials are used to access the host. If you do not specify the -cred_owner option, the credential owner is assumed to be the current user. For example:

   This example uploads the p13741363_112310_Linux-x86-64.zip patch zip file and the p13741363_112310_Linux-x86-64_M.xml metadata file present on the h1.example.com host to Software Library, using the AIMECRED named credential which is owned by SYSMAN.

   Note:

   Ensure that you specify either the -location option or the -patch_files option with the upload_patches verb, but not both. Specifying the -location option enables you to perform a batch upload of multiple patches, and is hence the recommended option.

   To view more information on the syntax and the usage of the upload_patches verb, run the following command:

42.2.5Analyzing the Environment and Identifying Whether Your Targets Can Be Patched

Before creating a patch plan to patch your targets, Oracle recommends that you view the patchability reports to analyze the environment and identify whether the targets you want to patch are suitable for a patching operation. These reports provide a summary of your patchable and non patchable targets, and help you create deployable patch plans. They identify the problems with the targets that cannot be patched in your setup and provide recommendations for them.

Patchability reports are available for Oracle Database, Oracle WebLogic Server, and Oracle SOA Infrastructure targets.

Note:

To view the patchability report for Oracle Fusion Middleware targets (Oracle WebLogic Server and Oracle SOA Infrastructure targets), the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in must be deployed in your setup.

To view the patchability reports, follow these steps:

1. From the Enterprise menu, select Reports, then select Information Publisher Reports.

2. Click Expand All to view all the branches under Information Publisher Reports.

3. To view the patchability report for Oracle Database targets, under the Deployment and Configuration branch, and the Patching Automation Reports sub branch, select EM Target Patchability Report.

4. To view the patchability report for Oracle Fusion Middleware (Oracle WebLogic Server and Oracle SOA Infrastructure) targets, under the Deployment and Configuration branch, and the Patching Automation Reports sub branch, click EM FMW Target Patchability Report.

Note:

If you see any missing property errors, then resolve the errors using the workarounds described in Section 42.5.1.1. If you see any unsupported configuration errors, then resolve the errors using the workarounds described in Section 42.5.1.2.

42.3 Identifying Patches to Be Applied

This section describes how you can identify the patches to be applied.

This section is mainly for Patch Designers who want to keep track of the various patch releases, look for recommendations from Oracle, and identify the ones they want to roll out in the environment.

This section covers the following:

Download Oracle Patch Using Wget

42.3.1 About Patch Recommendations

Patch recommendations are proactive notifications of potential system issues and recommendations that help you improve system performance and avert outages.

The Patch Recommendations region provides a portal to all recommended patches. From the bar graph, you can drill down to a list of recommended patch, view details about those patches, download the patches, or add them to a patch plan. A bar graph summarizes the number of issues found (one issue = one recommendation for one target).

Patches mentioned in the Patch Recommendation section are a collection of patches offered within MOS which can be applied as a group to one or more targets. To keep the Patch Recommendation section updated with the latest patches for your environment, there is a step called the Config Collection step that runs as a part of the patch plan when a patching job is submitted. Essentially, Config Collection enables to collect the changes that happen due to application of a patch or a rollback. These updates are communicated to the OMS through the Management Agents, which ultimately help in updating the patch recommendation region.

Note:

Starting with Enterprise Manager 12c, the Config Collection that is triggered at the end of patch application happens asynchronously, which means that collection may not complete when the plan completes execution. In such cases, you might need to recalculate the patch recommendations for your enterprise. Also, if the target collection has not happened properly, then too you might have to recalculate the patch recommendations.

To do so, follow these steps:

1. Run the following EM CLI commands to get the target information of a patch plan:

2. Perform the following steps to determine the time when the plan was deployed on the targets:

   1. From Enterprise menu, select Provisioning and Patching, and then click Patches and Updates.

   2. On the Patches and Updates page, from the Plans section, select the patch plan.

   3. From the Create Plan Wizard, select Review and Deploy.

   4. Click the link to the track the details of the deployment.

   5. Note down the start time of the job from the Job UI page.

3. On the Config Management side, use the following attributes to calculate the collection time stamp using MGMT$ECM_CURRENT_SNAPSHOTS view as follows:

   A combination of the start timestamp and last uploaded timestamp attributes help you determine when the collection has happened, and thereby lets you determine if the information available i the patch recommendation region is up-to-date.

The Recommended Patches region appears by default on the Patch & Updates page. You can edit this region to filter its contents.

To view details of a recommended patch, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Patch Recommendations region, click on the bar graph pertaining to the desired patches.

   Note:

   If you do not see the Patch Recommendations region, click Customize Page from the top-right corner, and then drag the Patch Recommendations region to the page.

   Alternatively, click All Recommendations to display all recommendations in the Patch Recommendation page. The Patch Recommendation page displays all the recommendations currently available for the Cloud Control targets.

3. On the Patch Recommendations page, select a recommended patch to view the context menu appears. From the context menu, click Full Screen.

42.3.2About Knowledge Articles for Patching

Knowledge articles are documents published on My Oracle Support. These articles can either be announcements or workarounds to known issues.

Some of the knowledge articles that describe workarounds to known issues have patch numbers mentioned. You can choose to make a note of this patch number and search it on My Oracle Support or Oracle Software Library as described in Section 42.3.4 or Section 42.3.5, respectively.

Alternatively, you can click the patch number in the knowledge article. This takes you to the Patch Search page. On the Patch Search page, from the context menu of the patch, click Add to Plan, and select either Add to New if you want to add the patch to a new patch plan, or Add to Existing if you want to add the patch to an existing patch plan.

42.3.3About Service Requests for Patching

Service requests are support requests raised on My Oracle Support to report and track issues, and receive online assistance from Oracle in resolving those issues.

Some of the service requests that describe workarounds to known issues have patch numbers mentioned. You can choose to make a note of this patch number and search it on My Oracle Support or Oracle Software Library as described in Section 42.3.4 or Section 42.3.5, respectively.

Alternatively, you can click the patch number in the knowledge article. This takes you to the Patch Search page. On the Patch Search page, from the context menu of the patch, click Add to Plan, and select either Add to New if you want to add the patch to a new patch plan, or Add to Existing if you want to add the patch to an existing patch plan.

42.3.4Searching for Patches on My Oracle Support

If you already know about the existence of a patch from external sources such as blogs, Oracle technology forums, or from colleagues, then use the search functionality to search for those patches. The search functionality enables you to perform more flexible and advanced searches, and offers capabilities such as saving a search that is used routinely, and searching based on existing saved searches. All of this lets you perform searches more quickly and efficiently.

To search a patch on My Oracle Support, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Patch Search region, enter the search parameters you want to use and click Search.

   Note:

   If you do not see the Patch Search region, click Customize Page from the top-right corner, and then drag the Patch Search region to the page.

   Alternatively, you can use the Saved tab to search any previously save searches. You can also use the Recent tab to access any recently performed identical (or similar) search.

   Once the patch search is complete, the results appear in the Patch Search Results page. On this page, you can select a patch and download it either to the local host (desktop) or to the Software Library.

Note:

To understand the other ways of searching patches on My Oracle Support, see My Oracle Support Help.

42.3.5Searching for Patches in Oracle Software Library

By default, when you search a patch on the Patches & Updates screen, the Cloud Control connects to My Oracle Support using the Internet connectivity available on that host, and searches the requested patch in My Oracle Support. This is because the search functionality is set to perform in online mode by default.

However, if your host does not have Internet connectivity, then you must switch over to offline mode so that the search can be performed in Oracle Software Library (Software Library).

To switch over to offline mode, follow these steps:

1. From the Setup menu, select Provisioning and Patching, then select Offline Patching.

2. For Connection, select Offline.

Note:

In offline mode, you cannot:

• Search and download patches from My Oracle Support

• Resolve patch conflicts with merge patches

• View the Related Activity region

• Access Quicklinks

• View or create upgrade plans

To search a patch in the Software Library, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Software Library Patch Search region, enter the search parameters you want to use and click Search.

   Note:

   If you do not see the Patch Search region, click Customize Page from the top-right corner, and then drag the Patch Search region to the page.

   Once the patch search is complete, the results appear in the Patch Search Results page.

42.4 Applying Patches

This section describes how you can create a patch plan with patches, save the patch plan as a patch template, create a new patch plan out of that template, and then apply the patches.

This section covers the following:

42.4.1 Creating a Patch Plan

This section is mainly for Patch Designers who want to create patch plans.

To create a patch plan, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, identify the patches you want to apply as described in Section 42.3.

3. On the Patch Recommendations page or on the Patch Search page (depending on how you identified the patch), select a patch you want to add to the Patch Plan.

4. From the context menu, click Add to Plan, and select Add to New.

   Note:

   If you have already created a patch plan, and if you want to add patches to that patch plan, then you can select Add to Existing.

5. In the Create a New Plan window, enter a unique name for your Patch Plan, and click Create Plan.

   The patch you select and the target it is associated with get added to the plan.

   Note:

   • If the patch you selected impacts other targets, then you are prompted to add the impacted targets as well.

   • When you create a Patch Plan, you can add a target that is a member of any system target in Cloud Control. When doing so, the other member targets of that system are automatically added to the Patch Plan. A system is a set of infrastructure components (hosts, databases, application servers, and so on) that work together to host your applications. In Cloud Control, a system and each of the components within it are modeled as individual target types that can be monitored.

   • For Oracle WebLogic Server, if you have deployed the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in, you can add any number of WebLogic domain targets to a single patch plan. If you have not deployed the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in, you can add only a single WebLogic domain target to a single patch plan. For information about how to deploy a new plug-in or upgrade an existing plug-in, see Oracle Enterprise Manager Cloud Control Administrator's Guide.

     If the WebLogic domain target that you add to a patch plan is a shared domain, then all the Administration Servers and the Managed Servers that are running on the domains that are shared with the domain being patched are automatically added into the same patch plan.

   • For Oracle SOA Infrastructure targets, all the SOA WebLogic domains that must be shutdown to patch the SOA targets are added to the patch plan as impacted targets. Therefore, the Administration Server and the Managed Servers running in each of these domains also are affected, and form the Other impacted targets when creating a patch plan.

42.4.2 Accessing the Patch Plan

This section is mainly for Patch Designers who want to access the patch plans they have created.

To access the patch plan you created in Section 42.4.1, use one of the following approaches.

Approach 1: Accessing Patch Plan from Plans Region

To access the patch plan from the Plans region, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, click the Patch Plan you want to view. Alternatively, select the Patch Plan, and in the context menu, click View. The Create Plan Wizard appears.

   To filter the plans table, select All Plan Types or Patch depending on your preference. To search for a plan, enter a plan name or partial plan name in the search box, then click the search button.

   Note:

   • If you do not see the Plans region, click Customize Page from the top-right corner, and then drag the Plans region to the page.

   • To view only the plans that you created, click the icon of a person in the Plans region.

Approach 2: Accessing a Patch Plan from the Patch Recommendations Region

To access the patch plan from the Patch Recommendations region, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Patch Recommendations region, click All Recommendations.

   Note:

   If you do not see the Patch Recommendations region, click Customize Page from the top-right corner, and then drag the Patch Recommendations region to the page.

3. On the Patch Recommendations page, in the table, a patch that is already part of a plan is shown with the plan icon in the In Plan column. Click the icon to display all plans with which the patch is associated, and then click a plan to open the Create Plan Wizard.

42.4.3 Analyzing, Preparing, and Deploying Patch Plans

This section is mainly for Patch Designers who want to analyze the patch plans and deploy them to roll out the patches.

To analyze the patch plan you created in Section 42.4.1 and deploy it (or save it as a patch template), follow these steps:

1. Access the patch plan using one of the approaches described in Section 42.4.2.

   Cloud Control displays the Create Plan Wizard.

2. On the Plan Information page, do the following:

   1. In the Overview section, validate the Patch Plan name. You can choose to edit it if you want.

   2. (Optional) Enter a short description for the patch plan.

   3. (Optional) In the Allow Access For section, click Add to grant patch plan access permissions to administrators or roles, for the current patch plan.

      In the Add Privileges to Administrators window, select an administrator or a role, the access permission that you want to grant, then click Add Privilege.

      Note:

      • From within a patch plan, you can only grant patch plan permissions to administrators or roles that have previously been created in Cloud Control. You cannot create administrators or roles from within a patch plan. For information on the roles and privileges required for patch plans and patch templates, see Section 42.2.2.

      • To remove an administrator or a role, in the Allow Access For section, select the administrator or role that you want to remove, then click Delete.

   4. Click Next.

3. On the Patches page, do the following:

   1. Review the patches added to the patch plan. Any recommended patches for your configuration are automatically added to the patch plan. In addition, any patches that you added manually are listed.

      If you are patching an Oracle Grid Infrastructure target that is part of Oracle Exadata, then you can add one Exadata Bundle Patch, and any number of one-off Grid Infrastructure and Oracle Database patches to a single patch plan, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed. In this scenario, ensure that you add the Exadata Bundle Patch while creating the patch plan, and then add the one-off Grid Infrastructure and Oracle Database patches as additional patches.

      If you do not have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed, then you cannot add one-off patches to a patch plan that already contains an Exadata Bundle Patch.

      If you are patching an Oracle Grid Infrastructure target that is not part of Oracle Exadata, then you can add one Grid Infrastructure Patch Set Update (PSU), and any number of one-off Grid Infrastructure and Oracle Database patches to a single patch plan, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed. In this scenario, ensure that you add the Grid Infrastructure PSU while creating the patch plan, and then add the one-off Grid Infrastructure and Oracle Database patches as additional patches.

      If you do not have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed, then you cannot add one-off patches to a patch plan that already contains a Grid Infrastructure PSU.

      To associate additional targets to a patch that is already in your patch plan, follow the instructions outlined in Section 42.6.7.

      To view the details of a patch, select the patch, then from its context menu, click View. To temporarily remove the patch from analysis and deployment, click Suppress. This leaves the patch in the patch plan, but does not consider it for analysis and deployment.

   2. Click Next.

   Note:

   Patching an Oracle database whose listener was started by a user different from the Oracle database home owner is not supported. To patch such a database, stop the database listener, restart it as the database home owner, then apply the required patch using a patch plan.

4. On the Deployment Options page, do the following:

   1. In the How to Patch section, select the mode of patching that you want to use.

      For standalone (single-instance) database targets, Oracle RAC targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata), you can choose between in-place patching and out-of-place patching. Out-of-place patching is available for Oracle RAC targets and Oracle Grid Infrastructure targets that are not a part of Oracle Exadata, only if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed. Out-of-place patching is available for Oracle Data Guard targets only if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed.

      For Oracle WebLogic Server, Oracle Fusion Applications, and Oracle SOA Infrastructure targets, the only patching mechanism offered is in-place patching. Out-of-place patching is not offered for these targets. For more information on in-place and out-of-place patching, see Section 42.1.6.2.

      If you want to clone the existing Oracle home of the database and patch the cloned Oracle home instead of the original Oracle home, select Out of Place. If you want to patch the existing original Oracle home of the target directly, without cloning the original Oracle home, select In Place.

      Also, you can choose to patch Oracle RAC targets, Oracle Grid Infrastructure targets (whether or not they are part of Oracle Exadata), Oracle Data Guard targets, Oracle WebLogic Server targets, Oracle Fusion Application targets, and Oracle SOA Infrastructure targets in rolling mode, or in parallel mode. For more information on patching targets in rolling mode and parallel mode, see Section 42.1.6.3.

      If you want to patch a single node of the target at a time, select Rolling. It is the default option, and it involves very little downtime. While patching your targets in rolling mode, you can choose to pause the execution of the patching deployment procedure after each node is patched. For information on how to do so, see Section 42.6.13.

      If you want to patch all the nodes of the target simultaneously, select Parallel. It involves downtime, as your entire system is shut down for a significant period. However, this process consumes less time, as all the target nodes are patched simultaneously.

   2. (Appears only for standalone database targets, Oracle RAC targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets) In the What to Patch section, do the following:

      If you have selected in-place patching, then review the details of the Oracle homes that will be patched. By default, all of the database instances are migrated.

      If you have selected out-of-place patching, then click Create New Location against the Oracle home that you want to clone, then enter the path to a location that is empty and has write permission. You can clone the Oracle home to any directory on the host where the target is being patched. After providing a location, if you want to change it, click Edit.

      For standalone database targets, Oracle RAC targets, Oracle Data Guard targets, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata), you have the option of migrating either all, or only some of the database instances created from the specified Oracle home. Select the ones that you want to migrate.

      Note:

      • After the cloned Oracle home is patched, and after the database instances are migrated to the cloned Oracle home, you can choose to retain the original Oracle home, or delete it if there are no other targets running from that Oracle home.

      • If the cloned home contains certain additional patches (that are not added to the patch plan) that include SQL statements, the SQL statements for these patches are not executed automatically when the database instance is migrated to the cloned home. For these patches, you must execute the SQL statements manually.

   3. In the Where to Stage section, do the following:

      In the Stage Patches section, select Yes for Stage Patches if you want the wizard to stage the patches from Software Library to a temporary location, before the patch is applied on the target. Specify the stage location. Select No for Stage Patches if you have already manually staged the patches that you want to apply. To manually stage a patch, download the patch, navigate to the location (parent directory) where you want to stage the patch, create a subdirectory with the same name as the patch zip file, then extract the contents of the patch zip file into this subdirectory. Specify the parent directory for Stage Location. If the stage location is a shared location, select Shared Location.

      For example, if you downloaded patch 699099.zip, and the stage location, which is the parent directory, is /u01/app/oracle/em/stagepatch, then, in this parent directory, create a subdirectory titled 699099 and extract the contents of the zip file. Specify /u01/app/oracle/em/stagepatch as the stage location.

      Important:

      If you are patching a WebLogic Server 10.3.6 target, or an earlier version, and you provide a custom stage location, the location you provide is disregarded, and the selected patches are staged to the default directory configured with SmartUpdate (which is <WEBLOGIC_HOME>/utils/bsu/cache_dir).

      In the Stage Root Component section, specify whether or not you want the wizard to stage the patching root component. The root component is a set of perl scripts (which are a part of the directive steps of deployment procedures) which requires root privileges for execution. The root component is required for patching Oracle database targets.

      Select Yes for Stage Root Component, then specify the location where you want the root component to be staged (the patch dispatcher location), if you want the wizard to stage the root component. root_dispatcher.sh and patching_root_dispatcher.sh are copied to this location. However, if you have already staged the root component, select No for Stage Root Component, then specify the location where you staged the root component, that is, the patch dispatcher location. If the patch dispatcher location is shared, select Dispatcher Location Shared.

      For information on how to stage the patching root component manually, see Section 42.6.8.

   4. In the Credential Information section, provide the required credentials. You can choose to use preferred credentials, or override them with different credentials.

      For patching Oracle WebLogic Server targets and Oracle SOA Infrastructure targets, you need the following sets of credentials:

      - Oracle WebLogic Domain Administrator Credentials: These credentials are required to connect to the Admin Server of the domain which monitors all the Managed Servers present in that domain.

      - Oracle WebLogic Server Home Credentials: These credentials are required to connect to all the Oracle homes present on different hosts.

      You can also choose to override the existing credentials by selecting Override Preferred WebLogic Domain Administrator Credentials and Override Preferred WebLogic Home Credentials. However, if you choose to override the preferred credentials, then you must validate the credentials. For Oracle WebLogic Server targets, you can validate only the Oracle WebLogic Server Home credentials, and not the administrator credentials.

      Note:

      The validation of credentials fails when the Management Agent is down, or when the credentials are incorrect.

      In Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4), normal Oracle home credentials are not required for patching secure Management Agent targets. If the patches that you want to apply on the Management Agent targets require root user access to perform certain tasks, then you must provide the privileged Oracle home credentials for the Management Agent targets.

      If the Management Agent targets that you want to patch are not secure, then you must set the preferred Management Agent host credentials for all the Management Agent targets that you want to patch. To set the preferred host credentials for Management Agent targets, from the Setup menu, select Security, then select Preferred Credentials. Select the Agent target type, then click Manage Preferred Credentials. Set the preferred host credentials for the required Management Agent targets.

   5. (Optional) Use the Customization section to customize the default deployment procedure used by the patch plan, and use the customized deployment procedure to patch your targets.

      By default, a patch plan uses a static, Oracle-supplied deployment procedure, or an OPlan based, dynamically generated deployment procedure to apply patches.

      Note:

      OPlan is an independent tool that creates and executes dynamic deployment procedures to patch your targets. It supports the patching of Oracle Database targets of version 11.2.0.2.0 and above deployed on the Linux x64, Solaris x64, Solaris SPARC, and AIX platforms.

      If you have the Enterprise Manager for Oracle Database 12.1.0.6 plug-in (or a higher version) deployed in your system, dynamically generated deployment procedures are used to patch Grid Infrastructure targets (those that are a part of Oracle Exadata, as well as those that are not a part of Oracle Exadata), Oracle RAC database targets, and Oracle Data Guard targets, in both, the in-place and out-of-place patching modes. However, if you do not have the Enterprise Manager for Oracle Database 12.1.0.6 plug-in deployed in your system, dynamically generated deployment procedures are only used to patch Grid Infrastructure targets (those that are a part of Oracle Exadata, as well as those that are not a part of Oracle Exadata) and Oracle RAC database targets in out-of-place patching mode. Static deployment procedures are used in all other patching operations. You can choose to customize both these types of deployment procedures, and use the customized deployment procedure to patch your targets.

      If the patching procedure consists of a static deployment procedure, click Create Like and Edit to customize the default deployment procedure. To use a customized deployment procedure, select the customized procedure from the list displayed in the Customization section of the Deployment Options page. For more information, see Section 42.6.12.1.

      If the patching procedure consists of a dynamically generated deployment procedure based on OPlan, select Specify custom steps to be added to generated patching deployment procedure, then edit the deployment procedure. For information on how to edit the dynamically generated deployment procedure, see Section 42.6.12.2.

      If you are patching Oracle WebLogic Server or Oracle SOA Infrastructure targets, you can set a timeout value after which the server is forcefully shut down, if it was not shut down by default. By default, the shutdown time is 30 minutes. You can change this by entering a value in the Timeout for Shutdown(in minutes) field. Oracle recommends that you set a timeout value, and ensure that it is based on monitoring of real time systems. If the SOA Infrastructure patch that you are applying involves SQL application functionality, then you must provide the absolute path to the SQL scripts used, in the Post-Install SQL Script Metadata field. For information about the SQL script location, refer to the respective readme documents of each patch. Ensure that the SQL scripts that you provide are JDBC-compliant.

      To patch SOA Infrastructure targets that are running on a Windows host, ensure that you use the %FMW_ORACLE_HOME% environment variable to provide a relative path to the SQL files present in the SOA patch, as displayed in the following graphic:

      
      

      Providing an absolute path, or using the %ORACLE_HOME% environment variable will result in an error. Also, before patching SOA Infrastructure targets that are running on a Windows host, ensure that you shut down all the servers running from the SOA instance home being patched. Stopping just the SOA servers running out of the SOA instance home will result in an error.

   6. In the Notification section, specify whether or not you want to enable email notifications when the patch plan is scheduled, starts, requires action, is suspended, succeeds, and fails.

      To enable email notifications, select Receive notification emails when the patching process, then select the required options. If a warning message, mentioning that the sender or the receiver email address is not set up, is displayed, perform the action mentioned in the warning.

   7. In the Rollback section, select Rollback patches in the plan to roll back the patches listed in the plan, rather than deploy them.

      The roll back operation is supported only for Management Agent, Oracle WebLogic Server, Oracle SOA Infrastructure, Oracle Restart, single-instance Oracle database, Oracle RAC database, Oracle Grid Infrastructure, and Oracle Grid Infrastructure targets that are part of Oracle Exadata.

      For more information on how to roll back a patch, see Section 42.6.14.

      Note:

      • For Oracle WebLogic Server targets, patching and rollback happens at domain level. When Oracle WebLogic Server targets are selected for rollback, the domain along with the Administration Server and the Managed Servers are rolled back. You cannot select the instances you want to rollback, and deselect the ones you do not want to rollback from the domain.

      • For SOA Infrastructure targets, patching and rollback happens at instance home level, which means, you can select the SOA Oracle home instances that you want to patch or from where you want to rollback the existing patches. If there are other servers running from the SOA home being rolled back, then all of these servers and their corresponding domains will also be rolled back along with the SQL metadata scripts that can be rolled back. Some of the SQL metadata scripts cannot be rolled back, in which case, Cloud Control will rollback the patch (bits in the Oracle Home) but the SQL remains unchanged.

        While patching a SOA setup, if the patch application fails on one of the Managed Servers, and succeeds on other Managed Servers, there will not be an automatic rollback operation to remove the patch from all Managed Servers where the patch was successfully applied. However, you will be notified about the failure, so you can manually rollback the patch.

      Typically, you will rollback a patch for the following reasons:

      - If you had forcefully applied an incoming patch that conflicted with a patch in the Oracle home, and now you want to uninstall that applied patch.

      - If the applied patch does not meet your requirements satisfactorily; the patch might have fixed a bug, but at the same time, introduced other bugs in the process.

   8. In the Conflict Check section, specify whether you want to enable or disable ARU Conflict Check, a check that uses Oracle Automated Release Updates (ARU) to search for patch conflicts within the patch plan during the analysis stage. Also, specify the action that the patching procedure must take when a patch conflict is encountered during deployment.

      For Conflicts, select Stop at Conflicts if you want the patching procedure to stop the deployment of the plan when a conflict is encountered, select Force Apply if you want the patching procedure to roll back the conflicting patches and apply the incoming patches when a conflict is encountered, or select Skip conflicts if you want the patching procedure to apply only the non-conflicting patches, and skip the application of the conflicting patches, when a conflict is encountered.

   9. Click Next.

5. On the Validation page, click Analyze to check for conflicts. For information about what checks are performed in the validation screen, see Section 42.1.3.3.

6. On the Review & Deploy page, review the details and do one of the following:

   • If you are patching your database targets in out-of-place patching mode, then click Prepare. This operation essentially clones the source Oracle home, and patches it. While this happens, the source Oracle home and the database instances are up and running.

     Once you click Prepare, a Deploy Confirmation dialog box appears, which enables you to schedule the Prepare operation. Select Prepare. If you want to begin the Prepare operation immediately, select Immediately. If you want to schedule the Prepare operation such that it begins at a later time, select Later, then specify the time. Click Submit.

     After the Prepare operation is successful, click Deploy. This operation essentially switches the database instances from the source Oracle home to the cloned and patched Oracle home. The Prepare and Deploy operations enable you to minimize downtime.

     Once you click Deploy, a Deploy Confirmation dialog box appears, which enables you to schedule the Deploy operation. Select Deploy. If you want to begin the Deploy operation immediately, select Immediately. If you want to schedule the Deploy operation such that it begins at a later time, select Later, then specify the time. Click Submit.

     Note:

     Instead of patching your Oracle homes in out-of-place patching mode, you can provision an Oracle home directly from a software image stored in Software Library (that has the required patches). To do this, follow these steps:

     1. Use the Provision Oracle Database deployment procedure to provision the software image stored in Software Library to the required location on the host.

     2. Create a patch plan. Ensure that you add all the patches that are a part of the provisioned Oracle home to this plan.

     3. On the Deployment Options page, in the What to Patch section, specify the location of the provisioned Oracle home.

     4. Analyze and deploy the plan.

        The database instance is switched from the old Oracle home to the newly provisioned Oracle home, and the post patching steps are performed.

   • If you are patching any other target in any other mode, click Deploy.

     Once you click Deploy, a Deploy Confirmation dialog box appears, which enables you to schedule the Deploy operation. Select Deploy. If you want to begin the Deploy operation immediately, select Immediately. If you want to schedule the Deploy operation such that it begins at a later time, select Later, then specify the time. Click Submit.

   Note:

   • After scheduling a Prepare or Deploy operation, the Prepare or Deploy button on the Review and Deploy page is renamed to Reschedule. If you want to reschedule the Prepare or Deploy operation, click Reschedule, specify the time, then click Submit.

   • After scheduling a Prepare or Deploy operation, if you want to discard the schedule and bring the patch plan back to its last valid state, click Stop Schedule.

   • The Prepare or Deploy operation schedule is discarded if you edit a patch plan deployment option or patch target. In this case, you must validate the patch plan again.

   Many patching operations use OPlan, an independent tool that creates and executes dynamic deployment procedures to patch your targets. The OPlan readme file for a patch plan contains detailed information about the step wise execution of the patch plan. If you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in deployed, you can view this file. To view this file, on the Review & Deploy page, click the Download link present beside Patching Steps.

Note:

To save a successfully analyzed or deployed patch plan as a patch template, see Section 42.4.5.

42.4.4 Switching Back to the Original Oracle Home After Deploying a Patch Plan

If you had patched an Oracle RAC target, Oracle single-instance database target, or an Oracle Grid Infrastructure target (that may or may not be a part of Oracle Exadata), in out-of-place patching mode, and you now want to switch back to the original home for some reason, then you can use the Switchback option available in the Create Plan Wizard. The advantage of using this option is that you do not actually roll back the patches from the cloned and patched Oracle home; you only switch back to the old, original Oracle home that exists without the patches.

Note:

• The Switchback option is available only for Oracle RAC, Oracle single-instance database, and Oracle Grid Infrastructure targets (that may or may not be a part of Oracle Exadata), and only when these targets are patched in out-of-place patching mode.

• You can switch back only if you have successfully analyzed and deployed a patch plan.

To switch back to the original Oracle home after a patch plan is deployed, follow these steps:

Wget Download Https

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, click the successfully analyzed and deployed patch plan you used for patching the Oracle RAC, Oracle single-instance database, or Oracle Grid Infrastructure targets. Alternatively, select the patch plan, and in the context menu, click View. The Create Plan Wizard appears.

3. In the Create Plan Wizard, on the Review & Deploy page, click Switchback.

42.4.5Saving Successfully Analyzed or Deployed Patch Plan As a Patch Template

This section is mainly for Patch Designers who want to save the successfully analyzed or deployed patch plans as patch templates so that operators can consume them to create fresh patch plans with the approved patches and predefined deployment options.

To save a patch plan as a patch template, follow Step (1) to Step (5) as outlined in Section 42.4.3, and then for Step (6), on the Review & Deploy page, click Save as Template. In the Create New Plan Template dialog, enter a unique name for the patch template, and click Create Template.

Oracle recommends you to follow this as a best practice if you have to roll out in a mass scale over a period of time involving more administrators. If you have a large data center, then as a Patch Designer, create a patch plan and apply the patches on a few databases, test if the patches are being applied successfully, then save the plan as a template. Later, have your Patch Operators create patch plans out of these templates so that they can roll out the same set of patches to the rest of the databases in the data center.

42.4.6 Creating a Patch Plan from a Patch Template and Applying Patches

Once a successfully analyzed or deployed patch plan is saved as a patch template, you can create patch plans out of the template, associate targets you want to patch, and deploy the newly created patch plan.

This is purely an optional step. You do not have to save your patch plans as patch templates to roll out patches. You can roll out patches directly from a patch plan as described in Section 42.4.3.

This section is mainly for Patch Operators who want to create patch plans from patch templates for rolling out the patches.

Approach 1

To create patch plans out of the patch templates, use one of the following approaches:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, select the patch template you want to use to create a patch plan out of it.

3. From the context menu, select Create Plan.

4. In the Create Plan from Template dialog, enter a unique name for the patch plan, select the targets on which you want to patch, and click Create Plan.

5. Return to the Patches & Updates page, and in the Plans region, click the patch plan you want to use. Alternatively, select the patch plan, and in the context menu, click View. The Create Plan Wizard appears.

6. In the Create Plan Wizard, go to the Validation page, and click Re-Analyze to analyze the patch plan with the newly associated targets.

7. After successfully analyzing the patch plan, on the Validation page, click Next.

8. On the Review & Deploy page, click Deploy.

Approach 2

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, do one of the following:

   • Select a patch template. From the context menu, select View. The Edit Template Wizard appears.

   • Click the name of a patch template. The Edit Template Wizard appears.

3. In the Edit Template Wizard, click Create Plan.

4. In the Create Plan from Template dialog, enter a unique name for the patch plan, select the targets on which you want to patch, and click Create Plan.

5. Return to the Patches & Updates page, and in the Plans region, click the patch plan you want to use. Alternatively, select the patch plan, and in the context menu, click View. The Create Plan Wizard appears.

6. In the Create Plan Wizard, go to the Validation page, and click Re-Analyze to analyze the patch plan with the newly associated targets.

7. After successfully analyzing the patch plan, on the Validation page, click Next.

8. On the Review & Deploy page, click Deploy.

42.4.7Patching Oracle Grid Infrastructure Targets

You can patch Oracle Grid Infrastructure targets using patch plans. To do so, follow these steps:

1. Identify the Oracle Grid Infrastructure Patch Set Update (PSU) or one-off patches that you want to apply, as described in Section 42.3.

2. Create a patch plan as described in Section 42.4.1.

3. Analyze and deploy the patch plan as described in Section 42.4.3.

   Important:

   • You can add one Grid Infrastructure PSU, and any number of one-off Grid Infrastructure and Oracle Database patches to a single patch plan, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed. In this scenario, ensure that you add the Grid Infrastructure PSU while creating the patch plan, and then add the one-off Grid Infrastructure and Oracle Database patches as additional patches.

     If you do not have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed, then you cannot add one-off patches to a patch plan that already contains a Grid Infrastructure PSU.

   • You can apply a Grid Infrastructure PSU on a Grid Infrastructure target when the RAC databases being managed are of different versions, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed. If you do not have this plug-in deployed, and the RAC databases being managed are of different versions, then you cannot apply a Grid Infrastructure PSU on the Grid Infrastructure target.

     For example, if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed, and a Grid Infrastructure target consists of Grid Infrastructure of version 11.2.0.3, and manages RAC databases of versions 11.2.0.2 and 11.2.0.3, you can apply a 11.2.0.3 Grid Infrastructure PSU on the Grid Infrastructure target. In this case, the Grid Infrastructure binaries and the 11.2.0.3 RAC databases are patched, but not the 11.2.0.2 RAC databases. You can also apply a 11.2.0.2 Grid Infrastructure PSU on the Grid Infrastructure target. In this case, the 11.2.0.2 RAC databases are patched, but not the Grid Infrastructure binaries and the 11.2.0.3 RAC databases.

42.4.8Patching Oracle Exadata

Using patch plans, you can patch the Oracle RAC database targets and the Oracle Grid Infrastructure targets (Oracle Clusterware) running on an Exadata Database Machine.

Exadata Patching can be performed in two modes: In Place Patching, and Out-of-place Patching, though Oracle recommends you to use the Out-of-place patching mechanism as the downtime involved is much lesser.

For information about the supported Exadata releases, see Section 42.1.5.

However, note that patch plans do not patch the Exadata Database Machine's compute node entities such as the operating system and firmware, and also its storage cells. They patch only the associated Oracle RAC database targets and the Oracle Grid Infrastructure (Oracle Clusterware) targets running on the machine.

Note:

Oracle Exadata Database Machine recommended bundle patches that apply to Oracle RAC and the Oracle Grid Infrastructure targets (Oracle Clusterware) are tested and certified with Cloud Control.

Therefore, when you create a patch plan with an Exadata Database Machine recommended bundle patch, make sure you add the cluster or the Oracle RAC database target running on the Exadata Database machine. The patch plan automatically recognizes their association with the Exadata Database machine, and prompts you to add all the impacted targets running on that machine. For example, if you select the cluster target, it prompts you to add all the Oracle RAC database targets and the Oracle Grid Infrastructure targets that are part of that cluster running on the Exadata Database Machine.

To patch an Exadata Database machine, follow these steps:

1. Identify the Exadata Database Machine recommended bundle patch you need to apply, as described in Section 42.3.

2. Create a patch plan as described in Section 42.4.1.

3. Add the cluster or the Oracle RAC database target running on the Exadata Database machine, and analyze and deploy the patch plan as described in Section 42.4.3.

   The following illustrate how you can add an Exadata Database Machine recommended bundle patch to a new patch plan, select a cluster target, and all the other associated Oracle RAC database targets and Oracle Grid Infrastructure targets.

   Figure 42-11 Adding Exadata Database Machine Bundle Patch to a Patch Plan

   
   

   Important:

   • You can add one Exadata Bundle Patch, and any number of one-off Grid Infrastructure and Oracle Database patches to a single patch plan, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed. In this scenario, ensure that you add the Exadata Bundle Patch while creating the patch plan, and then add the one-off Grid Infrastructure and Oracle Database patches as additional patches.

     If you do not have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed, then you cannot add one-off patches to a patch plan that already contains an Exadata Bundle Patch.

   • You can apply an Exadata Bundle Patch on a Grid Infrastructure target (that is a part of Oracle Exadata) when the RAC databases being managed are of different versions, as long as you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed. If you do not have this plug-in deployed, and the RAC databases being managed are of different versions, then you cannot apply an Exadata Bundle Patch on the Grid Infrastructure target.

     For example, if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed, and a Grid Infrastructure target (that is a part of Oracle Exadata) consists of Grid Infrastructure of version 11.2.0.3, and manages RAC databases of versions 11.2.0.2 and 11.2.0.3, you can apply a 11.2.0.3 Exadata Bundle Patch on the Grid Infrastructure target. In this case, the Grid Infrastructure binaries and the 11.2.0.3 RAC databases are patched, but not the 11.2.0.2 RAC databases. You can also apply a 11.2.0.2 Exadata Bundle Patch on the Grid Infrastructure target. In this case, the 11.2.0.2 RAC databases are patched, but not the Grid Infrastructure binaries and the 11.2.0.3 RAC databases.

Exadata Out-Of-Place Patching Of Oracle Grid Infrastructure and Oracle RAC Targets

Exadata Out-of-place patching mechanism allows you patch the Oracle Grid Infrastructure and Oracle RAC targets by making a copy of their existing Oracle homes, and patching the cloned Oracle homes. Once the cloned homes are patched, you can migrate the instances to run from the cloned home, which means there will be minimal downtime while switching over the instances, but not a significant downtime.

Figure 42-12 illustrates how Oracle Grid Infrastructure and Oracle RAC targets running on an Exadata Database Machine get patched in Out-of-place patching mode:

The migration of these instances can be performed in the following modes:

• Full Migration: If you choose the migrate all the database instances running in your data center in one session, then it is termed as Full Migration.

• Partial Migration: If you choose to migrate only some of the instances depending on the downtime you can afford in your data center in one session, then it is termed as Partial Migration. However, you must ensure that you migrate the remaining instances in the following sessions. This approach is particularly useful when you have multiple instances running out of an Oracle home.

Note:

for steps on how to perform Full Migration or Partial Migration of Oracle Grid Infrastructure Targets and Oracle RAC Targets running on Exadata Database Machine, see Section 42.4.3.

Switch Back is an option available for Oracle Grid Infrastructure targets and Oracle RAC targets running on Exadata machine, that enables you to switch the instances from the newly cloned Oracle homes back to the original Oracle homes in case of any problems.

For more information on how to perform a Switch Back, see Section 42.4.4.

42.4.9Patching Oracle Data Guard Targets

This section describes how to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU on various configurations of Oracle Data Guard targets. You can choose to patch your Oracle Data Guard targets in the in-place patching mode, or the out-of-place patching mode.

It consists of the following sections:

42.4.9.1 Oracle Data Guard Patching Workflow

If the primary and the standby databases are running from the same cluster, follow these steps:

1. Search for the required patch, then create a patch plan by selecting the cluster target.

2. Specify the required deployment options.

3. Analyze and deploy the plan.

However, if the primary and the standby databases are running from different clusters, follow these steps:

1. Search for the required patch, then create a patch plan by selecting the cluster target that contains the standby database.

2. Specify the required deployment options.

3. Analyze and deploy the plan.

4. (Optional) Perform a database switchover, such that the standby database becomes the new primary database, and vice versa. Performing a switchover can save database downtime.

   For information on how to perform a database switchover, see Oracle® Data Guard Broker.

5. Search for the required patch, then create another patch plan by selecting the cluster target that contains the primary database (or the new standby database, in case you have performed a switchover).

6. Specify the required deployment options.

7. Analyze and deploy the plan.

Important:

• Oracle recommends that you patch the standby database first, then patch the primary database.

• If your environment consists of multiple standby databases, ensure that you patch all the standby databases first, then patch the primary database. In case you want to perform a switchover, ensure that you patch a single standby database first, perform the switchover, then patch the remaining standby databases and the new standby database.

42.4.9.2 Oracle Data Guard Patching Scenarios

This section describes the steps to patch your Oracle Data Guard targets in various scenarios.

Scenario 1: The primary and standby databases are RAC databases.

Table 42-4 describes the steps to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU, when the primary and standby databases are RAC databases:

Table 42-4 Oracle Data Guard Patching (RAC - RAC)

Primary and Standby Database Configuration	How to Patch?
The primary and the standby RAC databases are running from the same cluster.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target. Specify the required deployment options. Analyze and deploy the plan.
The primary and the standby RAC databases are running from different clusters.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target that contains the standby RAC database. Specify the required deployment options. Analyze and deploy the plan. (Optional) Perform a database switchover, such that the standby RAC database becomes the new primary database, and vice versa. For information on how to perform a database switchover, see Oracle® Data Guard Broker. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the cluster target that contains the primary RAC database (or the new standby database, in case you have performed a switchover). Specify the required deployment options. Analyze and deploy the plan.
Two primary RAC databases, P1 and P2, are running from two different clusters, C1 and C2, respectively. Their standby RAC databases, S1 and S2, are running from C2 and C1, respectively.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the first cluster target (C1). Specify the required deployment options. Analyze and deploy the plan. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the second cluster target (C2). Specify the required deployment options. Analyze and deploy the plan. Note: You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1.

Scenario 2: The primary database is a RAC database, and the standby database is a single-instance database that is managed by a Cluster Ready Services (CRS) target or a Single Instance High Availability (SIHA) target.

Table 42-5 describes the steps to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU, when the primary database is a RAC database, and the standby database is a single-instance database that is managed by a CRS target or a SIHA target.

Table 42-5 Oracle Data Guard Patching (RAC - SIDB)

Primary and Standby Database Configuration	How to Patch?
The primary RAC database and the standby single-instance database are running from the same cluster.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target. Specify the required deployment options. Analyze and deploy the plan.
The primary RAC database and the standby single-instance database are running from different clusters.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target that contains the standby single-instance database. Specify the required deployment options. Analyze and deploy the plan. (Optional) Perform a database switchover, such that the standby single-instance database becomes the new primary database, and vice versa. For information on how to perform a database switchover, see Oracle® Data Guard Broker. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the cluster target that contains the primary RAC database (or the new standby database, in case you have performed a switchover). Specify the required deployment options. Analyze and deploy the plan.
Two primary RAC databases, P1 and P2, are running from two different clusters, C1 and C2, respectively. Their standby single-instance databases, S1 and S2, are running from C2 and C1, respectively.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the first cluster target (C1). Specify the required deployment options. Analyze and deploy the plan. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the second cluster target (C2). Specify the required deployment options. Analyze and deploy the plan. Note: You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1.

Scenario 3: The primary and standby databases are single-instance databases that are managed by CRS or SIHA targets.

Table 42-6 describes the steps to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU, when the primary and standby databases are single-instance databases that are managed by CRS or SIHA targets.

Table 42-6 Oracle Data Guard Patching (SIDB - SIDB)

Primary and Standby Database Configuration	How to Patch?
The primary and the standby single-instance databases are running from the same cluster.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target. Specify the required deployment options. Analyze and deploy the plan.
The primary and the standby single-instance databases are running from different clusters.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the cluster target that contains the standby single-instance database. Specify the required deployment options. Analyze and deploy the plan. (Optional) Perform a database switchover, such that the standby single-instance database becomes the new primary database, and vice versa. For information on how to perform a database switchover, see Oracle® Data Guard Broker. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the cluster target that contains the primary single-instance database (or the new standby database, in case you have performed a switchover). Specify the required deployment options. Analyze and deploy the plan.
Two primary single-instance databases, P1 and P2, are running from two different clusters, C1 and C2, respectively. Their standby single-instance databases, S1 and S2, are running from C2 and C1, respectively.	Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the first cluster target (C1). Specify the required deployment options. Analyze and deploy the plan. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the second cluster target (C2). Specify the required deployment options. Analyze and deploy the plan. Note: You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1.

Scenario 4: A primary RAC database, P1, and a primary single-instance database, P2 (that is managed by a CRS or a SIHA target), are running from two different clusters, C1 and C2, respectively. Their standby single-instance databases, S1 and S2, that are managed by CRS or SIHA targets, are running from C2 and C1, respectively.

Follow these steps to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU on this configuration:

1. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create a patch plan by selecting the first cluster target (C1).

2. Specify the required deployment options.

3. Analyze and deploy the plan.

4. Search for the required Oracle Grid Infrastructure PSU, or the Oracle Database PSU, then create another patch plan by selecting the second cluster target (C2).

5. Specify the required deployment options.

6. Analyze and deploy the plan.

Note:

You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1.

42.4.10Patching Oracle Identity Management Targets

Using patch plans, you can patch those Oracle Access Management Server and Oracle Identity Management Server targets that were provisioned using Identity Management Lifecycle tools. Other Oracle Identity Management targets are not supported for patching.

To patch Oracle Access Management Server and Oracle Identity Management Server targets (that were provisioned using Identity Management Lifecycle tools) using patch plans, you must have an Identity Management Pack Plus license. Also, the 12.1.0.6 Enterprise Manager for Oracle Fusion Middleware plug-in must be deployed on the OMS, and on all the Management Agents running on the hosts on which the Oracle Access Management Server and Oracle Identity Management Server targets are deployed.

To patch Oracle Access Management Server and Oracle Identity Management Server targets using a patch plan, follow these steps:

1. Identify the patches that you want to apply, as described in Section 42.3.

2. Create a patch plan, as described in Section 42.4.1.

3. Analyze and deploy the patch plan, as described in Section 42.4.3.

42.4.11Patching Oracle Siebel Targets

Using patch plans, you can patch Siebel Gateway Server and Siebel Server targets. Other Oracle Siebel targets are not supported for patching. To patch Siebel Gateway Server and Siebel Server targets, you must have the 12.1.0.5 Enterprise Manager for Oracle Siebel plug-in deployed in your system.

To patch Siebel Gateway Server and Siebel Server targets using a patch plan, follow these steps:

1. Identify the patches that you want to apply, as described in Section 42.3.

2. Create a patch plan, as described in Section 42.4.1.

3. Analyze and deploy the patch plan, as described in Section 42.4.3.

42.5Diagnosing and Resolving Patching Issues

This section describes the following:

42.5.1 Workarounds for Target Related Errors

This section describes the workarounds for target related errors, and consists of the following:

42.5.1.1 Workarounds for Missing Property Errors

Table 42-7 describes the possible missing property errors and the workarounds you can use to resolve them.

Table 42-7 Missing Properties Error and Workarounds

Problem	Workaround
Empty target property version	The target is not properly configured or maybe the target is unavailable. Reconfigure the target or check for metric collection errors.
Inadequate or incomplete target information collected by Oracle Management Agent.	To resolve this issue, recompute the dynamic properties and refresh the host configuration so that the Management Repository is updated with the latest configuration of the host. To do so, follow these steps: To recompute the dynamic properties, do one of the following: Option A: Stop and restart the Management Agent. This option is simpler because you do not have to understand the target model. $ emctl stop agent $ emctl start agent For a cluster, restart the Management Agent on all the nodes of the cluster. Option B: Reload the dynamic properties of all the targets. This option is better because there is no blackout or downtime for monitoring. To view the list of targets that are monitored by the Management Agent, run the following command: $ emctl config agent listtargets To reload the dynamic properties of a specific target, run the following command: $ emctl reload agent dynamicproperties [<Target_name>:<Target_Type>] For example: $ emctl reload agent dynamicproperties oradb:oracle_database $ emctl reload agent dynamic properties racdb_1:rac_database $ emctl reload agent dynamicproperties crs:cluster $ emctl reload agent dynamic properties wls:weblogic_j2eeserver $ emctl reload agent dynamicproperties server1.xyz.com:host To update the Management Repository with the latest configuration information, from the Enterprise menu, select Configuration, and then select Refresh Host Configuration. On the Refresh Host Configuration page, select the hosts for which the configuration must be updated, and click Refresh Hosts.
Targets are not properly discovered because of inadequate or incomplete target information collected during discovery.	To resolve this issue, rediscover the domain so that all the targets in the domain are discovered effectively. To do so, follow these steps: Log in to the Domain Home page using appropriate credentials. For example, Farm01_base_domain. On the (Farm01_base_domain) home page, from the Farm menu, select Refresh WebLogic Domain, and click Ok on all the following pages to complete the process. After successful completion of the process the domain home page is refreshed to discover all the targets afresh.

42.5.1.2 Workarounds for Unsupported Configuration Errors

Table 42-8 describes the possible unsupported configuration errors and the workarounds you can use to resolve them.

Table 42-8 Workarounds for Unsupported Configuration Errors

Problem	Workarounds
Oracle RAC Instance does not have an associated Oracle RAC Database	Rediscover the Oracle RAC target and add the Oracle RAC instance to the Oracle RAC database.
The database is not mediated by the OMS	The target discovery is not appropriate. Remove the target from Cloud Control, and rediscover on all the Management Agents in the cluster.

42.5.2Common Patching Issues

While analyzing or deploying patch plans, you might see errors if the following are true:

• If the OMS or the Management Agent is down

• If the Software Library is not properly configured

• If there is no connectivity to My Oracle Support (in online mode)

• If there is no Management Repository

• If there are no collections

• If there are host or Oracle home security issues

• If there are inherent OPatch or SQL errors

• If the patch plan consists of non-homogenous patches, for example, a combination of one-off patches and patch sets

• (For Oracle WebLogic Targets only) If there are inherent problems with the SmartUpdate tool.

• (For Oracle WebLogic Targets only) If there is problem discovering Oracle WebLogic targets reporting to the OMS.

You will see these errors in the following places:

• In the header section of the Validation page or the Review page in the Create Plan Wizard (Figure 42-13)

• In the Issues to Resolve section of the Validation page (Figure 42-14)

• In the Plans region of the Patches & Updates page (Figure 42-15).

Figure 42-13 Patch Plan Errors Displayed on the Validation Page

Figure 42-14 Patch Plan Errors Displayed in the Issues to Resolve Section

Figure 42-15 Patch Plan Errors Displayed in the Plans Region

42.5.3Resolving Patching Issues

Table 42-9 lists the different phases that the patch plan goes through, the different states the phases can have, and how you can diagnose and resolve the errors.

Note:

Also refer to the troubleshooting tips described in Section F.2.

Table 42-9 Diagnosing Patching Issues

Phase	State	Diagnosis and Resolution
Analysis	Analysis In Progress	N/A
	Analysis Error	Review the following log file: <gc_inst>/sysman/log/emoms.log
	Issues Remain	In the Create Plan Wizard, on the Validation page, review the issues listed in the Issues to Resolve section. In the Issues to Resolve section, if an error message states that you must click Show Detailed Results here, then click it. On the Procedure Activity Status page, in the Status Detail table, review the status of each of the steps. Click the status to view the log details.
	Conflicts Detected	In the Create Plan Wizard, on the Validation page, review the issues listed in the Issues to Resolve section. In the Issues to Resolve section, if an error message states that you must click Show Detailed Results here, then click it. On the Procedure Activity Status page, in the Status Detail table, review the status of each of the steps. Click the status to view the log details.
	Ready for Deployment	N/A
Preparation	Preparation In Progress	N/A
	Preparation Error	Review the following log file: <gc_inst>/sysman/log/emoms.log
	Preparation Failed	On the Validation page, click Show Detailed Results here. On the Procedure Activity Status page, in the Status Detail table, review the status of each of the steps. Click the status to view the log details.
	Preparation Successful	N/A
Deploy	Deployment In Progress	N/A
	Deployment Error	Review the following log file: <gc_inst>/sysman/log/emoms.log
	Deployment Failed	On the Validation page, click Show Detailed Results here. On the Procedure Activity Status page, in the Status Detail table, review the status of each of the steps. Click the status to view the log details.
	Deployment Successful	N/A

42.5.4 Rolling Back Patches

If you want to roll back the patches, follow the roll back instructions outlined in the ReadMe that is packaged with the patch you applied.

Roll back functionality is supported on the following targets: Management Agent, Oracle WebLogic Server, Oracle SOA Infrastructure, Oracle Restart, single-instance Oracle database, Oracle RAC database, Oracle Grid Infrastructure, and Oracle Grid Infrastructure targets that are part of Oracle Exadata. For more information about the steps to rollback, see Section 42.6.14. For all other targets, Cloud Control does not support the automatic rollback of patches, and therefore, you must roll back the patches manually.

42.6 Additional Patching Tasks You Can Perform

This section covers the additional tasks you can perform with patch plans. In particular, it covers the following:

42.6.1 Viewing or Modifying a Patch Template

To view or modify a patch template, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, do one of the following:

   • Select a patch template. From the context menu, select View. The Edit Template Wizard appears.

   • Click the name of a patch template. The Edit Template Wizard appears.

Note:

• An administrator who created the patch template and the super administrator of Cloud Control can modify a patch template.

• You can modify only the description and the deployment date in the patch template.

42.6.2 Saving a Deployed Patch Plan as a Patch Template

If you have already analyzed and deploy a patch plan, and if you want to save that patch plan as a patch template, then use one of the following approaches:

Approach 1

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region select a successfully analyzed deployable Patch Plan. The context menu appears.

   Note:

   You can create a patch template only from one Patch Plan at a time.

3. From the context menu, select Create Template. The Create New Plan Template dialog appears.

4. Enter a unique name for the template, then click Create Template.

   Note:

   When you select a plan, the Create Template option is not visible if you:

   • Select a nondeployable Patch Plan or a deployable Patch Plan that has either not been analyzed or resulted in errors after being analyzed.

   • Do not have the privileges to view the Patch Plan that you selected.

   • Do not have the privileges to create a template.

Approach 2

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region do one of the following:

   • Select a successfully analyzed deployable Patch Plan. From the context menu, select View. The Create Plan Wizard appears.

   • Click the name of a successfully analyzed deployable Patch Plan. The Create Plan Wizard appears.

3. In the Create Plan Wizard, in the Review & Deploy page, click Save as Template.

4. Enter a unique name for the template, then click Create Template.

Note:

You must create patch templates only with unique names.

42.6.3 Downloading Patches from a Patch Template

To download a patch from a patch template, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, select a patch template.

3. From the context menu, select View. The Edit Template Wizard appears.

4. In the Edit Template Wizard, on the Patches page, click a patch number. The patch details page appears.

5. On the patch details page, click Download.

42.6.4 Deleting a Patch Plan

To delete a patch plan, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, click the Patch Plan you want to delete. From the context menu, click Remove.

   Note:

   If you do not see the Plans region, click Customize Page from the top-right corner, and then drag the Plans region to the page.

42.6.5 Deleting a Patch Template

To delete a patch template, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region select one or more patch templates. The context menu appears.

3. From the context menu, select Remove.

Note:

An administrator who created the patch template and the super administrator of Cloud Control can modify a patch template.

42.6.6 Converting a Nondeployable Patch Plan to a Deployable Patch Plan

To make a nondeployable Patch Plan deployable, divide the Patch Plan into smaller deployable plans that contain only homogenous patches and targets.

42.6.7 Associating Additional Targets to a Patch in a Patch Plan

To associate additional targets to a patch in a patch plan, use one of the following approaches:

Approach 1

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Plans region, select a Patch Plan to which the patch belongs. From the context menu that appears, select View.

   Note:

   If you do not see the Plans region, click Customize Page from the top-right corner, and then drag the Plans region to the page.

3. In the Create Plan Wizard, on the Patches page, Click Add Patch. The Edit Search window appears.

4. In the Edit Search window, search the patch to which you want to associate additional targets.

5. Select the patch that you want to add, then click Add to This Plan. The Add Patch To Plan window appears.

6. In Add Patch To Plan window, search and select the additional targets that you want to associate with the patch, and then, click Add Patch to Plan.

   Note:

   Ensure that you select only homogeneous targets.

   For Oracle WebLogic Server, if you have deployed the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in, you can add any number of WebLogic domain targets to a single patch plan. If you have not deployed the Enterprise Manager for Oracle Fusion Middleware 12.1.0.4 plug-in, you can add only a single WebLogic domain target to a single patch plan. For information about how to deploy a new plug-in or upgrade an existing plug-in, see Oracle Enterprise Manager Cloud Control Administrator's Guide.

   If the WebLogic domain target that you add to a patch plan is a shared domain, then all the Administration Servers and the Managed Servers that are running on the domains that are shared with the domain being patched are automatically added into the same patch plan.

Approach 2

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Patch Recommendations region, click the graph.

   Note:

   If you do not see the Patch Recommendations region, click Customize Page from the top-right corner, and then drag the Patch Recommendations region to the page.

3. On the Patch Recommendations page, select a patch.

4. From the context menu, select Add to Plan, then Add to Existing, and select the plan you want to add the patch to.

   The patch you selected and the target it is associated with get added to the existing plan.

Approach 3

1. From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.

2. On the Patches & Updates page, in the Search region, search a patch you want to add to the patch plan.

   Note:

   If you do not see the Search region, click Customize Page from the top-right corner, and then drag the Search region to the page.

3. On the Patch Search page, click the patch to view its details.

4. On the patch details page, click Add to Plan, then Add to Existing, and select the plan you want to add the patch to.

   The patch you selected and the target it is associated with get added to the existing plan.

42.6.8 Manually Staging the Patching Root Component

To patch Oracle database targets, the Management Agent user must be able to run the perl, patching_root_dispatcher.sh, root_dispatcher.sh and id entities as the root user. These entities form a part of the patching root component.

While patching Oracle database targets, by default, the patching root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). However, if you want to manually stage the patching root component at a custom location before initiating the patching process, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Software Library.

2. Navigate to Patching/Common/DB/All/Generic/Components.

3. Select Root Component, then from the Actions menu, select Stage Entity.

4. Specify the host (where you want to stage the patching root component), and the dispatcher location, that is, the location on the specified host where you want to stage the patching root component. Click Submit to manually stage the patching root component.

   Important:

   Before you manually stage the patching root component at a custom location, ensure that the patching user has the read and execute permissions on the custom patch dispatcher location and on patching_root_dispatcher.sh.

5. Create the rootComponent/component/patching subdirectory at the patch dispatcher location.

6. Copy all the files except patching_root_dispatcher.sh from the dispatcher location to <dispatcher_location>/rootComponent/component/patching.

Note:

After staging the patching root component manually, you must specify this in the patch plan that you create for applying the required Oracle database patches. Access the Deployment Options page of the patch plan that you created. In the Where to Stage section, select No (already staged)

Wget Download Oracle Jdk

for Stage Root Component, and specify the dispatcher location where you have staged the patching root component manually. If the dispatcher location is a shared location, select Dispatcher Location Shared.

42.6.9 Restricting Root User Access for Patching

In Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4), you can provide restricted root access to the Management Agent user, such that the Management Agent user can only run certain commands as root, and not all commands. You can ensure this by editing the etc/sudoers policy file.

To patch Oracle database targets, the Management Agent user must be able to run the perl, patching_root_dispatcher.sh, root_dispatcher.sh and id entities as the root user. These entities form a part of the patching root component.

To provide restricted root access to the Management Agent user, that is, aime, such that this user can only run the perl, patching_root_dispatcher.sh, root_dispatcher.sh and id entities as the root user, edit the etc/sudoers file such that it has the following contents:

<command_alias> represents the alias that describes the entities that can be run by aime as root.

<agent_home> represents the Management Agent home.

<dispatcher_loc> represents the patch dispatcher location where the patching root component is staged. By default, the patching root component is automatically staged at %emd_emstagedir%. If you chose a custom location for the automatic staging, or staged the patching root component manually at a custom location (as described in Section 42.6.9), ensure that you specify this location for <dispatcher_loc>. Else, specify the default location, that is, %emd_emstagedir%.

42.6.10 Resolving Patch Conflicts

If the patches in the patch plan conflict among themselves or with patches in the Oracle home, then you can do one of the following to resolve the conflict:

• Request for a merge patch of the conflicting patches. To do so, click Request Patch on the Validation page.

• Roll back the conflicting patches in the Oracle home and forcefully apply the incoming patches. To do so, on the Deployment Options page, in the Advanced Patching Options section, from the Conflict Resolution list, select Forcefully apply incoming patches.

• Skip the conflicting patches. To do so, on the Deployment Options page, in the Advanced Patching Options section, from the Conflict Resolution list, select Skip conflicting patches.

42.6.11 Analyzing the Results of Patching Operations

If you want to analyze the results of the patching operations you have done over a period of time, then run the EM Deployable Patch Plan Execution Summary. The report shows the number of deployable and nondeployable plans you have had in the past, and provides a breakdown of the deployable plans indicating how many succeeded and failed, how many were analyzed and deployed, and so on.

To run the EM Deployable Patch Plan Execution Summary report, follow these steps:

1. From the Enterprise menu, select Reports, then select Information Publisher Reports.

2. On the Information Publisher Reports page, in the table, expand Deployment and Configuration, then expand Patching Automation Reports, and then select EM Deployable Patch Plan Execution Summary.

42.6.12Customizing Patching Deployment Procedures

This section describes how you can customize patching deployment procedures. For information about customizing deployment procedures in general, see Chapter 51. This chapter explains in detail what customization means, the different ways of customizing a deployment procedure, and so on.

By default, a patch plan uses a static, Oracle-supplied deployment procedure, or an OPlan based, dynamically generated deployment procedure to apply patches. You can customize both these kinds of deployment procedures. This section consists of the following:

42.6.12.1 Customizing a Static Patching Deployment Procedure

To customize a default, static deployment procedure, and use it to patch your targets, follow these steps:

1. Access the Deployment Options page.

2. In the Customization section, click Create Like and Edit.

3. Edit the deployment procedure (you can even add manual steps to the deployment procedure), then save it with a unique, custom name.

   For information on how to edit and save a deployment procedure, see Section 51.2.

4. To use the customized deployment procedure, return to the Customization section of the Deployment Options page, then select the customized deployment procedure.

   If you want to edit a customized deployment procedure, select the customized deployment procedure in the Customization section, then click Customize.

42.6.12.2 Customizing a Dynamic Patching Deployment Procedure

To customize a dynamically generated deployment procedure, and use it to patch your targets, follow these steps:

1. Access the Deployment Options page.

2. In the Customization section, select Specify custom steps to be added to generated patching deployment procedure.

   For each placeholder step in the deployment procedure, you can add three custom steps, a directive step (which enables you to run a directive stored in Software Library), a host command step (which enables you to run a command script on the patch targets), and a manual step (which enables you to provide manual instructions to a user).

3. Select all the custom steps that you want to add under the placeholder steps, then click Enable.

   To disable an enabled custom step, select the custom step, then click Disable.

4. Select a custom step that you want to add, then click Edit.

   If the custom step you selected is a directive step, an Edit Custom Step dialog box appears, which enables you to specify the details of a directive that you want to run. To specify a new directive or a different directive than the one displayed, click the icon displayed beside Directive Name. Search for the required directive that is present in Software Library, select it, then click Select. In the Directive Properties section, specify a value, or choose a variable (that will be defined in the dynamically generated deployment procedure), for each directive property. In the Credentials section, for Credential Usage, select the credentials that must be used to run the custom directive step. Click OK.

   If the custom step you selected is a host command step, an Edit Custom Step dialog box appears, which enables you to specify the details of a command script that you want to run on the patch targets. For Script, specify the commands that you want to run on the patch targets. For Interpreter, specify the complete path of the interpreter that must be used to execute the specified command script. For Credential Usage, select the credentials that must be used to run the custom host command step. Click OK.

   If the custom step you selected is a manual step, an Edit Custom Step dialog box appears, which enables you to provide manual instructions to the user during the execution of the deployment procedure. For Instructions, specify the instructions for the manual tasks that a user must perform in this custom step. Click OK. The specified instructions are displayed when this custom step of the deployment procedure is executed.

5. Repeat Step 4 for all the custom steps that you have enabled.

42.6.13 Pausing the Patching Process While Patching Targets in Rolling Mode

While patching your targets in rolling mode, you can choose to pause the execution of the patching deployment procedure after each node is patched. This feature is useful when you want to perform a clean up on the host having the patched node, verify whether the patch is applied successfully on the node, and so on, before starting the patching process on the next node.

Important:

This feature is available only if you have the 12.1.0.5 Enterprise Manager for Oracle Database plug-in, or a higher version, deployed.

To use this feature, follow these steps:

1. Create a custom static deployment procedure as described in Section 42.6.12.1. On the Create Like Procedure page, select the Procedure Steps tab, select the Wait for user confirmation option, then click Save.

2. Use the custom deployment procedure while creating a patch plan to patch your targets in rolling mode (by specifying this custom deployment procedure in the Customization tab of the Deployment Options page).

   The patching deployment procedure is paused after a node is patched, and you can resume its execution from the Procedure Activity page.

42.6.14 Rolling Back Patches

To rollback patches, you must create a new patch plan, select the relevant patches to rollback, and then select the rollback check box. To do so, perform the following steps:

Note:

The roll back functionality is supported on the following targets:

• Oracle Management Agents

• Oracle WebLogic Server

• Oracle Single Instance Databases

• Oracle SOA Infrastructure

• Oracle Restart

• Oracle RAC Database

• Oracle Grid Infrastructure

• Oracle Grid Infrastructure targets that are part of Oracle Exadata

1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, and then click Patches and Updates.

2. On the Patches and Updates page, in the Patch Search region, enter the patch that you want to rollback.

3. In the Add Patch to Plan dialog box, enter a unique name for the plan, and select all the targets from where you want to rollback the patches.

4. Click Create Plan.

5. In the Create Plan Wizard, select Deployment Options.

6. On the Deployment Options page, in the How to Patch section, select In Place, and in the Rollback section, select Rollback patches in the plan. Click Next.

7. On the Validation page, click Analyze to validate the plan. After a successful analysis, click Next.

8. On the Review and Deploy page, review the details you have provided for the patch plan, and then click Rollback to rollback the selected patch from the corresponding targets mentioned in the plan.

42.7 End-to-End Use Case: Patching Your Data Center

For an end-to-end use case that demonstrates how Enterprise Manager can be used to roll out patches across a data center, see Appendix E.

42.8 Patching Database as a Service Pools

To patch Database as a Service pools, you must use the Pool Maintenance option. For detailed information on how to patch Database as a Service pools, see Chapter 18, 'Maintaining the Database Pool' in Enterprise Manager Cloud Administration Guide.

Also, to standardize software and have a homogeneous software configuration across your enterprise, and perform subscription based software maintenance, ensure that you use the Software Standardization Advisor feature.