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.

See

• User-Defined Sharding for a conceptual overview of user-defined sharding

• Using Oracle Data Guard with an SDB for information about replicating a user-defined sharded database Oracle Data Guard

• Creating and Deploying a User-Defined SDB for tasks related to configuring, creating and deploying a user-defined sharded database

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.

See

• Using Oracle Multitenant with Oracle Sharding for information about how to use PDBs as shards

• Oracle Database Global Data Services Concepts and Administration Guide for information about the new commands

Oracle GoldenGate is used for fine-grained multi-master replication where all shards are writable, and each shard can be partially replicated to other shards within a shardgroup.

See Shard-Level High Availability

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

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

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.

• DBMS_LOB

  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 DBMS_LOB.compare 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 SDB, 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.

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.

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 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