14.2 Globally Distributed Autonomous AI Database: Sharding, Data Placement & Replication
Key Takeaways
Globally Distributed Autonomous AI Database runs on Autonomous AI Database on Dedicated Exadata Infrastructure and adds automated management of distributed database shards.
Each node of a Globally Distributed Autonomous AI Database is an independent database that stores a subset of the data, and nodes do not share storage.
The global service manager (GSM) routes each connection to the right node based on the sharding key, using its topology map of the distributed database.
Raft replication, available from Oracle AI Database 26ai, provides consensus-based replication with fast failover, zero data loss, and no reconfiguration when nodes are added or removed.
Globally Distributed Autonomous AI Database is billed by the number of ECPUs per hour.
When a Single Database Is Not Enough
A single Autonomous AI Database scales vertically and runs in one region, with standbys elsewhere for disaster recovery. Some applications need more:
- Horizontal scale beyond what one database can handle, such as global payments, telecom, or IoT platforms with very high transaction volumes.
- Data sovereignty, where customer data must physically stay in a specific country or region.
- Data proximity, where users get lower latency because their data sits near them.
- Fault isolation, where an outage affects only the subset of data on one node.
Oracle Globally Distributed Autonomous AI Database meets these needs by distributing one logical database across many nodes. Oracle describes it as a distributed version of Autonomous AI Database that runs on Autonomous AI Database on Dedicated Exadata Infrastructure and adds automated management of the distributed database. Applications still interact with a single logical database, and the service supports OLTP, analytics, and mixed workloads with relational, JSON, spatial, graph, and other data types.
Components
| Component | Role |
|---|---|
| Catalog | A database that supports automated node deployment, centralized management, and multi-node queries. It stores the master copy of the schema and of duplicated tables, and acts as the multi-node query coordinator. |
| Node (shard) | An independent database instance that stores a subset of the data. Nodes do not share storage, and they can be placed in one region or in different regions. |
| Data space | In user-managed distribution, a node and its replica that store the data for a range or list of key values. |
| Global service manager (GSM) | A regional listener that keeps a topology map of the distributed database and routes each connection to the correct node based on the sharding key. |
| Global service | A database service that clients use to connect to the distributed database. |
Sharding Keys, Sharded Tables, and Duplicated Tables
The sharding key is the column, such as customer_id or country_code, that decides which node stores a row.
- Sharded tables are split across nodes by the sharding key.
- A table family groups related sharded tables, such as customers, orders, and order lines, so that related rows live on the same node. Joins inside a family then run on one node without cross-node traffic.
- Duplicated tables hold small reference data, such as product catalogs or currency codes, with a copy on every node so that joins with them also stay local.
When an application passes the sharding key while connecting, the GSM sends the connection directly to the node with that data, which is the fastest path. Queries without a sharding key, such as global reports, go through the catalog, which coordinates a multi-node query across the nodes.
Data Distribution Methods
| Method | How data is placed | Best for |
|---|---|---|
| System-managed | Rows are spread automatically by consistent hash of the sharding key, which balances data and load and avoids hot spots. Chunks are rebalanced automatically when nodes are added or removed. | Scale-out with even distribution |
| User-managed (user-defined) | You map ranges or lists of key values to specific data spaces, for example all EU customers to nodes in Frankfurt. | Data sovereignty and data proximity |
The underlying Oracle Globally Distributed AI Database also supports composite distribution, which combines user-defined groups with system-managed placement inside each group, and directory-based distribution, where a directory records each key's location. The distribution method and replication technology are fixed when the distributed database is created.
Replication: Data Guard or Raft
| Replication | How it works | Notes |
|---|---|---|
| Oracle Data Guard (node level) | Each primary node has physical standby nodes. Standbys can be in the same region for high availability or in another region for disaster recovery. | Available with Oracle Database 19c and Oracle AI Database 26ai |
| Raft (chunk-set level) | Data is divided into replication units, each with replicas on different nodes, and a consensus protocol keeps them in sync. | Available from Oracle AI Database 26ai; fast failover with zero data loss; keeps the replication factor automatically when nodes fail; no reconfiguration when nodes are added or removed |
For high availability, Raft-replicated nodes can be placed in different availability domains within a region. In the underlying database, Raft replication is supported only with the system-managed distribution method, and it does not protect the catalog, which can be protected with Data Guard.
Availability, Billing, and Limits
- Oracle cites a 99.95% availability SLA, rising to 99.995% with Autonomous Data Guard.
- Billing is based on ECPUs per hour, because the nodes and catalog are Autonomous AI Databases.
- Service limits cover the number of distributed databases and distributed database private endpoints, plus the usual Autonomous AI Database limits for instances, ECPUs, and storage.
- Connectivity uses a private endpoint in your VCN.
Design Example: A Global Payments Platform
A payments company must keep EU customer data in the EU and US customer data in the US, while handling millions of transactions per hour:
- Use user-managed distribution with
country_codeas part of the sharding key, mapping EU values to data spaces in Frankfurt and US values to data spaces in Ashburn. - Put customers, accounts, and transactions in one table family so payment processing stays on one node.
- Make currency and fee tables duplicated tables.
- Protect each data space with replicas in another availability domain in the same region, so data does not leave its jurisdiction.
- Run global finance reports through the catalog as multi-node queries.
A bank must keep each customer's records in the customer's home region (EU or US) to meet data residency laws, while presenting one logical database to its applications. Which Globally Distributed Autonomous AI Database design fits?
User-managed distribution that maps EU and US key values to data spaces in those regions
System-managed distribution, which spreads rows evenly by consistent hash across all regions
One Autonomous AI Database with cross-region Autonomous Data Guard standbys in both regions
Duplicated tables for all customer data so every node has a full copy
An order system on Globally Distributed Autonomous AI Database frequently joins customers, orders, and order lines for one customer. How should the schema be designed so these joins run on a single node?
Store the orders and order lines tables as duplicated tables on every node
Shard each table by its own primary key so the data spreads evenly across nodes
Route all of these queries through the catalog as multi-node queries
Put the three tables in one table family sharded by the customer key
A team wants node replication that keeps the replication factor automatically after a node failure and does not need to be reconfigured when nodes are added. Which option meets this?
Node-level Oracle Data Guard with manually created standbys
Raft replication, available with Oracle AI Database 26ai
Cross-region backup replication
Refreshable clones of each node
Sections you finish are checked off in the contents.