The multiple processors available in an SMP environment allow
database operations to be completed significantly more quickly than with
databases assigned to only a single processor.
![]() |
Version 5
|
The I/O parallelism provided in DB2 Version 2 has been enhanced. It now exploits CPU parallelism in a single SQL query. Technology is introduced which exploits multiple processors of a symmetric multiprocessor (SMP) to speed up the execution of a single SQL query. Prior to this work, SMP exploitation was limited to that between multiple queries and to parallel I/O. A key purpose of this technology is to exploit the fact that disks, memory, and processors can be shared uniformly by multiple processors in an SMP system. This provides two important benefits:
See the Administration Guide for more information.
Support now exists for the LOAD utility to exploit multiple processors in SMP machines.
While loading data into a table in a multinode nodegroup, the data files must have been processed by the splitter utility (db2split), which writes a header to each file. Only ASC and DEL files may be used to load in a table that exists on a multinode nodegroup. In addition, you now have the option to pick a set of partitions, which may be the same or different from the partitions being loaded, to participate in the parallel split process. See the Command Reference for more information.
As well, you can specify the degree of LOAD parallelism desired for CPU and disk I/O. See the Command Reference and the API Reference for more information.
Backup and restore of multiple table spaces on SMP
machines are performed in parallel. See the Command
Reference for more information.
![]() |
Version 5.2
|
Multiple processors of an SMP are now used to speed up the process of generating an index. An index can be generated with the CREATE INDEX statement, the addition of a primary key or unique constraint to a table, or the REORG TABLE command. See the Command Reference for more information.
If a query is run with DEGREE = ANY, the database manager chooses the degree of intra-partition parallelism based on a number of factors including the number of processors and the characteristics of the query. The actual degree used at run time may be lower than the number of processors depending on these factors.
The degree of parallelism is determined by the SQL optimizer when the statement is compiled and may be adjusted before query execution depending on the database activity. The degree of parallelism may be lower than that chosen by the SQL optimizer if the system is heavily utilized. This occurs since intra-partition parallelism aggressively uses system resources to reduce the elapsed time of the query which may adversely affect the performance of other database users. See the Administration Guide for details.