Oracle Fail Safe allows a cluster system to continue providing service while the software is being upgraded to the next release. This process is called a rolling upgrade because each node is upgraded and restarted in turn, until all server nodes and all client nodes have been upgraded. You might want to perform a rolling upgrade for the following reasons:
To upgrade the Oracle Fail Safe software or install patches
To upgrade or patch a highly available Oracle single-instance database
To upgrade or patch other Oracle software
When you upgrade Oracle software, do not start the installation when any Oracle Fail Safe Manager operations or Microsoft Windows Failover Cluster Manager operations are in progress on groups. You must wait for a quiet period in cluster operations before you proceed with the upgrade.
Note:
To ensure minimal downtime and to identify any potential issues with other software that might be running on the cluster, Oracle recommends that you test the operations described in this appendix on an identically configured test cluster before you upgrade the production cluster.
This appendix includes the following topics:
During a rolling upgrade, you need to perform a planned failover to make the cluster resources running on one node move to another node. Each planned failover will disconnect users and cause a rollback of any interrupted, uncommitted work if a database is involved in the operation.
This brief outage typically is less than 1 minute and always is less than the downtime that would be experienced by users if Oracle Fail Safe was not installed. To prevent loss of work, notify users that you plan to shut down the system, and have all users commit their work and log off before you perform the failover. Advise users when they can reconnect and resume work after the database fails over to another cluster node.
While you are performing upgrades to a two-node cluster, remember that failback is disabled and your cluster is not protected against failures. In addition, each time that you stop and restart the cluster service on a node, all remaining cluster resources running on the node fail over to another node with a similar brief loss of service.
Oracle recommends the following procedure for upgrading software on your cluster when just the database software or both the database software and Oracle Fail Safe software must be upgraded.
Remove each database from its group.
Upgrade the Oracle Database software and the Oracle Fail Safe software if required. The order in which you perform these two upgrades is not important.
Add each database back to its group.
If you are only performing an Oracle Fail Safe software upgrade or applying a patch to the database software (but you are not going to upgrade the database software), then you do not need to remove any database from its group before doing an upgrade or applying the patch.
Patching typically involves updating the software from one release to another where only the fourth or fifth digit in the release number changes, for example, 11.1.0.6 to 11.1.0.7. An upgrade is required when the first, second, or third digit in the release number changes, for example 11.1.0 to 11.2.0 or 11.2.0 to 12.1.0.
See Also:
Oracle Database Upgrade Guide for information about prerequisites for preparing a new Oracle home on Windows
This section describes how to perform a rolling upgrade when you want to upgrade the Oracle Fail Safe software on a cluster that is currently running Oracle Fail Safe (for example, to upgrade the cluster from Oracle Fail Safe release 4.1.1 to release 4.2.1). The tasks described in this section apply to upgrades from any Oracle Fail Safe release before the current Oracle Fail Safe release.
If you are performing a rolling upgrade of the Oracle Fail Safe software, then you must upgrade the Oracle Fail Safe and Oracle Fail Safe Manager software clusterwide. You cannot run multiple releases of the Oracle Fail Safe software on the same cluster. See Oracle Fail Safe Release Notes for Microsoft Windows for information about the compatibility of various Oracle Fail Safe Manager releases with various releases of Oracle Fail Safe Server or Oracle Fail Safe.
Perform the steps described in Table A-1 on only one cluster node at a time.
Table A-1 Steps Required to Upgrade Oracle Fail Safe
| Step | Task | Tool | Comments |
|---|---|---|---|
|
1 |
Change the group attributes to the Prevent Failback mode for each group. |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
Changing the failback attributes prevents the group from failing back after its preferred node is restarted (later in Step 6). |
|
2 |
Move groups off the node on which you plan to perform the upgrade. |
Microsoft Windows Failover Cluster Manager |
In the tree view, right-click the group, then select Move. Repeat for each group on the node. By moving groups to another node, you can upgrade the current node while users continue to access the group on another node. When moving groups that contain databases with this method, Oracle Fail Safe will perform a checkpoint operation. |
|
3 |
Exit Microsoft Windows Failover Cluster Manager. |
Microsoft Windows Failover Cluster Manager |
From the File menu, select Exit. Note: Do not use Oracle Fail Safe Manager on other cluster nodes during the rest of the upgrade procedure until you run Validate cluster in Step 11. |
|
4 |
Deinstall the previous release of Oracle Fail Safe Manager and Oracle Fail Safe. |
Oracle Universal Installer |
See Deinstalling Oracle Fail Safe for instructions. Note: Perform this step only when installing a new release. |
|
5 |
Install the current Oracle Fail Safe release or patch set. |
Oracle Fail Safe installation kit |
You must install the same release of Oracle Fail Safe software on all server nodes in the cluster. Follow the installation instructions in Installing Oracle Fail Safe. |
|
6 |
Move groups that contain Oracle databases to the upgraded node. |
Microsoft Windows Failover Cluster Manager |
Move cluster groups that contain Oracle databases to the upgraded node. Note: To avoid problems that can arise due to version mismatches, do not use Oracle Fail Safe Manager to perform this task; use Microsoft Windows Failover Cluster Manager. |
|
7 |
Repeat steps 4 through 6 on the other cluster node or nodes. |
Various |
No comments. |
|
8 |
Run the Validate cluster operation. |
Oracle Fail Safe Manager |
Right-click the cluster name in the tree view, then select Validate. This step verifies that there are no discrepancies in the software installation (such as with the release information) on each node in the cluster, and registers resource DLLs. |
|
9 |
Review the Validate report. |
Oracle Fail Safe Manager |
Carefully review each error or warning and take corrective action if necessary. |
|
10 |
Restore the failback policy attributes on the groups. |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
|
|
11 |
Move each group back to its preferred node. |
Oracle Fail Safe Manager |
In the tree view, right-click the group, then select Move. If you are working in a two-node cluster, then you will be asked to confirm the move to the other node. If you are working in a cluster that contains more than two nodes, then you will be asked to select the destination node. This step redistributes the workload across the nodes in the cluster. |
|
12 |
Run the Validate group operation on all groups. |
Oracle Fail Safe Manager |
In the tree view, right-click a group, then select Validate to check all resources and confirm that they have been configured correctly. Repeat for each group in the cluster. See Oracle Fail Safe Concepts and Administration Guide for Microsoft Windows for a description of the validation tests performed during a Validate Configuration of the Oracle Resources group operation. |
Note:
In Windows, "service or application" or "clustered role" is sometimes referred to as a group.
Patching typically involves updating the database from one release to another where only the fourth or fifth digit in the release number changes, for example, 11.1.0.6 to 11.1.0.7. An upgrade is required when the first, second, or third digit in the release number changes, for example 11.1.0 to 11.2.0 or 11.2.0 to 12.1.0.
See Also:
Oracle Database Upgrade Guide for information about upgrading to the new release of Oracle Database
This section contains the following topics:
An upgrade requires installing a new release of the database. You must install the software for the new Oracle Database release before you can perform the upgrade of Oracle Database. The installation procedure for the new Oracle Database 12c Release 1 (12.1) installs the Oracle software into a new Oracle home.
Oracle recommends that you back up your database before performing the upgrade.
Follow the steps in Table A-2 to perform the upgrade. Perform the steps described on one cluster node at a time.
Table A-2 Steps for Upgrading a Database Configured for High Availability
| Step | Task | Tool | Comments |
|---|---|---|---|
|
1 |
Check compatibility |
Not applicable |
Ensure that the release of the database to which you plan to upgrade is compatible with the version of Oracle Fail Safe that you run. See the section on software compatibility in the Oracle Fail Safe Release Notes for Microsoft Windows. If the Oracle Database release and the Oracle Fail Safe software release are not compatible, then see Upgrading the Oracle Fail Safe Software and Installing Patches. |
|
2 |
Install the Oracle Database software on each cluster node. |
Oracle Universal Installer |
Use the same directory and Oracle home name on each cluster node. |
|
3 |
Remove each database from its group. |
Oracle Fail Safe Manager |
Perform the following steps:
|
|
4 |
Upgrade each database. |
Database Migration Assistant (or perform manually) |
Instructions for performing the upgrade are included in the database upgrade (or migration) manual for the release to which you are upgrading. |
|
5 |
Validate each standalone database |
Oracle Fail Safe Manager |
Perform the following steps:
|
|
6 |
Add each database back to its original group. |
Oracle Fail Safe Manager |
Perform the following steps:
|
When you patch a database that has been configured for high availability, it is not necessary to remove the database from the group before applying the patch.
Oracle Database 12c Release 1 (12.1) is a full release that includes all the latest patches and updates for Oracle Database. It is not necessary to check for patch set updates before proceeding with the upgrade process for this release. However, Oracle recommends that you periodically check for patches and patch set updates as a part of database administration.
Table A-3 describes how to patch databases configured for high availability in a two-node cluster. These steps assume that there are two nodes, Node A and Node B, and that Node A is the first node that will be patched. Perform these steps on only one cluster node at a time.
Table A-3 Steps for Patching a Database Configured for High Availability
| Step | Task | Tool | Comments |
|---|---|---|---|
|
1 |
Change the failback attributes to Prevent Failback for each group in the cluster. |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
|
|
2 |
Move all groups on Node A to Node B. |
Microsoft Windows Failover Cluster Manager |
In the tree view, right-click the group, then select Move. Repeat for each group on Node A. Use Microsoft Windows Failover Cluster Manager to move the Cluster Group if it is on Node A. By moving groups to another node, you can upgrade the current node while users continue to access the group on another node. When moving groups that contain databases with this method, Oracle Fail Safe will perform a checkpoint operation. |
|
3 |
Exit Oracle Fail Safe Manager and Microsoft Windows Failover Cluster Manager. |
Microsoft Windows Failover Cluster Manager |
In the File menu, select Exit. (The steps are the same in both Oracle Fail Safe Manager and Microsoft Windows Failover Cluster Manager.) |
|
4 |
Stop the cluster service on Node A. |
Microsoft Control Panel |
Open the Microsoft Windows Services window and then stop the Cluster Services service. |
|
5 |
Stop all running Oracle applications and all remaining Oracle services. |
Microsoft Control Panel |
Open the Microsoft Windows Services window and then stop all running Oracle services, including the Oracle Fail Safe service and the Distributed Transaction Coordinator Service (if it is running). |
|
6 |
Install the database patch in the correct home on Node A. |
Oracle Universal Installer |
Follow the instructions that come with the patch. If you did not stop the Distributed Transaction Coordinator Service in Step 5, then it is likely that a write error for |
|
7 |
Adjust the initialization parameter file, if needed. |
Editor of choice for pfile, SQL ALTER SYSTEM statement for spfile. |
Changes to the initialization parameter file should be made before databases are failed back. See the readme file supplied with the database patch for information about required parameter file changes. If you are maintaining multiple copies of the initialization parameter file (pfile) as you are maintaining them on private disks, then ensure that you update the file that will be used when the database is moved back to the current node. Once the patch scripts are completed, you will change the initialization parameter file back to the original values and restart the database. |
|
8 |
Move groups back to the selected node. |
Oracle Fail Safe Manager |
Once the groups are moved back to Node A, they will be restarted and running under the patched version of the database management system. Therefore, run the patch scripts as soon as the groups are moved back. By having changed the initialization parameter file as described in Step 8, you ensure that the database starts with the parameters needed to complete the patch. |
|
9 |
Restrict user access on each database to be upgraded. |
SQL*Plus |
As each database comes online on the selected node, restrict user access with the following SQL statement: ALTER SYSTEM ENABLE RESTRICTED SESSION; Do this as soon as possible after the database instance starts to prevent users from connecting to the database while the upgrade scripts run. You can also take the listener service for the group offline to prevent users from making Oracle Net connections. |
|
10 |
Run the upgrade scripts for the patch against each database being patched. |
SQL*Plus |
See the readme file supplied with the database patch. |
|
11 |
Repeat steps 4 through 7, replacing Node A in the instructions with Node B. |
Various |
To save time, you can run the upgrade scripts against the databases on Node A while the patch is being installed on Node B. |
|
12 |
Validate each group in the cluster. |
Oracle Fail Safe Manager |
In the tree view, right-click a group name, then select Validate. Repeat for each group in the cluster. |
|
13 |
End the restricted session on each database. |
SQL*Plus |
End the restricted session on each database with the following SQL statement: SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION; |
|
14 |
Validate the cluster. |
Oracle Fail Safe Manager |
In the tree view, right-click the cluster name, then select Validate. |
|
15 |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
|
|
|
16 |
Move each group back to its preferred node. |
Oracle Fail Safe Manager |
In the tree view, right-click a group name, then select Move. Repeat for each node in the cluster. This step balances the workload across the nodes in the cluster. |
Refer to the Oracle Fail Safe Concepts and Administration Guide for Microsoft Windows for instructions to use the Oracle Database Upgrade Assistant (DBUA) to upgrade a single-instance fail-safe database from one release to another or to move a single-instance Oracle database from one Oracle home to another.
See Also:
Oracle Database Upgrade Guide for information about using DBUA to upgrade the database
This section describes upgrading non-database Oracle product software and installing patches that require you to stop the Oracle services being used by Oracle Fail Safe. See Upgrading or Patching a Highly Available Oracle Database for the same information on Oracle Database software.
If your cluster is in an active/passive configuration, then you can eliminate a failover if you start the rolling upgrade on the passive cluster node. Once you have finished the upgrade on the passive cluster node, you can skip to Step 4 in Table A-4.
Perform the steps on one cluster node at a time.
Table A-4 Steps Required to Upgrade Other Oracle Product Software
| Step | Task | Tool | Comments |
|---|---|---|---|
|
1 |
Change the group failback attributes to the Prevent Failback mode. |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
|
|
2 |
Move groups off the node on which you plan to perform the upgrade. |
Microsoft Windows Failover Cluster Manager |
In the tree view, right-click the group, then select Move. By moving all groups to another node, you can work on the current node. When you use this method to move groups that contain databases, Oracle Fail Safe performs a checkpoint operation. |
|
3 |
Exit Microsoft Windows Failover Cluster Manager. |
Microsoft Windows Failover Cluster Manager |
On the current node, in the File menu, select Exit. |
|
4 |
Stop the cluster service on the node where you want to install the software. |
Microsoft Control Panel |
Open the Services window and stop the Cluster Service. |
|
5 |
Stop all running Oracle applications and all remaining Oracle services. |
Microsoft Control Panel |
Open the Services window and then stop all running Oracle services, including the Oracle Fail Safe service. |
|
6 |
Install the new Oracle product or component software. |
Oracle Universal Installer |
Follow the instructions that come with the Oracle product or component. |
|
7 |
Run the Validate operation on all groups. |
Oracle Fail Safe Manager |
In the tree view, right-click a group name, then select Validate to check all resources in the group and confirm that they have been configured correctly. Repeat for each group in the cluster. |
|
8 |
Repeat steps 2 through 8 on the other server node or nodes in the cluster. |
Various |
No comments. |
|
9 |
Run the Validate operation. |
Oracle Fail Safe Manager |
In the tree view, right-click the cluster name, then select Validate. This step verifies that there are no discrepancies in the software installation (such as with the release information) on each node in the cluster. |
|
10 |
Restore the failback policy attributes on the groups. |
Microsoft Windows Failover Cluster Manager |
Perform the following steps:
|
|
11 |
Move each group back to its preferred node. |
Oracle Fail Safe Manager |
In the tree view, right-click a group name, then select Move. Repeat for each node in the cluster. This step balances the workload across the nodes in the cluster. |