What Makes DB2 Tick

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.

"What does all this information have to do with me?" you might wonder . 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.

The information in this section is not very technical and does 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.

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.

NOTE

DB2 CSECT names begin with the characters DSN .

There are three major subcomponents of DB2: system services (SSAS), database services (DBAS), and distributed data facility services (DDFS).

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. (The address spaces might have been renamed at your shop.) 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, and so on) 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 : the Relational Data System (RDS), the Data Manager (DM), and the Buffer Manager (BM) (see Figure 20.15). 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 20.15. The components of the Database Services Address Space.

The next DB2 address space, DDFS, or Distributed Data Facility Services, is optional. DDFS, often simplified to 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 either DRDA or private protocols. Details about DB2's distributed database capabilities are covered later, in Part VIII of this book.

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 .

Finally, DB2 uses additional address spaces to manage the execution of stored procedures and user -defined functions. These address spaces are known as the Stored Procedure Address Spaces, or SPAS.

If you're running DB2 V4, only one SPAS is available. For DB2 V5 and later releases, however, if you're using the z/OS Workload Manager (WLM), you can define multiple address spaces for stored procedures. Indeed, as of DB2 V8, WLM-defined is the only approved method for new stored procedures. Pre-existing stored procedures will continue to run in a non-WLM-defined SPAS under DB2 V8. Of course, if the stored procedure is dropped and re-created, it must use the WLM. The non-WLM-defined SPAS is being phased out and will be completely removed in a future version of DB2.

So, at a high level, DB2 uses five address spaces to handle all DB2 functionality. DB2 also communicates with allied agents , such as CICS, IMS/TM, and TSO. And database services use the VSAM Media Manager to actually read data. A summary of the DB2 address spaces and the functionality they perform is provided in Figure 20.16.

Figure 20.16. The DB2 address spaces.

Database Services

Recall that the DBAS is composed of three distinct elements. Each component passes the SQL statement to the next component, and when results are returned, each component passes the results back (see Figure 20.17). The operations performed by the components of the DBAS as an SQL statement progresses on its way toward execution are discussed next.

Figure 20.17. From BM to DM to RDS.

The RDS is the component that gives DB2 its set orientation. When an SQL statement requesting a set of columns and rows is passed to the RDS, the RDS determines the best mechanism for satisfying the request. Note that the RDS can parse an SQL statement and determine its needs. These needs, basically, can be any of the features supported by a relational database (such as selection, projection, or join).

When the RDS receives a SQL statement, it performs the following procedures:

• Checks authorization

• Resolves data element names into internal identifiers

• Checks the syntax of the SQL statement

• Optimizes the SQL statement and generates an access path

The RDS then passes the optimized SQL statement to the Data Manager (DM) for further processing. The function of the DM is to lower the level of data that is being operated on. In other words, the DM is the DB2 component that analyzes rows (either table rows or index rows) of data. The DM analyzes the request for data and then calls the Buffer Manager (BM) to satisfy the request.

The Buffer Manager accesses data for other DB2 components. It uses pools of memory set aside for the storage of frequently accessed data to create an efficient data access environment.

When a request is passed to the BM, it must determine whether the data is in the bufferpool. If the data is present, the BM accesses the data and sends it to the DM. If the data is not in the bufferpool, it calls the VSAM Media Manager, which reads the data and sends it back to the BM, which in turn sends the data back to the DM.

The DM receives the data passed to it by the BM and applies as many predicates as possible to reduce the answer set. Only Stage 1 predicates are applied in the DM. (These predicates are listed in Chapter 2, "Data Manipulation Guidelines.")

Finally, the RDS receives the data from the DM. All Stage 2 predicates are applied, the necessary sorting is performed, and the results are returned to the requester.

Now that you have learned about these components of DB2, you should be able to understand how this information can be helpful in developing a DB2 application. For example, consider Stage 1 and Stage 2 predicates. Now you can understand more easily that Stage 1 predicates are more efficient than Stage 2 predicates because you know that they are evaluated earlier in the process (in the DM instead of the RDS) and thereby avoid the overhead associated with the passing of additional data from one component to another.