By Chris Leung and Emily Alameida

We’re excited to announce enhancements to the BLOCKING_THREADS table function and the -DISPLAY BLOCKERS command. These features are essential for identifying application threads that hold locks or claims that have the potential to obstruct critical operations like online schema changes. Now, database administrators can pinpoint exactly which threads are blocking schema changes on specific objects without sifting through unrelated data.

The BLOCKING_THREADS table function enhancements introduce granular input capabilities at the table, index, and space level as well as adding the DDLONLY option to specify that only locks acquired by DDL processing should be included in the output. The -DISPLAY BLOCKERS command enhancements add the equivalent TABLE, INDEX, and SPACENAM, and DDLONLY options to display blockers at the same level of granularity.

Previously, both BLOCKING_THREADS and -DISPLAY BLOCKERS only accepted database names as input. The output included all locks and claims across every object in the specified databases—useful in some cases, such as diagnosing blockers for CATMAINT operations on the catalog database (DSNDB06), but often too broad for more targeted schema changes.

Online schema changes are a common and necessary part of maintaining and evolving a Db2 environment. However, identifying the exact threads that are preventing these changes has historically been a manual and error-prone process.

This enhancement is designed to empower Db2 for z/OS administrators with the precision and control they need to maintain high availability and performance. By streamlining the process of identifying blocking threads, Db2 now supports smoother schema changes and more efficient database operations.