Oracle Global Data Services

Oracle logo

October 2025

Copyright © 2005, 2025 Oracle and/or its affiliates

GDS General Architecture

Database Tier Application Tier Routing Tier (Global Data Services) Shared Memory Client A Client B Connection Pool UCP, OCI, ODP.NET ONS Client ONS Server Network ONS Client ONS Server Global Service Manager(s) GDS Catalog Single-Instance/ Oracle RAC with Standby Fast Application
Notification (FAN) Fast Application
Notification (FAN) ONS:6234 TNS:1522 TNS :1521 TNS:1521 TNS:1521 ONS:6234 Oracle GoldenGate or Oracle Active Data Guard or Oracle True Cache Primary Single Instance/ Oracle RAC Standby Single-Instance/ Oracle RAC

Notes

Oracle Global Data Services (GDS) is a holistic automated workload management feature of Oracle Database. GDS is engineered to provide a unified and intelligent solution to the challenges of modern enterprises by introducing centralized service management, dynamic load balancing, and automated failover capabilities. It abstracts the complexity of managing replicated and distributed databases, enabling enterprises to focus on their business goals rather than operational overhead.

The services sit between your application and database tiers and helps direct application connections to the most appropriate destination.

Instead of connecting directly to a specific database, applications connect to an Oracle GDS, which then intelligently routes the connection to the optimal database instance based on factors such as:

- Workload type: Read-only versus Read-write

- Database role: Primary, Standby, or Cache

- Location: Geographic proximity for reduced latency

- Database load: Distributing connections evenly

- Database health: Avoiding failed or overloaded instances

A Global Data Services configuration and its global services are created and managed using the GDSCTL command-line interface.

Oracle GDS components include:

Global Data Services Pool

Global Data Services pool or connection pool is a named subset of databases within a GDS configuration that provides a unique set of global services and belongs to the same administrative domain. Partitioning of GDS configuration databases into pools simplifies service management and provides higher security by allowing each pool to be administered by a different administrator.

A database can only belong to a single Global Data Services pool. All databases in a pool need not provide the same set of global services. However, all databases that provide the same global service must belong to the same pool.

Global Data Services Region

A Global Data Services region is a named subset of databases in a GDS configuration and database clients that share network proximity such that the network latency between members of a region is typically lower than between members of different regions. A region usually corresponds to a local area or metropolitan area network (LAN or MAN). For example, a data center hosting one or more GDS configuration databases and database clients in geographical proximity to the data center might belong to the same region.

A region can contain multiple Global Data Services pools, and these pools can span multiple regions.

Global Service Manager

Global Service Manager (GSM) is the central software component of Global Data Services, providing service-level load balancing, failover, and centralized management of services in the GDS configuration. Global Data Service clients use a global service manager to perform all GDS configuration operations. 

A global service manager is analogous to the remote listener in an Oracle RAC database, except that a global service manager serves multiple databases.

A global service manager is associated with one and only one GDS configuration. Each region in the GDS configuration must have at least one global service manager. For high availability, Oracle recommends including at least three global service managers in each region. Every global service manager in a GDS configuration manages all global services supported by the configuration.

Global Data Services Catalog

A Global Data Services Catalog is a repository that stores configuration data for a Global Data Services configuration and all global services provided by that configuration.

A catalog is associated with one and only one GDS configuration. A catalog must reside in an Oracle database, and that database may be inside or outside the associated GDS configuration. For large-scale GDS configurations, it is recommended that the GDS catalog be hosted outside the databases in the GDS configuration. GDS catalog may be co-hosted along with catalogs of RMAN or Oracle Enterprise Manager.

Oracle recommends including a GDS Catalog Standby using Oracle Data Guard to enhance the availability of the Global Data Services Catalog database.

Oracle Notification Service Servers

GDS clients use Oracle Notification Service (ONS) to receive run-time load balancing advisory and high availability events from global service managers.

An Oracle Notification Service (ONS) server is co-located with each global service manager. All such ONS servers within a region are interconnected. Clients of global services subscribe to the ONS server network within their region and its buddy region and receive FAN notifications from those ONS server networks.

Related Resources

GDS Full-Fledged Deployment Architecture

West Region East Region Database Tier Database Pool Database Pool Database Pool Application Tier Routing Tier (Global Data Services) Client A Client B Client C Client D Connection Pool Connection Pool GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard RO Oracle True Cache Oracle True Cache Oracle True Cache Oracle True Cache RW/RO RW Primary GoldenGate Replica RO Active Data Guard Standby RO RO RW Primary RO Active Data Guard Standby RO Active Data Guard Standby RO Active Data Guard Standby RW/RO GoldenGate Replica RO RW/RO GoldenGate Replica RW/RO GoldenGate Replica RW Primary RO Active Data Guard Standby RO Active Data Guard Standby

Notes

The diagram showcases an example deployment architecture spanning two regions: East and West. Each of the three database pools is spread across both regions and demonstrates unique deployment setups using a combination of GoldenGate Replicas, Active Data Guard Standbys, and True Caches. The Global Service Managers, GSM-EAST and GSM-WEST act as remote listeners for all databases in the Global Data Services configuration and route connection requests to the most appropriate endpoint based on routing strategies such as geographical location, load balancing, role, replication lag, and service availability.

The topmost database pool has a primary database that supports Read-Write (RW) workloads, with a True Cache and an Active Data Guard Standby in each region to handle Read-Only (RO) workloads. True Cache reads from the primary database to warm up the cache or when there is a cache miss. Once a block is cached, it is updated automatically through redo apply from the primary database. Applications are configured so that frequent reads go to the True Caches, while writes and infrequent reads go to the primary database. The Active Data Guard Standby in each region provides disaster protection and high availability, while also reducing the load on the primary production database by supporting Read-Only workloads.

The middle database pool has a primary database supporting RW workloads with a GoldenGate Replica in each region that supports both Read-Write and Read-Only workloads. The Active Data Guard Standby in each region provides disaster protection and high availability, while also reducing the load on the primary production database by supporting Read-Only workloads.

The bottom database pool has a primary database supporting RW workloads, with a True Cache, GoldenGate Replica, and Active Data Guard Standby in each region offering enhanced query response times, disaster protection, and reduced load on the primary database.

GDS Deployment: High Level Steps

Related Resources

GDS Common Use Cases

Ensure Business Continuity with Automated Database Failover Minimize Resource Requirement with Intelligent Load Balancing Achieve Faster Response Times with Geo-Aware Workload Routing Improve Read Performance with Smart Replication Lag Aware Routing Boost Query Speed with Ultra-Fast Cache

Notes

The following are some common use cases for Oracle Global Data Services:

Ensuring Business Continuity with Automated Database Failover

Global Data Services extends Oracle RAC-style service failover (within and across data centers) and management capabilities to replicated databases, and takes into account service placement policies. It achieves higher availability and improved manageability by enabling Global Data Services with Active Data Guard and Oracle GoldenGate.

If a database global service crash occurs, GDS, considering the service placement attributes, automatically performs an inter-database service failover to another available database in the pool. GDS sends Fast Application Notification (FAN) events so that the client connection pools can reconnect to the new database where the global service has been started.

Minimizing Resource Requirement with Intelligent Load Balancing

Global Data Services extends Oracle RAC-style connect-time and run-time load balancing capabilities (within and across data centers) to a set of replicated databases. The algorithm takes into account load metrics, region affinity, network latency, and load balancing goals. It maximizes performance and achieves efficient resource utilization by enabling Global Data Services on Active Data Guard and Oracle GoldenGate.

GDS enables runtime load balancing across replicated databases by publishing a real-time load balancing advisory for connection pool-based clients (for example, OCI, JDBC, ODP.NET, WebLogic, and so on.). The connection pool-based clients subscribe to this load-balancing advisory and route database requests in real time across already-established connections.

With GDS's runtime connection load balancing feature, application client work requests are dynamically routed to the database that offers the best performance. In addition, GDS also supports the ability to dynamically re-distribute connections when the database performance changes.

With GDS's connect time load balancing, global service managers use the load statistics from all databases in the GDS pool, inter-region network latency, and the configured connect-time load balancing goal to route the incoming connections to the best database in a GDS pool.

Geo-Aware Workload Routing for Faster Response Times

With GDS, you can choose to configure client connections to be routed among a set of replicated databases in a local region. This capability allows you to maximize application performance (avoiding the network latency overhead of accessing databases in remote areas).

Improving Read Performance with Smart Replication Lag Aware Routing

With Oracle Active Data Guard, standbys may lag behind the primary database. A global service allows you to choose the acceptable lag tolerance for a given application. GDS routes requests to a standby database whose lag is below the limit. If the lag exceeds the lag limit, the service is relocated to another available standby database that lags below the threshold. New requests are routed to a standby database that satisfies the lag limit. If no standbys meet the threshold, the workload is routed to the primary database. When the lag is resolved or comes within the limit, GDS automatically brings up the service. 

With Oracle GoldenGate replication, when the lag exceeds the lag threshold defined for a service, that service is stopped on that database. The service is restarted if the lag comes back within the threshold. After the service has been stopped, the global service manager automatically performs failover processing. Any new connections to this service are directed elsewhere than the lagged database. So, if there are two databases in the pool, and the service is preferred_all with lag=10 initially, the service runs on both databases, and the connections are load-balanced. If the second database goes past the lag threshold, the service is stopped there, and any new connections are directed only to the first database. If the lag comes back within the threshold, the service is restarted, load balancing continues, and new connections can use the second database. If no replicas meet the threshold, the workload is routed to the primary database.

Boosting Query Speed with Ultra-Fast Cache

Oracle True Cache is an in-memory, consistent, and automatically managed SQL cache for Oracle Database. You can deploy Oracle True Cache with Oracle Database Global Data Services (GDS) to improve application response time and manage workload routing, dynamic load balancing, and service failover across multiple True Caches and other database replicas.

Related Resources

GDS Use Case 1: Ensure Business Continuity with Automated Database Failover

West Region East Region Database Tier Deployment 1 SALES GDS Pool Application Tier Routing Tier (Global Data Services) Deployment 2 SALES GDS Pool Client A Client B Connection Pool Connection Pool GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard Active Data Guard Failover Failover Oracle GoldenGate RW ORDER_ENTRY_SRVC RO REPORTING SRVC RW ORDER_ENTRY_SRVC Master Primary Client C Client D RO REPORTING_SRVC RW ORDER_ENTRY_SRVC Replica Standby

Notes

Global Data Services extends Oracle RAC-style service failover (within and across data centers) and management capabilities to replicated databases and achieves higher availability and improved manageability by enabling Global Data Services with Active Data Guard and Oracle GoldenGate.

If a database global service crash occurs, GDS, considering the service placement attributes, automatically performs an inter-database service failover to another available database in the pool. GDS sends Fast Application Notification (FAN) events so that the client connection pools can reconnect to the new database where the global service has been started.

The diagram shows SALES GDS Pool in two different deployments setups: Deployment 1 illustrates Active-Active database architecture using Oracle GoldenGate replication. Deployment 2 showcases Active-Passive database architecture utilizing Oracle Active Data Guard. 

Deployment 1 illustrates failure of Master database DB01 running RW workload -order_entry_srvc. Global Data Services fails over the RW workload to the available replica (DB02).

From a GSM node, use GDSCTL to configure GDS:

GDSCTL>add service -service order_entry_srvc -gdspool sales -preferred DB01 -available DB02

In Active-Active setup, RW (Read-Write) workload order_entry_srvc and RO (Read-Only) workload reporting_srvc can run on both replicas or be assigned to separate replicas. If a database fails, its workloads automatically transition to the surviving replica. Some customers configure Oracle GoldenGate replicas solely for failover, without executing workloads on them.

Deployment 2 illustrates failure of Standby database running RO workload reporting_srvc. Global Data Services fails over the RO workload to the Primary database.

GDSCTL> add service -service reporting_srvc -gdspool sales -preferred_all -role PHYSICAL_STANDBY -failover_primary

In Active-Passive setup, RW workloads are always processed on the primary database. If the primary fails, the standby takes over as the new primary, and RW workloads automatically transition to it. The standby database can optionally handle RO workloads under normal conditions. Upon primary failure, the standby assumes the primary role and serves both RW and RO workloads. 

TNS Entry in Client A and Client B tnsnames.ora:

order_entry_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=order_entry_srvc.sales.oradbcloud) (REGION=EAST)

)

TNS Entry in Client C and Client D tnsnames.ora:

reporting_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=reporting_srvc.sales.oradbcloud) (REGION=WEST)

)

Related Resources

GDS Use Case 2: Minimize Resource Requirement with Intelligent Load Balancing

West Region East Region Database Tier Deployment 1 SALES GDS Pool Application Tier Routing Tier (Global Data Services) Deployment 2 SALES GDS Pool Client A Client B Connection Pool Connection Pool GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard Active Data Guard Oracle GoldenGate RO REPORTING_SRVC Local Standby RO REPORTING_SRVC Remote Standby Client C Client D RW ORDER_ENTRY_SRVC Master RW ORDER_ENTRY_SRVC Master Deployment 3 SALES GDS Pool Active Data Guard RW ORDER_ENTRY_SRVC Primary Redo apply Cache miss, warm-up Redo apply Cache miss, warm-up RO REPORTING_SRVC Oracle True Cache RO REPORTING_SRVC Oracle True Cache RW ORDER_ENTRY_SRVC Primary

Notes

GDS provides connect time and run-time load balancing (within and across regions/data centers) for all work requests. 

GDS enables runtime load balancing across replicated databases by publishing a real-time load balancing advisory for connection pool-based clients (for example, OCI, JDBC, ODP.NET, WebLogic, and so on.). The connection pool-based clients subscribe to this load-balancing advisory and route database requests in real time across already-established connections.

With GDS's runtime connection load balancing feature, application client work requests are dynamically routed to the database that offers the best performance. In addition, GDS also supports the ability to dynamically re-distribute connections when the database performance changes.

With GDS's connect time load balancing, global service managers use the load statistics from all databases in the GDS pool, inter-region network latency, and the configured connect-time load balancing goal to route the incoming connections to the best database in a GDS pool.

The diagram shows SALES GDS Pool in three different deployments setups:

Deployment 1: Load balancing for Active-Active Oracle GoldenGate

GDSCTL>add service -service order_entry_srvc -gdspool sales -preferred_all -clbgoal LONG

In an active-active setup, RW workloads can be processed on both replicas or distributed based on workload type. RW services can be configured to balance traffic dynamically across available replicas. RO workloads can run on both replicas or be distributed independently of RW workloads. RO services can be configured to distribute queries optimally across multiple replicas for better performance. 

Deployment 2: Load balancing for Active-Passive Oracle Data Guard Standby

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role PHYSICAL_STANDBY -clbgoal LONG -rlbgoal SERVICE_TIME

In an active-passive setup, RW workloads are processed only on the primary database. If the primary is a RAC database, workloads may be distributed across RAC nodes, but they are not balanced across multiple databases. One or more standby databases can be used to offload RO workloads from the primary. If multiple standby databases exist such as a reader farm, RO workloads may be load-balanced among them.

Deployment 3: Load balancing for Oracle True Cache

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role TRUE_CACHE -failover_primary

In True Cache setup, RO workloads are processed in Oracle True Cache for quick response times and RW workloads are directed to primary database. GDS provides load balancing and service failover between multiple True Caches.


Example TNS Entry in Client A and Client B tnsnames.ora:

order_entry_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=order_entry_srvc.sales.oradbcloud) (REGION=EAST)

)

Example TNS Entry in Client C and Client D tnsnames.ora:

reporting_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=reporting_srvc.sales.oradbcloud) (REGION=WEST)

)

Related Resources

GDS Use Case 3: Achieve Faster Response Times with Geo-Aware Workload Routing

West Region East Region Database Tier Deployment 1 SALES GDS Pool Application Tier Routing Tier (Global Data Services) Deployment 2 SALES GDS Pool Client A Client B GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard Active Data Guard Oracle GoldenGate RO REPORTING_SRVC Local Standby RO REPORTING_SRVC Remote Standby Client C Client D Connection Pool Connection Pool RW ORDER_ENTRY_SRVC Master RW ORDER_ENTRY_SRVC Master Active Data Guard RW ORDER_ENTRY_SRVC Primary

Notes

With GDS, you can choose to configure client connections to be routed among a set of replicated databases in a local region. This capability allows you to maximize application performance by avoiding the network latency overhead of accessing databases in remote areas.

The diagram shows SALES GDS Pool in two different deployments setups:

Deployment 1: Geo-Aware Workload Routing for Active-Active Oracle GoldenGate

GDSCTL>add service -service order_entry_srvc -gdspool sales -preferred_all -locality LOCAL_ONLY -region_failover

In an active-active setup, regional RW workloads may be serviced by local (regional) database replicas.  Alternatively, both RW and RO regional workloads can be processed locally or uniformly across replicas. The regional RO workloads may be serviced by local (regional) database replicas.  Alternatively, both RW and RO regional workloads can be processed locally or uniformly across replicas.

Deployment 2: Geo-Aware Workload Routing for Active-Passive Oracle Data Guard Standby

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role PHYSICAL_STANDBY -locality LOCAL_ONLY -region_failover

Regional affinity does not apply to RW workloads in an active-passive setup. RW workloads are always processed on the primary database, regardless of its region. In a multi-standby environment (e.g., reader farm), RO workloads can be processed on a regional standby database to optimize performance and reduce latency.


Example TNS Entry in Client A and Client B tnsnames.ora:

order_entry_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=order_entry_srvc.sales.oradbcloud) (REGION=EAST)

)

Example TNS Entry in Client C and Client D tnsnames.ora:

reporting_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=reporting_srvc.sales.oradbcloud) (REGION=WEST)

)

Related Resources

GDS Use Case 4: Improve Read Performance with Smart Replication Lag Aware Routing

West Region East Region Database Tier Deployment 1 SALES GDS Pool Application Tier Routing Tier (Global Data Services) Deployment 2 SALES GDS Pool Client A Client B Connection Pool Connection Pool GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard Oracle GoldenGate Active Data Guard Oracle GoldenGate RO REPORTING_SRVC Replica Replication lag < Threshold RO REPORTING_SRVC Local Standby Lag >Threshold RO REPORTING_SRVC Remote Standby Lag >Threshold Client C Client D RO REPORTING_SRVC Replica Lag >Threshold RW ORDER_ENTRY_SRVC Primary Active Data Guard RW ORDER_ENTRY_SRVC RO REPORTING_SRVC Primary

Notes

With Oracle Active Data Guard, standbys may lag behind the primary database. A global service allows you to choose the acceptable lag tolerance for a given application. GDS routes requests to a standby database whose lag is below the limit. If the lag exceeds the lag limit, the service is relocated to another available standby database that lags below the threshold. New requests are routed to a standby database that satisfies the lag limit. If no standbys meet the threshold, the workload is routed to the primary database. When the lag is resolved or comes within the limit, GDS automatically brings up the service. 

With Oracle GoldenGate replication, when the lag exceeds the lag threshold defined for a service, that service is stopped on that database. The service is restarted if the lag comes back within the threshold. After the service has been stopped, the global service manager automatically performs failover processing. Any new connections to this service are directed elsewhere than the lagged database. So, if there are two databases in the pool, and the service is preferred_all with lag=10 initially, the service runs on both databases, and the connections are load-balanced. If the second database goes past the lag threshold, the service is stopped there, and any new connections are directed only to the first database. If the lag comes back within the threshold, the service is restarted, load balancing continues, and new connections can use the second database. If no replicas meet the threshold, the workload is routed to the primary database.

The diagram shows SALES GDS Pool in two different deployments setups:

Deployment 1: Replication Lag Aware Routing for Active-Active Oracle GoldenGate

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -lag 180

Specify replication lag limit for a service in seconds. In a single-replica setup, read-only (RO) workloads are served at the replica as long as the replication lag remains within the configured threshold. If the lag exceeds the threshold, the workload is failed over to the primary. In a multi-replica configuration, RO workloads are redirected to another replica within the acceptable replication lag limit. If no replicas meet the threshold, the workload is routed to the primary database.

Deployment 2: Replication Lag Aware Routing for Active-Passive Oracle Data Guard Standby

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role PHYSICAL_STANDBY -lag 180

Specify replication lag limit for a service in seconds. In a single-standby configuration, RO workloads are served at the standby as long as the replication lag remains within the allowed threshold. If the threshold is exceeded, the workload is redirected to the primary. In a multi-standby setup, the workload is transitioned to another standby within the acceptable replication lag limit. If no standbys meet the threshold, the workload is routed to the primary database.

 

Example TNS Entry in Client A and Client B tnsnames.ora:

order_entry_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=order_entry_srvc.sales.oradbcloud) (REGION=EAST)

)

Example TNS Entry in Client C and Client D tnsnames.ora:

reporting_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=reporting_srvc.sales.oradbcloud) (REGION=WEST)

)

Related Resources

GDS Use Case 5: Boost Query Speed with Ultra-Fast Cache

West Region East Region Database Tier Deployment 1 SALES GDS Pool Application Tier Routing Tier (Global Data Services) Deployment 2 SALES GDS Pool Client A Client B Connection Pool Connection Pool GSM-EAST GSM-WEST GDS Catalog GDS Catalog Standby Data Guard Frequent reads Cache miss, warm-up Cache miss, warm-up Redo apply Redo apply Frequent reads Writes and Infrequent reads Writes Frequent reads Frequent reads Infrequent reads Writes Oracle GoldenGate RO REPORTING_SRVC Oracle True Cache RO REPORTING_SRVC Oracle True Cache Oracle True Cache RO REPORTING_SRVC Oracle True Cache RO REPORTING_SRVC Client C Client D RW ORDER_ENTRY_SRVC RO REPORTING_SRVC Replica RW ORDER_ENTRY_SRVC Primary Cache miss, warm-up Cache miss, warm-up Redo apply Redo apply Active Data Guard RO REPORTING_SRVC Standby RW ORDER_ENTRY_SRVC Primary

Notes

Oracle True Cache is an in-memory, consistent, and automatically managed SQL cache for Oracle Database. True Cache improves application response time while reducing the load on the database. True Cache reads from the primary database to warm up the cache or when there's a cache miss. After a block is cached, it's updated automatically through redo apply from the primary database. Applications are configured so that frequent reads go to the True Cache and writes, and infrequent reads go to the primary database. Automatic cache management and consistency simplify application development, reducing development effort and cost. 

You can deploy Oracle True Cache with Oracle Database Global Data Services (GDS) to manage workload routing, dynamic load balancing, and service failover across multiple True Caches and other database replicas.

True Cache provides the following integrations with Oracle Global Data Services (GDS).

The diagram illustrates a basic True Cache configuration with GDS across two regions. 

The diagram shows SALES GDS Pool in two different deployments setups: Deployment 1 illustrates Active-Active database architecture using Oracle GoldenGate replication. Deployment 2 showcases Active-Passive database architecture utilizing Oracle Active Data Guard. Both the deployments use True Cache to boost query speed of Read-Only (RO) workloads.

Deployment 1 

From a GSM node, use GDSCTL to configure GDS:

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role TRUE_CACHE -failover_primary

Deployment 2 

GDSCTL>add service -service reporting_srvc -gdspool sales -preferred_all -role TRUE_CACHE -failover_primary

The primary database processes both RW and RO workloads. However, all or specific RO workloads can be offloaded to Oracle True Cache to improve performance. Oracle True Cache processes RO workloads, either fully or selectively, based on configured services. This reduces load on the primary database and enhances query response times


TNS Entry in Client A and Client B tnsnames.ora:

order_entry_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=order_entry_srvc.sales.oradbcloud) (REGION=EAST)

)

TNS Entry in Client C and Client D tnsnames.ora:

reporting_srvc =

(DESCRIPTION=(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)

 (FAILOVER=ON)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)         

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-EAST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-EAST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-EAST3)(PORT=1522))

)

  (ADDRESS_LIST=

    (LOAD_BALANCE=ON)    

    (ADDRESS=(PROTOCOL=TCP)(HOST=GSM-WEST)(PORT=1522))

    (ADDRESS=(PROTOCOL=TCP)(HOST= GSM-WEST2)(PORT= 1522))

    (ADDRESS=(PROTOCOL = TCP)(HOST=GSM-WEST3)(PORT=1522))

 )

 (CONNECT_DATA=

   (SERVICE_NAME=reporting_srvc.sales.oradbcloud) (REGION=WEST)

)

Related Resources