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.