In a multitenant RAC database, you have one or more instances that are connected to a container database. Within the container database, you have one or more pluggable databases. Figure 2-4 shows a two-node RAC database connected to a container database named CDB that contains two pluggable databases (PDB1 and PDB2). There are two instances in this configuration (CDB1 and CDB2). The RAC container database accesses shared ASM disks that are visible from each node.
Figure 2-4. A two-node RAC container database with two pluggable databases
In this example, the client initiates a connection to the PDB1 pluggable database. This connects to the RAC SCAN listener, which hands off the connection request to one of the database listeners (node 1 in this example). The listener connects the client to a server process in the CDB1 instance. In this configuration, the client is connected to the CDB1 instance and accessing the PDB1 pluggable database. The client has no visibility to the other pluggable databases (PDB2) within the container. In other words, the client can only access data within the pluggable database that the client is currently connected to (PDB1 in this example).
Sharded Database
Starting with Oracle 12.2, the sharded database feature is a logical database that is horizontally partitioned across a pool of physical databases that don’t share any hardware infrastructure. In other words, each database in the shard is hosted on a dedicated server with its own CPU, memory, and disk. The sharded database logically looks like one database to the end-user application, but under the covers, it consists of one or more physical databases.
Each database in the sharded database is referred to as a shard. The database shards can be single instance or multi-instance RAC databases. When creating a table, a column needs to be specified as the distribution key. The distribution key can be defined as consistent, hash, or list. Each sharded database environment uses a sharded catalog database. The sharded catalog supports tasks such as automated shard deployment,centralized management of the sharded database, and multi-shard queries. There are also shard directors which are listeners that handle connection routing based on the sharding key.
Figure 2-5 shows (at a high level) the basic architecture of a sharded database. The client initiates a connection to the global service associated with a sharded database. This connects the client to a connection pool. The request for data is routed to the appropriate instance based on the sharding key.
Figure 2-5. A sharded database that contains three database shards
The major benefits of database sharding are as follows:
•\ Linear scalability: You can add or remove shards as your business requirements dictate.
•\ Fault tolerance: The database shard exists on independent hardware; therefore, an outage on one database shard does not impact other shards.
•\ Geographic distribution of data: You might want to do this for legal reasons or privacy regulation reasons.
•\ Rolling upgrades: Each shard can be independently upgraded.
•\ Regional performance: Each shard can exist in a specific geographic region with its own hardware and storage configuration.
Each database shard is self-contained, meaning each shard will have its own SGA and background processes. So unlike RAC, where multiple instances share the same set of physical database files, sharding is multiple databases (each with its own instance) presented to the end user as one logical database.
