21 Patching Software Deployments
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. Patching is complex and involves downtime. You can use several approaches to identify and apply the patches.
This chapter describes how Oracle Enterprise Manager Cloud Control patch management solution addresses these patch management challenges. In particular, this chapter covers the following:
Overview of the New Patch Management Solution
This section describes the following:
Overview of the Current Patch Management Challenges
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, other Oracle software, and the challenges you might be facing while using them (Table 21-1).
Table 21-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. |
|
Custom Scripts |
User-created scripts developed around OPatch, SQLPlus, and so on. |
|
Deployment procedures |
Default procedures offered by Cloud Control for automating the patching operations |
|
About the New Patch Management Solution
Cloud Control addresses the challenges described in Overview of the Current Patch Management Challenges 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 analysis of the patch conflicts, therefore, there is minimal manual effort required. For more information on patch plans, see Overview of Patch Plans.
-
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, Oracle Restart, Oracle Real Application Clusters (RAC), Oracle Grid Infrastructure (that may or may not be a part of Oracle Exadata) targets, and targets in Oracle Data Guard configuration.
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.
-
Out-of-place patching is supported by Enterprise Manager for Oracle Restart 11.2.0.4 and 12.1.0.2 on Linux x64 and AIX platforms only if you have the 13.1.0.1 Enterprise Manager for Oracle Database plug-in deployed.
-
-
Flexible patching options such as rolling and parallel, both in offline and online mode.
Figure 21-1 shows you how you can access the Patches and Updates screen from within Cloud Control console.
Figure 21-1 Accessing the Patches & Updates Screen
Overview of Patch Plans
This section describes the following:
About Patch Plans
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:
- Patches (One-Off)
- Interim Patches that contain a single bug fix or a collection of bug fixes provided as required. It can also include 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.
- 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.
- Using Oracle Enterprise Manager Cloud Control to apply Patch Sets to any Oracle Fusion Middleware software (including Oracle WebLogic Server, Oracle SOA Infrastructure, and Oracle Service Bus) and Oracle Fusion Application software is not supported. Similarly, using Oracle Enterprise Manager Cloud Control to apply Bundle Patches to Oracle Identity Management software is not supported.
- Patch Sets are supported for only one specific version of Oracle Database.
- 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.
- You cannot add patches that require different database startup modes (upgrade or normal) in a single patch plan.
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 patch any target by using a patch plan. The plan also validates Oracle Database, Fusion Middleware, and Cloud Control patches against your environment to check for conflicts with installed patches. For more information on supported middle ware targets, see: Introduction to Middleware Provisioning.
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 Supported Targets, Releases, and Deployment Procedures for Patching.
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 Creating Administrators with the Required Roles for Patching.
About Types of Patch Plans
This section describes the types of patch plans.
A patch plan can be either deployable or non-deployable. A patch plan is deployable when:
-
It contains only patches of the same product family and platform.
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.
-
You cannot add patches that require different database startup modes (upgrade or normal) in a single patch plan.
-
-
It contains targets that are supported for patching, similarly configured, and are of the same product type, platform, and version (homogeneous targets).
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.
About the Create Plan Wizard
Figure 21-2 shows the Create Plan Wizard that enables you to create, view, and modify patch plans.
Figure 21-2 Create Plan Wizard
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 and 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 corresponding 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 dynamic deployment procedure, you can specify the custom steps that can be added in the generated deployment procedure. However, you cannot choose an existing procedure from the Procedure Library and customize and save it.
For standalone (single-instance) database, Oracle Restart, Oracle RAC database, Oracle Grid Infrastructure (that may or may not be a part of Oracle Exadata), and targets in Oracle Data Guard configuration, and 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.
-
-
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
-
SmartUpdate 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)
-
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. After you click the Deploy button, a dialog box appears which allows you to confirm the deployment of patches at that time or in future. 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.
Overview of Patch Templates
This section describes the following:
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.
About the Edit Template Wizard
Figure 21-3 shows the Edit Template Wizard that enables you to view the contents of a patch plan template and modify its description.
Figure 21-3 Edit Template Wizard
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.
Supported Targets, Releases, and Deployment Procedures for Patching
Note:
When patching Single Instance High Availability (SIHA) 12.1.0.2 Oracle Database through Enterprise Manager 13.4 and Perl 5.38 Update, the database needs to be patched at least to version 12.1.0.2.191015, with the October 2019 or later GI PSU patch applied on the target.Table 21-2 Supported Targets and Releases for Patching Oracle Database
Supported Target Type | Supported Targets and Releases | Patching Mode | Deployment Mode | Supported Platforms | Deployment Procedure |
---|---|---|---|---|---|
Oracle Database | Oracle Database (Standalone) 10g to 12c 4 Multitenant Database (Container and Pluggable Databases) |
In-Place | N/A | All Platforms | Patch Oracle Database |
Oracle Database (Standalone) 10g to 12c 4 Multitenant Database (Container and Pluggable Databases) |
Out-of-Place | N/A | All Platforms | Clone and Patch Oracle Database | |
Oracle RAC One Node Database 10g to 12c 4 | In-Place | Rolling | All Platforms except for Microsoft Windows | Patch Oracle RAC Database - Rolling | |
Oracle RAC One Node Database 10g to 12c 4 | In-Place | Parallel | All Platforms except for Microsoft Windows | Patch Oracle RAC Database - Parallel | |
Oracle RAC Database 10g to 11.2.0.1 | In-Place | Rolling | All Platforms except for Microsoft Windows | Patch Oracle RAC Database - Rolling | |
Oracle RAC Database 10g to 11.2.0.1 | In-Place | Parallel | All Platforms except for Microsoft Windows | Patch Oracle RAC Database - Parallel | |
Oracle Database | Oracle RAC Database 11.2.0.2 to 12.1.0.2 4 | In-Place | Rolling / Parallel | All Platforms except for Microsoft Windows | Dynamic Deployment Procedures 1 |
Oracle RAC Database 11.2.0.2 to 12.1.0.2 4 | Out-of-Place | Rolling / Parallel | All Platforms except for Microsoft Windows | Dynamic Deployment Procedures | |
Oracle Grid Infrastructure* 10g to 11.2.0.1 | In-Place | Rolling | All Platforms except for Microsoft Windows | Patch Oracle Clusterware - Rolling | |
Oracle Grid Infrastructure* 10g to 11.2.0.1 | In-Place | Parallel | All Platforms except for Microsoft Windows | Patch Oracle Clusterware - Parallel | |
Oracle Database | Oracle Grid Infrastructure* 11.2.0.2 to 11.2.0.4 | In-Place | Rolling / Parallel | All Platforms except for Microsoft Windows | Dynamic Deployment Procedures 2 |
Oracle Grid Infrastructure* 11.2.0.2 to 11.2.0.4 | Out-of-Place | Rolling / Parallel | All Platforms | Dynamic Deployment Procedures | |
Oracle Grid Infrastructure* 12.1.0.1 to 12.1.0.2 4 | In-Place | Rolling / Parallel | All Platforms | Dynamic Deployment Procedures 3 | |
Oracle Grid Infrastructure* 12.1.0.1 to 12.1.0.2 4 | Out-of-Place | Rolling / Parallel | All Platforms | Dynamic Deployment Procedures | |
Oracle Restart 10g to 11.2.0.4 | In-Place | N/A | All Platforms | Patch Oracle Restart | |
Oracle Restart - Release 12c 4 onwards | In-Place | N/A | All Platforms | Patch Oracle Restart(12.1.0.1.0 onwards) | |
Oracle Restart - Release 11.2.0.4 and 12.1.0.2 4 | Out-of-Place | N/A | Only Linux.X64 and AIX | Dynamic Deployment Procedures |
Note:
Symbol | Description |
---|---|
1 | To override and use the following static deployment procedures for In-Place patching mode. Set (update/insert) the use_static_dp to true in mgmt_patching_properties table.
|
2 | To override and use the following static deployment procedures for In-Place patching mode. Set (update/insert) the use_static_dp to true in mgmt_patching_properties table.
|
3 | To override and use the following static deployment procedures for In-Place patching mode, set (update/insert) the use_static_dp to true in mgmt_patching_properties table.
|
4 | Multitenant Database (Container and Pluggable Databases) is supported. |
Clusters* | Grid Infrastructure* |
N/A | Not applicable |
Table 21-3 Supported Targets and Releases for Patching other target types
Supported Target Type | Supported Targets and Releases | Supported Platform | Supported Default Deployment Procedure |
---|---|---|---|
Oracle Service Bus | Oracle Service Bus Infrastructure 13c Release 2 | All Platforms |
|
Oracle WebLogic Server |
Oracle WebLogic Server 10g (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), and 12c Release 2 (12.2.1.x) |
All Platforms |
|
Oracle Service Oriented Architecture | Oracle SOA Infrastructure 11g Release 1 (11.1.1.1.0 - 11.1.1.7.0), 12c Release 1 (12.1.3.0.0), and 12c Release 2 (12.2.1.0.0) | All Platforms |
|
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 |
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 Database | Oracle Automated Storage Management (Oracle ASM) 10g Release 1 to 11g Release 2 | All Platforms | Patch Standalone Oracle ASM |
Oracle Database | Oracle Software Only Patching (Grid Home / DB Home) | All Platforms | Patch Oracle Home |
Note:
- You can also patch primary and standby databases configured with Oracle Data Guard. For information on how to patch these targets, see Patching Oracle Data Guard Targets.
- 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.
- From the 12.2 release, classic patching using Lifecycle Management Graphical User Interface is deprecated. You must use the Database Fleet Maintenance feature to patch 12.2 databases and GI environments.
- Shared home patching is not feasible from EM console, because patch plan uses the OPlan.
Overview of Supported Patching Modes
This section describes the following patching modes:
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.
-
Ensure to run the necessary OPatch in online mode prior to applying the patches in offline mode. This can be accomplished either manually uploading the relevant version of OPatch to the software library or execute the out of box OPatch update job.
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 21-4 illustrates how multiple database instances running from an Oracle home get patched in in-place patching mode.
Figure 21-4 In-Place Mode of Patching
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.
Note:
-
Out-of-place patching is supported for standalone (single-instance) database targets, Oracle Restart 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 13.1.0.1 Enterprise Manager for Oracle Database plug-in is required for patching Oracle Restart targets in out-of-place mode.
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.
In case of a system patch such as a Grid Infrastructure patchset update, edit and provide the candidate Oracle Home location. This location is validated during analysis.
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, Oracle Restart 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 21-5 illustrates how multiple database instances running from an Oracle home get patched in out-of-place patching mode.
Figure 21-5 Out-of-Place Mode of Patching
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 Analyzing, Preparing, and Deploying Patch Plans.
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. This is validated during analysis.
Figure 21-6 illustrates how a two-node Oracle RAC target gets patched when rolling mode is used.
Figure 21-6 Rolling Mode of Patching
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 21-7 illustrates how a two-node Oracle RAC target gets patched when parallel mode is used.
Figure 21-7 Parallel Mode of Patching
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. |
|
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). |
|
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. |
Setting Up the 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.
Attention:
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:
Meeting Basic Infrastructure Requirements for Patching
Meet the basic infrastructure requirements as described in Setting Up Your Infrastructure. The chapter describes both mandatory and optional requirements.
Also, when patching a domain with the admin port and/or the SSL port enabled, the patching deployment procedure assumes that the SSL certificates are consistent across all nodes in the domain. Therefore, ensure that the SSL certificates are in the same location on all hosts. If the SSL certificates are in different locations, then the deployment procedure will fail as it will not be able to find the certificates in some hosts.
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 Installing Cygwin and Starting the SSH Daemon in Oracle Enterprise Manager Cloud Control Basic Installation Guide..
Creating Administrators with the Required Roles for Patching
Table 21-4 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 Creating Enterprise Manager User Accounts
Table 21-4 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 on selected Target (You can select a particular target you want to patch and grant operator privilege to it) |
|
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 |
Operator on selected Target (You can select a particular target you want to patch and grant operator privilege to it) |
|
Required when you want to grant access and also have restrictions. Alternatively, you can create an EM user with Patch Operator role. |
Patch Operator |
Create |
View |
CREATE_PATCH_PLAN VIEW_ANY_PLAN_TEMPLATE |
Operator on selected Target (You can select a particular target you want to patch and grant operator privilege to it) |
|
Required when you want to grant access and also have restrictions. Alternatively, you can create an EM user with Patch Deployer role. |
Patch Deployer |
Create |
View |
CREATE_PATCH_PLAN VIEW_ANY_PLAN_TEMPLATE sw |
Operator on selected Target (You can select a particular target you want to patch and grant operator privilege to it) |
|
Required when you want to grant access and also have restrictions. Deployer role, has no Software Library privileges, unlike Operator role. Alternatively, you can create an EM user with Patch Operator role. |
Setting Up the 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:
Enabling 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:
- From the Setup menu, select Provisioning and Patching, then select Offline Patching.
- For Connection, select Online.
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:
-
From the Setup menu, select Proxy Settings, then select My Oracle Support.
-
If you want the OMS to connect to MOS directly, without using a proxy server, follow these steps:
-
Select No Proxy.
-
Click Test to test if the OMS can connect to MOS directly.
-
If the connection is successful, click Apply to save the proxy settings to the repository.
-
-
If you want the OMS to connect to MOS using a proxy server, follow these steps:
-
Select Manual proxy configuration.
-
Specify the proxy server host name for HTTPS and an appropriate port value for Port.
-
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.
-
Click Test to test if the OMS can connect to MOS using the specified proxy server.
-
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.
Setting Up the 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:
Enabling 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:
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 Downloading Enterprise Manager Catalog Zip File From Another Host With Internet Connectivity and Uploading Enterprise Manager Catalog Zip File from your Host With No Internet Connectivity.
Downloading 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.
Uploading 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:
Uploading 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:
-
Log in to My Oracle Support (
https://support.oracle.com/
), then click the Patches & Updates tab. -
On the Patches & Updates page, in the Patch Search section, enter the patch number you want to search for as shown in Figure 21-8, then click Search.
Figure 21-8 Searching for Patches
-
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 21-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 21-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:
-
From the Enterprise menu, select Provisioning and Patching, then select Saved Patches.
-
Click Upload.
-
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 thePatchSearch.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, see Uploading Patches to Oracle Software Library.
-
Click Upload to upload the 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 Uploading Patches to Oracle Software Library), 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:
Analyzing 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.
To view the patchability reports, follow these steps:
- From the Enterprise menu, select Reports, then select Information Publisher Reports.
- Click Expand All to view all the branches under Information Publisher Reports.
- 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.
- 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. For more information on Fusion Middleware, see: Getting Started with Fusion Middleware Provisioning in Oracle Enterprise Manager Middleware Lifecycle Management Administrator's Guide.
Note:
If you see any missing property errors, then resolve the errors using the workarounds described in Workaround for Missing Property Errors. If you see any unsupported configuration errors, then resolve the errors using the workarounds described in Workaround for Unsupported Configuration Errors.
Identifying the Patches to Be Applied
This section describes how you can identify the patches to be applied.
Attention:
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:
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).
Enterprise Manager Cloud Control 13c supports patch recommendations for the following target types:
-
Oracle Database
-
Enterprise Manager Cloud Control (Management Agent/Oracle Management Service)
-
Oracle Fusion Applications
-
SOA Infrastructure
-
Oracle Real Applications Clusters
-
Oracle Real Applications Clusters with Clusterware
-
Oracle Data Guard
-
Oracle Exalytics (QFSDP recommendations only)
-
Oracle Coherence, Oracle WebLogic Server, Oracle JRockit for non-Exalogic systems
-
Oracle Siebel
-
Oracle Business Process Management
-
Application Development Framework Runtime
-
Oracle Service Bus
-
WebLogic Server
Note:
The pre-requisite for patching WebLogic domains is that the underlying Oracle Home must be discovered as a target. For SOA 11g, 12c and Service Bus domains this is automatically handled. However, for Service Bus 11g when the domain is discovered the OH is not discovered as a target. If you attempt to patch such a domain then the following warning is displayed. To overcome this, ensure that the Middleware Home and the underlying Oracle Homes are discovered as targets and the configuration collections for Oracle Home targets are the current ones.
For more information on patching Oracle Service Bus and respective recommendations, see Patching Oracle Service Bus.
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:
-
Run the following EM CLI commands to get the target information of a patch plan:
emcli get_patch_plan_data -name=<name of the plan>
-
Perform the following steps to determine the time when the plan was deployed on the targets:
-
From Enterprise menu, select Provisioning and Patching, and then click Patches and Updates.
-
On the Patches and Updates page, from the Plans section, select the patch plan.
-
From the Create Plan Wizard, select Review and Deploy.
-
Click the link to the track the details of the deployment.
-
Note down the start time of the job from the Job UI page.
-
-
On the Config Management side, use the following attributes to calculate the collection time stamp using
MGMT$ECM_CURRENT_SNAPSHOTS
view as follows:start_timestamp - timestamp of the collection (in target timezone) last_upload_timestamp (in DB timezone) when a collection was processed for this snapshot type.
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 in 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:
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
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 Recommendations page also displays the recommended Patch Set Updates and Composite Patch Updates currently available for the targets.
-
On the Patch Recommendations page, select a recommended patch to view the context menu appears. From the context menu, click Full Screen.
About 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 Searching for Patches on My Oracle Support or Searching for Patches in Oracle Software Library, 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.
About 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 Searching for Patches on My Oracle Support or Searching for Patches in Oracle Software Library, 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.
Searching 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:
Searching 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).
Note:
Ensure to run the necessary OPatch in online mode prior to applying the patches in offline mode. This can be accomplished either manually uploading the relevant version of OPatch to the software library or execute the out of box OPatch update job.
To switch over to offline mode, follow these steps:
-
From the Setup menu, select Provisioning and Patching, then select Offline Patching.
-
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:
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.
Note:
All the targets running on a host must be registered as Enterprise Manager targets for patching to be successful. Otherwise, it could result in partial patching wherein the binary bits are patched but the SQL is not applied and so on.
For example, if you have a RAC system with four Oracle homes and five instances of the Database running, then all four Oracle homes and five databases must be registered Enterprise Manager targets for the patching process to be successful.
This section covers the following:
-
Switching Back to the Original Oracle Home After Deploying a Patch Plan
-
Saving Successfully Analyzed or Deployed Patch Plan As a Patch Template
-
Creating a Patch Plan from a Patch Template and Applying Patches
-
Patching Grid Infrastructure and Databases on Oracle Exadata
-
Deploying WebLogic Patches Along with SOA or Oracle Service Bus Patches In A Single Patch Plan
Accessing the Patch Plan
Attention:
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 Creating a Patch Plan, 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:
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
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:
Analyzing, Preparing, and Deploying Patch Plans
Attention:
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 Creating a Patch Plan and deploy it (or save it as a patch template), follow these steps:
-
Access the patch plan using one of the approaches described in Accessing the Patch Plan.
Cloud Control displays the Create Plan Wizard.
-
On the Plan Information page, do the following:
-
In the Overview section, validate the Patch Plan name. You can choose to edit it if you want.
-
(Optional) Enter a short description for the patch plan.
-
(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 Creating Administrators with the Required Roles for Patching.
-
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.
-
-
Click Next.
-
-
On the Patches page, do the following:
-
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 Associating Additional Targets to a Patch in a Patch Plan.
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.
-
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.
-
-
On the Deployment Options page, do the following:
-
In the How to Patch section, select the mode of patching that you want to use.
For standalone (single-instance) database targets, Oracle Restart 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, see Overview of Patching in In-Place and Out-of-Place Mode.
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, see Overview of Patching in Rolling and Parallel Mode.
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 Pausing the Patching Process While Patching Targets in Rolling Mode.
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.
-
(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.
For out-of-place patching, select the Oracle home that will be cloned, click Create New Location against the Oracle home you want to clone, and enter the full path name to a new directory that will be automatically created during the cloning process. The directory cannot already exist, and the specified operating system user must have write permission for its parent directory.
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.
-
-
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 titled699099
and extract the contents of the zip file. Specify/u01/app/oracle/em/stagepatch
as the stage location.Note:
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 root component. The root component is a set of 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
is 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 Manually Staging the Patching Root Component.
-
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.
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.
-
(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 Customizing a Static Patching Deployment Procedure.
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 Customizing a Dynamic Patching Deployment Procedure.
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. -
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.
-
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 RAC One node 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 Rolling Back Patches.
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.
-
-
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.
-
Click Next.
-
-
On the Validation page, click Analyze to check for conflicts. For information about what checks are performed in the validation screen, see About the Create Plan Wizard.
-
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:
-
Use the Provision Oracle Database deployment procedure to provision the software image stored in Software Library to the required location on the host.
-
Create a patch plan. Ensure that you add all the patches that are a part of the provisioned Oracle home to this plan.
-
On the Deployment Options page, in the What to Patch section, specify the location of the provisioned Oracle home.
-
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 Saving Successfully Analyzed or Deployed Patch Plan As a Patch Template.
Conflict Patches
When applying WebLogic Server, SOA, or Service Bus patches, there may be conflicts among the patches. This is encountered during the analysis phase. We can select the appropriate patch conflict resolution action in the Deployment Options page. Refer to the following table for details.
Patch Conflict resolution is supported from WebLogic Server 12.1.2.0.0 onwards.
The following tasks or actions can be performed by the user when the analysis results display any patch conflicts:
Selected action | Description |
---|---|
Stop at Conflicts |
This can be selected if you want the patching procedure to stop the deployment of the plan when a conflict is encountered. |
Force Apply |
This can be selected if you want the patching procedure to roll back the conflicting patches and apply the incoming patches when a conflict is encountered. |
Skip Conflicts |
This can be selected if you want the patching procedure to apply only the non-conflicting patches and skip applying the conflicting patches when a conflict is encountered. |
For WebLogic Server versions earlier than 12.1.2.0.0, the patch conflicts can be removed using the following steps.
- Create a Patch Plan with a new Patch Set Update.
- Analyze the patch. In case there are any conflicting patches, the Run WebLogic Home Prerequisite Checks indicates the conflicting patches with the new patches that are part of the new Patch Plan just created.
- Make a note of the patch number that is conflicting with the newly created Patch Plan and that needs to be rolled back.
- Create a new Rollback plan that includes the conflicting patches for all the targets.
- Analyze the Rollback plan.
- Apply the Rollback plan.
- All the conflicting patches are now removed from the WebLogic Server Home. Now the Patch Plan that was initially created with the Patch Set Update can be analyzed.
- Apply the Patch Plan.
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, Oracle Restart 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, Oracle Restart, 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:
- From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
- 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 Restart, 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.
- In the Create Plan Wizard, on the Review & Deploy page, click Switchback.
Saving Successfully Analyzed or Deployed Patch Plan As a Patch Template
Attention:
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 Analyzing, Preparing, and Deploying Patch Plans, 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.
Important:
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.
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 Analyzing, Preparing, and Deploying Patch Plans.
Attention:
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:
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
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.
-
From the context menu, select Create Plan.
-
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.
-
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.
-
In the Create Plan Wizard, go to the Validation page, and click Re-Analyze to analyze the patch plan with the newly associated targets.
-
After successfully analyzing the patch plan, on the Validation page, click Next.
-
On the Review & Deploy page, click Deploy.
Approach 2
Patching Oracle Grid Infrastructure Targets
You can patch Oracle Grid Infrastructure targets using patch plans. To do so, follow these steps:
Oracle Grid Infrastructure and Oracle RAC Configuration Support
This section describes the configurations that OPlan supports for patching GI and RAC databases of versions 11.2.0.2 or higher, on Linux X64, Solaris X64, Solaris SPARC and AIX platforms. Enterprise Manager integrates with OPlan to generate the procedure dynamically. If you use OPlan, then the commands that run as root will use the script available in the target Oracle Home. The commands required to run as root depend on the version and the mode of patching.
The following table lists the details:
Table 21-5 Oracle Grid Infrastructure and Oracle RAC Configuration Support
Version | Mode | Command |
---|---|---|
11.2 |
In-Place |
|
11.2 |
Out Of Place |
|
12.1 |
In-Place |
|
12.1 |
Out of Place |
|
Patching Grid Infrastructure and Databases on 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 Supported Targets, Releases, and Deployment Procedures for Patching.
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:
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 21-10 illustrates how Oracle Grid Infrastructure and Oracle RAC targets running on an Exadata Database Machine get patched in Out-of-place patching mode:
Figure 21-10 Out Of Place Patching Of Clusters
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 Analyzing, Preparing, and Deploying Patch Plans.
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 Switching Back to the Original Oracle Home After Deploying a Patch Plan.
Patching 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:
Oracle Data Guard Patching Workflow
- Search for the required patch, then create a patch plan by selecting the cluster target.
- Specify the required deployment options.
- Analyze and deploy the plan.
Note:
- 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.
Oracle Data Guard Patching Scenarios
Scenario 1: The primary and standby databases are RAC databases.
Table 21-6 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 21-6 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. |
|
The primary and the standby RAC databases are running from different clusters. |
|
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. |
Note: You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1. |
Table 21-7 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 (Single Instance High Availability) target.
Table 21-7 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. |
|
The primary RAC database and the standby single-instance database are running from different clusters. |
|
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. |
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 21-8 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.Note:
When patching Single Instance High Availability (SIHA)12.1.0.2 Oracle Database through Enterprise Manager 13.4 and Perl 5.38 Update, the database needs to be patched at least to version 12.1.0.2.191015, with the October 2019 or later GI PSU patch applied on the target.Table 21-8 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. |
|
The primary and the standby single-instance databases are running from different clusters. |
|
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. |
Note: You can patch the clusters in any order, that is, C1 first and then C2, or C2 first and then C1. |
Follow these steps to apply an Oracle Grid Infrastructure PSU or an Oracle Database PSU on this configuration:
- 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.Patching 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:
- Identify the patches that you want to apply, as described in Identifying the Patches to Be Applied.
- Create a patch plan, as described in Creating a Patch Plan.
- Analyze and deploy the patch plan, as described in Analyzing, Preparing, and Deploying Patch Plans.
Patching 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:
- Identify the patches that you want to apply, as described in Identifying the Patches to Be Applied.
- Create a patch plan, as described in Creating a Patch Plan.
- Analyze and deploy the patch plan, as described in Analyzing, Preparing, and Deploying Patch Plans.
Patching Oracle Service Bus
Fusion Middleware patching through Enterprise Manager is supported for targets like WebLogic Domain, SOA, and Oracle Service Bus (OSB). This topic contains the procedure to patch an Oracle Service Bus using the Enterprise Manager.
A single node of Oracle Service Bus Domain consists of Service Bus Domain Target, Service Bus Cluster Target, Service Bus Target, WebLogic Cluster Target, and WebLogic Server Targets.
The Service Bus Cluster Target comprises of all the Service Bus targets. The WebLogic Cluster Target comprises all the WebLogic Server targets. The WebLogic Server Targets comprise of a single Administration Server and a Managed Server.
This procedure of patching an Oracle Service Bus through the Enterprise Manager patching framework comprises of creating a patch plan by selecting a Service Bus Target or a Service Bus Cluster Target. The user can select a single target and the associated targets are included automatically during patching. The user can also edit the plan to add more patches, analyze, rollback, and create a template.
For more information on creating a patch plan, see Creating a Patch Plan.
Before you begin patching of Oracle Service Bus, ensure that you meet the following prerequisites:
-
The user needs to ensure that Oracle Home collection is complete. Patching throws an error if one or more Oracle Homes are not discovered.
Note:
The pre-requisite for patching WebLogic domains is that the underlying Oracle Home must be discovered as a target. For SOA 11g, 12c and Service Bus domains this is automatically handled. However, for Service Bus 11g when the domain is discovered the OH is not discovered as a target. If you attempt to patch such a domain then the following warning is displayed. To overcome this, ensure that the Middleware Home and the underlying Oracle Homes are discovered as targets and the configuration collections for Oracle Home targets are the current ones.
There is no Oracle Home (OH) target associated for the patch being applied. To rectify this issue the user should promote the OH being patched, by choosing the "Discover Promote Oracle Home Target" job in Enterprise Manager. Ensure the OH target is available after this operation is completed, and the configuration metrics for the OH target is collected.
-
The user needs to ensure to set the Oracle Homes and Domain administrator credentials.
-
For offline patching, the user needs to ensure to have the necessary OPatch downloaded from MOS and manually upload to the saved patches.
For patching WebLogic Server 12.2.1.x Enterprise Manager expects Opatch release 13.3.0.0.0 to be available in the software library. At the time of releasing Enterprise Manager, this version of OPatch was not available for download from MOS. Hence, when patching WebLogic Server 12.2.1.x, Enterprise Manager uses the Opatch installed in the WebLogic Server Oracle Home instead of trying to download the latest OPatch from MOS.
-
The target selector needs metadata from My Oracle Support to filter the targets based on the patch types. The user must run Refresh from My Oracle Support job in online mode. In case of offline mode the user must upload the catalog.zip file.
-
Patching on Oracle Service Bus is supported on the following versions:
-
11.1.1.5.0
-
11.1.1.6.0
-
11.1.1.7.0
-
11.1.1.9.0
-
12.1.3.0.0
-
12.2.1.0.0
-
-
The SOA patch containing SQL script may fail if the metadata is not specified in the right format. The metadata has to be specified in the Deployment Options page in the field Location of Post Install SQL Script.
Ensure that the SQL scripts are specified in the following format:
<patch_number1>:<sql_script1_location>:<sql_script2_location>:<patch_number2>:<sql_script3_location>:...
Example:
14082705:%ORACLE_HOME%/rcu/integration/soainfra/sql/createschema_soa infra_oracle.sql
Additionally, this information is available in the Post-Installation Instructions in the README.txt file. In case the Location of Post Install SQL Script field is left blank or the right SQL script is not specified then the following error message is mentioned in the log:
One or more SQL files included in this patch are not selected for post-patch execution. To correct this, update your selection in the "Deployment options" page. To continue without making any changes, run the required SQL scripts manually after the patch is deployed successfully.
-
The relevant patch, target, and domain details are displayed in the following table:
Patch Targets SOA
SOA Infrastructure
Oracle Service Bus
Service Bus
To apply patching for Oracle Service Bus, follow these steps:
Deploying WebLogic Patches Along with SOA or Oracle Service Bus Patches In A Single Patch Plan
This topic contains the procedure to deploy WebLogic Patches as well as SOA or Oracle Service Bus patches using a single patch plan. Using a single patch plan to deploy all the required patches would reduce down time during patching.
In case of SOA or Oracle Service Bus domain the user can apply Web Logic patches or SOA or Oracle Service Bus product patches. These patches can be applied in different sessions by creating separate patch plans. However each patch deployment session would involve down time. To reduce the system down time, you can create one patch plan by selecting the Web Logic platform patches as well as SOA or Oracle Service Bus patches and then apply this patch plan in one session.
Note:
-
The combined patching is supported only from Oracle Service Bus or SOA release 12.1.3.0.0 onwards. This mode of combined patching is supported only from Oracle Service Bus or SOA release 12.1.3.0.0 onwards. For earlier versions of Oracle Service Bus and SOA, create separate patch plans to apply the patches.
-
To achieve this, first create the patch plan by selecting the desired Weblogic patches and selecting the desired domain targets. Add the Oracle Service Bus or SOA patches to the same patch plan and ensure to reselect the same domain targets in the target selector window as detailed in the steps below. This will ensure that all required patches and the targets to deploy them against are selected.
The user can apply multiple patches through a single patch plan.
For more information on creating a patch plan, see Creating a Patch Plan.
Note:
An Oracle Service Bus or SOA target must have an Oracle Home associated with it. Else, the following error message is displayed with the resolution:
There is no Oracle Home(OH) target associated for the patch being applied. To rectify this issue the user should promote the OH being patched, by choosing the "Discover Promote Oracle Home Target" job in Enterprise Manager. Ensure the OH target is available after this operation is completed, and the configuration metrics for the OH target is collected.
To apply patching for Oracle Service Bus, follow these steps:
Note:
You can also include any SQL scripts that need to be executed while applying patch.
- From the Enterprise menu, select Provisioning and Patching, then select Saved Patches.
- Click Upload.
- Provide the location of the patch file and the patch metadata, and click Upload.
- Once the patch has been uploaded, select the patch. This takes you to the patch home page.
- Click Create Plan by selecting the WebLogic patch and WebLogic domain As the target.
- Enter the name of the plan in the Plan Name field.
- Enter WebLogic domain As the target type.
- Click Create Plan.
- The WebLogic Server patch plan is created and can be deployed along with Oracle Service Bus or SOA patch.
- From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
- Select the patch plan that you created from the list of patch plans.
- Click Next.
- In the Patches & Updates, under the Patches tab, click on Add Patch.
- Search and select a SOA or Oracle Service Bus patch and select the same domain target.
- Enter the rest of the details in the EM User Interface, validate the credentials, and choose the customization required. Ensure that the data prefilled or selected is accurate.
- Click Analyze. The deployment procedure is submitted.
- Once analysis is complete click Review, for the tool to review, analyze, and validate the details.
- Click Next.
- Click Deploy. The deployment procedure is submitted and patching is in progress.
- The patch is deployed.
- The WebLogic Server patch is successfully applied.
Diagnosing and Resolving Patching Issues
This section describes the following:
Workaround for Errors
This section describes the workaround for the following errors:
Workaround for Missing Property Errors
Table 21-9 describes the possible missing property errors and the workarounds you can use to resolve them.
Table 21-9 Missing Properties Error and Workaround
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:
|
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:
|
Workaround for Unsupported Configuration Errors
Table 21-10 describes the possible unsupported configuration errors and the workarounds you can use to resolve them.
Table 21-10 Workaround 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. |
Common Patching Issues
- 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.
Note:
When patching Single Instance High Availability (SIHA)12.1.0.2 Oracle Database through Enterprise Manager 13.4 and Perl 5.38 Update, the database needs to be patched at least to version 12.1.0.2.191015, with the October 2019 or later GI PSU patch applied on the target.- In the header section of the Validation page or the Review page in the Create Plan Wizard, see: Figure 21-11.
- In the Issues to Resolve section of the Validation page, see:Figure 21-12.
- In the Plans region of the Patches & Updates page, see: Figure 21-13.
Figure 21-11 Patch Plan Errors Displayed on the Validation Page
Figure 21-12 Patch Plan Errors Displayed in the Issues to Resolve Section
Figure 21-13 Patch Plan Errors Displayed in the Plans Region
Resolving Patching Issues
Table 21-11 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 Troubleshooting Patching Issues.
Table 21-11 Diagnosing Patching Issues
Phase | State | Diagnosis and Resolution |
---|---|---|
Analysis |
Analysis In Progress |
N/A |
Analysis Error |
Review the following log file:
|
|
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. In case the Issues to Resolve table is empty, then exit and re-enter the plan. |
|
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:
|
|
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:
|
|
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 |
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 RAC One node, Oracle Grid Infrastructure, and Oracle Grid Infrastructure targets that are part of Oracle Exadata. For more information about the steps to rollback, see Rolling Back Patches. For all other targets, Cloud Control does not support the automatic rollback of patches, and therefore, you must roll back the patches manually.
Additional Patching Tasks You Can Perform
This section covers the additional tasks you can perform with patch plans. In particular, it covers the following:
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
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
On the Patches & Updates page, in the Plans region select a successfully analyzed deployable Patch Plan.
Note:
You can create a patch template only from one Patch Plan at a time.
-
Select Create Template. The Create New Plan Template dialog appears.
-
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
- From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
- On the Patches & Updates page, in the Plans region click the name of a successfully analyzed deployable patch plan. The Create Plan wizard appears.
- In the Create Plan Wizard, in the Review & Deploy page, click Save as Template.
- Enter a unique name for the template, then click Create Template.
Note:
You must create patch templates only with unique names.
Downloading Patches from a Patch Template
To download a patch from a patch template, follow these steps:
- From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
- On the Patches & Updates page, in the Plans region, select a patch template.
- From the context menu, select View. The Edit Template Wizard appears.
- In the Edit Template Wizard, on the Patches page, click a patch number. The patch details page appears.
- On the patch details page, click Download.
Deleting a Patch Template
- From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
- On the Patches & Updates page, in the Plans region select one or more patch templates. The context menu appears.
- 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.
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.
Note:
For more information, see Patch Plan Becomes Nondeployable and Fails.
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
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
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.
-
In the Create Plan Wizard, on the Patches page, Click Add Patch. The Edit Search window appears.
-
In the Edit Search window, search the patch to which you want to associate additional targets.
-
Select the patch that you want to add, then click Add to This Plan. The Add Patch To Plan window appears.
-
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, using a single patch plan, you can patch only one domain. However, if it is a shared domain, then the admin servers and Managed Servers running on different domains, which are shared with the domain being patched, are automatically added into the same plan.
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
-
From the Enterprise menu, select Provisioning and Patching, then select Patches & Updates.
-
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.
-
On the Patch Recommendations page, select a patch.
-
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
Manually Staging the Patching Root Component
For information on how to manually stage the patching root component, see Root Components for Patching.
Restricting Root User Access for Patching
For information on how to restrict the root user access, see Root Components for Patching.
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.
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:
- From the Enterprise menu, select Reports, then select Information Publisher Reports.
- 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.
Customizing Patching Deployment Procedures
This section describes how you can customize patching deployment procedures. For information about customizing deployment procedures in general, see Customizing Deployment Procedures. 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:
Customizing a Static Patching Deployment Procedure
To customize a default, static deployment procedure, and use it to patch your targets, follow these steps:
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.
Note:
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:
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 RAC One Node
-
Oracle Grid Infrastructure
-
Oracle Grid Infrastructure targets that are part of Oracle Exadata
- In Cloud Control, from the Enterprise menu, select Provisioning and Patching, and then click Patches and Updates.
- On the Patches and Updates page, in the Patch Search region, enter the patch that you want to rollback.
- 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.
- Click Create Plan.
- In the Create Plan Wizard, select Deployment Options.
- 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.
- On the Validation page, click Analyze to validate the plan. After a successful analysis, click Next.
- 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.
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 End-to-End Use Case: Patching Your Data Center.
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 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.