Using Global Data Services (Architectures, Use Cases, Application Development)

Distributed Databases

Oracle Global Data Services (GDS) intelligently routes requests across distributed databases and shards according to data locality, improving performance, scalability, parallelism, and availability while presenting applications with a single logical database. Typical use cases include global e-commerce, social media, financial services, content delivery, and geographically distributed IoT processing.

Using Global Data Services with Oracle Sharding

Oracle Sharding and Oracle Globally Distributed Database distribute and replicate data across independent Oracle databases presented as one logical database, supporting elastic scaling to as many as 1,000 shards. Built on GDS, the architecture provides enterprise database capabilities while enabling data sovereignty, regulatory compliance, and data proximity across global regions.

Using True Cache with Global Data Services

Oracle True Cache provides an in-memory, consistent SQL cache that improves response times and reduces primary-database load, while GDS manages workload routing, load balancing, and failover across True Caches and database replicas. A typical deployment routes frequent reads to True Cache and writes or infrequent reads to the primary database using GDS catalogs, GSMs, global services, ONS, and connection pools, subject to service naming and patch requirements.

Supported Replication Technologies and Implementation Architectures

GDS abstracts replicated databases behind global services and provides workload routing, dynamic load balancing, role-aware failover and switchover, and centralized configuration and monitoring. Supported use cases include disaster recovery, read scaling, geographically distributed content and CRM systems, analytics, and mobile applications using Active Data Guard, GoldenGate, RAFT replication, or shared GDS infrastructure.

Using Oracle Active Data Guard with Global Data Services

This procedure performs a controlled, rolling relocation of sessions across an Active Data Guard reader farm. Administrators verify service status, stop the service without force to quiesce FAN-aware pools and drain connections, disconnect remaining sessions after transactions complete, confirm session removal, start the service on the target standby, and verify that new sessions connect successfully.

Using Oracle GoldenGate with Global Data Services

This procedure enables graceful GoldenGate role transitions by draining GDS service connections, disconnecting remaining sessions, verifying that Replicat has applied all source transactions using SCNs, and starting the service on the target database. GoldenGate must use dedicated TNS aliases rather than GDS services, heartbeat tables should track lag, and failover procedures can estimate potential data loss when the source is unavailable.

Using RAFT Replication with Global Data Services

RAFT is a consensus-based replication protocol that automatically maintains replication configuration and consistency across distributed database shards or replicas despite failures, partitions, message loss, or topology changes. It organizes data into replication units, supports active nodes and rapid sub-second failover, and is enabled for system-managed sharded databases by specifying native replication when creating the shard catalog.

One GDS Infrastructure for Many Replicated Configurations

A single Global Data Services infrastructure can manage multiple replicated database configurations, allowing organizations to support high availability, disaster recovery, and read scaling across several database groups through shared GDS management capabilities.

Summary: Replicated Databases Compared to Distributed Databases

Replicated and distributed database architectures address different requirements, so selection should be based on workload, availability, scalability, locality, and performance needs. Replication maintains copies of data across databases for failover and read scaling, whereas distribution partitions data across locations or shards to scale capacity and satisfy geographic or sovereignty requirements.

GDS Use Case Summary

GDS supports business continuity, resource optimization, geo-aware routing, replication-lag-aware reads, and accelerated queries through intelligent management of replicated and cached databases. GoldenGate active-active architectures can serve read-write and read-only workloads across replicas, Active Data Guard active-passive configurations centralize writes while scaling reads, and True Cache deployments offload selected or all read-only workloads from a primary database.

Application Development Considerations

Applications in GDS environments should use GDS capabilities for resilient connectivity, failover, and workload management. Key practices include evaluating workload suitability, separating read-only and read-write services, configuring FAN and ONS, using reliable client connection endpoints, enabling connection pooling and Fast Connection Failover, and controlling direct-connection surges.

Application Workload Suitability for Global Data Services

GDS is most appropriate for replication-aware applications that can separate read-only, read-mostly, and read-write workloads into distinct services. Suitable applications either avoid or resolve GoldenGate multi-master conflicts and ideally tolerate defined replication lag, allowing read workloads to use replicas while write workloads remain properly coordinated.

Using FAN ONS with Global Data Services

FAN uses Oracle Notification Service to propagate database availability and workload events to clients, enabling rapid failover and connection management across GDS environments. Applications should use dynamic GDS services, avoid administrative database or PDB services, enable FAN and ONS support in the client, rely on automatic ONS discovery where possible, and configure redundant node groups and endpoints for multi-site deployments.

Client Side Configuration

Clients should connect through multiple highly available GSM endpoints using dynamic global services, rather than local listeners, database services, or PDB services. Connection descriptors should use a single DESCRIPTION, load-balanced GSM addresses, suitable retry and timeout settings, and current client drivers to support FAN, failover, and reliable connection behavior.

Configuring FAN for Java Clients Using Universal Connection Pool

Oracle recommends UCP or WebLogic Active GridLink with the JDBC Thin Driver to provide Fast Connection Failover, enabled through the UCP FastConnectionFailoverEnabled property or automatically by Active GridLink. Configuration requires dynamic service URLs, ONS settings when needed, required JDBC, UCP, and ONS libraries, optional Application Continuity, and appropriate manual ONS endpoints for custom or multi-cluster environments.

Configuring FAN for OCI Clients

OCI clients provide FAN support at the driver level, including SQL*Plus and PHP when service notification, client event settings, and XML configuration are enabled. Administrators should use automatic ONS discovery from TNS addresses where possible, configure FAN events in the client network configuration, and ensure server-side FAN notification is enabled for all OCI-based clients.

Controlling Logon Storms

Connection pools are preferred for preventing logon storms, but direct-connection environments can be protected by increasing operating-system socket backlog capacity and the GSM listener queue size. Recommended tuning includes raising and persisting net.core.somaxconn and setting TCP.QUEUESIZE in sqlnet.ora, requiring root access for OS changes and database administration privileges for Oracle configuration changes.
Read More: Controlling Logon Storms