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

Follow us on Facebook, Twitter, or Oracle Blogs.