Partitions

Db2 usually distributes the data evenly across the partitions of a table space when it is created. However, the distribution of the data might become uneven over time, as inserts and deletes occur. You can rebalance data among the partitions by redefining partition boundaries with no impact to availability. You can also add a partition to the table and to each partitioned index on the table; the new partition becomes available immediately.

You can spread the partitions of a large table over several Db2 storage groups or data sets. The partitions of the table do not all need to use the same storage group.

You can also put different partitions on different device types, which means that you can put frequently accessed data in separate partitions and place these partitions on faster devices.

You can use separate jobs for mass update, delete, or insert operations instead of using one large job; each smaller job can work on a different partition. Separating the large job into several smaller jobs that run concurrently can reduce the elapsed time for the whole task.

For certain read-only queries, Db2 can use parallel processing on more than one partition. Parallel processing (for read-only queries) is most efficient when you spread the partitions over different disk volumes and allow each I/O stream to operate on a separate channel. Use the Parallel Sysplex data sharing technology to process a single read-only query across many Db2 subsystems in a data sharing group. You can optimize Parallel Sysplex query processing by placing each Db2 subsystem on a separate central processor complex.

Certain table space types do not have partitions, including segmented (non-UTS) table spaces and simple table spaces. However, all such table spaces are deprecated.