Partitioned Table Support - IBM 170 Servers Manual

Partitioned Table Support

Table partitioning is a new feature introduced in i5/OS V5R3. The design is localized on an individual
table basis rather than an entire library. The user specifies one or more fields which collectively act as a
partitioning key. Next the records in the table are distributed into multiple disjoint sets based on the
partitioning scheme used: either a system-supplied hashing function or a set of value ranges (such as dates
by month or year) supplied by the user. The user can partition data using up to 256 partitions in i5/OS
V5R3. The partitions are stored as multiple members associated with the same file object, which
continues to represent the overall table as a single entity from an SQL data-access viewpoint.
The primary motivations for the initial release of this feature are twofold:
Eliminate the limitation of at most 4 billion (2^32) rows in a single table
Enhance data administration tasks such as save/restore, import/export, and add/drop which can be
done more quickly on a partition basis (subset of a table)
In theory, table partitioning also offers opportunities for performance gains on queries that specify
selection referencing a single or small number of partitions. In reality, however, the performance impact
of partitioned tables in this initial release are limited on the positive side and may instead result in
performance degradation when adopted too eagerly without carefully considering the ramifications of
such a change. The resulting performance after partitioning a table depends critically on the mix of
queries used to access the table and the number of partitions created. If fields used as partitioning keys
are frequently included in selection criteria the resulting performance can be much better due to improved
locality of reference for the desired records. When used incorrectly, table partitioning may degrade the
performance of queries by an order of magnitude or more -- particularly when a large number of
partitions (>32) are created.
Performance expectations of table partitioning on i5/OS V5R3 should not be equated at this time with
partitioning concepts on other database platforms such as DB2 for Linux, Unix and Windows or offerings
from other competitors. Nor should table partitioning on V5R3 be confused with the DB2 Multisystem
for i5/OS offering. Carefully planned data storage schemes with active end-user disk arm management
lead to the performance gains experienced with partitioned databases on those other platforms. Further
gains are realized in other approaches through execution on clusters of physical nodes (in an approach
similar to DB2 Multisystem for i5/OS). In addition, the entire schema is involved in the partitioning
approach. On the other hand, the System i table partitioning design continues to utilize single level
storage which already automatically spreads data to all disks in the relevant ASP. No new performance
gains from I/O balancing are achieved when partitioning a table. Instead the gains tend to involve
improved locality of reference for a subset of the data contained in a single partition or ease of
administration when adding or deleting data on partition boundaries.
An in-depth discussion of table partitioning for i5/OS V5R3 is available in the white paper Table
Partitioning Strategies for DB2 FOR i5/OS available at
http://www.ibm.com/servers/eserver/iseries/db2/awp.html
This publication covers additional details such as:
Migration strategies for deployment
Requirements and Limitations
Sample Environments (OLTP, OLAP, Limits to Growth, etc.) & Recommended Settings
Indexing Strategies
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 4 - DB2 Performance
48