Planning Your Deployment

Many decisions need to be made when planning a Oracle Globally Distributed Database deployment including the distributed database topology, replication method, and the distributed database methodology.

Your particular distributed database may employ a variety of Oracle software components such as Oracle Data Guard and Oracle Real Application Clusters (Oracle RAC) along with different data distribution methods including system-managed (automatic), user-defined, and composite data distribution.

Depending on which data distribution method you choose (system, user-defined, or composite), you can further refine your topology planning with decisions about considerations such as the number of chunks, shardgroups or shardspaces, regions, standbys, and open as opposed to mounted databases, and so on.

See Oracle Globally Distributed Database Architecture and Concepts for information pertaining to these topology options.

Plan the Configuration

To plan your Oracle Globally Distributed Database configuration you need an understanding of the objects that make up a distributed database configuration, so that you can best configure and deploy them to meet your requirements.

The distributed database configuration consists of the data distribution (sharding) method, replication (high availability) technology, the default number of chunks to be present in the distributed database initially, the location and number of shard directors, the numbers of shardgroups, shardspaces, regions, and shards in the distributed database, and the global services that will be used to connect to the distributed database.

Oracle Database Global Data Services Architecture

Because the Oracle Globally Distributed Database feature is built on the Oracle Database Global Data Services feature, to plan your topology you might benefit from an understanding of the Global Data Services architecture. See Introduction to Global Data Services for conceptual information about Global Data Services.

Provision and Configure Hosts and Operating Systems

Before you install any software, review these hardware, network, and operating system requirements for Oracle Globally Distributed Database.

Number and Sizing of Host Systems

Depending on your specific configuration, the hosts that are needed may include the following:

  • Shard catalog host. The shard catalog host runs the Oracle Database that serves as the shard catalog. This database contains a small amount of distributed database topology metadata and any duplicated tables that are created for your application. In addition, the shard catalog acts as a multi-shard query coordinator for cross-shard queries and services connections for applications that have not been written to be distributed database-aware. In general, the transaction workload and size of this database are not particularly large.

  • Shard catalog database standbys (replicas). At least one more host to contain a replica or standby of the primary shard catalog database is recommended. This host is necessary in case of a failure of the primary catalog host.

    In addition, while acting as a standby database, this host can also be configured to be a query coordinator for cross-shard queries. To improve the scalability and availability of multi-shard query workloads, Oracle Active Data Guard standby shard catalog databases in read-only mode can act as multi-shard query coordinators. See Multi-Shard Query Coordinator Availability and Scalability.

  • Shard director host. The shard director (global service manager) software can reside on a separate host, or it can be co-located on the same host as the shard catalog. This component of the distributed database system is comprised of a network listener and several background processes used to monitor and configure a distributed database configuration. If it is co-located on the same host as the catalog database, the shard director must be installed in a separate Oracle Home from the catalog database, because the installation package is different than the one used for Oracle Database.

  • Multiple shard directors. For high-availability purposes, it is recommended that you have more than one shard director running in a distributed database system. Any additional shard directors can run on their own hosts or on the hosts running the standby shard catalog databases.

  • Shards. In addition to the above hosts, each shard that is configured in the system should also run on its own separate host. The hosts and their configurations chosen for this task should be sized in the same way as a typical Oracle Database host depending on how much load is put on each particular shard.

  • Shard standbys (replicas). Again, for high-availability and disaster recovery purposes, use Oracle Data Guard and replicas created for all sharded data. Additional hosts will be needed to run these replica or standby databases.

When the number of hosts and capacity requirements for each host have been determined, provision your hardware resources as appropriate for your environment using whatever methodologies you choose.

Note:

Oracle Globally Distributed Database does not support proxy PDBs.

Hardware and Operating System

Hardware and operating system requirements for shards are the same as those for Oracle Database. See your Oracle Database installation documentation for these requirements.

Hardware and operating system requirements for the shard catalog and shard directors are the same as those for the Global Data Services catalog and global service manager. See Oracle Database Global Data Services Concepts and Administration Guide for these requirements.

Network

Low Latency GigE is strongly recommended

Port Communication

Before installing any software, you must confirm that the hosts can communicate with each other though the ports as described below. Because a distributed database configuration is inherently a distributed system, it is crucial that this connectivity between and among all of the hosts is confirmed before moving on to the next steps in the deployment process. Failure to set up port access correctly will lead to failures in subsequent commands.

  • Each and every shard must be able to reach each and every shard director's listener and ONS ports. The shard director listener ports and the ONS ports must also be opened to the application/client tier, all of the shards, the shard catalog, and all other shard directors.

    The default listener port of the shard director is 1522, and the default ONS ports on most platforms are 6123 for the local ONS and 6234 for remote ONS.

  • Each and every shard must be able to reach the TNS Listener port (default 1521) of the shard catalog (both primary and standbys).

  • The TNS Listener port of each shard must be opened to all shard directors and the shard catalog.

  • All of the port numbers listed above are modifiable during the deployment configuration. However, the port numbers to be used must be known before setting up the host software.

Host Name Resolution

Host name resolution must be successful between all of the shard catalog, shards, and shard director hosts. Operating system commands such as ‘ping’ must succeed from a given host to any other host when specifying any host names provided during distributed database configuration commands.

Database

To see which editions of Oracle Database support Oracle Globally Distributed Database, see:

  1. Oracle Database Features and Licensing app at https://apex.oracle.com/database-features/.

    Select the Licensing tab, deselect all boxes under Offerings, and search for Oracle Globally Distributed Database to display the list of all supported editions.

  2. Permitted Features, Options, and Management Packs by Oracle Database Offering in Oracle Database Licensing Information User Manual for notes regarding the use of Oracle Globally Distributed Database in specific editions.