Overview of Patching and Upgrading GDS

Before and after patching, verify GDS service definitions and status with GDSCTL. To enable rolling zero-downtime upgrades, there are specific rules to follow.

What You Need to Know About Patching Global Data Services

Before patching:

Please ensure that all database services are defined correctly
and are running at the correct databases/instances.
Validate that the global services are defined correctly before
patching:
```
$ gdsctl config service -service <global-service-name>
```
Verify that the services are up and running on the correct
instances.
```
$ gdsctl status service -service lobal-service-name\>
```

After patching:

Please ensure that all database service definitions are correct,
and that they come up at the correct databases/instances.
Validate that the global services are defined correctly after
patching.
```
$ gdsctl config service -service <global-service-name>
```
Verify that the services are up and running on the correct
instances.
```
$ gdsctl status service -service <global-service-name>
```

What You Need to Know About Upgrading Global Data Services

There are four components that comprise the distributed Global Data Services infrastructure, and each component may reside in a separate installation and may be upgraded independently using the usual upgrade procedure; however, there are certain rules about component versioning that should be followed. The components and rules are as follows:

Catalog database: The catalog database is the central repository for the GDS metadata; it is a standard Oracle Database installation. The version of the catalog database must always be greater than or equal to the version of any GDSCTL session that connects to it, and exactly equal to the version of any global service manager server that connects to it, with one exception: to ease migration, the catalog may temporarily have a version greater than some global service manager servers that are connected to it, until any change is made to the catalog, at which time any connected global service manager that is not at the same version will be disconnected, and any stopped global service manager that is not at the same version will not be allowed to connect.
GDSCTL client: This component is run in an ad-hoc manner from a terminal session on any system that contains a global service manager installation. The version of the GDSCTL client is the version of the global service manager installation that it runs from.
Global service manager server: The version of the global service manager server is the version of the global service manager installation from which the server runs. A global service manager server cannot connect to any catalog database that is at a lower version than itself. A global service manager server cannot connect to any catalog database that is at a higher version than itself in which changes have already been made to the catalog at that higher version.
Pool database: A pool database is any database added to a GDS pool which runs a global service. You may upgrade or downgrade pool databases at any time.

Given these rules, it is possible to perform a rolling upgrade of the distributed GDS infrastructure with zero service downtime.

Parent topic: GDS Patching and Upgrading