This chapter describes the best practices for running patching Deployment Procedures and helps you get started with the patching operation. In particular, this chapter covers the following:
Table 19-0 shows the sequence of steps you must follow to successfully patch a target.
Ensure that you meet all the prerequisites, mainly creating and configuring Oracle Software Library (Software Library), applying mandatory patches, uploading OPatches to the Software Library, and meeting all other prerequisites for online and offline patching.
For information about the prerequisites to be met, see the prerequisites section of the chapters in Part VI, "Patching".
Identifying Patchability of an Environment by Running EM Target Patchability Report
Run the Patchability Report to analyze the database environment and identify whether the database targets you want to patch are suitable for a patching operation . If they are not suitable, then you can diagnose and find out whether they are not suitable due to missing properties or unsupported configuration, and also resolve them based on the recommendations provided for those issues.
For information about the patchability report, see Appendix H, "About Patching Automation Reports".
Creating "Patch Plans", accumulating patches, and checking for conflicts
Create a Patch Plan and accumulate patches from various sources, such as patch recommendations, service requests, or even simple patch search results. Patch Plan is a feature that has resulted from the integration of My Oracle Support and Enterprise Manager 11g Grid Control. The feature helps you roll out patches as a group using My Oracle Support.
Using a Patch Plan, accumulate patches, validate applicability of the patches, identify patch conflicts, and resolve them beforehand. Then, select a Deployment Procedure to apply the patches.
Note: This requires connectivity to My Oracle Support.
For information about creating a Patch Plan, Creating a Patch Plan.
Running Pre-Flight Checks through Deployment Procedure in Analyze Mode
Simulate the patch execution by running the Deployment Procedures in Analyze Mode, and check whether the prerequisites and all other necessary requirements for patching are met. This way, you can resolve all operational conflicts and issues beforehand.
Note: If you are using Patch Plans to roll out patches, then first run the Deployment Procedure in Analyze mode, then reselect the Patch Plan and associate it with the Deployment Procedure, and then run the Deployment Procedure again in Deploy mode. The direct flow will be offered in the future release of Enterprise Manager Grid Control.
To understand how you can run the patching Deployment Procedures in Analyze Mode, see Chapter 21, "Simulating Patching Deployment Procedures to Check Prerequisites".
Deploying Patch Using Deployment Procedures
After ensuring that the prerequisites are met, go ahead and run the Deployment Procedure to patch a target.
To understand how you can run the patching Deployment Procedure, follow the instructions outlined in the chapters of Part VI, "Patching".
The following are the best practices you can implemented to make the Patch Management process simpler and efficient using Deployment Procedures:
The Deployment Procedures offered by Enterprise Manager Grid Control are default procedures that have been created considering all the best practices in the industry. You can, of course, use them with the default settings to patch your targets in the environment, however, you also have the choice of customizing them to include additional custom steps, disable unwanted steps, and use authentication tools to run some steps as another user.
By customizing Deployment Procedures, you can also implement different error handling methods. For example, in a patching operation where multiple hosts are patched in parallel, it may be wise to skip the host on which a failure occurs. However, failure on a device creation could render the remaining provisioning operation ineffective. Therefore, it may be necessary to abort the entire procedure for failure of such a step.
For more information about customizing a Deployment Procedure, see Chapter 31, "Customizing Deployment Procedures".
Occasionally, due to secure practices, the direct access to an account of a target (for example, an
Oracle user) might not be available. You might have deployed secure authentication software such as SUDO or Powerbroker to enable logging into the systems and carrying out the operations as a secure user (for example,
Oracle). The Deployment Procedures support enabling secure authentication to carry out orchestration. You can do one-time customization to enable SUDO, Power broker, or any other secure authentication modules.
For information about using Privilege Delegation to set SUDO/PAM, see Using Privilege Delegation. Also see My Oracle Support note 603108.1.
Typically, during patch rollouts using Deployment Procedures, multiple targets across hosts can be patched. In the standard mode, the Deployment Procedure stages the patch to every Oracle home and applies the patch from there.
Using the Deployment Procedure extensibility framework, you can opt to prestage the patch to a shared location amongst the servers being patched in a local hub (for example, if you have targets worldwide and if you are managing them from a central OMS, then you can prestage the patch to the regional location before patching the targets local to that location). This can be carried out as a pre-maintenance activity.
This approach eliminates the requirement for staging a patch during the maintenance window, and saves time and network bandwidth during the patching process.
The following are the two parts to this mode:
Select a Deployment Procedure (for example, Patch Oracle Database Procedure)
In the first step of the wizard, in the Select Stage Location section, specify a shared stage location or central stage location (see Figure 19-1). Save the location by clicking Save for further usage. The location can be any NFS location or can be on a Net App filer, which is accessible by the OMS and the targets to be patched.
Provide the required details in the wizard, and run the Deployment Procedure in Analyze mode so that you can check for prerequisites and also stage the patch in the specificed location.
Do a Create Like of the out-of-box patching Deployment Procedures. For example, select the Patch Oracle Database procedure. Create a Deployment Procedure, which has the staging steps in the procedure disabled as shown in Figure 19-2. Save the procedure with a new name such as Patch Oracle Database Procedure Apply Only.
Run the customized apply-only procedure that you saved in Step (1). In the first step of the run, select the stage location you saved or used when you ran the Deployment Procedure in Analyze mode.
Select the patch, select the targets, and then submit the procedure for execution. During the run, the patch will not get staged again, instead it will be selected from the specified pre-staged location.
This section covers the following:
The Deployment Procedures can be tied up with the Enteprise Manager notification systems to get notifications on the status of the procedure run. Deployment Procedures use the standard PAF Status Notification Rule to send out notifications. The prerequisite is to set the methods of notifications and their setup (such as SMTP server for emails) in Enterprise Manager Grid Control. Also, the standard rule can be customized to extend notifications to specific procedure runs and various methods of notification based on the requirement.
The following steps describe how you can enable notifications and get notified on the status of Deployment Procedures. This involves enabling of notifications in the required Deployment Procedures and by configuring the notification rule for specific jobs and methods of notification.
To enable the notification, do a Create Like of the out-of-box Deployment Procedure. Figure 19-4 illustrates the 'XYZ Corp Lab Database Patch Procedure', which is a copy of the out-of-box procedure "Patch Oracle Database".
Select Enable Notification. Provide a name for the "Procedure Status Notifications Job Tag". This is to create notification rules specific to a Deployment Procedure. Also, the job name can be associated to create a rule specific to this procedure and set notification methods as required. Figure 19-4 illustrates the Job tag specified as "LabSys_DBPatching_Notification", which is unique to the Deployment Procedure used to patch lab systems at XYZ Corp.
Select a status from Status for which Notification is to be Sent. The list displays the status for which you would want to be notified for this particular Deployment Procedure. In Figure 19-4, you will see that Action Required, Failed, and Succeeded are selected to receive the notifications.
The Provisioning Framework uses the out-of-box generic "PAF Status Notification" rule to send notifications for the status of the procedure run. The standard rule can be used to send the basic e-mail notifications.
To access the notification rules, Click Preferences. On the Preferences page, from the left menu bar, under Notification, click Rules. Figure 19-5 shows how to enable Subscribe options for the PAF Status Notification rule to send e-mails. Click Apply after subscribing.
Advanced users can customize the standard PAF Status Notification rule to receive notifications in required ways for specific Deployment Procedures. For example, you might want to be notified by e-mail for a test system procedure, but for a production run, you might want to be informed on the status through SMS alerts.
To incorporate specific requirements and enable different methods of notification, you need to edit the standard out-of-box notification rule and the job with a specific name, and associate a specific method of notification from the predefined notification methods. The following steps explain how you can do this:
Do a Create Like of the standard PAF Status Notification Rule. Provide a name. For example, based on the procedure you are configuring this for, you can name it 'Lab system databases patching procedure notification' rule. See Figure 19-6.
Select the Jobs subtab and edit the job to associate a job name (LabSys_DBPatching_Notification) with this new notification rule. Provide a name as the job name tag used during the customization of the Deployment Procedure for which notification is enabled.
Select the Methods subtab. Set the required notification method for the new rule. You can choose the basic "Send Email" option or select from various advanced notification methods available or incorporated by you. shows the notification methods, which have been created and available with Enterprise Manger Grid Control.
Save the new rule. This completes the process of enabling notifications and configuring rule for a specific Deployment Procedure.
On running the Deployment Procedure, based on the status selected under "Send Notification For Status" list, the users registered with the OMS will receive notifications on various notification methods deployed.
Note:The notification is sent to all registered e-mail addresses under the Enterprise Manager user account. If you want this only to a specific group or individual (for example, to the DBA group or DBA who is patching), you need to create a shared Enterprise Manager user or a separate Enterprise Manager account for the DBA, and register the specific e-mail address to notification setup by logging into Enterprise Manager with the specific Enterprise Manager user credentials.
When the Deployment Procedures are run in Analyze mode, they identify issues related to the patches selected. They can either be patch conflicts (can use the plans and go through the merge patch process or can also handle during the execution) or other issues such as failures associated with missing components.
By default, the patching Deployment Procedures (for example, Patch Oracle Database) trigger OPatch in napply mode with the option skip_subset. This option skips the molecules from applying if it is a subset of any patch in the Oracle home.
The standard patching Deployment Procedures support passing of additional OPatch options from the Select Patches screen of the patching Deployment Procedure to work around the conflicts.
However, this method is dynamic and requires users to input every time the procedure is run. If you want to incorporate these options as a part of the procedures for rollouts, you can hard-code the options in the directive step Apply Patches.
Select a patching Deployment Procedure, and do a Create Like of it. Select and edit the step Apply Patches, and in the Map Properties step, specify the required OPatch options. Save the procedure. See Figure 19-11.
Typical patch rollouts consist of two or more patches. In order to avoid errors while selecting the patches during a patching process, you can define the patches in a predefined patch list. After doing so, you can select the patch list instead of selecting the individual patches, and thereby avoid errors.
To create a patch list and use it for rollouts, follow these steps:
Create a patch list file with the details of the patches you want to roll out simultaneously. The patch list file must contain the patch ID, the platform ID, and the release number of the target on which you want to apply the patch. Ensure that you separate these values using a comma.
Table 19-2 shows the platform IDs for different platforms.
Store the patch list file either on your local host or upload it to the Software Library.
If you want to upload it to the Software Library, then follow these steps:
In Grid Control, click Deployments, then Provisioning.
On the Components page, click Create Component.
In the Describe page, select Generic Component from Type list, and specify a name for the component. Click Next.
On the Customize page, click Next.
On the Upload File page, select an appropriate option and upload the patch list file.
On the Set Directives page, click Next.
On the Review page, click Finish.
In Grid Control, Click Deployments.
In the Patching section, click Patching through Deployment Procedures.
On the Deployment Procedure Manager page, select a patching Deployment Procedure you want to run. Click Schedule Deployment.
On the Software Updates page, from the Standalone Database Updates section, click Upload From File.
On the Upload File page, select a source where the patch list file is available, and click Upload.
On the Software Update page, in the Standalone Database Updates section, you should see the patches automatically selected using the patch list file.
Provide the required details for the rest of the Deployment Procedure and submit it.
Deployment Procedures, by default, do not support rolling back of a patch. You can handle it by customization, either through a simple host command step or by associating a directive step to rollback the patches. For more information, see My Oracle Support note 577557.1.
Note:If there are failures while applying a patch, then OPatch automatically rolls back the patch and restores the system. However, patchset or patset failure cannot be rolled back, so you must follow the best practice of taking a backup of the Oracle home before applying patchsets.
The following are the recommendations for testing and implementation:
Use Oracle Management Service 11g Release 1 (11.1) that is updated with all the latest recommended patches
Select a canonical set of targets based on the production version
Select standalone databases to begin with and then move to RAC configuration
Run the Deployment Procedure in Analyze mode to check for prerequisites. After checking for prerequisites, run the Deployment Procedure in Deploy mode.
If you have secure authentication requirement, first use direct Oracle home credentials and then configure the Deployment Procedure for SUDO
Increase the coverage on the configurations gradually
Introduce best practices as applicable for your rollouts