Changes in This Release for Oracle Sharding

This preface contains:

Changes in Oracle Database 18c

The following are changes in Using Oracle Sharding for Oracle Database 18c.

New Features

The following features are new in this release:

User-Defined Sharding Method

User-defined sharding allows you to explicitly specify mapping of data to individual shards. It is used when, because of performance, regulatory, or other reasons, certain data needs to be stored on a particular shard and you must have full control moving data between shards. This method allows you to define LIST or RANGE based sharding.


Support for PDBs as Shards

Use a PDB in a CDB for shards or a shard catalog database. In this release Oracle Sharding supports a shard or shard catalog as a single PDB in a CDB. The GDSCTL command ADD SHARD is extended and new commands ADD CDB, MODIFY CDB, CONFIG CDB, and REMOVE CDB are implemented so that Oracle Sharding can support a multitenant architecture.


Support for Oracle GoldenGate Replication

Oracle GoldenGate is used for fine-grained active-active replication where all shards are writable, and each shard can be partially replicated to other shards within a shardgroup. The Automatic Conflict Detection and Resolution feature added in Oracle 12.2 is used to handle any conflicts due to the active-active replication

See Shard-Level High Availability

Centralized Diagnostics

The SQL SHARDS() clause lets you query Oracle supplied objects, such as V$, DBA/USER/ALL views, dictionary tables, and so on, across all shards.

See Querying System Objects Across Shards

Multi-Shard Query Consistency Level

You can use the initialization parameter MULTISHARD_QUERY_DATA_CONSISTENCY to set different consistency levels when executing multi-shard queries.

See Specifying Consistency Levels in a Multi-Shard Query

Sharding Support for JSON, LOBs and Spatial Objects

This release enables JSON operators that generate temporary LOBs, large JSON documents (those that require LOB Storage), Spatial Objects, Index and Operators and Persistent LOBs to be used in a sharded environment.

The following interfaces are new or changed as part of this feature.

  • Query and DML statements

    Cross shard queries involving LOBs are supported.

    DMLs involving more than one shard are not supported. This behavior is similar to scalar columns.

    DMLs involving a single shard are supported from coordinator.

    Locator selected from a shard can be passed as bind value to the same shard.

  • OCILob

    All non-BFILE related OCILob APIs in a sharding environment are supported. with some restrictions.

    On the coordinator, the OCI_ATTR_LOB_REMOTE attribute of a LOB descriptor returns TRUE if the LOB was obtained from a sharded table.

    Restrictions: For APIs that take two locators as input, OCILobAppend, OCILobCompare for example, both of the locators should be obtained from the same shard. If locators are from different shards an error is given.


    All non-BFILE related DBMS_LOB APIs in a sharding environment are supported, with some restrictions. On the coordinator, DBMS_LOB.isremote returns TRUE if the LOB was obtained from a sharded table.

    Restrictions: For APIs that take two locators as input, DBMS_LOB.append and for example, both of the locators should be obtained from the same shard. If the locators are from different shards an error given.

See Creating a Schema for a System-Managed Sharded Database, Creating a Schema for a User-Defined SDB, and Creating a Schema for a Composite SDB for examples of using LOBs in sharded database deployment.

Optimizer Enhancements for Multi-Shard Queries

Various enhancements were made to improve the robustness and fault tolerance of shard queries. The query explain plan is enhanced to display information for all shards participating in the query.

See Supported Query Shapes in Proxy Routing and Execution Plans for Proxy Routing for updated information about these topics.

Shard Replacement

If a shard fails and is unrecoverable, you can replace it using the ADD SHARD -REPLACE command in GDSCTL. You can also use the -replace command option to move a shard to new equipment for any reason.

See Replacing a Shard

Oracle RAC Sharding

Oracle RAC Sharding creates an affinity for table partitions to particular Oracle RAC instances, and routes database requests that specify a partitioning key to the instance that logically holds the corresponding partition. This provides better cache utilization and dramatically reduces block pings across instances. The partitioning key can only be added to the most performance critical requests. Requests that don’t specify the key still work transparently and can be routed to any instance. No changes to the database schema are required to enable this feature.

See Oracle Real Application Clusters Administration and Deployment Guide

UCP Support for Data-Dependent Routing to Oracle Sharding Middle Tiers

A Oracle Universal Connection Pool (UCP) feature called middle-tier routing allows smart routers (F5 BigIP, for example) to route to the middle tier associated with a sharding key.

See Creating Affinity Between Middle-Tier Connection Pools and Shards

Other Changes

The following are additional changes in the release:

  • Sharding Content Moved to New Book

    In Oracle Database 12c Release 2 ( the Oracle Sharding content was part of the Oracle Database Administrator’s Guide. Starting in Oracle Database 18c the Oracle Sharding content is contained in its own book, Using Oracle Sharding.