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.
No comments:
Post a Comment