At a high-enough level, every relational database management system (DBMS) is similar, but there are architectural aspects that will differ -- sometimes, significantly -- from DBMS to DBMS, or even from platform to platform.
Understanding the components of a piece of software helps you use that software more effectively. By understanding the physical layout of DB2, you can arrive at system solutions more quickly and develop SQL that performs better. Knowing something about the architecture of your favorite DBMS can help you to optimize usage, improve development and simplify administrative tasks.
This article will not get very technical and it will not delve into the bits and bytes of DB2. Instead, it presents the basic architecture of a DB2 subsystem and information about each subcomponent of that architecture.
A DB2 is DB2 is a…
With that in mind, let’s take a look at the architecture of DB2 for z/OS at a high level, but with enough detail to be useful.
The first thing we need to understand that DB2 for z/OS is one of three code bases that IBM names “DB2,” which are as follows:

·         DB2 for z/OS – the flagship, mainframe relational DBMS built by IBM and with three decades of usage in the field.

·         DB2 for Linux, Unix and Windows – the distributed implementation of DB2 that runs on Unix/Linus and Windows servers.

·         DB2 for iSeries – the midrange version of DB2 that runs on IBM’s proprietary iSeries (earlier AS/400) computers.

So with that out of the way, this article discusses DB2 for z/OS, only.
Starting at the Beginning
Conceptually, DB2 is a relational database management system. Actually, some might object to this term instead calling DB2 a SQL DBMS because it does not conform exactly to Codd’s relational model. Physically, DB2 is an amalgamation of address spaces and intersystem communication links that, when working together, provide the services of a database management system.
Each DB2 subcomponent is comprised of smaller units called CSECTs. A CSECT performs a single logical function. Working together, a bunch of CSECTs provide general, high level functionality for a subcomponent of DB2. DB2 CSECT names begin with the characters DSN.
DB2’s Primary Address Spaces
There are four major subcomponents of DB2: 
  1. System services (SSAS)
  2. Database services (DBAS)
  3. Inter-resource Lock Manager (IRLM)
  4. Distributed Data Facility services (DDF).
The SSAS, or System Services Address Space, coordinates the attachment of DB2 to other subsystems (CICS, IMS/TM, or TSO). SSAS is also responsible for all logging activities (physical logging, log archival, and BSDS). DSNMSTR is the default name for this address space. Of course, the address spaces may have been renamed at your shop. It is typical for the DSN to be replaced with the 4 byte subsystem identifier used for each DB2 subsystem; for example, if your test DB2 environment is known as DB2T, then the SSAS is likely to be named DB2TMSTR.
DSNMSTR is the started task that contains the DB2 log. The log should be monitored regularly for messages indicating the errors or problems with DB2. Products are available that monitor the log for problems and trigger an event to contact the DBA or systems programmer when a problem is found.
The DBAS, or Database Services Address Space, provides the facility for the manipulation of DB2 data structures. The default name for this address space is DSNDBM1. This component of DB2 is responsible for the execution of SQL and the management of buffers, and it contains the core logic of the DBMS. Database services use system services and z/OS to handle the actual databases (tables, indexes, etc.) under the control of DB2. Although DBAS and SSAS operate in different address spaces, they are interdependent and work together as a formal subsystem of z/OS.
The DBAS can be further broken down into three components, each of which performs specific data-related tasks: 
  1. Relational Data System (RDS), 
  2. Data Manager (DM) 
  3. Buffer Manager (BM). 
The Buffer Manager handles the movement of data from disk to memory; the Data Manager handles the application of Stage 1 predicates and row-level operations on DB2 data; and the Relational Data System, or Relational Data Services, handles the application of Stage 2 predicates and set-level operations on DB2 data.
Figure 1The components of the Database Services Address Space.
The next DB2 address space, DDF, or Distributed Data Facility services, is optional. DDF is required only when you want distributed database functionality. If your shop must enable remote DB2 subsystems to query data between one another, the DDF address space must be activated. DDF services use VTAM or TCP/IP to establish connections and communicate with other DB2 subsystems using the DRDA protocol.
DB2 also requires an additional address space to handle locking. The IRLM, or Intersystem Resource Lock Manager, is responsible for the management of all DB2 locks (including deadlock detection). The default name of this address space is IRLMPROC.
Additional Address Spaces
There are additional system address spaces that interact with DB2. For example, additional address spaces can be used by DB2 to manage the execution of stored procedures and user-defined functions. In older releases of DB2 (V4 and V5 era) these address spaces were known as the Stored Procedure Address Spaces, or SPAS. For current DB2 releases (V8 and later), the z/OS Workload Manager (WLM) is used to manage COBOL stored procedures. WLM is used to control and define multiple address spaces for non-SQL stored procedures. 
So, at a high level, DB2 uses four primary address spaces and WLM to handle all DB2 functionality. But DB2 also communicates with allied agents, like CICS, IMS/TM, and TSO. These services comprise additional address spaces that operate with DB2 to deliver user interaction.
Additionally, database services (DBAS) uses the VSAM Media Manager to actually read data from the native VSAM files where all DB2 user data is stored.
A summary of the DB2 address spaces and the functionality they perform is provided in Figure 2.
Figure 2. The DB2 address spaces.
So, armed with this knowledge of how DB2 is architected, you can more readily grasp how SQL is processed by DB2 and how you can write better SQL to optimize access. Additionally, knowing how distributed requests or OLTP transactions work with DB2 can be helpful in terms of designing and writing effective application code. This article just skims the surface and is a good starting point for learning about DB2 for z/OS. Once you’ve mastered this level of understanding, the next challenge is to dig a little deeper into each component and learn more about how it works and how you can use that knowledge to improve DB2 functionality at your shop.