A fix is available
APAR status
Closed as program error.
Error description
PBG growth with Append=YES because Online Reorg Part does not reset the last part number (FOPBLASTPT) having free space while concurrntly running sql exists. 1. DSNB1CPS frees PB. 2. Original PB is kept after reorg (not shadow PB). 3. LOG and SWHICH phase call dsnb1cpp (not dsnb1cps) with part number, so they don't free PB 4. At a deallocation of REORG job, dsnb1cps is called, but PBOPENP is more than 0 because of insert job is running and last part is open. So original PB with FOPBLASTPT=lastpart# is kept even after reorg job ends. 5. If there is no concurrently running insert job, deallocation of REORG job calls dsnb1cps and free PB because PBOPENP is zero.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All DB2 9 for z/OS and DB2 10 for z/OS * * users of ONLINE REORG utility against * * PBG table space with APPEND attribute. * **************************************************************** * PROBLEM DESCRIPTION: After running REORG with SHRLEVEL * * CHANGE or REFERENCE on a PBG table * * space with APPEND YES attribute, * * the subsequent rows are inserted to * * the cached last partition of the * * table space. The reclaimed spaces * * prior to the cached last partition * * during the REORG were not reused. * **************************************************************** * RECOMMENDATION: * **************************************************************** Since PBG table with APPEND attribute indicates data rows are inserted to the end of table, the last partition of the table space is cached during the insert transaction. When insert transaction is running concurrently with ONLINE REORG on a PBG table with APPEND YES attribute, REORG can reclaim space and leave empty partition(s) towards at the end of table space. However, the cached last partitioned number from prior insert transaction was not reset during REORG and subsequent inserted rows are inserted to the last cached partition. As a result, reclaimed space in the empty partitions prior to the cached last partition may not be reused and further causes the growth of table space.
Problem conclusion
DB2 code has been modified to set the right starting partition after the table space's closed.
Temporary fix
Comments
APAR Information
APAR number
PM80852
Reported component name
DB2 OS/390 & Z/
Reported component ID
5740XYR00
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2013-01-17
Closed date
2013-04-08
Last modified date
2013-05-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK93229 UK93230
Modules/Macros
DSNIPPHC
Fix information
Fixed component name
DB2 OS/390 & Z/
Fixed component ID
5740XYR00
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 May 2013