Storage changes in Db2 13

Function level 507 introduces support for specifying greater than 64 GB primary and secondary allocation quantities in the CREATE TABLESPACE and ALTER TABLESPACE statements. The primary space allocation quantity (PRIQTY) is increased to support up to 1 TB, and the secondary space allocation quantity (SECQTY) is increased to support up to 200 GB. This enhancement reduces the need to allocate extents frequently by taking advantage of the DSSIZE value and increased space allocation quantities for table spaces.

For more information, see the following related topics:

• CREATE TABLESPACE statement
• CREATE LOB TABLESPACE
• ALTER TABLESPACE statement
• Secondary space allocation for Db2 table spaces and indexes

APAR PH64760 delivered the functional code for greater than 64GB primary and secondary space allocation quantities.

Function level 100 introduces improvements to how Db2 manages and frees above-the-bar storage, especially to reduce the disruptive impact of issuing excessive IARV64 REQUEST(DISCARDDATA) service requests.

Db2 13 no longer issues the IARV64 REQUEST(DISCARDDATA) request during thread deallocation or at certain intervals of COMMIT, and enhanced storage management is no longer controlled by the REALSTORAGE_MANAGEMENT subsystem parameter, which is also removed. In Db2 13, the storage is returned to the memory object. A system-level timer drives contraction for the memory object to release unused frames back to z/OS. Also, Db2 13 periodically checks the available free frames before the LPAR starts to page (by using the z/OS calculations for available free frames and LO threshold). If this value becomes lower than 5 times the z/OS calculated OK threshold, the memory object contraction is triggered.

• When below-the-bar Db2 storage consumption exceeds 64-percent threshold, Db2 automatically begins contraction of private storage pools.
• When extended common service area (ECSA) storage consumption exceeds the 85-percent threshold, Db2 automatically begins contraction of storage pools that are allocated in the ECSA.

In both cases, the storage contraction stops after storage consumption drops below the threshold.

This enhancement optimizes Db2 13 and improves its performance without changing how you configure, monitor, and use Db2.

Function level 100 reduces the amount of ECSA storage that is used for processing DDF threads to be equivalent to processing local threads. The previous recommendation was an extra 2 KB per DDF thread.

With APAR PH58162 (September 2024), Db2 requests performance blocks (IWMPBs) for WLM enhanced delay monitoring for all threads in 64-bit HVCommon storage, and these control blocks no longer reside in the extended common service area (ECSA). This change further reduces the amount of ECSA storage footprint for processing threads beyond the reductions in the original Db2 13 release.

With these changes, delays for all local attach threads and all distributed server threads (DBATs) are monitored in RMF, and their buffer pool delays might trigger WLM buffer pool adjustments.

The DSNL044I message is also updated to indicate when an IWM4MCRE macro request fails to allocate more IWMPBs for local attach threads or DBATs. After Db2 issues DSNL044I for this condition, the processing of threads continues, but thread delays are not reflected in the RMF information, and buffer pool delays no longer trigger possible WLM buffer pool adjustments. For more information about this situation, see the APAR closing text.

Related function levels for this APAR: FL 100 New function in this APAR takes effect after the PTF is applied at any function level; FL 507 Activating function level 507 or higher verifies that this APAR is applied.

For more information, see the following related topics:

• Calculating the storage requirement for the extended common service area
• DSNL044I
• PH58162

Db2 13 reduces the use of ECSA storage for IFI buffers from a maximum of 50 MB to a fixed 8 MB.

Function level 100 reduces the use of ECSA storage for IFI buffers to a maximum of 25 MB. Then, after function level 500 is first activated, it is further reduced to 8 MB. The storage behavior that is introduced in function level 500 continues even if you later activate function level 100*.

To compensate for the reduction in ECSA storage, you must set aside an extra 50 MB for HVCOMMON and 25 MB for private storage. You can reduce the ECSA storage after function level 500 is activated and Db2 starts using the new storage pools. When Db2 uses the new storage pools, the use of ECSA for the retrieval of IFI records noticeably decreases. You can monitor use of the new storage pools by starting the statistics trace to collect IFCID 225. Then, you can check the SHARED / COMMON storage summary report in the formatted IDCID 225 SMF trace record.

For more information about ECSA storage requirements, see Calculating the storage requirement for the extended common service area.

Starting in function level 100, Db2 supports a greater number of concurrent threads, by using above-the-bar (ATB) agent-local storage for statement text and attribute strings for dynamic SQL statements. In earlier releases, Db2 kept a copy of dynamic SQL statement text and attribute strings in agent local below-the-bar (BTB) storage while the statement is being prepared and executed.

For any specific thread, multiple dynamic SQL statements can be executing depending on the nesting level. The maximum length of an SQL statement is 2 MB, but much more storage can be allocated and the consumption of BTB storage could prevent the number of threads from scaling.

This enhancement optimizes Db2 13 and improves its performance without changing how you configure, monitor, and use Db2.

With IRLM 2.3 at function level 50C or higher, which is included with Db2 13, IRLM can now invoke an existing capability in z/OS Sysplex Services for Data sharing (XES) to dynamically expand the coupling facility (CF) lock structure storage size. This new internal monitoring capability in IRLM can improve lock request processing throughput, by expanding the CF lock structure size to process lock requests, instead of rejecting them.

The existing XES monitoring of the CF lock structure use is defined in the coupling facility resource management (CFRM) policy as a threshold percentage value, and it is enabled with a default of 80% when it is not equal to zero. This monitoring retrieves statistics on the CF lock structure every 60 seconds when the storage usage is less than the threshold and every 30 seconds when the storage usage is equal to or greater than the full threshold. IRLM can determine the storage needed at a higher level of granularity than the existing monitoring by XES of CF structure, especially when a spike in locking activities results in rejection of lock requests due to insufficient Record List Entries (RLEs) even before z/OS has a chance to start the CF lock structure alteration.

The existing structure monitoring by XES handles storage contraction, and it contracts all eligible structures in the coupling facility by 10 percent in each cycle when the entire coupling facility is at or more than 90% full.

IRLM issues the following messages when it adjusts the CF lock structure storage size: DXR189I and DXR190I.