Database partition and processor environments

Last Updated: 2024-02-15

This section provides an overview of both single database partition and multiple database partition configurations. The former include single
processor (uniprocessor) and multiple processor (SMP) configurations, and the latter include database partitions with one processor (MPP) or
multiple processors (cluster of SMPs), and logical database partitions.

Capacity refers to the number of users and applications able to access the database. This is in large part determined by memory, agents, locks, I/O,
and storage management. Scalability refers to the ability of a database to grow and continue to exhibit the same operating characteristics and
response times. Capacity and scalability are discussed for each environment.

Single database partition on a single processor

This environment is made up of memory and disk, but contains only a single CPU (see Figure 1). The database in this environment serves the needs
of a department or small office, where the data and system resources (including a single processor or CPU) are managed by a single database
manager.

Figure 1. Single database partition on a single processor

Capacity and scalability

In this environment you can add more disks. Having one or more I/O servers for each disk allows for more than one I/O operation to take place at the
same time.

A single-processor system is restricted by the amount of disk space the processor can handle. As workload increases, a single CPU might not be able
to process user requests any faster, regardless of other components, such as memory or disk, that you might add. If you have reached maximum
capacity or scalability, you can consider moving to a single database partition system with multiple processors.

Single database partition with multiple processors

This environment is typically made up of several equally powerful processors within the same machine (see Figure 2), and is called a symmetric
multiprocessor (SMP) system. Resources, such as disk space and memory, are shared.

With multiple processors available, different database operations can be completed more quickly. Db2® database systems can also divide the work
of a single query among available processors to improve processing speed. Other database operations, such as loading data, backing up and
restoring table spaces, and creating indexes on existing data, can take advantage of multiple processors.

Figure 2. Single partition database symmetric multiprocessor environment

Capacity and scalability

You can increase the I/O capacity of the database partition associated with your processor by increasing the number of disks. You can establish I/O
servers to specifically deal with I/O requests. Having one or more I/O servers for each disk allows for more than one I/O operation to take place at
the same time.

If you have reached maximum capacity or scalability, you can consider moving to a system with multiple database partitions.

Multiple database partition configurations

You can divide a database into multiple database partitions, each on its own machine. Multiple machines with multiple database partitions can be
grouped together. This section describes the following database partition configurations:
– Database partitions on systems with one processor
– Database partitions on systems with multiple processors
– Logical database partitions
Database partitions with one processor
In this environment, there are many database partitions. Each database partition resides on its own machine, and has its own processor, memory,
and disks (Figure 3). All the machines are connected by a communications facility. This environment is referred to by many different names,
including: cluster, cluster of uniprocessors, massively parallel processing (MPP) environment, and shared-nothing configuration. The latter name
accurately reflects the arrangement of resources in this environment. Unlike an SMP environment, an MPP environment has no shared memory or
disks. The MPP environment removes the limitations introduced through the sharing of memory and disks.

A partitioned database environment allows a database to remain a logical whole, despite being physically divided across more than one database
partition. The fact that data is distributed remains transparent to most users. Work can be divided among the database managers; each database
manager in each database partition works against its own part of the database.

Figure 3. Massively parallel processing (MPP) environment

Capacity and scalability

In this environment you can add more database partitions to your configuration. On some platforms the maximum number is 512 database
partitions. However, there might be practical limits on managing a high number of machines and instances.

If you have reached maximum capacity or scalability, you can consider moving to a system where each database partition has multiple processors.

Database partitions with multiple processors

An alternative to a configuration in which each database partition has a single processor, is a configuration in which each database partition has
multiple processors. This is known as an SMP cluster (Figure 4).

This configuration combines the advantages of SMP and MPP parallelism. This means that a query can be performed in a single database partition
across multiple processors. It also means that a query can be performed in parallel across multiple database partitions.

Figure 4. Several symmetric multiprocessor (SMP) environments in a cluster

Capacity and scalability

In this environment you can add more database partitions, and you can add more processors to existing database partitions.

Logical database partitions

A logical database partition differs from a physical partition in that it is not given control of an entire machine. Although the machine has shared
resources, database partitions do not share the resources. Processors are shared but disks and memory are not.

Logical database partitions provide scalability. Multiple database managers running on multiple logical partitions can make fuller use of available
resources than a single database manager can. Figure 5 illustrates the fact that you can gain more scalability on an SMP machine by adding more
database partitions; this is particularly true for machines with many processors. By distributing the database, you can administer and recover each
database partition separately.

Figure 5. Partitioned database with symmetric multiprocessor environment

Figure 6 illustrates that you can multiply the configuration shown in Figure 5 to increase processing power.

Figure 6. Partitioned database with symmetric multiprocessor environments clustered together

 Note: The ability to have two or more database partitions coexist on the same machine (regardless of the number of processors) allows
greater flexibility in designing high availability configurations and failover strategies. Upon machine failure, a database partition can be
automatically moved and restarted on a second machine that already contains another database partition of the same database.

Summary of parallelism best suited to each hardware environment

The following table summarizes the types of parallelism best suited to take advantage of the various hardware environments.

Table 1. Types of Possible Parallelism in Each Hardware Environment

Intra-Query Parallelism
Hardware Environment I/O Parallelism
Intra-Partition Inter-Partition
Parallelism Parallelism

Single Database Partition, Single Processor Yes No 1 No

Single Database Partition, Multiple Processors (SMP) Yes Yes No

Multiple Database Partitions, One Processor (MPP) Yes No 1 Yes

Multiple Database Partitions, Multiple Processors

Yes Yes Yes
(cluster of SMPs)

Logical Database Partitions Yes Yes Yes

1 There can be an advantage to setting the degree of parallelism (using one of the configuration parameters) to some value greater than one,

even on a single processor system, especially if your queries are not fully using the CPU (for example, if they are I/O bound).

Parent topic:
Partitioned database environments