EDMPOOL - External Data Manager Pool

Enhanced Definition

The EDMPOOL (External Data Manager Pool) is a crucial memory area within the DB2 for z/OS `DBM1` address space, managed by the External Data Manager (EDM). Its primary purpose is to cache frequently accessed DB2 control blocks and object descriptors, such as Database Descriptors (`DBD`s), Cursor Tables (`CT`s), Package Tables (`PT`s), and Skeleton Cursor Tables (`SKCT`s). This caching significantly reduces I/O operations and CPU usage associated with loading these objects from disk, thereby enhancing DB2 subsystem performance. The External Data Manager Pool (EDMPOOL) is a critical memory area within the DB2 for z/OS DBM1 address space, primarily used for caching frequently accessed DB2 control blocks and compiled SQL structures. Its main purpose is to improve DB2 performance by reducing physical I/O and CPU consumption associated with retrieving these essential metadata objects from disk.

Key Characteristics

- Memory Location: Resides within the DBM1 address space of the DB2 for z/OS subsystem, separate from buffer pools which cache data pages.
- Cached Objects: Stores control blocks for DB2 objects like DBDs (Database Descriptors), CTs (Cursor Tables), PTs (Package Tables), and SKCTs (Skeleton Cursor Tables).
- Performance Optimization: Reduces physical I/O to the DB2 catalog and directory by keeping frequently used object definitions in memory, leading to faster SQL execution and application response times.
- Configurable Size: Its size and behavior are controlled by various DSNZPARM parameters, notably EDM_POOL_SIZE (for DBD, CT, PT storage) and MAX_CONCURRENT_PKG_OPS / MAX_CONCURRENT_SQL_STMTS (for SKCT storage).
- Dynamic Management: DB2 dynamically manages the objects within the EDMPOOL, promoting frequently used objects and potentially flushing less used ones when space is needed.

Use Cases

- SQL Statement Execution: Caching SKCTs for prepared SQL statements significantly speeds up subsequent executions of the same statement by avoiding re-preparation.
- Application Program Execution: Storing PTs (Package Tables) for DB2 PACKAGEs allows applications to quickly access their compiled SQL logic without re-reading from the DB2 directory.
- Database Access: Caching DBDs (Database Descriptors) provides rapid access to the structural definitions of databases, tablespaces, and indexes, improving the efficiency of data access.
- Concurrency Support: Enables multiple concurrent users or applications to quickly access the same DB2 object definitions without contention or repeated disk I/O.

Related Concepts

The EDMPOOL is an integral part of the DB2 for z/OS subsystem's memory architecture, working in conjunction with buffer pools (which cache data and index pages) and log buffers (for transaction logs). It is managed by the External Data Manager component within the DBM1 address space. Its configuration through DSNZPARMs directly impacts the performance of applications, including those running under CICS or IMS, that interact with DB2.

Best Practices:

Monitor Usage: Regularly monitor EDMPOOL usage statistics using DISPLAY DBM1 commands, SMF records, or performance monitoring tools like DB2PM to identify potential bottlenecks or over-allocation.
Tune DSNZPARMs: Adjust EDM_POOL_SIZE, MAX_CONCURRENT_PKG_OPS, and MAX_CONCURRENT_SQL_STMTS based on workload analysis to ensure optimal caching and minimize object reloads.
Avoid Excessive Flushing: Ensure the EDMPOOL is adequately sized to prevent frequent flushing of cached objects, which can degrade performance by forcing DB2 to reload objects from disk.
Consider DBM1 Storage: Factor EDMPOOL size into the overall DBM1 private storage requirements to avoid memory constraints within the DB2 address space.
Prioritize SKCTs: For OLTP environments with many unique SQL statements, pay close attention to SKCT caching parameters (MAX_CONCURRENT_PKG_OPS, MAX_CONCURRENT_SQL_STMTS) to maximize the benefit of prepared statement reuse.