Vector Data Type Support

With Globally Distributed Database support for Vector Search, tables containing vectors are automatically distributed and replicated across a pool of Oracle databases that share no hardware. Similarity searches are automatically conducted in parallel across shards or directed to a specific shard if the sharding key is provided.

Globally Distributed Database AI Vector Search offers several benefits, including greater scalability by allowing vectors to be distributed across multiple machines, improved performance by conducting parallel vector searches across shards, and improved data resilience because if one shard goes down, the other shards can continue to operate. It also allows vector search to be deployed as part of a distributed database, where a single logical database is distributed over multiple geographies.

See Oracle AI Vector Search in a Distributed Database

Chunk Move Enhancement for Composite Data Distribution

In the composite data distribution method, the data can be organized into different shardspaces based on the value of super shard key column values. This enhancement creates a way to split the existing data chunks as per super shard key values into new shardspaces.

In Oracle 21c, for composite distribution, the data should be arranged physically as per super shard keys, possibly in different a shardspace once the super shard key is specified, but this data movement had to be done manually by selecting a huge amount of data from the source shardspace, inserting it into a temporary table, then deleting it from the source shardspace and inserting from the temporary table into the target shardspace. This would be done over database links (DBLINK), row by row, and would take a significant amount of time.

In Oracle Database 23ai, a bulk move of data between shardspaces is supported by running the split partitionset command. When there is a need to re-arrange the data based on the super shard key, you split the existing data chunks as per super shard key values into new shardspaces, which triggers the bulk data movement. Oracle Globally Distributed Database 23ai splits the data and makes the data available for access for client connections for the maximum possible time while the bulk data movement operation is in progress.

Benefits :

• Automates the splitting and moving data

• Keeps data online during split and move

• Allows bulk data move using transportable tablespace

See Splitting Chunks into Shardspaces Based on Super Key for more information.

Raft Replication

Raft replication, built right into Oracle Globally Distributed Database, provides built-in replication without requiring configuration of Oracle Data Guard. Raft replication uses logical replication with a consensus-based commit protocol, which enables declarative replication configuration and sub-second fail over.

Oracle Globally Distributed Database relies on replication for availability, but using Data Guard requires you to understand, deploy, and maintain the underlying replication technologies, which results in operational overhead, especially with hyperscale deployments.

Raft replication makes replication simple and transparent because replication is built right into Oracle Globally Distributed Database.

See Raft Replication Configuration and Management for more information.

Directory-Based Data Distribution

Today, our customers are using three types of data distribution methods: System-managed, User-defined , and Composite. Directory-based distribution, which is an enhanced type of user-defined distribution method, lets you control the placement of the data on the shards.

Directory-based distribution helps you use your distributed database resources more efficiently when there is not a large enough set of distinct key values to result in an even distribution of data with system-managed distribution. Directory-based distribution also provides full control over the mapping of key values to shards.

Directory-based distribution allows you to explicitly associate key value with shards, giving you full control over the mapping of key values to shards.

See Directory-Based Data Distribution for more information.

Synchronous Duplicated Tables

This feature introduces a new kind of duplicated table that is synchronized on the shards ‘on-commit’ on the shard catalog. The rows in a duplicated table on the shards are synchronized with the rows in the duplicated table on the shard catalog when the active transaction performing DMLs on the duplicated tables in the shard catalog is committed.

This features enables efficient and absolute data consistency and synchronization for duplicated tables, across all shards at all times.

See Creating Duplicated Tables for more information.

Fine-Grained Refresh Rate Control For Duplicated Tables

This feature enables refresh rate control for individual duplicated tables, and it helps optimize the use of resources by customization of refresh rates for individual duplicated tables. .

The new REFRESH clause in CREATE DUPLICATED TABLE and ALTER TABLE allows you to specify a refresh interval for a duplicated table. You can set an interval in seconds, minutes, hours, or you can set the table to only refresh on demand. For example:

CREATE DUPLICATED TABLE Products 
...
REFRESH INTERVAL 2 MINUTE;

ALTER TABLE Products MODIFY REFRESH ON DEMAND;

See Customizing Duplicated Table Refresh Rates for more information.

Distributed Database Coordinated Backup and Restore Enhancements

Coordinated backup and restore functionality has several major enhancements in this release:

• Enhanced error handling and diagnosis for backup jobs (see Error Handling for Automated Backup Operations).

• Automation of shard catalog database restore. Previously the shard catalog had to be restored manually using RMAN. In this release GDSCTL RESTORE BACKUP is enhanced to support shard catalog restoration with the option -shard CATALOG (see Restoring the Shard Catalog from Backup).

• Using the new GDSCTL RMAN command you can submit RMAN commands to a list of shards for execution. RMAN statements can be submitted in the body of the command, or you can reference an RMAN command file. (see Running RMAN Commands from GDSCTL).

• Support for using different RMAN recovery catalogs for different shards is provided by running GDSCTL CONFIG BACKUP multiple times to specify different recovery catalogs for specific shards and the shard catalog (see Specifying Multiple Recovery Catalogs).

• Encryption of backup sets with the new GDSCTL CONFIG BACKUP -encryption option lets you enable or disable the encryption of backup sets and choose an encryption algorithm (see Backup Set Encryption).

• Support for additional backup destinations:

  • Oracle Object Storage - using existing GDSCTL CONFIG BACKUP options you can now send backups to Object Storage (see Using Oracle Object Storage as a Backup Destination).

  • Zero Data Loss Recovery Appliance - GDSCTL CONFIG BACKUP is enhanced with several new Recovery Appliance-specific parameters (-zdlra_*) to specify Recovery Appliance as the backup destination (see Using Recovery Appliance as a Backup Destination).

  • Amazon S3 - using existing GDSCTL CONFIG BACKUP options you can now send backups to Amazon Simple Storage Service (see Using Amazon S3 as a Backup Destination).

Automatic Data Move on Sharding Key Update

Sometimes a sharding key value needs updating. The previous solution was to delete the data associated with the old key value and re-insert it with a new key value. The goal of this enhancement is to allow row movement both within a shard and between shards.

When the sharding key value on a particular row of a sharded table is updated, Now moving the data to a new location is handled by Oracle Globally Distributed Database, whether it is in a different partition on the same shard or on a different shard.

This feature provides you with the flexibility to update the sharding key without worrying about the destination of the records, because this feature allows Oracle Globally Distributed Database to take care of the row movement regardless of the row destination, which could be on a different shard.

Benefits:

• Provides flexibility to update the sharding key value

• Allows transparent data movement between shards

See Enabling Automatic Data Movement on Sharding Key Update for more information.

Global Partitioned Index Support on Subpartitions

This feature allows a global partitioned index on the sharding key when the sharded table is sub-partitioned, as in a distributed database using composite data distribution. You can create primary key/unique indexes on sharded tables that are composite partitioned without having to include sub-partition keys.

This feature removes the restriction on the primary key columns when the sharded table is sub-partitioned, as in composite data distribution.

See Creating Indexes on Sharded Tables for more information and examples.

PL/SQL Function Cross-Shard Query Support

PL/SQL functions are enhanced with the keyword SHARD_ENABLE to allow PL/SQL functions to be referenced in cross-shard queries. With the new keyword, the query optimizer takes the initiative to push the execution of the PL/SQL function to the shards.

This feature significantly improves performance for PL/SQL functions for distributed database environments.

See Pushing PL/SQL Function Queries to the Shards for more information.

See SHARD_ENABLE Clause in Oracle Database PL/SQL Language Reference for syntax and usage information.

Pre-Deployment Network Validation

An option to run a series of checks while processing several GDSCTL commands during the configuration and deployment of a distributed database verify that there is no potential environmental issue.

This feature proactively avoids common pitfalls to reduce time taken to complete a distributed database deployment.

See Pre-Deployment Network Validation for more information.

New Partition Set Operations for Composite Data Distribution

For distributed databases using the composite data distribution method, two new ALTER TABLE operations enhance partition set maintenance.

Previously, partition set operations did not support specifying tablespace sets for child and reference-partitioned tables that are affected due to add and split partition set operations. MOVE PARTITIONSET lets you move a whole partition set from one tablespace set to another, within the same shardspace. MODIFY PARTITIONSET lets you add values to the list of values of a given partition set.

These new operations enhance data redistribution capability. MOVE PARTITIONSET gives you the control to move all subpartitions of a given table to another tablespace set, within a given shardspace. You can also specify separate tablespace sets for LOBs and subpartitions. MODIFY PARTITIONSET extends the add list values feature of partitions to partition sets.

See ALTER TABLE in Oracle Database SQL Language Reference for more information.

Parallel Cross-Shard DML Support

The Oracle Globally Distributed Database query coordinator can run cross-shard updates, inserts, and deletes in parallel on multiple shards. This feature improves cross-shard DML performance by running these operations in parallel rather than serially.

Oracle Data Pump Adds Support for Distributed Database Metadata

Oracle Data Pump supports data migration to Oracle Globally Distributed Database with support for sharded DDL. You can migrate distributed database objects to a target database based on source database shard objects.

Oracle Data Pump adds support for distributed database DDL in the API dbms_metadata.get_ddl(). A new transform parameter, INCLUDE_SHARDING_CLAUSES, facilitates this support. If this parameter is set to true, and the underlying object contains it, then the get_ddl() API returns distributed database DDL for create table, sequence, tablespace, and tablespace set.

See Oracle Database Utilities topics TRANSFORM and Placing Conditions on Transforms, and Oracle Database PL/SQL Packages and Types Reference topic SET_TRANSFORM_PARAM and SET_REMAP_PARAM Procedures for details, examples, and reference.

Automatic Parallel Direct Path Load Using SQL*Loader

SQL*Loader enables direct data loading into the database shards for high speed data ingest. SQL*Loader can load data faster and easier into Oracle Database with automatic parallelism and more efficient data storage.

With this release, SQL*Loader client can automatically start a parallel direct path load for data without dividing the data into separate files and starting multiple SQL*Loader clients. Instead of preparing your tables manually for parallel loads and setting the PARALLEL parameter, you can perform the same task automatically by running SQL*Loader with just one command, setting the degree of parallelism using the DEGREE_OF_PARALLELISM parameter, and setting DIRECT=TRUE.

See Oracle Database Utilities topics Sharded Automatic Parallel Loading Modes for SQL*Loader and Automatic Parallel Load of Table Data with SQL*Loader for more information.