Distributed Database Features

The definition of a distributed database has been debated since distributed systems first appeared in the late 1970s. Oracle defines a distributed database as a geographically distributed system composed of Oracle products. Hardware vendors define it as different databases running on the same hardware platforms. GUI and tools vendors define it as architecturally distributed systems with different access methods. Each definition captures part of the reality, but none captures all of it. The most comprehensive and enduring specification comes from C.J. Date, who identified 12 characteristics that distinguish a true distributed database from a loosely coupled collection of independent systems. This lesson examines those characteristics and maps each one to the Oracle 23ai and OCI implementations that fulfill them in 2026.

Homogeneous Distributed Database Systems

A homogeneous distributed database system is a network of two or more Oracle databases that reside on one or more machines, all participating as peers in a single logical database. The Nano Banana 2 diagram below illustrates the 2026 edition of this architecture — three Oracle database sites (MFG, HQ, and SALES) connected through a Modern Design Hub with 100+ Tb/s real-time synchronization using Raft consensus algorithms.

In a homogeneous distributed Oracle environment, an application can simultaneously access or modify data in several databases within a single distributed environment. A Manufacturing client connected to the MFG database can retrieve joined data from the local products table and the remote dept table on the HQ database in a single query. The location and platform of the remote database are transparent to the client application. Creating a synonym for the remote object makes the transparency complete:

-- Create a synonym on MFG for the remote dept table on HQ
CREATE SYNONYM dept FOR dept@hq_link;

-- Query now appears local to the MFG database user
SELECT * FROM dept;

Users on the MFG database do not need to know that the dept data resides on the HQ database. Oracle Net Services resolves the database link to the remote connection descriptor, establishes the connection using the TNS service name in the tnsnames.ora or Easy Connect Plus string, and returns the result set transparently.

In Oracle 23ai, homogeneous distributed systems can incorporate Oracle databases of different versions — provided that applications do not rely on features unavailable in the older version. A distributed query joining Oracle 23ai and Oracle 19c databases is valid; the application must not use 23ai-specific syntax such as VECTOR_DISTANCE or REGEXP when querying the 19c node. Oracle Global Data Services (GDS) in OCI manages cross-version distributed environments, routing queries to nodes that support the required functionality.

Feature 1 — Continuous Operation

Each site in a distributed database must be capable of processing independently from other remote sites. The addition of a new site must not require the entire system to go offline. Each node must be available 24 hours per day, seven days per week, and maintenance tasks — OS upgrades, RDBMS patches, adding or removing participating sites — must be executable without a full system outage.

Oracle 23ai implements continuous operation through several mechanisms:

• Oracle Active Data Guard: Standby databases remain open for read queries while receiving redo log data from the primary. Planned maintenance on the primary — patching, upgrades — is performed through a rolling switchover to the standby, maintaining read/write availability throughout the maintenance window.
• Oracle Real Application Clusters (RAC): Multiple database instances share a single database, providing continuous operation through instance redundancy. If one RAC instance fails, surviving instances continue serving connections. RAC superseded Oracle Parallel Server (OPS) in Oracle 9i by introducing Cache Fusion — in-memory block sharing across the cluster interconnect, eliminating the disk-based coordination bottleneck of OPS.
• Online Redefinition: Tables can be restructured, partitioned, and migrated to different tablespaces while remaining fully available for DML operations through DBMS_REDEFINITION.
• Zero Downtime Patching (ZDP) in OCI: Oracle Autonomous Database and Exadata Cloud Service apply patches without interrupting active sessions — the patch is applied to one node at a time while other nodes continue serving traffic.

Feature 2 — Replication Independence

Replication independence means that users and applications are not concerned with how changes to replicated tables are propagated or whether their local replica is the most current version. The distributed system manages replication transparently — applications issue standard DML statements and the replication layer ensures that changes reach all participating nodes.

Replication in Oracle has evolved from the Oracle7 snapshot model through three generations:

• Generation 1 — Oracle Snapshots: Read-only copies of master tables refreshed periodically. A CUSTOMER table snapped to remote sites for local read queries. The snapshot refresh cycle determined the maximum staleness of the replica. Simple, functional, but one-directional and batch-oriented.
• Generation 2 — Advanced Replication / Publish-Subscribe: Oracle Advanced Queuing introduced the publish/subscribe model where the publisher (sender of replicated data) does not need to know the state of the subscriber (receiver). Subscribers register interest in specific tables or rows and receive updates asynchronously. The DBMS_AQ.LISTEN procedure allowed subscribers to receive incoming messages as if they were local database changes. This generation supported bidirectional replication and multi-master configurations but required careful conflict resolution design.
• Generation 3 — Oracle GoldenGate: The current standard for Oracle replication. GoldenGate captures committed transactions from the Oracle redo log through a log-based capture process and applies them to target databases with sub-second latency. GoldenGate supports heterogeneous replication — Oracle to MySQL, PostgreSQL, Kafka, and cloud data warehouses — and provides conflict detection and resolution for bidirectional multi-master topologies. In OCI, GoldenGate is available as a fully managed service through OCI GoldenGate.

The replication independence objective requires that changes propagate to all replicas and commit as a single transaction using two-phase commit (2PC). In practice, strict 2PC enforcement across all replicas imposes performance costs proportional to the number of participating nodes and the network latency between them. Modern Oracle architectures balance this through Active Data Guard's synchronous redo shipping for near-zero-RPO replication within an OCI region and asynchronous GoldenGate replication for cross-region or cross-cloud topologies where strict 2PC would add unacceptable latency.

Feature 3 — Hardware Independence

Hardware independence means that a distributed query can retrieve and update data regardless of the hardware platform on which the data resides. A single transaction can span Oracle databases running on x86 servers, ARM-based cloud instances, SPARC systems, and IBM Power platforms without the application needing any knowledge of the underlying hardware.

Oracle Net Services implements hardware independence by abstracting all hardware-specific details below the TNS layer. The application issues standard T-SQL through OCI, JDBC, ODBC, or ADO.NET — the driver translates the request into TDS-equivalent Oracle Net packets, and Oracle Net handles the communication to the remote database regardless of its hardware platform.

In OCI, hardware independence has been extended to the cloud infrastructure layer. An Oracle database running on OCI Exadata X9M (custom Oracle hardware), OCI Compute (x86 VM), OCI Ampere (ARM-based VM), or on-premises hardware connected through FastConnect all participate in the same distributed Oracle environment through the same Oracle Net Services connectivity layer. The Modern Design Hub in the Nano Banana 2 diagram represents this hardware-agnostic cloud layer — any client device (high-end workstation, edge node, smart device, ultra-portable notebook, smartphone, tablet, IoT node) can connect to any participating Oracle database regardless of the hardware running beneath it.

Additional Distributed Database Features

The following features of a distributed Oracle database system are covered in detail on their dedicated pages within this module. Each link leads to a lesson examining the specific feature in the context of Oracle Net Services and OCI:

1. Local Autonomy — each site operates independently and retains control over its own data, schema, and security policies
2. Location Independence — users access data without needing to know its physical location
3. Fragmentation Independence — data can be partitioned across sites transparently to the application
4. Distributed Query Processing — queries spanning multiple sites are optimized and executed transparently
5. Distributed Transaction Management (update processing) — ACID guarantees across all participating nodes
6. Operating System Independence — Oracle Net operates across Windows, Linux, AIX, and Solaris
7. Network Independence — Oracle Net abstracts the underlying network protocol

No Reliance on a Central Site

An ideal distributed database places no single site in a position of governing authority over all other sites. All sites are equally remote from one another. Each site retains its own Oracle data dictionary and security model — a read-only set of tables and views that holds the metadata governing that site's objects, users, roles, privileges, integrity constraints, stored procedures, triggers, and space allocations.

In practice, no Oracle deployment is perfectly decentralized — some degree of centralized administration is necessary for governance and compliance. The principle, however, guides Oracle's architecture: each Oracle database in a distributed system maintains its own complete data dictionary, and the loss of any single site does not prevent the surviving sites from continuing to operate. Oracle's Global Data Services catalog in OCI provides a centralized catalog of available database services across all participating sites, but the individual databases themselves retain autonomous operation capability if the GDS catalog becomes unavailable.

Organizations deploy multiple Oracle databases in a distributed system for a range of business and technical reasons:

1. Different databases aligned with specific business functions — manufacturing, human resources, finance, order management — each optimized for its domain workload
2. Databases aligned with geographic boundaries — a large headquarters database in an OCI primary region with smaller regional databases in OCI secondary regions closer to regional users
3. Operational and analytical databases serving the same data in different ways — an OLTP order entry database feeding an Autonomous Data Warehouse through GoldenGate for near-real-time analytics
4. Multiple sharded copies of the same database providing horizontal read scalability for high-traffic internet commerce workloads through Oracle Sharding
5. Production database copies serving as development and test environments — provisioned as OCI database clones that are isolated from production but use consistent schema snapshots

Summary

C.J. Date's 12-specification framework for distributed databases provides the conceptual foundation for understanding what Oracle's distributed database architecture is designed to achieve. Continuous operation — implemented through Active Data Guard, RAC, and Zero Downtime Patching — ensures no maintenance activity requires a complete system outage. Replication independence — implemented through GoldenGate's log-based capture and apply architecture — ensures applications are isolated from the mechanics of data propagation. Hardware independence — implemented through Oracle Net's TNS abstraction layer — ensures that the underlying hardware platform at any node is invisible to the application. Each site retains its own data dictionary and autonomous operation capability, with OCI Global Data Services providing centralized service catalog management without creating a single point of failure at the data level. The next lesson examines Oracle's topology solution — the service name, database link, and synonym architecture that makes all these distributed features accessible through standard Oracle SQL syntax.