Configuration Best Practices of GDS in Maximum Availability Architecture
Each region should have a total of three GSMs, with each GSM residing on dedicated hardware. This setup ensures redundancy, as even if one GSM experiences an outage, the other two will continue to provide the required services.
The GDS catalog, which is essential for GDS operations, must be protected using Data Guard. The primary and standby databases that host the GDS catalog should be deployed on separate hardware.
To further enhance the reliability and manageability of the GDS catalog database, it is recommended to consolidate it with Oracle Enterprise Manager Cloud Control.
Additionally, regular backups using Recovery Manager (RMAN) should be performed to safeguard the GDS catalog database against any potential data loss.
Global Services and Distributed Transactions
Using global services in XA transactions on a multi-instance Oracle RAC environment can potentially result in performance degradation. To mitigate this issue, it is advised to enable the -dtp parameter and set it to TRUE for any service utilized by XA transactions. Setting this parameter guarantees that all XA transactions will be performed through the service having tightly coupled branches running on a single instance.
Global Services in Multitenant Architecture
The container database (CDB) can be part of the GDS configuration. The service can be created at the CDB$ROOT or pluggable database (PDB) level. If the PDB property is not set, then the global service is created at the CDB root level.
Global Service Failover Details
When a global service or database fails, the GSM considers preferred databases as failover targets before available databases.
If the failover was intentional, using GDSCTL, then the service does not failover to another database. Settings will remember the current database as a failover target, and if another replicated database fails, then the previously mentioned service can start again on the remembered database.
The GDS framework supports role-based global services. If the GDS pool contains databases that are part of the Oracle Data Guard broker configuration, the GDS framework can automatically start the global service when the database role matches the role specified for this service. Valid roles are PRIMARY, PHYSICAL_STANDBY, LOGICAL_ STANDBY, and SNAPSHOT_STANDBY.
The global service cannot failover between regions if the locality parameter is set to LOCAL_ONLY and the inter-region failover is not enabled.
It is recommended to have fast connection failover enabled for the Oracle clients, which provides rapid failover of the connections in the case of service outages. Instead of waiting for the response from the failed database, which can be as many as 60 seconds, depending on the failure, clients receive FAN events and react immediately.
If something blocks the GSM from connecting to the Global Data Services catalog, then the GSM will not be able to automatically failover a service.