Oracle Global Data Services (GDS)

Oracle Global Data Services (GDS): Automated Workload Management for Replicated Databases (Video Included)

1. Introduction to Global Data Services (GDS)

Oracle Global Data Services (GDS) provides Automated Workload Management for Replicated Databases. It is designed to extend the concept of services to database replicas.

Key GDS Capabilities:

• Automatic and transparent client workload management across replicas.
• Workload routing based on load, locality, or replication lag.
• Inter-database Service failover across replicas.
• Load balancing, including connect-time and run-time capabilities.
• Centralized service management across replicas.

GDS databases must be Oracle Database EE 12.1+. They can be Single Instance or RAC, CDB or Non-CDB, and run on engineered systems (like Oracle Exadata) or commodity hardware. Importantly, GDS requires licensing for either Oracle Active Data Guard or Oracle GoldenGate.

2. Benefits of Oracle GDS

Implementing GDS helps maximize your application performance and mitigate downtime during planned and unplanned outages.

Benefit Area	Details & Insights	Supporting Sources
High Availability & Downtime Mitigation	GDS provides automatic failover of client workload to another datacenter to mitigate unplanned outages. It enables continuous availability. For planned maintenance, GDS allows for transparent workload movement, achieving zero-downtime (e.g., during patching, as noted in a case study). GDS supports Global Service failovers for both Oracle GoldenGate and Active Data Guard.
Performance & Load Balancing	Applications use GDS to maximize performance. It routes workload based on load, locality, or lag. For Active/Active Oracle GoldenGate configurations, GDS can route all workloads to the nearest and best database in the client’s region (Region Affinity). GDS provides Connect-time Load Balancing (CLB) and Run-time Load Balancing (RLB) advisory to clients, supporting intelligent load balancing even across asymmetrical database servers.
Resource Utilization	GDS solves the challenge of unbalanced replicas by providing automatic and transparent client workload management. It enables better resource utilization of replicas, allowing workloads to be balanced on reader farms (e.g., Active Data Guard or GoldenGate reading farm) for improved scalability.
Manageability & Cost	GDS allows administrators to manage resources of replicas with one interface. It provides centralized management of database services across replicas. GDS is a cost-effective solution as it is included with Active Data Guard or Oracle GoldenGate.

 

3. Workload Management Challenges Addressed by GDS

Before GDS, managing workloads across replicas presented significant challenges:

Challenge Type	Description	Supporting Sources
Workload Balance	Replicated environments often suffer from no automated load balancing, leading to unbalanced resources and sub-optimal resource utilization across data centers.
Service Failover	Lack of Global Service Failover results in application outages when replicas fail, meaning there is No Service HA (High Availability).
General HA Deployment	Challenges associated with deploying highly available systems include the risk of failure, lack of skills, and high cost and complexity.

 

 

4. High-Level GDS Deployment and Usage

GDS is managed using the GDSCTL CLI or Enterprise Manager DB Plug-in.

A. GDS Deployment Steps (High Level):

1. Install GSM software on GSM servers (minimum of 1, recommended 3 GSMs per region).
2. Pre-create the GDS catalog database.
3. Setup GDS Administrator accounts & privileges (e.g., granting gsmadmin_role to the admin user on the GDS Catalog database).
4. Configure GDS using GDSCTL commands such as create catalog, add gsm, add gdspool, and add database. (Note: For Data Guard environments, add brokerconfig should be used instead of add database).
5. Define and start Global Services using GDSCTL (e.g., add service -service sales_qry_srvc -gdspool sales -preferred db01 –available db02).
• Services can be configured with attributes based on placement (-preferred, -available, -preferred_all), role (-role PRIMARY or PHYSICAL_STANDBY), lag tolerance (-lag 180), locality (LOCAL_ONLY, ANYWHERE), and load balancing goals (-clbgoal, -rlbgoal).

 

B. Client Connectivity and Application Requirements:

Applications must be GDS-Ready by adhering to specific configuration requirements:

• Use Oracle Integrated Connection Pools/Drivers (OCI, JDBC, ODP.NET, WebLogic).
• TNS entries must include the GSM Listener end points and specific parameters such as CONNECT_TIMEOUT, RETRY_COUNT, RETRY_DELAY, and TRANSPORT_CONNECT_TIMEOUT.
• For locality-based routing, specify the client’s REGION in the connection URL or TNS entry.
• Applications must subscribe to FAN events (published by GDS via ONS) by enabling Fast Connection Failover (FCF) to proactively handle instance events.

 

 

What is a GDS pool?

A Global Data Services pool (GDS pool) is a fundamental component of the Oracle Global Data Services (GDS) architecture, serving to group a collection of databases for administrative and service management purposes.

Here is a comprehensive breakdown of what a GDS pool is, based on the sources:

Definition and Purpose

• A GDS pool is a named subset of databases located within a larger GDS configuration.
• The databases in a GDS pool provide a unique set of global services.
• A GDS pool belongs to the same administrative domain.

Role in Management and Security

• Partitioning the databases in a GDS configuration into pools simplifies service management.
• GDS pools provide ** higher security** by allowing each pool to be administered by a different administrator.
• When configuring GDS, the GDSCTL command-line utility is used to add a GDS pool (e.g., add gdspool -gdspool sales).

Rules and Constraints

• A database can only belong to a single Global Data Services pool.
• While all databases in a pool do not necessarily need to provide the same set of global services, all databases that do provide the same global service must belong to the same pool.
• A Global Data Services region—a set of databases and clients sharing network proximity—can contain multiple GDS pools, and these pools can span multiple regions.
• For configurations involving Oracle Data Guard broker, only an entire broker configuration can be included in (or deleted from) a GDS pool, and a broker configuration cannot span multiple pools.
• A pool that contains a Data Guard configuration cannot have databases that do not belong to that configuration.
• The set of databases in a GDS pool must be either the set of databases that belong to a single broker configuration or a set of databases that do not belong to a broker configuration.

Usage Examples

The sources frequently use GDS pools (such as a "Sales GDS Pool" or "HR GDS Pool") in command examples to define where global services should run:

• When defining a global service, you must specify the pool it belongs to, along with its preferred and available databases. For example:

GDSCTL>add service -service sales_qry_srvc -gdspool sales -preferred db01 –available db02.

• One large company utilizes approximately 260 GDS Pools within their consolidated Oracle database environment.

List three GDS configuration topics.

The following three topics are central to configuring and managing an Oracle Global Data Services (GDS) environment:

1. Defining the GDS Configuration Components (Pools and Regions): A GDS configuration requires administrators to logically organize databases based on function and physical location. This involves defining:
• Global Data Services Pools: A named subset of databases within the configuration that provides a unique set of global services and belongs to the same administrative domain. All databases providing the same global service must belong to the same pool. Configuration involves using GDSCTL commands like add gdspool.
• Global Data Services Regions: A named subset of databases and clients that share network proximity (low network latency), usually corresponding to a local area network. A region may contain multiple GDS pools. Configuration involves adding regions (e.g., create catalog -region siteA, siteB).
2. Centralized Configuration Metadata (The GDS Catalog): The GDS environment relies on a central repository to store its definitions. The Global Data Services catalog is the repository that stores configuration data for the GDS configuration and all global services it provides.
• A catalog is associated with only one GDS configuration.
• The catalog must reside in an Oracle Database 12c or later database.
• Configuration steps include pre-creating the GDS catalog database and then using GDSCTL to create catalog.
3. Defining Global Services and Their Attributes: A Global Data Services configuration is primarily defined by the global services it offers, which are functionally similar to local database services but span multiple databases. Configuring these services dictates workload management behavior:
• Global services have a set of attributes that control starting the services, load balancing connections, and failing over those connections.
• Attributes unique to global services include preferred or available databases, replication lag tolerance, and region affinity.
• Configuration involves defining and starting these services using GDSCTL, specifying the service name, the GDS pool, and placement (e.g., -preferred db01 –available db02).

 

What Oracle database versions are supported?

Based on the sources, Oracle Global Data Services (GDS) is supported on specific Oracle Database versions:

• The databases participating in the GDS configuration (the GDS databases) must be Oracle Database EE 12.1+ (Enterprise Edition 12.1 or later).
• More broadly, database versions earlier than Oracle Database 12c can provide local services, but only Oracle Database 12c, and later, can provide global services.
• The Global Data Services catalog—the repository that stores configuration data—must reside in an Oracle Database 12c or later database.

Additionally, the sources mention Oracle Database 21c in the context of architecture:

• The multitenant container database (CDB) is the only supported architecture in Oracle Database 21c.

The GDS databases can be Single Instance or Oracle Real Application Clusters (Oracle RAC), and they can be CDB (Container Database) or Non-CDB.

  

List three unique global service attributes.

The sources explicitly identify the attributes that are unique to global services compared to traditional local database services.

Here are three unique global service attributes:

1. Preferred or Available Databases: Global services span the instances of multiple databases. Administrators must specify which databases support the global service, known as preferred databases. If a preferred database fails, the Global Service Manager (GSM) maintains the service cardinality by relocating the service to an available database. This attribute defines service placement across the entire Global Data Services (GDS) pool.
• Example options include: -preferred dbname_list, -available dbname_list, or -preferred_all (implying all databases in the pool are preferred).
2. Replication Lag (Lag Tolerance): This attribute establishes an application's tolerance for non-current data. When configured, GDS uses this setting to route requests only to replica databases that are not lagging behind the primary database by longer than the specified maximum acceptable lag value (in seconds).
• For applications that require real-time data, the lag time can be set to zero.
• This specification is supported for Active Data Guard configurations.
• Example option: -lag {lag_value | ANY} (e.g., -lag 180).
3. Region Affinity (Locality): This attribute controls where the service operates relative to the clients, enabling geographical affinity between clients and databases. The Global Service Manager (GSM) uses region affinity to route client connections based on network proximity.
• Any-Region Affinity (the default) routes a client request to the best database regardless of region, giving preference to a local region if databases are equally loaded.
• Affinity to a Local Region (LOCAL_ONLY) ensures that GDS will not route to databases in other regions, regardless of load.
• Affinity to a Local Region with Interregion Failover (LOCAL_ONLY -region_failover) attempts to use the local region first, but if all databases in the local region fail, the request is forwarded to a database in another region instead of being denied.

 

VIDEO: