Inter-partition parallelism occurs automatically based on the number
of database partitions and the distribution of data across these database
partitions.
About this task
Note: You must modify configuration parameters to take advantage
of parallelism within a database partition or within a non-partitioned database.
For example, intra-partition parallelism can be used to take advantage of
the multiple processors on a symmetric multi-processor (SMP) machine.
- Enabling parallelism for loading data
- The load utility automatically makes use of parallelism, or you can use
the following parameters on the LOAD command:
- CPU_PARALLELISM
- DISK_PARALLELISM
In a partitioned database environment, inter-partition parallelism
for data loading occurs automatically when the target table is defined on
multiple database partitions. Inter-partition parallelism for data loading
can be overridden by specifying OUTPUT_DBPARTNUMS. The load utility also intelligently
enables database partitioning parallelism depending on the size of the target
database partitions. MAX_NUM_PART_AGENTS can be used to control the maximum
degree of parallelism selected by the load utility. Database partitioning
parallelism can be overridden by specifying PARTITIONING_DBPARTNUMS when ANYORDER
is also specified.
- Enabling parallelism when creating indexes
- To enable parallelism when creating an index:
- The table must be large enough to benefit from parallelism
- Multiple processors must be enabled on an SMP computer.
- Enabling I/O parallelism when backing up a database or table space
- To enable I/O parallelism when backing up a database or table space:
- Use more than one target media.
- Configure table spaces for parallel I/O by defining multiple containers,
or use a single container with multiple disks, and the appropriate use of
the DB2_PARALLEL_IO registry variable. If you want to take advantage of parallel
I/O, you must consider the implications of what must be done before you define
any containers. This cannot be done whenever you see a need; it must be planned
for before you reach the point where you need to backup your database or
table space.
- Use the PARALLELISM parameter on the BACKUP command
to specify the degree of parallelism.
- Use the WITH num-buffers BUFFERS parameter on the BACKUP command
to ensure enough buffers are available to accommodate the degree of parallelism.
The number of buffers should equal the number of target media you have plus
the degree of parallelism selected plus a few extra.
Also, use a backup
buffer size that is:
- As large as feasible. 4 MB or 8 MB (1024 or 2048 pages) is a good rule
of thumb.
- At least as large as the largest (extentsize * number of containers) product
of the table spaces being backed up.
- Enabling I/O parallelism when restoring a database or table space
- To enable I/O parallelism when restoring a database or table space:
- Use more than one source media.
- Configure table spaces for parallel I/O. You must make the decision to
use this option before you define your containers. This cannot be done whenever
you see a need; it must be planned for before you reach the point where you
need to restore your database or table space.
- Use the PARALLELISM parameter on the RESTORE command
to specify the degree of parallelism.
- Use the WITH num-buffers BUFFERS parameter on the RESTORE command
to ensure enough buffers are available to accommodate the degree of parallelism.
The number of buffers should equal the number of target media you have plus
the degree of parallelism selected plus a few extra.
Also, use a restore
buffer size that is:
- As large as feasible. 4 MB or 8 MB (1024 or 2048 pages) is a good rule
of thumb.
- At least as large as the largest (extentsize * number of containers) product
of the table spaces being restored.
- The same as, or an even multiple of, the backup buffer size.