This section provides an overview of the following hardware environments:
In each hardware environment section, considerations for capacity and scalability are described. Capacity refers to the number of users and applications able to access the database in large part determined by memory, agents, locks, I/O, and storage management. Scalability refers to the ability for 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. This environment has been given many names such as: standalone database, client/server database, serial database, uniprocessor system, and single node/non-parallel environment. Figure 6 illustrates this environment.
Figure 6. Single Partition On a Single Processor
|
The database in this environment serves the needs of a department or small office where the data and system resources (including only a single processor or CPU) are managed by a single database manager.
Table 1 lists the types of parallelism best suited to take advantage of this hardware configuration.
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 be taking 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 become insufficient in processing user requests any faster, regardless of other additional 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 configuration is described in the next section.
This environment is typically made up of several equally powerful processors within the same machine and is called a symmetric multi-processor (SMP) system. Resources such as disk space and memory are shared. More disks and memory are found in this machine compared to the single-partition database, single processor environment. This environment is easy to manage since physically everything is together in one machine and the sharing of memory and disks is expected.
With multiple processors available, different database operations can be completed significantly more quickly than with databases assigned to only a single processor. DB2 can also divide the work of a single query among available processors to improve processing speed. Other database operations such as the LOAD utility, the backup and restore of table spaces, and index creation on existing data can take advantage of the multiple processors. Figure 7 illustrates this environment.
Figure 7. Single Partition Database Symmetric Multiprocessor System
 |
Table 1 lists the types of parallelism best suited to take advantage of this hardware configuration.
In this environment you can add more processors. However, since it is possible for the different processors to 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. One application on one processor may be accessing the same data as another application on another processor, possibly causing the second application to wait for access to the data.
You can increase the I/O capacity of the database partition associated with your processor, such as 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 scalablity, you can consider moving to a system with multiple partitions. These configurations are described in the next section.
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 with each partition on its own machine and having its own processor, memory, and disks. Figure 8 illustrates this. A machine consists of a CPU, memory, and disk with all machines connected by a communications facility. Other names that have been given to this environment include: a cluster, a cluster of uniprocessors, a massively parallel processing (MPP) environment, or a 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.
Figure 8. Massively Parallel Processing System
 |
A partitioned database environment allows a database to remain a logical whole while being physically divided across more than one partition. To applications or users, the database can be used as a whole and the fact that data is partitioned remains transparent to most users. The work to be done with the data can be divided out to each of the database managers. Each database manager in each partition works against its own part of the database.
Table 1 lists the types of parallelism best suited to take advantage of this hardware configuration.
Capacity and Scalability: In this environment you can add more database partitions (nodes) to your configuration. On some platforms, for example the RS/6000 SP, the maximum is 512 nodes. However, there may be practical limits for 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. This configuration is described in the next section.
As 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.
This configuration combines the advantages of SMP and MPP parallelism. This means 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 1 lists the types of parallelism best suited to take advantage of this hardware configuration.
Capacity and Scalability: In this environment you can add more database partitions, as in the previous section. You can also 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, the database partitions do not share the resources. Processors are shared but disk and memory are not.
One reason for using logical database partitions is to provide scalability. Multiple database managers running in multiple logical partitions may be able to make fuller use of available resources than a single database manager could. This will become more true as machines with even more processors are manufactured. Figure 10 illustrates the fact that you may gain more scalability on an SMP machine by adding more partitions, particularly for machines with many processors. By partitioning the database, you can administer and recover each partition separately.
Figure 10. Partitioned Database, Symmetric Multiprocessor System
 |
Figure 11 illustrates the fact that you can multiply the configuration shown in Figure 10 to increase processing power.
Figure 11. Partitioned Database, Symmetric Multiprocessor Systems Clustered Together
 |
Note also that 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. See Chapter 12, High Availability Cluster Multi-Processing (HACMP) on AIX for a description of how, upon machine failure, a database partition can be automatically moved and restarted on another machine already containing another partition of the same database.
Table 1 lists the types of parallelism best suited to take advantage of this hardware environment.
The following table summarizes the types of parallelism best suited to
the various hardware environments.
Table 1. Types of Parallelism Possible for 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 | ||
| |||||