Patching and Upgrading Oracle Globally Distributed Database

There are special considerations for patching and upgrading a distributed database deployment.

Patching Oracle Globally Distributed Database

Applying an Oracle patch to a distributed database environment can be done on a single shard or all shards; however, the method you use depends on the replication option used for the environment and the type of patch being applied.

Oracle Globally Distributed Database uses consolidated patching to update a shard director (GSM) ORACLE_HOME, so you must apply the Oracle Database release updates to the ORACLE_HOME to get security and Global Data Services fixes.

Most patches can be applied to a single shard at a time; however, some patches should be applied across all shards. Use Oracle’s best practices for applying patches to single shards just as you would a non-distributed database, keeping in mind the replication method that is being used with the distributed database.

Oracle opatchauto can be used to apply patches to multiple shards at a time, and can be done in a rolling manner. Data Guard configurations are applied one after another, and in some cases (depending on the patch) you can use Standby First patching.

If a patch addresses an issue with multi-shard queries, replication, or the sharding infrastructure, it should be applied to all of the shards in the distributed database.

Note:

Because logical standbys are not supported in Oracle Sharding, rolling upgrades may run into a DDL recovery issue because a physical standby database becomes a 'transient logical standby' during a rolling upgrade. To avoid this issue, follow the steps in Performing a Rolling Upgrade.

See Also:

Oracle OPatch User's Guide

Oracle Data Guard Concepts and Administration for information about patching in an Oracle Data Guard configuration.

Upgrading Oracle Globally Distributed Database Components

The order in which Oracle Globally Distributed Database components are upgraded is important for limiting downtime and avoiding errors as components are brought down and back online.

Upgrading the Oracle Globally Distributed Database environment is not much different from upgrading other Oracle Database and global service manager environments; however, the components must be upgraded in a particular sequence such that the shard catalog is upgraded first, followed by the shard directors, and finally the shards.

Before upgrading any Oracle Globally Distributed Database components you must

  • Complete any pending MOVE CHUNK operations that are in progress.

  • Do not start any new MOVE CHUNK operations.

  • Do not add any new shards during the upgrade process.

  1. Upgrade the shards with the following points in mind.

    • For system-managed distributed databases: upgrade each set of shards in a Data Guard Broker configuration in a rolling manner.

    • For user-defined distributed databases: upgrade each set of shards in a shardspace in a rolling manner.

    • For composite distributed databases: in a given shardspace, upgrade each set of shards in a Data Guard Broker configuration in a rolling manner.

  2. Upgrade the shard catalog database.

     For best results the catalog should be upgraded using a rolling database upgrade; however, global services will remain available during the upgrade if the catalog is unavailable, although service failover will not occur.

  3. Upgrade any shard directors that are used to run GDSCTL clients, and which do not also run a global service manager (GSM) server, before you update the shard directors running GSMs.
  4. For shard directors running GSMs, do the following steps on one GSM at a time.

    To ensure zero downtime, at least one GSM server should always be running. GSM servers at an earlier version than the catalog will continue to operate fully until catalog changes are made.

    1. Stop one of the GSMs to be upgraded.

    2. Copy the tnsnames.ora, gsm.ora, gsmwallet directory from the old version to the new version.

      After copying the gsm.ora file it needs to be edited. The WALLET_LOCATION DIRECTORY path needs to be updated to point to the new Oracle home location because it points to the old home gsmwallet directory.

      Ideally, wallets should be stored in a directory outside of Oracle Home, for example, in an Oracle Base admin directory.

    3. Connect to the new GSM using GDSCTL, and start the GSM.

    4. Stop the old GSM.

    For an example, see Global Data Services Patching and Upgrading Examples.

See Also:

Oracle Database Global Data Services Concepts and Administration Guide for information about upgrading the shard directors.

Oracle Data Guard Concepts and Administration for information about using DBMS_ROLLING to perform a rolling upgrade.

Oracle Data Guard Concepts and Administration for information about upgrading databases in an Oracle Data Guard configuration.

Performing a Rolling Upgrade

Because logical standbys are not supported by Oracle Globally Distributed Database, rolling upgrades may run into a DDL recovery issue because a physical standby database becomes a 'transient logical standby' during a rolling upgrade.

To avoid this issue, perform the following steps.

  1. Shut down the shard catalog database.
    Shutting down the shard catalog database prevents any shard director (GSM) from becoming the master, and the catalog will not try to apply any DDL in this state, but the shard director will continue in steady-state allowing production applications to connect and run.
  2. Perform the rolling upgrade.
  3. When the rolling upgrade is complete, start up the shard catalog database.

Note:

During a rolling upgrade, some operations such as automatic failover may not be available while the shard catalog is shut down.

Downgrading an Oracle Globally Distributed Database

Oracle Globally Distributed Database does not support downgrading.

Shard catalogs and shards cannot be downgraded.