Globally Distributed Autonomous Database brings the power of distributed (sharded) databases to Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Oracle Globally Distributed Autonomous Database is a cloud-based, fully-managed database service that enables the sharding of data across globally distributed converged databases. It is designed to support large-scale, mission-critical applications. It is a highly available, fault-tolerant, and scalable database service that enables organizations to store and process massive amounts of data with high performance and reliability.

The Globally Distributed Autonomous Database is built on top of Oracle's autonomous technology, which means that it is self-driving, self-securing, and self-healing. This allows automation of many of the routine tasks associated with managing a database, such as patching, tuning, and backup and recovery, which can help reduce the risk of human error and improve system uptime.

For a detailed discussion of distributed database features supported in Oracle Database, see Oracle Sharding Overview for Oracle Database 19c and Oracle Globally Distributed Database Overview for Oracle Database 23ai.

To gain a greater understanding of Globally Distributed Database concepts, familiarize yourself with the following terminology.

• Catalog - an Oracle Database that supports automated shard deployment, centralized management of the distributed database, and multi-shard queries.

  A Catalog serves following purposes:

  • Serves as an administrative server for the entire distributed database

  • Stores a gold copy of the database schema

  • Manages multi-shard queries with a multi-shard query coordinator

  • Stores a gold copy of duplicated table data

• Shard - A distributed database is a collection of shards.

  Each shard in a distributed database is an independent Oracle Database instance that hosts subset of the distributed database data. Shared storage is not required across the shards.

  Shards can all be placed in one region or can be placed in different regions.

  Shards are replicated for high availability and disaster recovery with Oracle Data Guard. For high availability, Data Guard standby shards can be placed in the same region where the primary shards are placed. For disaster recovery, the standby shards can be located in another region.

• Shardspace - A shardspace is a shard that stores data corresponding to a range or list of key values in a user-managed data distribution configuration. A shardspace consists of a shard and its replica.

• Shard director - A network listener that enable high performance connection routing based on a sharding key. In addition, a shard director is a set of processes known collectively as a Global Service Manager (GSM) that acts as a regional listener for clients that connect to a Globally Distributed Database.

  The shard director maintains a current topology map of the distributed database. Based on the sharding key passed during a connection request, the director routes the connections to the appropriate shard.

• Global service - A database service that is used to access data in the distributed database.

  A global service is an extension to the notion of the traditional database service. All of the properties of traditional database services are supported for global services.

For more in depth information about distributed database components and schema objects see Architecture and Concepts in Oracle Globally Distributed Database.

Oracle's Globally Distributed Database services offer data replication solutions to ensure high availability, disaster recovery, and additional scalability for reads.

Globally Distributed Database offers shard-level replication with Oracle Data Guard on Oracle Database releases 19c and 23ai. Raft replication is available with Oracle Database beginning in release 23ai.

Oracle Globally Distributed Database automatically deploys the specified replication topology to the procured systems, and enables data replication.

Shard-level Replication with Oracle Data Guard

A shard is a database. Oracle Data Guard replication of shards to physical standby databases can be used to provide individual shard-level high availability. Replication is automatically configured and deployed when the distributed database is created.

Oracle Data Guard is tightly integrated with Oracle's Globally Distributed Database services to provide high availability and disaster recovery with strict data consistency and zero data loss. Oracle Data Guard replication maintains synchronized copies (standby databases) of shards (the primary databases) for high availability and data protection. Standbys can be deployed locally or remotely.

Chunk Set-level Replication with Raft Replication

Instead of replication at the whole shard level using additional databases for standbys, the Raft replication feature in a Globally Distributed Database creates sets of chunks of data from each shard and distributes them automatically among the shards to handle chunk assignment, chunk movement, workload distribution, and balancing upon scaling (addition or removal of shards), including planned or unplanned shard availability changes.

Raft replication is built into the Globally Distributed Database to provide a consensus-based, high-performance, low-overhead availability solution, with distributed replicas and fast failover with zero data loss, while automatically maintaining the replication factor if shards fail. With Raft replication management overhead does not increase with the number of shards. If you are used to NoSQL databases and do not expect to know anything about how replication works, native replication just works.

Unlike Data Guard replication, Raft replication does not need to be reconfigured when shards are added or removed, and replicas do not need to be actively managed.

For more details about how Raft replication works see Using Raft Replication in Oracle Globally Distributed Database.

Oracle's Globally Distributed Database services resources have a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID).

Globally Distributed Autonomous Database resources are listed here.

For example, the OCID format for a Distributed Autonomous Database resource is ocid1.osddistributedautonomousdb.oc1.iad.<UNIQUE ID>.

For information about the OCID format and other ways to identify your resources, see Resource Identifiers.

Metering and billing for Globally Distributed Autonomous Database is based on the number of ECPU per hour.

Because ECPUs are allocated in the Autonomous Database, see Compute Management and Billing for details.

Globally Distributed Database Service Limits can be set for Distributed Database Count and Distributed Database Private Endpoint Count.

Autonomous Database instances, ECPU count, and storage need to have limits set for Autonomous Database service.

See Plan and Monitor Capacity for details.

Oracle's Globally Distributed Database services are integrated with various Oracle Cloud Infrastructure services and features.

• IAM
  
• Work Requests
  
• Monitoring