by Tim Read
Published May 2012Part I - Overview of the Example Configuration
The first step in the upgrade process is to check that the target configuration you plan to use is supported under the Oracle Solaris 11 and Oracle Solaris Cluster 4.0 software. This check must include all the components in the application stack, as well as any replication technology you intend to use to transfer the data between the clusters. Once the target configuration is validated, then you can start the process of building the second cluster and setting up the replication.
In this example, we use an Oracle Database 11g Release 2 database that we want to upgrade from the global zone of an Oracle Solaris 10 cluster to a zone cluster on a new Oracle Solaris Cluster 4.0 system. This virtualized approach is often used when consolidating multiple clusters onto a single physical cluster. We could also have chosen to upgrade our database to the global zone of our Oracle Solaris 11 cluster if desired.
In the example, both clusters store the database data in a ZFS file system and the Data Guard feature of Oracle Active Data Guard is used to replicate the data between the clusters. The example could equally well have shown a configuration that used Oracle Grid Infrastructure running Oracle Real Application Clusters (Oracle RAC) with the data stored in Oracle Automatic Storage Management, but that would be a little too complex for the purposes of this series of articles. Even with this simpler example, the upgrade process could take several days depending on the size and complexity of your configurations.
The example configuration runs an Oracle Database version 184.108.40.206 database on both the Oracle Solaris 10 and Oracle Solaris 11 clusters, because that version is the first supported database release that the operating systems share in common.
For convenience, both clusters use a quorum server located on the network. Quorum servers can be particularly useful if you have campus clusters; however, for most standard data center deployments, configuring a single quorum disk per cluster is sufficient.
The precise details of the servers used in the example are not important, but Figure 1 gives a high-level view of the network and storage topology. Although the clusters in the example have minimal network and storage configurations, using redundant network and storage connectivity for all mission-critical production clusters is recommended.
Figure 1. Overview of the Clusters Used in the Example
Table 1 provides an overview of the steps involved in the upgrade process and who is responsible for completing them.Table 1. Upgrade Steps and Step Owners
|Ensure the existing database is prepared for the upgrade by checking the listener, name service, and wallet setup. Configure logging properties.||Oracle Database administrator|
|Ensure the existing database is integrated with Oracle Solaris Cluster 3.3 5/11 software by creating resource group and resources.||System administrator or role-based access control (RBAC) authorized user|
|Install Oracle Solaris 11 on the target cluster nodes.||System administrator|
|Install and configure Oracle Solaris Cluster 4.0 software on the target cluster nodes.||System administrator|
|Create a zone cluster on the target Oracle Solaris Cluster 4.0 system.||System administrator|
|Create file systems, logical host addresses, and user IDs for the zone cluster nodes.||System administrator|
|Create a resource group and resources that add the file system and logical host address online on the zone cluster.||System administrator|
|Add any extra Oracle Solaris 11 packages needed by the application stack to the zone cluster installations.||System administrator|
|Install the Oracle Database 220.127.116.11 software on the zone cluster nodes.||Oracle Database administrator|
|Ensure the new database is ready by creating the listener, name service, and wallet setup. Use a modified copy of the original database initialization parameters to start up a standby database.||Oracle Database administrator|
|Back up the original database and restore it on the new zone cluster, and then begin the recovery process.||Oracle Database administrator|
|Integrate the new standby database with Oracle Solaris Cluster 4.0 software by creating a resource group and resources.||System administrator or RBAC authorized user|
|Update the database parameters at both sites and then create the Data Guard broker configuration.||Oracle Database administrator|
|Disable Oracle Solaris Cluster's Oracle Database agent monitoring at both sites.||System administrator or RBAC authorized user|
|At a suitable point, test the Data Guard broker switchover.||Oracle Database administrator|
|Re-enable Oracle Solaris Cluster's Oracle Database agent monitoring at both sites.||System administrator or RBAC authorized user|
|Start the Oracle Solaris Cluster Geographic Edition software at both sites.||System administrator or RBAC authorized user|
|Add trust between the Oracle Solaris Cluster Geographic Edition installations.||System administrator or RBAC authorized user|
|Create a partnership between the Oracle Solaris Cluster Geographic Edition installations. Then create a protection group for the Data Guard broker configuration. Start the protection group to re-enable the Data Guard replication.||System administrator or RBAC authorized user|
|At a suitable point, test the Oracle Solaris Cluster Geographic Edition switchover.||System administrator or RBAC authorized user|
|Revision 1.0, 05/01/2012|