As we studied in the previous blog posts, Oracle Global Data Services (GDS) is a feature of Oracle Database 12c that provides connect-time and run-time load balancing, region affinity, replication lag tolerance based workload routing, and enables inter-database service failover over a set of replicated databases.
In this blog post, I will talk about how you can perform workload routing across the standby databases based on replication lag tolerance.
A Data Guard standby database can lag behind its Primary for various reasons. With GDS, applications can choose between accessing real-time vs. slightly out-of-date data. Applications can set maximum acceptable lag limit for a global service. GDS routes requests to standby databases whose replication lag is below the limit. As showcased in Figure 1, when the replication lag at a given standby database exceeds the configured lag limit, the global service is brought down by GDS on that particular database and the new requests are routed to a database that satisfies the lag limit.
Note: If there is no available standby database, then the global service is shutdown. Once the lag is resolved or comes within the limit, GDS automatically brings up the global service.
Figure 1: Routing after replication lag exceeded the tolerance
In Oracle Database 12c Global Data Services, the lag attribute is supported only for Active Data Guard. To achieve this capability, the global services should be defined as shown below with the –lag attribute denoted in Seconds.
GDSCTL>add service -service reporting_srvc -gdspool sales –preferred_all –role PHYSICAL_STANDBY –lag 180
By setting the max tolerable replication lag at the service level, customers can make sure that their applications always access the standby databases that provide right data for the business.