Rolling back a previously applied SQL Server patch package


You can roll back a Microsoft SQL Server patch package that has been applied to a node, and return the node to the previous patch level.

A node might host:

  • Both primary and secondary instances of multiple clustered instances
  • Both primary and secondary replicas of multiple availability groups
  • A combination of the preceding types

BDA does not reboot such nodes during patching. The following reason appears in the Middle Tier:

<yyyy/mm/dd> HH:MM:SS [WARN] GA.MiddleTier.Process.RunMssqlPatch (pid: <processID> - line: <lineNumber> - file: <fileName>) These nodes will not be considered for reboot before or after patching or rollback activity: <nodeName1> <nodeName2> <nodeName3> ...
The reason being one of the below:
1. These nodes host both primary and secondary instance of multiple clustered instances
2. These nodes host both primary and secondary replicas of multiple availability groups
3. Combination of 1 and 2

Before you begin

  • The Can Rollback option is selected in the attributes for the package.
  • The host or database is running the latest hotfix.

To roll back an SQL Server patch package that has already been applied to a node

  1. From the Management Console main page, select Patching > Patch Repository in the Context Frame.
  2. In the Patch Repository page, select the patch package you want to uninstall, and select Rollback from the list box for that row. In the MS SQL Server Patch Rollback Candidates page, populate the following fields, and click Next.

  3. You can view a list of the targets that were excluded from the roll back candidates list and why specific databases did not meet the criteria for rollback by clicking Excluded Candidates
  4. On the Custom Fields page, populate the custom fields you have defined in the template, and click Next.

    Note

    This page appears only when in the BMC Database Automation XML template, either custom fields are defined used for this activity or New in 8.9.03any custom fields are defined for the scheduling options (present on the Scheduling page in this wizard). If you have defined custom fields, value of those options on the Scheduling page will be derived from these custom fields. For more information, see Adding-custom-fields-to-a-template.

  5. In the Job Options page, specify any of the following Job options, and click Next.

  6. In the Scheduling page, select when to run this job in the Job Execution field, and click Next.
    New in 8.9.03If you choose to run the job now or at a future time, optionally, you can use the Set Maintenance Window option to specify the Maintenance Window Start Time and the Maintenance Window End Time during which the job should be scheduled and running.
  7. If the Change Control page displays, populate the following fields, and click Next.

    Note

    The Change Control page appears only when change control is configured for your environment. See Configuring-change-control.

  8. In the Summary page, review the information.
    To make changes, do the following:
    1. Click Go to to return to the provisioning step that you want to edit.
    2. Make your changes.
    3. Click Save and Review to return to the Summary page.
  9. Specify your verification preferences.
    • To continue with database creation after the pre-verification tests have been successfully run without manual intervention, select Automatically Continue If All Tests Succeed.
    • To create the database without having first run the pre-verification steps, select Skip Pre-Verification Tests.

      Note

      The Skip Pre-Verification Tests option should only be used when you are certain all tests can succeed. The option skips verification and advances directly to the actual provisioning activity.

  10. Click Execute Job or Schedule Job (depending on your selection in the Scheduling page).


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*