Distributed Databases   «Prev  Next»

Lesson 1

Features of Distributed Databases

The purpose of this module is to examine the new Oracle features related to distributed databases. As you know, Oracle software is evolving constantly to improve database connectivity between distributed systems. With the introduction of Oracle, we see several new features that improve connectivity between remote databases and offer improved security and replication reliability.
After completing this module, you will be able to:
  1. List primary Oracle enhancements for distributed databases
  2. Work with queue propagation
  3. Describe enhanced LOB support in Oracle
  4. Monitor replication by querying V$ views
  5. Implement snapshot security
  6. Walk through the steps for creating snapshots offline
  7. Identify the new features of snapshot deployment templates

The objective of this module is to provide you with enough detailed information about the new Oracle distributed features to enable you to use them in your organization and to understand their functions well enough to pass the OCT exam. This module assumes that you already have a baseline understanding of Oracle distributed database concepts, including snapshots and replication techniques. Let us began by taking a closer look at each of the enhancements for distributed databases.

Enhancements for "Oracle Distributed Databases" between Oracle 19c and 23c

Oracle 23c introduces significant enhancements over Oracle 19c in the area of distributed databases, focusing on scalability, developer productivity, cloud-readiness, and cross-shard operations. Here’s a structured comparison of the key improvements:
πŸ”„ Enhancements in Oracle Distributed Databases (19c β†’ 23c)
Feature Area Oracle 19c Oracle 23c Enhancements
Sharding Supported with manual configuration Auto-Sharding with native support for Relational Sharding and JSON Relational Duality Views
Cross-Shard Queries Manual query federation Improved cross-shard query execution plans and automatic result aggregation with better parallelization
Multi-Shard Transactions Complex 2PC with limitations Enhanced support for lightweight XA, fast commit protocols, and shard-local ACID with global consistency
Data Residency & Compliance Basic data partitioning Data Sovereignty-aware partitioning, supporting Geo-sharding for regulatory compliance
JSON Handling JSON stored as text or BLOB JSON Relational Duality Views, allowing JSON-centric applications to operate over normalized relational tables across shards
Distributed Graph & ML External or add-on Native support for graph queries, vector operations, and AI/ML pipelines across distributed nodes
Developer Experience Mostly manual config Multitenant container-based distributed setup, SQL macros, REST APIs, and AutoML integration
Cloud-native readiness Optimized for on-prem & hybrid Designed for distributed cloud, supports autonomous shards, and Kubernetes-based deployment
Security Localized roles and auditing Centralized auditing, end-to-end encryption, unified RBAC across distributed nodes
Data Sync & Refresh DB Links & Streams Oracle GoldenGate optimized for shards, plus declarative replication policies

πŸ†• Highlight: JSON Relational Duality in 23c
This new model allows seamless integration of relational and JSON data across shards. It enables:
  • Real-time access to both views
  • Updates via either format
  • JSON apps to operate over distributed normalized schema

This is a game-changer for "modern microservices and mobile-first architectures".
πŸ” Distributed Security in 23c
  • Role and privilege propagation across shards
  • Fine-grained audit policies
  • Integrated with Oracle Data Safe for compliance

🌐 Use Case Evolution
Use Case Improved in 23c
Global Retail Chains βœ… Better Geo-sharding & partitioning
Mobile Banking Apps βœ… Duality Views for JSON APIs
Real-time Analytics βœ… Faster cross-shard joins
AI on Distributed Data βœ… Integrated ML pipelines
Components affected by the shift from "DB Links and Streams" in Oracle 19c
Here is a breakdown of the components affected by the shift from "DB Links and Streams" in Oracle 19c to "Auto-Sharding" in Oracle 23c, and how this impacts deployment, scalability, and architecture:
πŸ”„ Component-Level Comparison: Oracle 19c vs Oracle 23c
Component Oracle 19c (DB Links & Streams) Oracle 23c (Auto-Sharding)
Network Configuration Requires manual setup of DBLINKS between databases. Complex TNS configurations. Auto-discovered shard catalogs and connections. Simplified config via GDSCTL.
Data Movement / Replication Streams required for replication; deprecated and superseded by GoldenGate. Declarative replication between shards. No Streams. Uses GoldenGate or built-in sync logic.
Application Logic Apps must be shard-aware or use views that federate across DB Links. Transparent sharding. App connects to a shard catalog; routing is automated.
Schema Management Manual sync of schema definitions across nodes. Shard catalog enforces uniform schema across all shards automatically.
Query Execution Queries across DB Links have latency and limited parallelism. Optimized cross-shard querying and result aggregation built-in.
Security Separate authentication per DB link; limited centralized auditing. Centralized identity (e.g., IDCS), unified audit policies across shards.
High Availability Manual failover handling; Streams configuration is fragile. Built-in shard-level HA; shard director reroutes based on health.
Scalability Vertical scaling; horizontal scaling is non-trivial. Native horizontal scaling by adding shards declaratively.
Monitoring & Tuning Requires custom scripts or Enterprise Manager to monitor DB Links & Streams. Integrated with Oracle Sharding Management and AWR views per shard.
Deployment Complexity High – must configure Streams, DB Links, failover manually. Lower – auto-sharding setup via shard catalog, GDSCTL. Declarative approach.

πŸ” Specific Components Affected in Oracle 19c
  • DB Link Management: Requires manual creation with CREATE DATABASE LINK.
  • Streams: Needs configuration for capture, propagation, and apply.
  • TNS Configuration: tnsnames.ora and listener.ora entries grow complex.
  • Application Code: May have to include link-specific syntax like SELECT * FROM table@remote_db.

πŸš€ Specific Components Affected in Oracle 23c
  • Shard Catalog (New Component): Central authority that manages shard topology.
  • Shard Director (GDS): Built-in routing mechanism replaces manual connection logic.
  • Auto-Sharding Engine: Handles distribution, rebalancing, and availability natively.
  • Duality Views (Optional): Allow relational-JSON hybrid querying across shards.

🧠 Summary
  • Oracle 19c relies on manual linking and replication logic, creating brittle and tightly coupled systems.
  • Oracle 23c shifts toward cloud-native, autonomous distributed management using Auto-Sharding, enabling scalability, elasticity, and resilience with far fewer touchpoints.


shard Catalog
shard Catalog

These enhancements collectively improve Oracle’s capabilities for distributed databases by focusing on scalability (sharding, multitenant), availability (Data Guard, RAC), performance (In-Memory, query optimization), and management simplicity (GDS, automation).

Distributed Databases

Distributed Database Architecture

When an organization is geographically dispersed, it may choose to store its databases on a central database server or to distribute them to local servers (or a combination of both). A distributed database is a single logical database that is spread physically across computers in multiple locations that are connected by a data communications network. We emphasize that a distributed database is truly a database, not a loose collection of files. The distributed database is still centrally administered as a corporate resource while providing local flexibility and customization. The network must allow the users to share the data; thus a user (or program) at location A must be able to access (and perhaps update) data at location B. The sites of a distributed system may be spread over a large area (e.g., the United States or the world) or over a small area (e.g., a building or campus). The computers may range from PCs to large-scale servers or even supercomputers. A distributed database requires multiple instances of a database management system (or several DBMSs), running at each remote site. The degree to which these different DBMS instances cooperate, or work in partnership, and whether there is a master site that coordinates requests involving data from multiple sites distinguish different types of distributed database environments.
  • Distributed Database System
    A distributed database system allows applications to access data from local and remote databases. In a homogenous distributed database system, each database is an Oracle Database. In a heterogeneous distributed database system, at least one of the databases is not an Oracle Database. Distributed databases use a client/server architecture to process information requests. This section contains the following topics:
    1. Homogenous Distributed Database Systems
    2. Heterogeneous Distributed Database Systems
    3. Client/Server Database Architecture

SEMrush Software TargetSEMrush Software Banner