In DB2 Enterprise - Extended Edition (DB2 EEE), a database is distributed across multiple machines, and database partition servers are installed on a set of machines. Because the database is partitioned across multiple machines, you can use multiple CPUs across multiple machines to satisfy requests for information. The retrieval and update requests are decomposed automatically into subrequests and executed in parallel on the database partition servers on each machine.
As an illustration of the power of processing in a partitioned database system, assume that you have 100 000 000 records that you want to scan in a single-partition database. This scan would require that a single database manager search 100 000 000 records. Now suppose that these records are spread evenly over 20 database partition servers; each database manager only has to scan 5 000 000 records. If each database partition server scans at the same time and with the same speed, the time required to do the scan should be approximately 5% of that of a single-partition system handling this task.
User interaction with DB2 EEE is handled through one of the database partition servers (node). This database partition server is known as the coordinator node for the partitioned database system. By default, every database partition server in your partitioned database system can act as a coordinator node. The database partition server that a client or application connects to becomes the coordinator node. You should consider spreading out users across database partitions servers to distribute the coordinator function. For more information, refer to the Administration Guide.
DB2 EEE keeps communications overhead as low as possible. For example, if a row is being added to a table, the database partition server checks a partitioning map, which specifies the database partition server where the row is stored. The row is only sent to that database partition server, with the result that only the interested database partition servers take part in the insert.