Db2 Architecture Overview

Core architecture in one picture

A Db2 subsystem is both a set of address spaces and a set of internal services. System services and database services coordinate with the lock manager (IRLM). Applications attach locally or arrive remotely through the Distributed Data Facility. Inside database services, pools hold hot data and executable SQL information. Across failures, the log and recovery system protect committed work.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Db2 subsystem architecture (conceptual)
 
  Applications (allied) / Remote clients (DDF)
           |                    |
           v                    v
     Attachment facilities   DIST (DDF)
           \                  /
            \                /
             v              v
        +-----------------------+
        | Database services     |  buffer pools, EDM, RID, sort,
        | (DBM1)                |  data manager, SQL engine path
        +-----------------------+
             |           |
             v           v
        IRLM locks    System services (MSTR)
                           |
                           v
                     Logs / BSDS / recovery
                           |
                           v
              Table spaces, indexes on disk

Db2 subsystem architecture

At the subsystem level you always have (at least) system services and database services, plus IRLM for locking. Most production systems also run DDF. Stored procedures and UDFs typically run in WLM-managed address spaces. That subsystem shell is the operating container; the architecture topics below live mostly inside those containers.

Beginners should avoid mixing “logical objects” (tables, indexes, views) with “runtime architecture” (pools and managers). Tables are what SQL talks about. Buffer pools and logs are how Db2 makes SQL fast and recoverable. Both matter; they answer different questions.

Db2 storage hierarchy

From an application point of view, data lives in tables. Physically on z/OS, Db2 stores rows in pages inside table spaces (VSAM linear data sets in typical configurations). Indexes have their own pages. When SQL needs a row, Db2 prefers to find the page in a buffer pool. If the page is not in memory, Db2 reads it from disk into a buffer. Dirty pages are written later according to deferred write thresholds and checkpoint/log forces.

Hierarchy from outside in

• SQL objects: tables, indexes, views
• Physical containers: table spaces, index spaces, storage groups
• Pages: fixed-size units transferred between disk and memory
• Buffer pools: in-memory cache of pages in DBM1
• Disk / SMS / volumes: durable home of the data sets

Performance conversations often start at the buffer pool layer because a high hit ratio means fewer waits for I/O. Recovery conversations start at the log and image-copy layer because durability depends on recorded changes and backup copies.

Memory pools you will hear about constantly

Buffer pools

Buffer pools are the largest and most important performance lever for many workloads. They cache data and index pages. Sites assign objects to pools (for example separating catalog/directory from busy application tables, or isolating random OLTP from heavy sequential batch). Tuning parameters control size, sequential steal behavior, and when deferred writes kick in. You do not need every parameter on day one, but you should know that “the table is slow” often means “pages are not found in buffer pools efficiently.”

EDM pool

The EDM pool (Environmental Descriptor Manager pool) caches the descriptors Db2 needs to execute SQL: package and plan information, database descriptors (DBDs), and related structures. If EDM is under pressure, Db2 may reread catalog/directory information more often, burning CPU and adding latency. Application bind and package design interact with EDM behavior because executable SQL forms live in this ecosystem.

Dynamic statement cache

Dynamic SQL—common with Java and other remote clients—must be prepared. The dynamic statement cache keeps prepared statements so repeated text can reuse work. Good cache hit rates reduce prepare CPU. Poorly parameterized SQL that creates endless unique statement strings can waste the cache. Beginners writing static embedded SQL in COBOL feel this less; mid-tier developers feel it every day.

RID pool

A RID is a row identifier. Some access paths build lists of RIDs (for example list prefetch or multi-index access) before fetching data pages. Those lists live in the RID pool. If the pool is too small, Db2 may abandon the efficient strategy and fall back to something costlier—sometimes a table space scan—without an obvious application change. That is why RID failures show up in performance analysis.

Sort pool

When Db2 must sort—ORDER BY, GROUP BY, DISTINCT, certain joins—it uses the sort pool. Enough memory keeps sorts in storage; overflow goes to work files and increases elapsed time. Batch reporting jobs are classic sort consumers. Online transactions that sort large sets can also stress this area.

Managers and facilities

Log manager and recovery system

Db2 uses write-ahead logging: log information about changes is forced as needed so recovery can reconstruct committed state and undo incomplete units of work. The Bootstrap Data Set (BSDS) and active/archive logs participate in tracking log data sets and subsystem restart information. The recovery system builds on logs, image copies, and utilities such as RECOVER to restore objects after media failure or to a point in time.

For application developers, the visible contract is COMMIT and ROLLBACK (or CICS syncpoint). For DBAs, the visible contract is logging parameters, archive practices, and recovery drills. Architecture ties both together: every committed update must be reconstructible.

Lock manager

Concurrency is not optional on a shared enterprise database. The lock manager—implemented with IRLM—serializes access to pages, rows, or other resources according to isolation and lock size. Deadlock detection chooses a victim when transactions wait on each other circularly. In data sharing, global locking extends the model across members using coupling facility structures. Application design (index use, commit frequency, hotspot rows) strongly affects lock behavior.

Data manager and storage manager

The data manager is the part of the engine that works with rows and pages to satisfy SQL predicates and projections—reading, inserting, updating, and deleting in the structures Db2 understands. The storage manager concerns how space is organized and maintained for those structures: extents, free space, and the physical realities behind table spaces and indexes. You will meet both ideas again when studying REORG, space maps, and access paths.

Distributed data facility

DDF is the architectural doorway for remote SQL. It accepts DRDA requests, participates in distributed transaction protocols as configured, and hands database work into the database services path. Portions of DDF/DRDA work can be zIIP eligible depending on how the request arrives and what it runs—important for cost and capacity planning, even if you are not tuning zIIP on day one.

Instrumentation facility

The instrumentation facility produces traces and statistics that monitors and accounting reports consume: CPU by plan/package, wait times, buffer pool metrics, lock suspensions, and more. Without instrumentation, architecture is a diagram; with it, architecture becomes measurable. SMF and online monitors sit on top of this facility.

Utility processing

Utilities such as LOAD, REORG, COPY, RUNSTATS, and RECOVER are part of the operational architecture. They reorganize physical layouts, gather optimizer statistics, take backups, and recover objects. Some run as batch jobs; some are available as stored procedures. Utility processing interacts with buffer pools, logs, and object states (for example restricted statuses). Application teams feel utilities when objects are in advisory or restrictive states during maintenance windows.

System services vs database services

System services (MSTR) emphasize subsystem control, logging-related system activity, and coordination functions. Database services (DBM1) emphasize the SQL and data path: pools, page access, and database-related engines. When you escalate a problem, classifying it as system-level versus data-path-level saves time. Both are required; neither alone is “all of Db2.”

WLM-managed stored procedures in the architecture

Stored procedures extend SQL with procedural logic. Architecturally they usually execute in WLM-managed address spaces, isolated from the core engine. That design protects DBM1 from runaway procedures, allows priority management, and scales address spaces with demand. Native SQL procedures and external procedures both participate in this model with different runtime characteristics. Treat WLM environments as first-class architecture, not an afterthought.

How a SQL statement travels (simplified)

A local COBOL program issues EXEC SQL. The attachment connects the allied address space to Db2. Authorization and package context are established. For static SQL, Db2 uses the bound package (helped by EDM caching). Locks are obtained via IRLM as needed. Data pages are found in buffer pools or read from disk. Changes generate log records. At COMMIT, Db2 makes the unit of work durable according to logging rules. A remote JDBC client follows a similar database path after DIST accepts the connection—the entry door differs; the integrity rules do not.

Explain It Like I'm Five

Think of Db2 as a giant library. The shelves on disk hold the books (table spaces). A reading room table (buffer pools) keeps popular books nearby so you do not walk to the basement every time. A card catalog drawer in memory (EDM / statement cache) remembers how to find things quickly. A sign-out desk (locks/IRLM) stops two kids from scribbling on the same page at once. A diary (the log) writes down every change so if the lights go out, the librarian can fix the books. Delivery bikes (DDF) bring requests from other schools. Helper rooms (WLM procedures) do special projects without blocking the main reading room. That whole system is Db2 architecture.

Exercises

1. Match each pool (buffer, EDM, RID, sort, dynamic statement cache) to one sentence describing what it caches or holds.
2. Explain why write-ahead logging matters to a bank transfer that credits one account and debits another.
3. A monitor shows high synchronous read I/O against a busy table space. Which architectural layer would you inspect first, and what question would you ask?
4. Describe one difference between system services and database services in your own words.
5. Sketch the path of a remote SELECT from a laptop JDBC client to a page in a buffer pool, naming DIST, DBM1, and IRLM where they belong.