EDM - External Data Manager

Enhanced Definition

EDM (External Data Manager) in DB2 for z/OS is a crucial component responsible for managing the EDM pool, an in-memory storage area for frequently accessed DB2 control blocks and object definitions. Its primary purpose is to reduce I/O operations to the DB2 catalog and directory, thereby enhancing application performance and overall system efficiency. The External Data Manager (EDM) is a critical component within **DB2 for z/OS** responsible for managing in-memory control blocks and structures, primarily within the **EDM pool**. It stores frequently accessed database objects such as **package sections**, **cursors**, and **access path information** to optimize database operations, reduce I/O, and improve overall query performance.

Key Characteristics

- In-memory Cache: The EDM pool acts as an in-memory cache for essential DB2 object definitions, including Database Descriptors (DBDs), Cursor Tables (CTs), and Package Tables (PTs).
- Performance Enhancement: Significantly reduces disk I/O to the DB2 catalog and directory by keeping frequently used object definitions readily available in memory.
- Dynamic Management: Objects are loaded into the EDM pool on demand when first accessed by an application and are aged out based on usage patterns and available space, using a Least Recently Used (LRU) algorithm.
- Multiple Sub-pools: Comprises distinct sub-pools: the DBD pool for database descriptors, the CT pool for cursor tables (for dynamic SQL), and the PT pool for package tables (for static SQL).
- Configurable Size: The overall size of the EDM pool and its individual sub-pools can be configured by DB2 system administrators via DB2 ZPARMs (parameters in the DSNZPxxx module).
- Critical for Workload: Heavily utilized by all DB2 applications executing SQL statements, making its efficient management vital for OLTP (Online Transaction Processing) and batch workloads.

Use Cases

- Optimizing Transaction Processing: For high-volume OLTP applications, keeping DBDs, CTs, and PTs in the EDM pool minimizes I/O and significantly speeds up transaction execution, reducing response times.
- Batch Job Performance: Improves the performance of batch jobs that access numerous tables or utilize many packages, especially during the initial phases of object access.
- Dynamic SQL Execution: Enhances the performance of applications using dynamic SQL by caching cursor tables, which are generated at run-time for SQL statements.
- DB2 System Startup: During DB2 subsystem startup, critical system objects and frequently used application objects are pre-loaded into the EDM pool to ensure quick availability and reduce initial access latency.

Related Concepts

The EDM pool is a vital part of the DB2 for z/OS storage hierarchy, working in conjunction with buffer pools (which cache data pages) and the log buffer (which buffers log records). It directly interacts with the DB2 Catalog and Directory by caching their contents to avoid repeated disk access, thereby reducing contention and improving throughput. Proper sizing and management of the EDM pool are crucial for the overall performance of DB2 applications and the stability of the entire DB2 subsystem.

Best Practices:

Monitor EDM Pool Usage: Regularly use DB2 monitoring tools (e.g., OMEGAMON for DB2, DB2 PM, or the DISPLAY DBM1 command) to track EDM pool hit ratios, page-in rates, and space utilization for each sub-pool.
Tune ZPARMs: Adjust the EDM_POOL_SIZE, DBD_POOL_SIZE, CT_POOL_SIZE, and PT_POOL_SIZE parameters in the DSNZPxxx module based on detailed workload analysis to minimize page-ins and maximize hit ratios.
Avoid EDM Pool Thrashing: Ensure the pool is adequately sized to prevent frequent loading and unloading of objects, which can lead to excessive I/O, CPU consumption, and performance degradation.
Consider Workload Changes: Re-evaluate and adjust EDM pool sizing after significant application changes, new deployments, or shifts in workload patterns to maintain optimal performance.
Prioritize Critical Objects: While direct object pinning is not available, ensure that frequently accessed packages and DBDs for critical applications have sufficient space to remain in the pool for extended periods.