Centralized workload management for replicas – one way to simplify workload management for replicas is by centralizing it. Using the GDSCTL command-line utility or the Oracle Enterprise Manager Cloud Control (OEMCC) graphical user interface, you can administer the global resources of regionally or globally replicated databases.
If you need information about the options provided by a specific tool, you can access the help feature.
[gsmosuser@gsmnode bin]$ echo $PWD /u01/app/oracle/product/19.0.0/gsmhome_1/bin
Directly pass the help option to the tool:
[gsmosuser@gsmnode bin]$ ./gdsctl -help
Or you can use the help option in the interface:
GDSCTL> help
Connect-time load balancing ensures that network traffic is evenly distributed across multiple servers. This distribution prevents any single server from becoming overloaded and maximizes the efficient use of resources. In simple terms, it helps balance the workload and prevents servers from being overwhelmed, leading to better resource management.
Here is how to add or modify a service:
[-clbgoal {SHORT | LONG}]
•\ SHORT: This is the default option. It is well-suited for load balancing during runtime. Here is an example of its use:
GDSCTL> add service -service hr_srvc -gdspool hrpool –preferred_all -clbgoal SHORT
•\ LONG: This is an option suitable for applications that involve long- lived connections, such as batch jobs. It prioritizes connection persistence, aiming to minimize disruptions caused by connection reassignments. Here is an example of its use:
GDSCTL> add service -service hr_srvc -gdspool hrpool –preferred_all -clbgoal LONG
Region-based workload routing allows businesses to direct user requests to the nearest available database location based on the user’s geographical region.
By routing requests to the closest database, the latency is reduced, resulting in faster response times and improved user experience.
For example, if a user in Europe tries to access data, the request can be automatically routed to a database located in Europe, rather than going through a database in a different region, such as Asia or the Americas.
Here is how to add or modify a service:
[-locality {ANYWHERE | LOCAL_ONLY [-region_failover]}]
•\ ANYWHERE: This is the default option. The connections from the clients are routed to any region for load balancing or failover. The choice
of the database is based on its performance and network latency between regions where the client and database reside. If databases in different regions have the same load, then the policy gives preference to the local region. Here is an example of its use:
GDSCTL> add service -service hr_srvc -gdspool hr –preferred_all –locality ANYWHERE
•\ LOCAL_ONLY: GDS will never route connections to databases in other regions. Inter-region failover is disabled. The client connection is routed to the best database in the client’s region. The database in the local region is chosen based on its performance. If there is no database in the local region offering the global service, then the client connection request fails; it is never redirected to another region even if the remote region has available instances. Here is an example of its use:
GDSCTL> add service -service hr_srvc -gdspool hr –preferred_all –locality LOCAL_ONLY
•\ LOCAL_ONLY -region_failover: The connections are routed to another region if all databases in the local region have failed. Here is an example of its use:
GDSCTL> add service -service hr_srvc -gdspool hr –preferred_all –locality LOCAL_ONLY –region_failover
Active Data Guard and Oracle GoldenGate are replication technologies extensively utilized in Oracle databases. These technologies enable the replication of data across various sites, which can consist of either RAC or single-instance databases. GDS plays a crucial role in facilitating seamless service failovers and load balancing between these diverse sites.
Figures 1-1 and 1-2 are simple illustrations of maximum availability architecture without and with GDS.
In the absence of GDS, client connections lack transparency during failover events. If the server to which clients are connected experiences a failure, both the clients and the application servers will encounter errors, and subsequent connections will not be automatically redirected to an available database, as illustrated in Figure 1-1.
Figure 1-1. No failover without GDS
GDS offers automated workload management, effectively addressing failover scenarios, as illustrated in Figure 1-2. It removes the need for specialized custom connection managers and load balancers dedicated to handling database workloads.
Figure 1-2. Global service failover with GDS
The GDS configuration needs to be stored in a separate database called the Global Data Services catalog. The catalog is associated with only one GDS configuration. Theminimum version of the database is Oracle Database 12c.
Similar to any of the Oracle databases, the GDS repository also needs to be configured using high-availability technologies such as Oracle RAC, Oracle Data Guard, and/or Oracle Clusterware.
In Figure 1-3, you can see the GDS catalog database is in an Active Data Guard configuration, and the sales database uses GoldenGate. A GDS configuration contains multiple GSMs per region. Placing and partitioning databases into GDS pools simplifies service management and provides higher security by allowing each pool to be administered by a different administrator.
Figure 1-3. GDS components and architecture