DB2 Address Space and Architecture

CS185c

Chris Pollett

Feb. 11, 2010

(These notes are based on slides which are copyright IBM)

Outline

Address Spaces
- Attachment Facilities
- Logging and Recovery
- Database Service Address Space
System Architecture
- Relational Data System and Components
- Data Manager
- Buffer Manager
- Internal Resource Lock Manager
- Stored Procedures
- Distributed Data Facility

Conceptually, DB2 is a relational database management system.
Physically, DB2 is an amalgamation of address spaces and intersystem communication links, that, when adequately tied together, provide the services of a relational database management system.
Each DB2 subsystem consists of a few tasks started from the operator console.
Each of these started tasks run its own address space.
We will now start to look at some of these address spaces.

The Master address space is also called the System Service Address Space.
SSAS, or System Service Address Spaces, coordinates the interface of DB2 with other subsystems, such as CICS, IMS/TM, or TSO.
SSAS is also responsible for all logging and recovery in DB2.
DSNMSTR is the default name for this address space.

Attachment Facilities act like a gateway to DB2.
They provide the communication link between end users, subsystems, and applications and DB2 itself.

DB2 uses its logs for recovery from system errors or disastrous conditions.
Upon a change request or a system event, DB2 writes logs to the log output buffers.
These log output buffers are externalized to active logs when buffers are full or when a transaction is committed.
The active logs are defined to high performance DASD devices.
Old logs are offloaded to the archive logs, which are usually defined to slower devices, such as tapes.
The BSDS acts as the index for the DB2 active and archive logs. BSDS allows DB2 to determine from which log data set to retrieve a particular log record.

DBM1 contains the core logic of DB2 as a database management system.
SQL is prepared and executed in DBM1.
Buffer pools and buffer pool management is also done in DBM1.
The default name for this address space is DSNDBM1.
We next look at the three major components that use this address space: The Relational Data System (RDS), the Data Manager (DM), and the Buffer Manager (BM).

This subsystem contains the SQL compiler. The compiler converts the SQL that comes into DB2 into a type of relational algebra expression, optimizes this, and outputs something that could actually be used to fetch data.
The RDS also contains the runtime executor of the results of this compilation process.
It further provides the Catalog service and manages meta data such as database descriptors (DBDs) and object descriptors (OBDs).

There are two phases to execution of SQL in DB2.
The first is to prepare the SQL into a compiled form with optimized access paths, and the second is to run execute the SQL according to this preparation.
The "prepare" process includes syntax and semantic checking, query transformation according to the relational algebra, and access path selection.
The "run time" process includes executing the query according to the plan selected by the Optimizer.
The RDS Runtime component interfaces with the Data Manager component. The DM accesses data at the record level.
The flow within RDS is controlled and coordinated by the Executives subcomponent of RDS.

The Data Manager (DM) component is also called the DB2 engine.
The DM takes a plan and actually makes requests to get/alter data.
It does this on the record at a time level. That is, the runtime interfaces to DM operates on the record level.
To operate on a record, the DM maps the requested record into the data page of the table.
The DM invokes the Buffer Manager (BM) to locate the data page in the buffer pool.
The DM copies data from the buffer pool into thread specific storage, evaluates stage-1 predicates (such as simple selects), and returns data back to RDS.
The DM also interfaces with the IRLM to do locking that might be needed in concurrent access situations.

The Buffer Manager (BM) accesses physical data for Data Manager and Index Manager.
When a page request enters the Buffer Manager, the BM has a search mechanism to quickly locate the page in a buffer pool and return the address of it back to DM.
If the page does not exist in the buffer pool, the BM invokes the VSAM Media Manager to retrieve it (usually from DASD) into the buffer pool.
When the buffer pools are full, the BM uses the LRU algorithm to replace the oldest inactive pages with the newly brought-in pages.
When a buffer page is changed, or dirty, the page is not written out to the data set immediately.
Instead, the BM applies the deferred write strategy to minimize the overall I/Os.

A DBMS is designed to service many concurrent users accessing the same piece of data.
However, to any given user/transaction one design goal is to make it "appear" that it is operating in isolation on an otherwise static (except for the users commands) set of data.
Obviously, if one only allowed one user to operate at a time and do their complete transactions before the next person could begin, we could guarantee this kind of isolation.
This would be a vast waste of computer resources, since a typical user might now always be doing operations on DB2. So we instead allow multiple transactions to operate at the same time, but restrict access to the who gets to look at which data at a given time so that things in principle could be "serialized".
This restriction mechanism is done with locking and this locking is managed by the IRLM.
The address associated with the IRLM is DSNIRLM.

Prior to DB2 V9, DB2 uses a separated address space called SPAS to execute stored procedures and user-defined functions.
The SPAS runs as an allied address space providing an independent environment for stored procedures to execute.
This isolates the user-written stored procedure code in its own little world so that it cannot interfere with the system code of DB2 itself.
SPAS is removed in DB2 V9.
In V9 and beyond, each stored procedure runs in its own address space spawned by the Work Load Manager (WLM).

A distributed environment provides the flexibility to access data that are located at different sites in a computer network.
The DDF runs in its own address space.
The DDF Server services the data requests that come from a DRDA (Distributed Relational Database Architecture) client.
The DDF is an optional DB2 address space, and is required only when you need the distributed database functionalities.

We are now going to switch gears a little and take a look at the components of the DBM1 address spaces in more detail... the RDS, DM and BM.
We are going to start at the level of SQL...

In the RDS layer we handle data in the set-level.
The RDS component interfaces to the Data Manager (DM) component. DM invokes the Index Manager (IM) to handle the index access. Index Manger is under the big Data Manager umbrella. In the Data Manager layer we handle data at the record level.
The Data Manager interfaces to the Buffer Manager (BM) component. In the Buffer Manager layer we handle physical data access.