Upgrading Global Data Services

Understand the recommended upgrade sequence for GDS components to maintain availability and achieve zero downtime.

Complete operating system (OS) updates before database and global service manager upgrades. Generally, an out-of-place (fresh) installation on a new server is simpler and safer than in-place.

For example, suppose you want to upgrade your operating system from Oreacle Linux 8 (OL8) to Oracle Linux 9 (OL9):

• Review the README to confirm that your Oracle database release, Grid Infrastructure (if used), and GSM/GDS versions are certified on OL9.
• Confirm that any required OS packages and kernel settings for that Oracle database release are available and supported on OL9.

An out-of-place upgrade for the operating system for this scenario includes the following:

• Build new OL9 hosts.
• Install the required Oracle software cleanly
• Move configurations from your old servers to the new servers, and roll over to the new servers, so that availability is maintained.
• SELinux mode If used, decide if it is enforcing or permissive apply any required policies.
• Apply firewalld rules for GSM listener ports and inter-node communication.
• Review any endpoint security/EDR agents that might block Oracle binaries or network ports.

For in-place operating system upgrades in particular, validate the upgrade:

• GSM server starts cleanly and stays up
• gdsctl client operations work (connect, status, configuration queries)
• Service failover/relocation works between GSM servers
• Basic client connectivity to services works from application subnets
• Logs show no recurring library/permission/crypto errors

For GSM upgrades generally, the order you should proceed is as follows:

1. Upgrade the catalog database. For best results this should be done 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.
2. Upgrade global service manager installations that are used to run GDSCTL clients, which do not also run a global service manager server (if any).

   Note:

   Global service manager upgrades should be done in-place; however, an in-place upgrade will cause erroneous error messages unless permissions on the following files for the following platforms are updated to 755:

   On Linux/Solaris64/Solaris Sparc64:

   $ORACLE_HOME/QOpatch/qopiprep.bat

   $ORACLE_HOME/jdk/bin/jcontrol

   $ORACLE_HOME/jdk/jre/bin/jcontrol

   On AIX:

   $ORACLE_HOME/QOpatch/qopiprep.bat

   $ORACLE_HOME/jdk/jre/bin/classic/libjvm.a

   $ORACLE_HOME/jdk/bin/policytool

   On HPI:

   $ORACLE_HOME/jdk/jre/lib/IA64N/server/Xusage.txt

   $ORACLE_HOME/jdk/jre/bin/jcontrol

   $ORACLE_HOME/QOpatch/qopiprep.bat

   On Windows, no error messages are expected.

3. Stop, upgrade, and restart all global service manager servers one-at-a-time. In order to ensure zero downtime, at least one global service manager server should always be running. Global service manager servers at an earlier version than the catalog will continue to operate fully until catalog changes are made.
4. Upgrade pool databases in any order, either before or after the global service manager and catalog database upgrades, at the discretion of the pool database administrator.

• SELinux mode (enforcing vs permissive) and any required policies
• firewalld rules for GSM listener ports and inter-node communication
• Any endpoint security/EDR agents that might block Oracle binaries or network ports

Parent topic: GDS Patching and Upgrading