Learn what a federated distributed database configuration is, why you need it, and how it works.

A federated distributed database is a distributed database configuration where the shards consist of independent databases with similar schemas.

Creating a distributed database from independent databases reduces the need to import tons of data into a single location for data analytics.

Consider the following benefits to this approach.

• Create a distributed database environment using existing, geographically distributed databases; there is no need to provision new systems.
• Run multi-shard queries; access data from many locations in a single query.

Oracle Globally Distributed Database, in a federated distributed database configuration, treats each independent database as a shard, and as such can issue multi-shard queries on those shards.

You can create a federated distributed database configuration with minor version mismatches between the shard databases. For example, one region could be on Oracle Database 23.1 and another could be on Oracle Database 23.3. All database shards and the shard catalog must be on Oracle Database 21c or later.

You can convert existing databases running the same application into a federated distributed database configuration, without modifying the database schemas or the application.

However, the databases must have the same schema or minor differences. For example, a table can have an extra column in one of the databases.

An application upgrade can trigger changes in the schema, such as when you add a new table, new column, new check constraint, or/and modify a column data type. When part of an overall federated distributed database configuration, Oracle Globally Distributed Database handles the schema differences caused by an application upgrade, as long as the overall schema structure stays the same.

Tables that have different sets of data on each of the federated databases are equivalent to the sharded tables in a traditional distributed database. Tables with the same content on all of the federated databases are equivalent to the duplicated tables in a traditional distributed database.

When you create the federated distributed database configuration, the system assumes that all of the tables are sharded, so you must explicitly mark the tables that must be considered duplicated by the multi-shard query coordinator.

There are some limitations to creating a federated distributed database configuration.

• There is no concept of chunk in a federated distributed database configuration, so the GDSCTL MOVE CHUNK command is not supported.
• Application sharding key-based routing is not supported.
• The existing databases, before being added to a federated distributed database configuration, must be upgraded to Oracle Database 21c or later.
• DDLs, cross-shard insert, update, and delete are not supported from the shard catalog in a federated distributed database architecture under ENABLE SHARD DDL.

The database users do not need to exist on all of the federated databases, but the schema owners should exist on all of the databases. The privileges and the passwords of these schema owners can be different. Only common privileges are imported for security.