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:
1. In the Overview section, validate the Patch Plan name. You can choose to edit it if you want.
2. (Optional) Enter a short description for the patch plan.
3. (Optional) In the Allow Access For section, click Add to grant patch plan access permissions to administrators or roles, for the current patch plan.
  In the Add Privileges to Administrators window, select an administrator or a role, the access permission that you want to grant, then click Add Privilege.
  Note:
  - From within a patch plan, you can only grant patch plan permissions to administrators or roles that have previously been created in Cloud Control. You cannot create administrators or roles from within a patch plan. For information on the roles and privileges required for patch plans and patch templates, see 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.
4. Click Next.
On the Patches page, do the following:
1. Review the patches added to the patch plan. Any recommended patches for your configuration are automatically added to the patch plan. In addition, any patches that you added manually are listed.
  
  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.
2. Click Next.
On the Deployment Options page, do the following:
1. In the How to Patch section, select the mode of patching that you want to use.
  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 Out-of-Place Patching.
  
  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.
2. In the Where to Stage section, do the following:
  In the Stage Patches section, select Yes for Stage Patches if you want the wizard to stage the patches from Software Library to a temporary location, before the patch is applied on the target. Specify the stage location. Select No for Stage Patches if you have already manually staged the patches that you want to apply. To manually stage a patch, download the patch, navigate to the location (parent directory) where you want to stage the patch, create a subdirectory with the same name as the patch zip file, then extract the contents of the patch zip file into this subdirectory. Specify the parent directory for Stage Location. If the stage location is a shared location, select Shared Location.
  
  For example, if you downloaded patch 699099.zip, and the stage location, which is the parent directory, is /u01/app/oracle/em/stagepatch, then, in this parent directory, create a subdirectory titled 699099 and extract the contents of the zip file. Specify /u01/app/oracle/em/stagepatch as the stage location.
  
  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.
3. 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.
4. (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.
  
  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 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.
5. 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.
6. 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, and Oracle SOA Infrastructure.
  
  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.
7. 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.
8. 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 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 targets from the source Oracle home to the cloned and patched Oracle home. The Prepare and Deploy operations enable you to minimize downtime.
  
  Once you click Deploy, a Deploy Confirmation dialog box appears, which enables you to schedule the Deploy operation. Select Deploy. If you want to begin the Deploy operation immediately, select Immediately. If you want to schedule the Deploy operation such that it begins at a later time, select Later, then specify the time. Click Submit.
  Note:
  Instead of patching your Oracle homes in out-of-place patching mode, you can provision an Oracle home directly from a software image stored in Software Library (that has the required patches). To do this, follow these steps:
  1. Use the Provision Oracle Database deployment procedure to provision the software image stored in Software Library to the required location on the host.
  2. Create a patch plan. Ensure that you add all the patches that are a part of the provisioned Oracle home to this plan.
  3. On the Deployment Options page, in the What to Patch section, specify the location of the provisioned Oracle home.
  4. Analyze and deploy the plan.
- 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.

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.