Db2 Partition Groups: Database Partitions vs Table Spaces



Db2 partition groups are a partitioned database concept.

A developer moving between Db2 LUW and Db2 for z/OS can easily mix up partition groups, table spaces, and partition-by-range table spaces. The old version of this page described database partition groups, which are associated with partitioned Db2 LUW databases, not the same thing as a modern Db2 for z/OS PBR universal table space.

This refresh preserves the original URL but makes the terminology clear. Use this page when you need to understand database partition groups in Db2 LUW-style partitioned environments and how that differs from the table-space partitioning discussed in the Db2 Table Spaces Guide.

What Is a Db2 Database Partition Group?

A database partition group is a named set of one or more database partitions. IBM's Db2 documentation for CREATE DATABASE PARTITION GROUP says the statement defines a new database partition group within the database, assigns database partitions to it, and records the definition in the system catalog.

In a partitioned database, a table space can be created in a database partition group. That means objects in that table space use the partitions assigned to the group. This is a database distribution concept, not a COBOL coding option.

Partition Groups Are Not z/OS PBG or PBR

Mainframe developers usually hear partitioning in the context of Db2 for z/OS table spaces: PBG, PBR, partitions, DSSIZE, and buffer pools. Database partition groups are different. They come from partitioned database environments where data can be distributed across database partitions.

Term	Where it fits	What it controls
Database partition group	Db2 LUW partitioned database environments	Which database partitions a table space uses.
PBG table space	Db2 for z/OS universal table spaces	Growth by adding partitions as data grows.
PBR table space	Db2 for z/OS universal table spaces	Range-based partition placement and maintenance.
Buffer pool	Db2 storage and memory management	Page cache and page size used by table spaces or indexes.

How Partition Groups Work

A database can have multiple database partitions. A partition group chooses a subset of those partitions, or all of them. Table spaces created in that partition group use those partitions for data placement.

CREATE DATABASE PARTITION GROUP PG_REPORTING
  ON DBPARTITIONNUMS (0 TO 2, 5, 8);

That example creates a group over database partitions 0, 1, 2, 5, and 8. A table space created in that group uses the group definition. If a new database partition is later added to the system, the group does not automatically mean the data is redistributed; administration steps are needed.

Why Table Spaces Use Partition Groups

The main reason is placement. Smaller or specialized data can be placed on one set of database partitions, while larger or reporting-oriented data can be placed on another set. This gives DBAs a way to separate workload and storage behavior.

Need	Partition group choice	Reason
Small lookup tables	Small or selected group	Avoid spreading small objects unnecessarily.
Large reporting tables	Wider group	Distribute data across more database partitions.
Workload isolation	Dedicated group	Keep one class of work away from another where design allows.

Default Partition Groups

Older Db2 partitioned database explanations commonly mention default groups such as catalog, temporary, and default user table-space groups. The exact names and behavior depend on Db2 product and version, so treat the old names as environment-specific. Always check the catalog and site standards before assuming a default group name.

For learning, the important point is simpler: a database partition group defines a set of database partitions, and table spaces can be associated with that set.

Developer Impact

COBOL programs and embedded SQL do not normally name a database partition group. The impact is indirect. The placement of table spaces affects how data is distributed, how parallel work behaves, and which database partitions hold the rows.

• Developers should know whether the slow table is in a partitioned environment.
• DBAs should know whether the table space is in the expected partition group.
• Performance tests should use production-like data distribution.
• Data redistribution can be a major operational activity, not a small metadata edit.

Questions to Ask Before Changing a Partition Group

• Which database partitions are in the current group?
• Which table spaces depend on that group?
• Will changing group membership require redistribution?
• Do queries use partition-compatible join and distribution patterns?
• Is the issue really partition placement, or is it an SQL access-path problem?

For access-path work, use the Db2 SQL Optimization Tips for COBOL Programs guide. For storage object basics in Db2 for z/OS, use the Db2 Table Spaces Guide.

FAQ

Is a Db2 partition group the same as a partitioned table space?

No. A database partition group is a set of database partitions in a partitioned database environment. A partitioned table space, such as PBG or PBR in Db2 for z/OS, is a different storage design concept.

Does a COBOL program choose the partition group?

No. COBOL SQL references tables. The table space and database design determine the partition group or storage placement underneath.

Can a table space use only selected database partitions?

Yes, in a partitioned Db2 LUW environment, a table space can be created in a database partition group that includes selected database partitions.

Use the term partition group only when the environment really uses database partition groups. For Db2 for z/OS PBG and PBR design, use table-space partitioning terminology instead.

Db2 Table Spaces Guide: PBG, PBR, Pages, and Storage



Db2 table spaces organize table storage and growth.

A COBOL program sees a table name in embedded SQL, but Db2 stores the rows in a table space. That storage choice affects page size, partition growth, REORG work, buffer pool assignment, locking behavior, and recovery planning. When a table grows from 5 million rows to 500 million rows, the table-space design becomes part of the application performance story.

This refresh updates the original short definition into a practical Db2 for z/OS guide. It explains table spaces, partition-by-growth and partition-by-range universal table spaces, buffer pool relationship, and the information developers should collect before asking a DBA to change storage design.

What Is a Db2 Table Space?

A table space is the Db2 storage object that holds table data. IBM's Db2 for z/OS documentation for CREATE TABLESPACE states that the statement defines a table space at the current server, and that the type depends on the keywords specified. For current universal table spaces, the main choices are partition-by-growth and partition-by-range.

Application SQL normally references tables, not table spaces. Still, table-space design influences the path Db2 takes to read, insert, update, delete, reorganize, and recover the data.

Table, Table Space, Index Space, and Database

The names can sound similar, but they refer to different layers. A table is the logical object your SQL reads. A table space is the storage object that contains the table rows. Indexes are stored separately in index spaces. A database is a logical container for table spaces and related objects.

Object	Purpose	Developer sees it where?
Table	Logical rows and columns.	SELECT, INSERT, UPDATE, DELETE.
Table space	Stores table data pages.	DDL, DBA reports, utility jobs, storage reviews.
Index space	Stores index pages.	EXPLAIN output, access-path tuning, DBA reports.
Database	Groups related Db2 storage objects.	DDL naming and administration.

PBG and PBR Universal Table Spaces

Most new Db2 for z/OS designs use universal table spaces. The two common forms are partition-by-growth and partition-by-range.

Type	How it grows	Good fit
Partition-by-growth (PBG)	Db2 adds partitions as the object grows, up to the maximum.	Tables that need growth handling but do not have a useful range partitioning key.
Partition-by-range (PBR)	Rows are placed by defined range boundaries.	Large tables with date, account, region, or other range-based access and maintenance needs.

PBG can be easier to start with. PBR can be stronger when data lifecycle and access patterns follow a known range. For example, a transaction table partitioned by business month can support targeted REORG, LOAD, COPY, and recovery work.

CREATE TABLESPACE Example

The exact DDL belongs to the DBA and site standards, but developers should understand the shape of the definition. This example shows a small partition-by-growth table space assigned to an 8 KB buffer pool.

CREATE TABLESPACE ACCTTS01
  IN ACCTDB
  MAXPARTITIONS 64
  SEGSIZE 32
  BUFFERPOOL BP8K0
  LOCKSIZE ROW
  COMPRESS YES;

The BUFFERPOOL clause matters because it identifies the buffer pool used for the table space and determines the page size. If the workload uses wide rows or large indexes, page size and buffer pool choice need DBA review before the object is built.

How Table Spaces Affect Application Performance

A table-space choice does not replace SQL tuning, but it can support or hurt the access pattern. A table that receives heavy inserts, monthly purges, and frequent account lookups has different storage needs from a small reference table.

• Partitioning can limit utility and recovery work to part of a large table.
• Page size affects how rows fit on pages and which buffer pool is used.
• Compression can reduce storage and I/O but adds CPU considerations.
• Lock size and row density can affect concurrency during batch and online peaks.
• Poor clustering can increase page reads even when an index is used.

For page-cache behavior, see the related Db2 Buffer Pool Guide. For predicate and access-path checks, see Db2 SQL Optimization Tips for COBOL Programs.

Developer Checklist Before Requesting a Table-Space Change

Table-space changes are not casual edits. They can require utilities, outages, storage planning, and fallback steps. Bring evidence instead of a vague performance complaint.

• SQL statements and package or job names that show the problem.
• EXPLAIN output for the slow statements.
• Row counts before and after the data growth.
• Insert, update, delete, and purge pattern.
• Whether queries are range-based, random lookup, or scan-heavy.
• Utility pain points: REORG time, COPY time, LOAD restart, or recovery window.

Questions to Ask the DBA

A good table-space review is a joint exercise. Developers know the business access pattern; DBAs know the physical design and subsystem constraints.

Question	Why it matters
Is this table better as PBG or PBR?	Growth-only tables and range-maintained tables need different designs.
Which buffer pool and page size will it use?	Page size and cache behavior affect reads, writes, and memory pressure.
What are the REORG, COPY, and recovery expectations?	Utility windows often drive partitioning decisions.
Does the clustering index match the main access pattern?	Good clustering reduces unnecessary page reads.

Common Mistakes

• Choosing PBG for every table because it is simple, even when range maintenance is the real requirement.
• Ignoring buffer pool page size until after wide rows are already in production.
• Designing partitions around today’s row count without considering five years of growth.
• Assuming a table-space change will fix a query with non-indexable predicates.
• Leaving utility and recovery teams out of the design conversation.

FAQ

Can one Db2 table space contain more than one table?

Older designs can include multi-table table spaces, but modern Db2 for z/OS designs commonly use universal table spaces that are centered on one table. Confirm the rule with your site standards and Db2 version.

Does a COBOL program access a table space directly?

No. COBOL embedded SQL references tables and indexes indirectly through access paths. Db2 uses the table space and index spaces underneath.

Is PBG or PBR better for large tables?

It depends on the growth and access pattern. PBG is useful when growth is the main concern. PBR is usually better when data is naturally managed by range, such as month, account range, or region.

A table-space design is good when it matches the way the data grows, the way SQL reads it, and the way operations must recover it. Treat it as part of application design, not only a storage detail.