Global Data Services Patching Example

This example shows the steps required to patch an active GDS environment.

This example us for the following context:

GSM on host gdsp1 in Ashburn region
GSM on host gdsp2 in Mumbai region
Catalog database on host gdscatp in Ashburn region
Operating system is Linux
gdspool (gdspry) database on host gdscomp in Ashburn region

example /etc/hosts file:

10.0.0.11 gdsp1.example.com gdsp1

10.0.0.19 gdscomp.example.com gdscomp

192.168.0.4 gdsp2.example.com gdsp2

10.0.0.167 gdscatp.example.com gdscatp

Before applying patches:

Ensure that you select the patch for your Linux distribution operating system (OS), complete any operating system updates, and ensure that prerequsites are met.
- Check your operating system (OS), and update it as needed (Red Hat Enterprise Linux (RHEL) or Oracle Linux (OL) For example, RHEL8, OL8, RHEL9, OL9. For example:
```
cat /etc/os-release
uname -r
```
- Ensure the OS is on a vendor-supported patch level (Oracle Linux / RHEL errata cadence).
- The required packages (glibc, libaio, and so on) match Oracle prerequisites for that release.
- The Time sync (chrony/ntpd), hostname and DNS stability, and basic hardening align with your internal standards.
Ensure that OPatch is the required minumum version for that release update. Confirm the current patch state:
- $ORACLE_HOME/Opatch/opatch version
- $ORACLE_HOME/Opatch/opatch lsinventory

Advised Order for Patching and Upgrading Global Data Services for Oracle Database 19c

For each host, capture the following
- cat /etc/os-release and uname -r
- GSM home paths and version evidence:
  - gsmctl status
  - opatch lsinventory from the GSM home
- The RU or patch IDs applied (from inventory output)
- Date, time and change ticket reference.
Download the RU you need, based on your database release. For example:
- Oracle Database 19c Proactive Patch Information (Doc ID 2521164.1)
- Download the 19.30 Database RU for Linux x86-64 (RHEL/OL8 uses the Linux x86-64 RU)
Review the RU readme. It will state the minimum required Opatch version. If needed, update OPatch first (see Knowledge Base My Oracle Support Doc ID 274526.1 / 6880880).

Unzip the RU into a staging directory. For example:

cd /u01/stage
unzip pRU_patch_190000_Linux-x86-64.zip
cd RU_patch_dir

First apply the RU on the gdscat database.

When the catalog database is unavailable during the upgrade, global services will remain available and applications will continue to connect to pool databases. Stop, patch or upgrade, then restart global service manager servers one at a time.

Note:

To ensure zero downtime, at least one global service manager server should always be running.

For example: Stop services for the home being patched.
```
# example (adjust to your environment)
srvctl stop database -d    # if GI-managed
# or:
sqlplus / as sysdba
SQL\> shutdown immediate;

lsnrctl stop LISTENER
```

Run a patch conflict directory (recommended). For example:

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./

You should see output similar to the following:

Prereq "checkConflictAgainstOHWithDetail" passed.

Apply Patch/Upgrade the catalog database. For example:

$ORACLE_HOME/OPatch/opatch apply
$ORACLE_HOME/OPatch/opatch lspatches

You should see an entry indicating you have installed the latest patch.

patch_number;Database Release Update : RU_number

patch_number;OCW RELEASE UPDATE RU_number

OPatch succeeded.

Stop GSM1 from the old GSM1 home.

GDSCTL> stop gsm -gsm gsm1;
GSM is stopped successfully
GDSCTL>

Run data patch.

cd $ORACLE_HOME/OPatch
./datapatch -sanity_checks
./datapatch -verbose

Check invalid objects on the CDB and PDBs and run $ORACLE_HOME/rdbms/admin/utlrp.sql to revalidate those objects.

sqlplus / as sysdba
SQL> select patch_id, action, status, description
     from dba_registry_sqlpatch
     order by action_time;

Recompile any invalid objects (Catalog CDB and PDBs)

sqlplus / as sysdba
SQL> select owner, status, count(*)
     from dba_objects
     where status <> 'VALID'
     group by owner, status
     order by 3 desc;

SQL> @?/rdbms/admin/utlrp.sql

Repeat invalid object checks in relevant PDBs if needed:

SQL> alter session set container=GDSCATP;
SQL> select owner, status, count(*)
     from dba_objects
     where status <> 'VALID'
     group by owner, status;

Start the listener.
```
$ lsnrctl start LISTENER
```

Suggested Steps to Patch the GSMs

Stop the GSM, apply the patch, then restart the GSMs one at a time. To ensure zero downtime, at least one global service manager server should always be running. Start on host gdsp1. When the patch has been applied and the GSM has been restarted, proceed to host gdsp2 and repeat the steps to patch the GSM.
Note:
Apply the 19.25 RU. Follow
the same patch apply steps used for the catalog database. Do not run
datapatch for GSM.

For example:

STEP_LIST_PLACEHOLDER_9

Parent topic: GDS Patching and Upgrading