|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: