|DB2_PARALLEL_IO also affects table spaces with more than one |container defined. If you do not set the registry variable, the I/O |parallelism is equal to the number of containers in the table space. If |you set the registry variable, the I/O parallelism is equal to the result of |prefetch size divided by extent size. You might want to set the |registry variable if the individual containers in the table space are striped |across multiple physical disks.
|For example, a table space has two containers and the prefetch size is four |times the extent size. If the registry variable is not set, a prefetch |request for this table space will be broken into two requests (each request |will be for two extents). Provided that the prefetchers are available |to do work, two prefetchers can be working on these requests in |parallel. In the case where the registry variable is set, a prefetch |request for this table space will be broken into four requests (one extent per |request) with a possibility of four prefetchers servicing the requests in |parallel.
|In this example, if each of the two containers had a single disk dedicated |to it, setting the registry variable for this table space might result in |contention on those disks since two prefetchers will be accessing each of the |two disks at once. However, if each of the two containers was striped |across multiple disks, setting the registry variable would potentially allow |access to four different disks at once.
|In the "Nodegroup Design Considerations" subsection of the |"Designing Nodegroups" section , the following text from the |"Partitioning Keys" sub-subsection stating the points to be considered |when defining partitioning keys should be deleted only if |DB2_UPDATE_PART_KEY=ON: