This section provides an overview of the following hardware environments:
Capacity and scalability are discussed for each environment. 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.
This environment is made up of memory and disk, but contains only a single CPU (see Figure 25). It is referred to by many different names, including stand-alone database, client/server database, serial database, uniprocessor system, and single node or non-parallel environment.
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.
Table 3 lists the types of parallelism best suited to take advantage of this hardware configuration.
Figure 25. Single Partition On a Single Processor
|
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. You can also add more hard disk space to this environment.
A single-processor system is restricted by the amount of disk space the processor can handle. However, as workload increases, a single CPU may not be able to process user requests any faster, regardless of other components, such as memory or disk, that you may add. If you have reached maximum capacity or scalability, you can consider moving to a single partition system with multiple processors.
This environment is typically made up of several equally powerful processors within the same machine (see Figure 26), and is called a symmetric multi-processor (SMP) system. Resources, such as disk space and memory, are shared.
With multiple processors available, different database operations can be completed more quickly. DB2 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.
Table 3 lists the types of parallelism best suited to take advantage of this hardware configuration.
Figure 26. Single Partition Database Symmetric Multiprocessor System
 |
In this environment you can add more processors. However, since the different processors may attempt to access the same data, limitations with this environment can appear as your business operations grow. With shared memory and shared disks, you are effectively sharing all of the database data.
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 partitions.
You can divide a database into multiple partitions, each on its own machine. Multiple machines with multiple database partitions can be grouped together. This section describes the following partition configurations:
In this environment, there are many database partitions. Each partition resides on its own machine, and has its own processor, memory, and disks (Figure 27). 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 partition. The fact that data is partitioned remains transparent to most users. Work can be divided among the database managers; each database manager in each partition works against its own part of the database.
Table 3 lists the types of parallelism best suited to take advantage of this hardware configuration.
Figure 27. Massively Parallel Processing System
 |
In this environment you can add more database partitions (nodes) to your configuration. On some platforms, for example the RS/6000 SP, the maximum number is 512 nodes. However, there may 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 partition has multiple processors.
An alternative to a configuration in which each partition has a single processor, is a configuration in which a partition has multiple processors. This is known as an SMP cluster (Figure 28).
This configuration combines the advantages of SMP and MPP parallelism. This means that a query can be performed in a single partition across multiple processors. It also means that a query can be performed in parallel across multiple partitions.
Table 3 lists the types of parallelism best suited to take advantage of this hardware configuration.
 |
In this environment you can add more database partitions, and you can add more processors to existing 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 may make fuller use of available resources than a single database manager could. Figure 29 illustrates the fact that you may gain more scalability on an SMP machine by adding more partitions; this is particularly true for machines with many processors. By partitioning the database, you can administer and recover each partition separately.
Figure 29. Partitioned Database, Symmetric Multiprocessor System
 |
Figure 30 illustrates the fact that you can multiply the configuration shown in Figure 29 to increase processing power.
Figure 30. Partitioned Database, Symmetric Multiprocessor Systems Clustered Together
 |
Table 3 lists the types of parallelism best suited to take advantage of this hardware environment.
| Note: | The ability to have two or more 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 partition of the same database. For more information, see Chapter 11, Designing for High Availability. |
The following table summarizes the types of parallelism best suited to take
advantage of the various hardware environments.
Table 3. Types of Parallelism Possible in Each Hardware Environment
| Hardware Environment | I/O Parallelism | Intra-Query Parallelism | |||
|---|---|---|---|---|---|
| Intra- Partition Parallelism | Inter- Partition Parallelism | ||||
| Single Partition, Single Processor | Yes | No(1) | No | ||
| Single Partition, Multiple Processors (SMP) | Yes | Yes | No | ||
| Multiple Partitions, One Processor (MPP) | Yes | No(1) | Yes | ||
| Multiple Partitions, Multiple Processors (cluster of SMPs) | Yes | Yes | Yes | ||
| Logical Database Partitions | Yes | Yes | Yes | ||
| |||||