Partitioned tables

 

DB2^® UDB for iSeries™ supports partitioned tables using SQL.

Partitioning allows for the data to be stored in more than one member, but the table appears as one object for data manipulation operations, such as queries, inserts, updates, and deletes. The partitions inherit the design characteristics of the table on which they are based, including the column names and types, constraints, and triggers.

Partitioning allows you to have much more data in your tables. Without partitioning, there is a maximum of 4 294 967 288 rows in a table, or a maximum size of 1.7 terabytes. A partitioned table, however, can have many partitions, with each partition able to have the maximum table size. For more information about maximum size for partitioned tables, refer to the DB2 UDB for iSeries White Papers.

Partitioning can also enhance the performance, recoverability, and manageability of your database. Each partition can be saved, restored, exported from, imported to, dropped, or reorganized independently of the other partitions. Additionally, partitioning allows for quickly deleting sets of records grouped in a partition, rather than processing individual rows of a nonpartitioned table. Dropping a partition provides significantly better performance than deleting the same rows from a nonpartitioned table.

A partitioned table is a database file with multiple members. A partitioned table is the equivalent of a database file member. Therefore, most of the CL commands that are used for members are also valid for each partition of a partitioned table.

You must have DB2 Multisystem installed on your system to take advantage of partitioned tables support. There are, however, some important differences between DB2 Multisystem and partitioning. DB2 Multisystem provides two ways to partition your data:

• You can create a distributed table to distribute your data across several systems or logical partitions.

• You can create a partitioned table to partition your data into several members in the same database table on one system.

In both cases, you access the table as if it were not partitioned at all.

• Creation of partitioned tables
  New partitioned tables can be created using the CREATE TABLE statement.

• Modification of existing tables
  You can change existing nonpartitioned tables to partitioned tables, change the attributes of existing partitioned tables, or change partitioned table to nonpartitioned tables.

• Indexes with partitioned tables
  Indexes can be created as partitioned or nonpartitioned. A partitioned index creates an individual index for each partition. A nonpartitioned index is a single index spanning all partitions of the table.

• Query performance and optimization
  Queries that reference partitioned tables need to be carefully considered because partitioned tables are often very large. It is important to understand the effects of accessing multiple partitions on your system and applications.

• Save and restore considerations
  A partitioned table can be saved and restored just as any other database file.

• Journaling a partitioned table
  You can journal a partitioned table as you can journal any other database file with multiple members. When you journal a partitioned table, all the partitions of the table are journaled by the same journal.

• Traditional system interface considerations
  An SQL table is a database physical file with one member (partition). Therefore, when the file is accessed by a traditional system application, the traditional system application reads and writes to the member by opening the file's member.

• Restrictions for a partitioned table
  When you use partitioned tables, be aware of these restrictions.

 

Parent topic:

DB2 Multisystem

 

Related concepts

DB2 Multisystem: Basic terms and concepts

 

Related information

DB2 for i5/OS white papers