# Global Data Services Concepts and Administration

This file contains the text from each Global Data Services Concepts and Administration article landing page, release 26ai.

# Introduction to Oracle AI Database Global Data Services

## Getting Started with Oracle Global Data Services

Oracle Global Data Services (GDS) extends Oracle RAC, Data Guard, and Active Data Guard with globally coordinated high availability, disaster recovery, workload balancing, intelligent routing, and centralized service management. It automatically redirects connections during outages, distributes workloads according to location and performance policies, supports data residency requirements, enables planned maintenance and rolling upgrades, and improves application availability across regions and cloud environments while reducing administrative complexity.

Read More: [Getting Started with Oracle Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/getting-started-with-oracle-global-data-services.html)

## Challenges in Managing Distributed, Replicated, and Globally Deployed Databases

Distributed and replicated database environments introduce operational complexity, including synchronization across geographically dispersed systems, fragmented service management, application-aware failover requirements, difficult outage and maintenance handling, uneven workload distribution, cross-region latency, data sovereignty obligations, and high manual administration costs. Without centralized automation, organizations face configuration drift, inefficient resource use, increased risk of downtime or data loss, and greater dependence on specialized personnel.

Read More: [Challenges in Managing Distributed, Replicated, and Globally Deployed Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/challenges-in-managing-distributed-replicated-and-globally-deployed-databases.html)

## How Oracle GDS Addresses Globally Distributed Database Challenges

Oracle GDS centralizes and automates management of distributed databases through GDSCTL and Global Service Managers, providing policy-driven service placement, failover, workload routing, and monitoring. It evaluates database health, resource utilization, workload characteristics, geography, and replication status to route connections intelligently, balance demand, support compliance-aware deployments, simplify operations, and reduce manual errors across on-premises, OCI, hybrid, and multicloud environments.

Read More: [How Oracle GDS Addresses Globally Distributed Database Challenges](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/how-oracle-gds-addresses-globally-distributed-database-challenges.html)

## Benefits of Oracle Global Data Services

Oracle GDS provides fault-tolerant, centrally managed services across replicated databases, enabling higher availability, transparent scalability, improved performance, and more efficient use of geographically distributed resources. It supports dynamic database expansion without application changes, analytics across sharded data, linear growth for transaction volumes, rapid and potentially zero-data-loss failover through RAFT replication, data residency controls, and deployment across data centers, Oracle cloud services, and multicloud architectures.

Read More: [Benefits of Oracle Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/benefits-of-oracle-global-data-services.html)

## Oracle GDS and Network Load Balancers Comparison

Compared with standard network load balancers, Oracle GDS adds database-aware capabilities including client-published routing and failover intelligence, replication-lag-based routing, inter-database global service failover, role-based service placement, centralized management across replicas, and native Active Data Guard integration. Both technologies support locality-based routing and connect-time load balancing, but GDS provides deeper database functionality and may be included with qualifying Active Data Guard or Oracle GoldenGate licensing.

Read More: [Oracle GDS and Network Load Balancers Comparison](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/oracle-gds-and-network-load-balancers-comparison.html)

## Capabilities of Global Data Services

Oracle GDS supports connect-time and runtime load balancing, intelligent region- and replication-lag-based routing, automatic inter-database service failover, role-based global services, centralized administration, RAFT replication, Oracle Distributed Database, and Oracle True Cache. It uses database load, network latency, service policies, and real-time advisories to route new and existing connections, dynamically rebalance workloads through gravitation, relocate services when standby lag exceeds defined limits, and manage distributed services through GDSCTL or Oracle Enterprise Manager.

Read More: [Capabilities of Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/introduction-to-oracle-ai-database-global-data-services/capabilities-of-global-data-services.html)


# Oracle GDS Architecture and Concepts

## Overview of Oracle Global Data Services Configuration

Oracle Global Data Services (GDS) provides global services across multiple physical databases, allowing clients to connect through a single logical service name while GDS manages routing, load balancing, and failover. Local services continue to operate independently, and global and local services can coexist. The GDS catalog centrally stores configuration and runtime information, while local repositories maintain service details for each database. GDSCTL is used for centralized global-service administration; databases synchronize with the catalog when joining or restarting, and global service managers start, stop, or relocate services as required by service properties and database availability.

Read More: [Overview of Oracle Global Data Services Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/overview-of-oracle-global-data-services-configuration.html)

## Global Data Services Architecture

The GDS architecture comprises global service managers, databases, clients, regions, pools, catalogs, and supporting communication components that coordinate global service delivery. The reference architectures illustrate how these components interact to provide centralized service management, workload routing, high availability, and distributed database access across a GDS configuration.

Read More: [Global Data Services Architecture](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-data-services-architecture.html)

## Oracle GDS Concepts for Deployment Planning

Deployment planning for Oracle Global Data Services focuses on workload management, security guidance, best practices, and the organization of core GDS components. Key planning topics include balancing workloads across distributed replicated databases and understanding the components used to organize, administer, and optimize global services.

Read More: [Oracle GDS Concepts for Deployment Planning](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/oracle-gds-concepts-for-deployment-planning.html)

## Understanding Oracle Global Data Services Workload Management

GDS global services organize and balance workloads across replicated databases using service definitions, placement rules, replication-lag limits, and regional preferences. A GDS pool groups databases containing replicated data, while a region groups databases and clients with network proximity. Global services retain traditional database-service capabilities and add controls for preferred and available databases, routing to standbys within acceptable lag, and directing applications toward preferred regions.

Read More: [Understanding Oracle Global Data Services Workload Management](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/understanding-oracle-global-data-services-workload-management.html)

## Global Data Services Components

Core GDS components include networks, pools, regions, global service managers, the GDS catalog, and Oracle Notification Service servers. Together, these components provide communication, database grouping, regional organization, centralized configuration storage, service management, workload routing, high availability, and event notification across distributed Oracle databases.

Read More: [Global Data Services Components](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-data-services-components.html)

## GDS Networks

GDS networking coordinates management, database registration, event notification, connection forwarding, workload routing, and cross-shard communication. It uses components and protocols such as GSM, ONS, OCI, AQ, NSGR, IPC, JDBC, and RPC, supported by processes including GSM listeners, registration agents, monitors, proxies, ONS clients, and performance pingers. Communication uses standard database, notification, and private interprocess ports according to each operational function.

Read More: [GDS Networks](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/gds-networks.html)

## Global Data Services Pool

A GDS pool is a named subset of databases within a GDS configuration that shares global services and an administrative domain. Pools simplify service administration and improve security by enabling separate administration boundaries. Each database belongs to only one pool, and all databases providing a particular global service must belong to the same pool, although databases within a pool may provide different services.

Read More: [Global Data Services Pool](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-data-services-pool.html)

## Global Data Services Region

A GDS region groups databases and clients with close network proximity, typically within a LAN, MAN, or nearby data center, to support efficient communication and availability. Regions can contain multiple pools, and pools can span regions. Each region should have a designated buddy region containing GSMs that can provide access to the GDS configuration if local GSMs become unavailable.

Read More: [Global Data Services Region](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-data-services-region.html)

## Global Service Manager

The Global Service Manager is GDS’s central component for service-level load balancing, failover, monitoring, routing, and configuration operations. Each GSM belongs to one GDS configuration, serves a region, and manages all global services in that configuration; multiple GSMs per region improve availability and performance. GSMs provide regional client listeners, collect database and network metrics, publish runtime load-balancing advisories, monitor service health, and notify clients of failures. A master GSM updates catalog metadata, while another GSM can assume that role if it fails.

Read More: [Global Service Manager](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-service-manager.html)

## Global Data Services Catalog

The GDS catalog is an Oracle database repository containing configuration data and global-service definitions for one GDS configuration. It may reside inside or outside the associated GDS databases, with external hosting recommended for large deployments. The catalog database can share infrastructure with RMAN or Enterprise Manager catalogs, and Oracle RAC, Data Guard, or Clusterware is recommended to improve catalog availability.

Read More: [Global Data Services Catalog](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/global-data-services-catalog.html)

## Oracle Notification Service Servers

Oracle Notification Service servers deliver runtime load-balancing advisories and high-availability events from GSMs to GDS clients. An ONS server runs with each GSM, and ONS servers within a region interconnect to form a notification network. Clients subscribe to networks in their local and buddy regions to receive FAN events, while ONS servers on RAC nodes handle local-service events separately and do not join the regional GDS ONS networks.
Read More: [Oracle Notification Service Servers](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/oracle-gds-architecture-and-concepts/oracle-notification-service-servers.html)


# GDS Administration

## Overview of Global Data Services Administration

Global Data Services administration covers the catalog, GSM software, regions, pools, services, users, and monitoring, primarily through GDSCTL. Administrators install and upgrade GSMs, maintain the catalog, configure framework components, and manage regions, pools, databases, and services. Administrators require appropriate operating-system access, a catalog account with GSMADMIN\_ROLE, and credentials for GSMCATUSER and GSMUSER connectivity. Pool administrators may manage databases and services within assigned pools, while GDSCTL operations update the catalog and propagate changes through GSMs to configuration databases.

Read More: [Overview of Global Data Services Administration](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/overview-of-global-data-services-administration.html)

## Managing the GDS Stack

Managing the GDS stack requires controlled startup and shutdown of its dependent components. Startup proceeds from the catalog and GSMs through pool databases and services to applications, while shutdown follows the reverse order, beginning with clients and ending with the catalog.

Read More: [Managing the GDS Stack](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-the-gds-stack.html)

## Starting Up the GDS Stack

A GDS environment should be started in dependency order: start the catalog database and listener, start GSMs and verify catalog connectivity, start pool databases and listeners, start global services, and finally start applications and clients.

Read More: [Starting Up the GDS Stack](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/starting-up-the-gds-stack.html)

## Shutting Down the GDS Stack

A safe GDS shutdown follows reverse dependency order: stop applications and clients, stop global services, shut down pool databases and listeners, stop GSMs, and then stop the catalog database and listener.

Read More: [Shutting Down the GDS Stack](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/shutting-down-the-gds-stack.html)

## Monitoring the GDS Environment

GDSCTL provides services, databases, and status commands for monitoring global services, member databases, and GSMs. These commands show service instances and readiness, database registration and health, roles and regions, GSM connectivity to the catalog, mastership, endpoints, pending tasks, reconnections, and diagnostic log locations.

Read More: [Monitoring the GDS Environment](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/monitoring-the-gds-environment.html)

## Managing Global Data Services

Global Data Services administration includes managing regions and buddy relationships, creating and modifying pools and pool administrators, and adding, validating, modifying, or removing member databases. These activities are performed with GDSCTL while connected to the GDS catalog as required.

Read More: [Managing Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-global-data-services.html)

## Managing GDS Regions

GDS regions can be added, modified, or removed with GDSCTL; a single-region configuration automatically receives the default REGIONORA region. Region names must be unique valid identifiers of up to 30 characters, and existing regions can be assigned buddy regions to support configuration relationships.

Read More: [Managing GDS Regions](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-gds-regions.html)

## Managing GDS Pools

GDS pools are created and managed with GDSCTL while connected to the catalog. Administrators can add pools, assign pool administrators, modify membership or users, and remove pools. Pool names must be unique valid identifiers, and a default DBPOOLORA pool is created when the catalog is created if no additional pool is required.

Read More: [Managing GDS Pools](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-gds-pools.html)

## Managing Member Databases

Managing member databases includes adding databases to pools, configuring valid node checking for registration, and integrating Oracle Data Guard Broker configurations. These procedures ensure databases can provide global services, register securely with GSMs, and participate in role-based service management.

Read More: [Managing Member Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-member-databases.html)

## Adding a Database to a Global Data Services Pool

Before adding a database to a GDS pool, unlock and configure GSMUSER, ensure the database uses an SPFILE, and configure SCAN for RAC databases where applicable. Connect to the catalog and use GDSCTL add database with the database connect identifier, region, and pool; database software, release updates, and datapatch levels must exactly match existing members. Database attributes can later be modified or removed, and pool services are automatically created on newly added databases when applicable.

Read More: [Adding a Database to a Global Data Services Pool](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/adding-a-database-to-a-global-data-services-pool.html)

## Valid Node Checking for Registration

Valid node checking for registration restricts GSM registration requests to approved IP addresses, host names, or subnets. Auto-VNCR normally adds the remote database host during add database operations when the name resolves consistently; otherwise, administrators must manually add invited nodes or subnets to the catalog with GDSCTL.

Read More: [Valid Node Checking for Registration](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/valid-node-checking-for-registration.html)

## Adding Oracle Data Guard Broker Managed Databases to a Database Pool

A Data Guard Broker configuration is managed as a single unit in GDS and must be added to or removed from one pool as a whole. Databases enter or leave the pool through DGMGRL broker membership changes, not individual GDSCTL operations. Broker configurations can be added only to empty pools, pools cannot mix broker-managed and unmanaged databases, and role-based global services require a broker-managed pool.

Read More: [Adding Oracle Data Guard Broker Managed Databases to a Database Pool](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/adding-oracle-data-guard-broker-managed-databases-to-a-database-pool.html)

## Managing Global Services

GDSCTL supports the complete global-service lifecycle across pool databases, including creation, modification, startup, shutdown, enablement, disablement, and deletion. Administration also covers RAC instance placement, regional failover, and graceful application switchover, with service configuration and application connection behavior determining availability during planned or unplanned events.

Read More: [Managing Global Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/managing-global-services.html)

## Creating a Global Service

Create a global service with GDSCTL add service, associating it with a pool and optionally specifying preferred or available databases. Services can be created across all pool databases with preferred\_all, while RAC services require a subsequent modify service operation to assign instances before startup.

Read More: [Creating a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/creating-a-global-service.html)

## Starting a Global Service

GDSCTL start service starts an existing service on eligible pool databases according to preferred databases, role, replication-lag, cardinality, and database health criteria. Newly created services require an explicit initial start; automatic-management services can subsequently start when databases become eligible, whereas manual-management services require administrator-initiated starts on each target database.

Read More: [Starting a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/starting-a-global-service.html)

## Stopping a Global Service

GDSCTL stop service stops a global service on selected databases or throughout a pool. User-initiated stopping temporarily reduces service cardinality without triggering failover, although the database remains a possible failover target. Automatically managed services may restart after database recovery or new database creation, so manual management is required to suppress automatic startup completely.

Read More: [Stopping a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/stopping-a-global-service.html)

## Enabling a Global Service

GDSCTL enable service reactivates a disabled service on a specified database or pool target. Automatically managed services start immediately when the database is eligible, while manually managed services require a separate start operation; enabling also makes the database eligible as a failover target.

Read More: [Enabling a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/enabling-a-global-service.html)

## Disabling a Global Service

GDSCTL disable service prevents a service from starting or failing over on specified databases. The service must first be stopped, and once disabled it cannot start or serve as a failover target until explicitly enabled again.

Read More: [Disabling a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/disabling-a-global-service.html)

## Modifying Global Service Attributes

GDSCTL modify service changes service properties such as role, replication-lag limits, load balancing, database placement, and RAC-specific settings. It can add, remove, or relocate services among databases and may create, delete, start, or stop service instances as configuration changes are applied.

Read More: [Modifying Global Service Attributes](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/modifying-global-service-attributes.html)

## Deleting a Global Service

Delete a global service by stopping it and then using GDSCTL remove service. The operation removes the service definition from the GDS catalog and from every database where the service was created.

Read More: [Deleting a Global Service](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/deleting-a-global-service.html)

## Adding a Service to a Global Data Services Pool

Use GDSCTL add service to create a service in a pool, optionally with preferred\_all to target every pool database. For RAC databases, follow creation with modify service to select preferred instances. Service names must meet uniqueness and length rules, and domain-qualified names must be used in subsequent commands when initially specified with a domain.

Read More: [Adding a Service to a Global Data Services Pool](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/adding-a-service-to-a-global-data-services-pool.html)

## Global Data Services Failover Across Regions Flow

Cross-region failover involves switching or failing over the production database, starting application servers at the secondary site, directing wide-area traffic to the secondary load balancer, and updating DNS as necessary. Automatic or manual DNS failover may require DNS NOTIFY propagation, authoritative and caching-server refreshes, local cache clearing, and eventual routing of clients through the secondary application tier.

Read More: [Global Data Services Failover Across Regions Flow](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/global-data-services-failover-across-regions-flow.html)

## Graceful Application Switchover

Graceful application switchover depends on correctly configured services and applications that obtain connections through those services. FAN-aware pools can drain short transactions efficiently, while long-running workloads or non-FAN connections may require additional quiescing time, planned disconnection, or Application Continuity. Configurations must be tested before production use to validate client, service, and failover behavior.

Read More: [Graceful Application Switchover](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/graceful-application-switchover.html)

## GDS Patching and Upgrading

Safe GDS patching and upgrading requires validating service definitions and status before and after maintenance and following component versioning rules. Guidance covers rolling upgrades, catalog and GSM sequencing, pool database maintenance, out-of-place GSM updates, and active-environment patching procedures intended to preserve service availability.

Read More: [GDS Patching and Upgrading](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/gds-patching-and-upgrading.html)

## Overview of Patching and Upgrading GDS

Before and after patching, use GDSCTL configuration and status commands to verify that services are defined and running on the correct databases and instances. Rolling upgrades are possible because the catalog must be at least as new as GDSCTL, GSMs must meet catalog compatibility requirements, and pool databases may be upgraded independently; maintaining at least one compatible GSM supports zero service downtime.

Read More: [Overview of Patching and Upgrading GDS](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/overview-of-patching-and-upgrading-gds.html)

## Upgrading Global Data Services

Upgrade operating systems before database and GSM software, preferably through validated out-of-place installations, and verify networking, security, connectivity, failover, and client operations. The recommended sequence is catalog database, GDSCTL-only GSM installations, GSM servers one at a time while keeping one running, and pool databases in administrator-selected order; platform-specific file permissions may be required for in-place GSM upgrades.

Read More: [Upgrading Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/upgrading-global-data-services.html)

## GSM Out-of-Place Update Examples

The example demonstrates a rolling 19.18 update from a 19.3 GDS environment by patching the catalog, alternating GSM mastership while upgrading GSM installations, then patching pool databases individually. It also illustrates moving GSM homes on the same host or to different hosts by copying configuration and wallet files, updating wallet and endpoint settings, restarting GSMs sequentially, refreshing passwords where required, and validating configuration, database, and service status.

Read More: [GSM Out-of-Place Update Examples](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/gsm-out-of-place-update-examples.html)

## Global Data Services Patching Example

This procedure patches an active Linux-based GDS environment by validating operating-system prerequisites and OPatch, staging the release update, patching the catalog first, running datapatch and invalid-object checks, and restarting listeners. GSMs are patched one at a time with at least one remaining online to preserve availability; datapatch is used for the catalog database but not for GSM installations.

Read More: [Global Data Services Patching Example](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/global-data-services-patching-example.html)

## Password Management in a GDS Environment

GSMCATUSER password changes require updating the database account with SQL\*Plus, synchronizing the catalog through GDSCTL modify catalog, and updating each GSM with its new catalog password. GSMUSER credentials are encrypted in the catalog and can be re-encrypted with new keys. GSMCATUSER and GSMUSER are shared for GSM operations and must not be used for human connections, while GSMADMIN\_INTERNAL must remain locked and reserved for GDS-owned objects; sharded environments require coordinated rotation of relevant GSM credentials.
Read More: [Password Management in a GDS Environment](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/gds-administration/password-management-in-a-gds-environment.html)


# Installation and Configuration

## Oracle GDS Capacities and Requirements

Capacity planning should precede deployment and be reviewed as workloads, databases, and services grow. GDS includes redundant core components such as Global Service Managers and the GDS Catalog, client integrations for intelligent routing and failover, and database-side ONS and gsmuser components. A single GSM supports up to 5,000 GDS pools, 10 regions, 5 GSMs per region, 10,000 database instances, 10,000 global services, and 1,000 mid-tier connection pools. GDS databases may be single-instance or RAC, container or non-container, deployed on commodity or engineered systems, and managed with GDSCTL or Enterprise Manager.

Read More: [Oracle GDS Capacities and Requirements](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/oracle-gds-capacities-and-requirements.html)

## Planning GDS Deployment

Plan bidirectional network access among GSM listeners, ONS ports, pool-database listeners, the GDS catalog, client or application tiers, and other GSMs. Default ports are 1522 for GSM listeners, 1521 for database listeners, 6123 for local ONS, and 6234 for remote ONS; separately hosted GDSCTL installations also require access to the catalog listener. Detailed platform requirements, including memory, storage, kernel versions, and packages, should be validated against the Oracle AI Database Linux installation guidance.

Read More: [Planning GDS Deployment](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/planning-gds-deployment.html)

## GDS Software Installation

Install the Global Service Manager from separate media in its own Oracle home, distinct from other Oracle software and from any additional GSM installations on the same host. Deploy at least one GSM per region, preferably three on separate hosts for high availability, with dedicated hosts recommended for large configurations; physical or virtual systems are supported. Each GSM must be installed individually because the installer does not support multiple hosts, and installation must be performed by the GDS administrator using a non-root operating-system account.

Read More: [GDS Software Installation](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/gds-software-installation.html)

## Installing a Global Service Manager

Prepare a dedicated, separate Oracle home for each GSM and deploy at least one per region, preferably three on separate hosts for high availability. As the GDS administrator, download and extract the GSM media, run Oracle Universal Installer from its root directory, then configure ORACLE\_HOME, PATH to include the GSM bin directory, and TNS\_ADMIN to use the home’s network administration directory. Installation provides GSM and GDSCTL binaries, must not be run as root, and should be updated to the latest Oracle Database release afterward.

Read More: [Installing a Global Service Manager](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/installing-a-global-service-manager.html)

## GDS Catalog Database and GDS Catalog Setup

Every GDS configuration requires a catalog database, which should be independently deployed and protected with technologies such as Oracle RAC, Oracle Data Guard, and Clusterware, particularly for high availability and disaster recovery. The catalog must use an SPFILE, RAC deployments require SCAN, and bidirectional access is needed for GSM, database, ONS, and GDSCTL connections using the standard ports. Administrators should manage the catalog through GDSCTL rather than direct database connections, designate a primary catalog repository, and provide appropriate catalog credentials when creating it.

Read More: [GDS Catalog Database and GDS Catalog Setup](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/gds-catalog-database-and-gds-catalog-setup.html)

## Global Data Services Configuration

A GDS configuration applies Oracle’s database service model across a set of replicated databases. Its deployment includes installing GSMs, creating the GDS catalog, configuring regions, pools, databases, and global services, assigning administrator privileges, and enabling client connectivity. Supporting topics provide deployment procedures, a complete GDSCTL-based example, and best-practice recommendations aligned with Oracle Maximum Availability Architecture.

Read More: [Global Data Services Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/global-data-services-configuration.html)

## Oracle GDS Deployment Steps

Deploy GDS by installing GSM software on its servers, using at least one GSM per region and preferably three, and preparing the catalog database. Establish administrator accounts and privileges, create the catalog and any standby databases, configure GSMs, regions, pools, databases, and global services with GDSCTL, and finally enable client connectivity.

Read More: [Oracle GDS Deployment Steps](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/oracle-gds-deployment-steps.html)

## GDS Configuration Example

A complete GDS deployment may use administrator-managed services assigned to specific instances or policy-managed services distributed through server pools. The process creates and protects an independent catalog, establishes GSM administrator credentials, creates the catalog with appropriate connectivity and Auto VNCR settings, unlocks required accounts, adds and starts GSMs, creates regions and pools, authorizes nodes, and registers databases that meet SPFILE and RAC SCAN requirements. After resolving firewall or incorrect-interface registration issues, administrators create and start primary read-write and standby read-only global services, then verify GSM, database, and service readiness with GDSCTL status and services commands.

Read More: [GDS Configuration Example](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/gds-configuration-example.html)

## GDS Configuration Best Practices

For high availability and efficient routing, use Oracle-integrated connection pools such as UCP, OCI, or ODP.NET so clients receive failover and load-balancing notifications. Deploy three GSMs per region on separate hardware because they are lightweight, stateless listeners that can reload metadata from the catalog. Protect the small GDS catalog with Oracle Data Guard, preferably using a local maximum-availability standby with Fast-Start Failover and a remote physical standby; catalog standbys should use Active Data Guard and separate hardware and storage.
Read More: [GDS Configuration Best Practices](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/installation-and-configuration/gds-configuration-best-practices.html)


# Troubleshooting Global Data Services

## Obtaining the Status of GDS Components

Use the GDSCTL `status` command to check the running state of Global Data Services components, including global service managers, services, and databases, with commands such as `status gsm`, `status service`, and `status database`.

Read More: [Obtaining the Status of GDS Components](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/obtaining-the-status-of-gds-components.html)

## Viewing GDS Configuration Information

Use the GDSCTL `config` command to view static configuration details for GDS components, including GSMs, regions, GDS pools, databases, services, and invited nodes.

Read More: [Viewing GDS Configuration Information](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/viewing-gds-configuration-information.html)

## Networking Issues

Troubleshoot GDS networking failures by investigating listener and connectivity errors such as ORA-12514, ORA-12516, ORA-12541, and GSM-40167, checking service availability, local listeners, GSM processes, and VNCR hostname resolution.

Read More: [Networking Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/networking-issues.html)

## ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

ORA-12514 may indicate that the global service is down or disabled, or that a GDS pool database is unavailable; verify that pool databases are running and that the affected service is enabled and started.

Read More: [ORA-12514: TNS:listener does not currently know of service requested in connect descriptor](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/ora-12514-tnslistener-does-not-currently-know-of-service-requested-in-connect-descriptor.html)

## ORA-12516: TNS:listener could not find available handler with matching protocol stack

ORA-12516 commonly occurs when the GDS pool database’s local listener is unavailable, so verify that the listener is running and able to provide a matching connection handler.

Read More: [ORA-12516: TNS:listener could not find available handler with matching protocol stack](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/ora-12516-tnslistener-could-not-find-available-handler-with-matching-protocol-stack.html)

## ORA-12541: TNS:no listener

ORA-12541 may occur when all global service managers are down; verify that the configured GSM processes and their listeners are running.

Read More: [ORA-12541: TNS:no listener](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/ora-12541-tnsno-listener.html)

## GSM-40167: VNCR entry is not resolvable on GSM host

GSM-40167 during GSM restart after an upgrade is commonly caused by short hostnames in the VNCR list; remove the corresponding `invitednode` entries for the short shard hostnames and retry the GSM startup.

Read More: [GSM-40167: VNCR entry is not resolvable on GSM host](Global Data Services Concepts and Administration/Troubleshooting Global Data Services/26ai/GSM-40167: VNCR entry is not resolvable on GSM host)

## Resolving Database Registration Issues when Using add brokerconfig in GDS Environments

If a database remains unregistered after `add brokerconfig`, check `GDSCTL status database` for `Registered: N`, then assign the database to a region with `modify database`; when adding multiple standby databases, add and synchronize them one at a time to avoid ORA-45539.

Read More: [Resolving Database Registration Issues when Using add brokerconfig in GDS Environments](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/resolving-database-registration-issues-when-using-add-brokerconfig-in-gds-environments.html)

## Invalid Objects Related Issues

DBRU or individual patches can invalidate `GSMADMIN_INTERNAL` objects; first confirm that its `cloud` table contains no configuration data in the root and every PDB, then, if empty, recreate the schema using the Oracle-supplied scripts, recompile objects, validate that no invalid objects remain, and remove duplicate objects incorrectly created in SYS, contacting Oracle Support if problems persist.

Read More: [Invalid Objects Related Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/invalid-objects-related-issues.html)

## User and Password Management Issues

For GDS user and password problems, especially ORA-01045 involving `GSMADMIN_INTERNAL`, do not unlock the internal account or grant it privileges; instead investigate incorrect credentials, wallets, connection strings, scripts, or tools that attempt direct logins with this restricted user.

Read More: [User and Password Management Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/user-and-password-management-issues.html)

## ORA-01045: user GSMADMIN\_INTERNAL lacks CREATE SESSION privilege logon denied

`GSMADMIN_INTERNAL` is an internal-only account intentionally restricted from general database login, so ORA-01045 usually indicates a misconfigured component, script, wallet, or connection string; correct the underlying credential reference and avoid directly modifying the schema unless instructed by Oracle Support.

Read More: [ORA-01045: user GSMADMIN\_INTERNAL lacks CREATE SESSION privilege logon denied](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/ora-01045-user-gsmadmin_internal-lacks-create-session-privilege-logon-denied.html)

## Troubleshooting GDS Issues

General GDS troubleshooting covers catalog connectivity errors, database access when GSMs are unavailable, direct catalog access during GSM outages, and use of `SYS_CONTEXT('USERENV', ...)` values to identify sessions connected through global services.

Read More: [Troubleshooting GDS Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/troubleshooting-gds-issues.html)

## GSM-45034: Connection to GDS catalog is not established

GSM-45034 indicates that a GSM cannot reach the GDS catalog, typically because the catalog database or listener is unavailable, the connect descriptor is incorrect or unreachable, or credentials are invalid; verify database and listener availability, connectivity, service configuration, and credentials.

Read More: [GSM-45034: Connection to GDS catalog is not established](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/gsm-45034-connection-to-gds-catalog-is-not-established.html)

## Connecting to GDS Configuration Databases When No Global Service Managers Are Running

Configure connection descriptors with failover address lists ordered as regional GSM listeners, buddy-region GSM listeners, and finally local or RAC SCAN listeners, ensuring clients use GSM whenever available and fall back to local database listeners only when all GSMs are down.

Read More: [Connecting to GDS Configuration Databases When No Global Service Managers Are Running](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/connecting-to-gds-configuration-databases-when-no-global-service-managers-are-running.html)

## Connecting to Catalog Databases When No Global Service Managers Are Running

When all GSMs are unavailable, connect to the GDS catalog directly through its local listener or RAC SCAN listener by placing those addresses in the final failover option, allowing administration and maintenance to continue without GSM processes.

Read More: [Connecting to Catalog Databases When No Global Service Managers Are Running](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/connecting-to-catalog-databases-when-no-global-service-managers-are-running.html)

## Using SYS\_CONTEXT Parameters in a GDS Environment

GDS global-service sessions expose distinctive `USERENV` context values that make a database pool appear as one logical database, including wildcard-style `DB_UNIQUE_NAME` and `DB_DOMAIN` values and GDS-generated values for `INSTANCE`, `INSTANCE_NAME`, and `SERVICE_NAME`.

Read More: [Using SYS\_CONTEXT Parameters in a GDS Environment](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/using-sys_context-parameters-in-a-gds-environment.html)

## Troubleshooting GSM Issues

GSM troubleshooting addresses database task connection timeouts such as GSM-40148 with ORA-12170 and GSM initialization failures such as GSM-45054 or NET-40006, focusing on network reachability, listener availability, catalog connectivity, and configuration correctness.

Read More: [Troubleshooting GSM Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/troubleshooting-gsm-issues.html)

## GSM-40148: Database task failed with ORA-12170

GSM-40148 with ORA-12170 indicates a TNS connection timeout during broker configuration; test GSM addresses from database hosts, test primary and standby database addresses from every GSM host, verify DNS and firewall access, and ensure any required TNS aliases exist consistently in each GSM host’s `tnsnames.ora`.

Read More: [GSM-40148: Database task failed with ORA-12170](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/gsm-40148-database-task-failed-with-ora-12170.html)

## GSM-45054: GSM error or NET-40006: unable to start GSM

GSM-45054 and NET-40006 commonly occur when GSM initialization cannot access the GDS catalog; verify that the catalog database and local listener are running and that the configured connection descriptor is correct and reachable.

Read More: [GSM-45054: GSM error or NET-40006: unable to start GSM](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/gsm-45054-gsm-error-or-net-40006-unable-to-start-gsm.html)

## GDS Logs and Tracing

GDS diagnostic procedures include locating GSM logs and trace files, enabling GDSCTL and GSM tracing, tracing catalog and pool databases, and collecting runtime evidence needed to isolate and resolve GDS failures.

Read More: [GDS Logs and Tracing](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/gds-logs-and-tracing.html)

## Using Global Data Services Log and Trace Files

Use `status gsm` to identify GSM listener logs and trace files; when additional diagnostics are required, enable GDSCTL logging in `gsm.ora`, GSM tracing with `set trace_level`, and database event 10798 tracing on catalog and pool databases, then disable each diagnostic setting after collection.

Read More: [Using Global Data Services Log and Trace Files](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/using-global-data-services-log-and-trace-files.html)

## Advanced Global Data Services Troubleshooting

For advanced troubleshooting or Oracle Support investigations, collect OPatch inventory, scripted GDSCTL configuration and status output, validation results, GSM listener status, GSM alert and trace files, `GDSCTL.log`, network configuration files, and inventory data from GSM and catalog hosts.
Read More: [Advanced Global Data Services Troubleshooting](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/troubleshooting-global-data-services/advanced-global-data-services-troubleshooting.html)


# Using Global Data Services (Architectures, Use Cases, Application Development)

## Distributed Databases

Oracle Global Data Services (GDS) intelligently routes requests across distributed databases and shards according to data locality, improving performance, scalability, parallelism, and availability while presenting applications with a single logical database. Typical use cases include global e-commerce, social media, financial services, content delivery, and geographically distributed IoT processing.

Read More: [Distributed Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/distributed-databases.html)

## Using Global Data Services with Oracle Sharding

Oracle Sharding and Oracle Globally Distributed Database distribute and replicate data across independent Oracle databases presented as one logical database, supporting elastic scaling to as many as 1,000 shards. Built on GDS, the architecture provides enterprise database capabilities while enabling data sovereignty, regulatory compliance, and data proximity across global regions.

Read More: [Using Global Data Services with Oracle Sharding](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-global-data-services-with-oracle-sharding.html)

## Using True Cache with Global Data Services

Oracle True Cache provides an in-memory, consistent SQL cache that improves response times and reduces primary-database load, while GDS manages workload routing, load balancing, and failover across True Caches and database replicas. A typical deployment routes frequent reads to True Cache and writes or infrequent reads to the primary database using GDS catalogs, GSMs, global services, ONS, and connection pools, subject to service naming and patch requirements.

Read More: [Using True Cache with Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-true-cache-with-global-data-services.html)

## Supported Replication Technologies and Implementation Architectures

GDS abstracts replicated databases behind global services and provides workload routing, dynamic load balancing, role-aware failover and switchover, and centralized configuration and monitoring. Supported use cases include disaster recovery, read scaling, geographically distributed content and CRM systems, analytics, and mobile applications using Active Data Guard, GoldenGate, RAFT replication, or shared GDS infrastructure.

Read More: [Supported Replication Technologies and Implementation Architectures](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/supported-replication-technologies-and-implementation-architectures.html)

## Using Oracle Active Data Guard with Global Data Services

This procedure performs a controlled, rolling relocation of sessions across an Active Data Guard reader farm. Administrators verify service status, stop the service without force to quiesce FAN-aware pools and drain connections, disconnect remaining sessions after transactions complete, confirm session removal, start the service on the target standby, and verify that new sessions connect successfully.

Read More: [Using Oracle Active Data Guard with Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-oracle-active-data-guard-with-global-data-services.html)

## Using Oracle GoldenGate with Global Data Services

This procedure enables graceful GoldenGate role transitions by draining GDS service connections, disconnecting remaining sessions, verifying that Replicat has applied all source transactions using SCNs, and starting the service on the target database. GoldenGate must use dedicated TNS aliases rather than GDS services, heartbeat tables should track lag, and failover procedures can estimate potential data loss when the source is unavailable.

Read More: [Using Oracle GoldenGate with Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-oracle-goldengate-with-global-data-services.html)

## Using RAFT Replication with Global Data Services

RAFT is a consensus-based replication protocol that automatically maintains replication configuration and consistency across distributed database shards or replicas despite failures, partitions, message loss, or topology changes. It organizes data into replication units, supports active nodes and rapid sub-second failover, and is enabled for system-managed sharded databases by specifying native replication when creating the shard catalog.

Read More: [Using RAFT Replication with Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-raft-replication-with-global-data-services.html)

## One GDS Infrastructure for Many Replicated Configurations

A single Global Data Services infrastructure can manage multiple replicated database configurations, allowing organizations to support high availability, disaster recovery, and read scaling across several database groups through shared GDS management capabilities.

Read More: [One GDS Infrastructure for Many Replicated Configurations](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/one-gds-infrastructure-for-many-replicated-configurations.html)

## Summary: Replicated Databases Compared to Distributed Databases

Replicated and distributed database architectures address different requirements, so selection should be based on workload, availability, scalability, locality, and performance needs. Replication maintains copies of data across databases for failover and read scaling, whereas distribution partitions data across locations or shards to scale capacity and satisfy geographic or sovereignty requirements.

Read More: [Summary: Replicated Databases Compared to Distributed Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/summary-replicated-databases-compared-to-distributed-databases.html)

## GDS Use Case Summary

GDS supports business continuity, resource optimization, geo-aware routing, replication-lag-aware reads, and accelerated queries through intelligent management of replicated and cached databases. GoldenGate active-active architectures can serve read-write and read-only workloads across replicas, Active Data Guard active-passive configurations centralize writes while scaling reads, and True Cache deployments offload selected or all read-only workloads from a primary database.

Read More: [GDS Use Case Summary](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/gds-use-case-summary.html)

## Application Development Considerations

Applications in GDS environments should use GDS capabilities for resilient connectivity, failover, and workload management. Key practices include evaluating workload suitability, separating read-only and read-write services, configuring FAN and ONS, using reliable client connection endpoints, enabling connection pooling and Fast Connection Failover, and controlling direct-connection surges.

Read More: [Application Development Considerations](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/application-development-considerations.html)

## Application Workload Suitability for Global Data Services

GDS is most appropriate for replication-aware applications that can separate read-only, read-mostly, and read-write workloads into distinct services. Suitable applications either avoid or resolve GoldenGate multi-master conflicts and ideally tolerate defined replication lag, allowing read workloads to use replicas while write workloads remain properly coordinated.

Read More: [Application Workload Suitability for Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/application-workload-suitability-for-global-data-services.html)

## Using FAN ONS with Global Data Services

FAN uses Oracle Notification Service to propagate database availability and workload events to clients, enabling rapid failover and connection management across GDS environments. Applications should use dynamic GDS services, avoid administrative database or PDB services, enable FAN and ONS support in the client, rely on automatic ONS discovery where possible, and configure redundant node groups and endpoints for multi-site deployments.

Read More: [Using FAN ONS with Global Data Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/using-fan-ons-with-global-data-services.html)

## Client Side Configuration

Clients should connect through multiple highly available GSM endpoints using dynamic global services, rather than local listeners, database services, or PDB services. Connection descriptors should use a single DESCRIPTION, load-balanced GSM addresses, suitable retry and timeout settings, and current client drivers to support FAN, failover, and reliable connection behavior.

Read More: [Client Side Configuration](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/client-side-configuration.html)

## Configuring FAN for Java Clients Using Universal Connection Pool

Oracle recommends UCP or WebLogic Active GridLink with the JDBC Thin Driver to provide Fast Connection Failover, enabled through the UCP FastConnectionFailoverEnabled property or automatically by Active GridLink. Configuration requires dynamic service URLs, ONS settings when needed, required JDBC, UCP, and ONS libraries, optional Application Continuity, and appropriate manual ONS endpoints for custom or multi-cluster environments.

Read More: [Configuring FAN for Java Clients Using Universal Connection Pool](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/configuring-fan-for-java-clients-using-universal-connection-pool.html)

## Configuring FAN for OCI Clients

OCI clients provide FAN support at the driver level, including SQL\*Plus and PHP when service notification, client event settings, and XML configuration are enabled. Administrators should use automatic ONS discovery from TNS addresses where possible, configure FAN events in the client network configuration, and ensure server-side FAN notification is enabled for all OCI-based clients.

Read More: [Configuring FAN for OCI Clients](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/configuring-fan-for-oci-clients.html)

## Controlling Logon Storms

Connection pools are preferred for preventing logon storms, but direct-connection environments can be protected by increasing operating-system socket backlog capacity and the GSM listener queue size. Recommended tuning includes raising and persisting net.core.somaxconn and setting TCP.QUEUESIZE in sqlnet.ora, requiring root access for OS changes and database administration privileges for Oracle configuration changes.
Read More: [Controlling Logon Storms](https://docs.oracle.com/en/database/oracle/oracle-database/26/gsmug/using-global-data-services-architectures-use-cases-application-development/controlling-logon-storms.html)