Oracle Global Data Services
October 2025
Copyright © 2005, 2025 Oracle and/or its affiliates
Copyright © 1994, 2025, Oracle and/or its affiliates.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software," "commercial computer software documentation," or "limited rights data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government's use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle®, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
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
A 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
A 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.
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
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.
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)
)
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)
)
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)
)
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)
)
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).
-role TRUE_CACHE option for global services.JDBC SetReadOnly() supports global services.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)
)