Skip Headers
Oracle® Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching
11g Release 1 (11.1.0.1.0)

E16599-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

19 Getting Started with Patching

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:

Getting Started with Patching

Table 19-0 shows the sequence of steps you must follow to successfully patch a target.

Table 19-1 Getting Started with Patching

Sequence Action More Information

Step 1

Meeting Prerequisites

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".

Step 2

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".

Step 3

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.

Step 4

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".

Step 5

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".


Best Practices

The following are the best practices you can implemented to make the Patch Management process simpler and efficient using Deployment Procedures:

Customizing a Deployment Procedure

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".

Enabling Secure Authentication

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.

Eliminating Patch Staging Requirement During Maintenance Downtimes

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:

Prestage the Patch While Running the Deployment Procedure in Analyze 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.

Figure 19-1 Specifying a Shared Stage Location

Specifying a Shared Stage Location

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.

Customize the Deployment Procedure to Make It 'Apply Only'

  1. 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.

    Figure 19-2 Disabling Staging Steps

    Disabled Staging Steps
  2. 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.

    Figure 19-3 Selecting Stage Location

    Selecting Stage Location
  3. 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.

Enabling Unattended Patching Using Remote Notifications

This section covers the following:

Enabling Notifications

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.

  1. 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".

    Figure 19-4 Enable Notification for Deployment Procedures

    Enable Notification for Deployment Procedures
  2. 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.

  3. 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.

Configuring Notification Rules

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.

Figure 19-5 Subscribe to Emails for the Standard 'PAF Status Notification' Rule

Subscribe to Emails

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:

  1. 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.

    Figure 19-6 "Create Like" of Standard PAF Notification Rule and incorporating changes

    Create Like of Standard PAF Notification Rule
  2. 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.

    Figure 19-7 Edit the Job of the new PAF Status Notification Rule

    Edit the Job of the new PAF Status Notification Rule

    Figure 19-8 Associate the job name of the Custom Deployment Procedure

    Associate the job name of the Custom Deployment Procedure
  3. 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.

    Figure 19-9 Set Notification Methods -Basic Email Notification and Advanced Notification Methods

    Set Notification Methods
  4. 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.

Using OPatch Options to Handle Issues Identified with Patches

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.

Figure 19-10 Advanced OPatch options UI field for additional flexibility with patching operation

Advanced OPatch options

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.

Figure 19-11 OPatch options as part of the Directive step

OPatch options as part of the Directive step

Handling Patch Selection During Rollouts Involving Multiple Patches

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:

  1. 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.

    Figure 19-12 Creating Patch List

    Creating Patch List

    Table 19-2 shows the platform IDs for different platforms.

    Table 19-2 Platform IDs

    Platform Name Platform ID

    Linux x86

    46

    Linux x86_64

    226

    Windows_NT_32 bit

    912

    Solaris Sparc

    23

    HP UX Itanium

    197

    HP UX PARISC

    59

    IBM AIX 5L

    212


  2. 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:

    1. In Grid Control, click Deployments, then Provisioning.

    2. On the Components page, click Create Component.

    3. In the Describe page, select Generic Component from Type list, and specify a name for the component. Click Next.

    4. On the Customize page, click Next.

    5. On the Upload File page, select an appropriate option and upload the patch list file.

    6. On the Set Directives page, click Next.

    7. On the Review page, click Finish.

  3. In Grid Control, Click Deployments.

  4. In the Patching section, click Patching through Deployment Procedures.

  5. On the Deployment Procedure Manager page, select a patching Deployment Procedure you want to run. Click Schedule Deployment.

  6. On the Software Updates page, from the Standalone Database Updates section, click Upload From File.

  7. On the Upload File page, select a source where the patch list file is available, and click Upload.

    Figure 19-13 Selecting the Patch List

    Selecting the Patch List
  8. On the Software Update page, in the Standalone Database Updates section, you should see the patches automatically selected using the patch list file.

  9. Provide the required details for the rest of the Deployment Procedure and submit it.

Rolling Back a Patch

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.

Recommendations for Testing and Implementation

The following are the recommendations for testing and implementation: