Introduction

On Tuesday, we talked about the Workload Manager.
We talked about Service Level Agreements.
We described how classification rules are used to classify work into different services classes.
We then talked about how DB2 can make use of the Workload Manager, and also for which DB2 address spaces service classes are predefined, and for which address spaces one can define one's own service classes.
We talked about how DB2 can use recommendations from the WLM to manage Buffer Pool sizes.
We then talked about DB2 and WLM in the distributed setting.
Finally, we discussed WLM with regard to stored procedure priorities.
The WLM is an important z/OS technology used by DB2, today we will look at another such z/OS technology, the Distributed Data Facility (DDF).

Distributed Databases

The distributed data facility will be useful in running DB2 in a multi installation setting. To begin though, it is useful to understand what is a distributed database and what are some of its properties.
As you might guess, a distributed database is a database that is not entirely stored at a single physical location, but rather is scattered over a network of interconnected computers.
A distributed database, however, provides a single database image to the user.
To the end-user it appears as if he is operating on just a single DBMS.

Characteristic of Distributed Databases

Location transparency -- Users and applications do not need to know where the data is stored. As a result, users can move one database system from one location to another one without rewriting the application.
Scalability -- The maximum amount of transactions and the size of the database system is theoretically unlimited when you use a distributed database because you can extend your distributed database without modifying existing databases and applications by adding more processing power.
Phased growth -- You can extend your distributed database at each location separately without affecting other locations
Portability of application -- You can develop an application at one location, and port it to another location without modifying it.
Local autonomy -- Each location is managed by a local DBMS and does not need to allow remote users or applications to control it. Each database system has its own user data, catalogs, logs, and so on.
Independent from system -- A distributed database provides a single system image to users and applications.

Distributed Relational Data Architecture (DRDA)

DRDA is a set of protocols that:
- Enables access to distributed data, regardless of location
- Provides an open, robust heterogeneous distributed database environment
- Coordinates communication among distributed locations
- Provides a single database image
Some benefits of DRDA are that:
- Supports full data distribution including multi-site update
- Adopted by many vendors (for instance, besides DB2, Oracle has a gateway)

Functions and Protocols of DRDA

Functions
- Application requester (AR) -- this accepts SQL requests from an application and sends them to the appropriate application server (or servers) for subsequent processing. AR is implements in DB2 as DB2 connect
- Application server (AS) -- this receives SQL requests from application requesters and processes them.
- Database server (DS) -- this receives requests from application servers or other database servers, processes what it can, and forwards the rest to another database server until the task is done.
Communication protocols
- Application support protocol (AS protocol) -- this is the protocol used in AR to AS chats.
- Database support protocol (DS protocol) -- this is the protocol used in AS to DS chats.

Graphic containing protocols used in DRDA

DRDA Levels

There are five DRDA levels which are used to control how data is distributed:
- User-assisted distribution
- Remote request
- Remote unit of work(RUW)
- Distributed unit of work(DUW)
- Distributed request
Each level specifies:
- The number of SQL statements and RDBMSs per unit of work
- The number of RDBMSs per SQL statement
We will now look at each of these levels in turn...

User Assisted Distribution

In this set-up, the user is responsible to

Extract the data from the original system
Load the data to the requesting system
Redo the operations when data changed.

User-assisted distribution is useful for producing a snapshot of tables to satisfy one- time requests.

This set-up, because of the user involvement, is not usually viewed as having distributed data access.

Remote Request

"Remote request" is the first level of true distribution within DRDA.
In this level, a single SQL statement can be issued to read or change data in a single remote RDBMS within a single unit of work.
A DRDA remote request enables data access to a single remote DBMS, even if a local DBMS does not exist.
A DRDA remote request provides the capability of issuing only one SQL statement to a RDBMS per unit of work (UOW), i.e., per scope of commit.
An application can access multiple databases. However, only one database is accessed at a time, and only one SQL statement is included in a single UOW. In this case, the result of one SQL statement will not affect the result of another SQL statement.

Remote Unit of Work (RUW)

The remote unit of work (RUW) DRDA level allows multiple SQL statements to read or change data in a single RDBMSs within a single unit of work.
Within this scope of commit, the multiple SQL statements must all target a single RDBMS.

Distributed Unit of Work (DUW)

DRDA Distributed Unit of work (DUW) enables multiple SQL statements to read or change data in multiple RDBMSs within a single unit of work.
However, only one RDBMS can be specified per SQL statement.
As with any unit of work, the SQL statements within the commit scope either all succeed or all fail.
A two-phase commit protocol (the same protocol as was discussed when we talked about CICS/DB2 AF) is needed because multiple RDBMS's are involved.

Distributed Request

DRDA distributed request capability enables complete data distribution.
A distributed request enables a single SQL statement to read or change data in multiple RDBMSs in the same SQL statement.
This level is not yet implemented by most RDBMS vendors including IBM.

Distributed Data Facility (DDF)

DDF is the implementation of DRDA on DB2 for z/OS
DDF supports the following DRDA levels:
- Remote request
- Remote unit of work
- Distributed unit of work
The user-level is trivial so not mentioned above.

DB2 Connect

DB2 Connect provides the DRDA application requester functions on Linux, UNIX, and Windows operating systems.
It is an Open Interface providing various industry standard client APIs including:
- Embedded SQL for a few high-level language
- Open Database Connectivity (ODBC)
- Java Database Connectivity (JDBC)
- Embedded SQLJ for Java (SQLJ)
It also supports Microsoft Windows data interfaces such as: ADO, RDO, OLE, ActiveX, and a DB2 .Net Data Providers

DDF Requester and Server Flow

An image illustrating communication flow between a DDF requestor and a DDF server

DDF only exists on the DB2 system for z/OS.
The DB2 Connect we talked about in the previous slide does not contain DDF code.
DB2 Connect is DRDA compliant so it can be used to access a remote z/OS DB2 via DDF.
The situation above illustrates two DB2 z/OS systems and how they might communicate using DDF.

Character Encoding Schemes

DB2 uses Coded Character Set IDs (CCSIDs) to describe the data stored in a DB2 subsystem.
DB2 supports specification of three CCSID sets: ASCII, EBCDIC, and UNICODE.
These CCSIDs are specified at the subsystem level and the values are stored in catalog tables, plans and packages, DECP and directory.
So changing them after they are set should be avoided.
n a DRDA environment, conversion between character sets is done automatically by the receiver of the data, whenever needed.

Connection Information Saved in Catalogs

Connection information is stored in the DB2 Catalog in the Communications Data Base tables, or CDB.
The DDF reads the CDB to perform authid name translations and to map DB2 objects to VTAM (Virtual Telecommunications Access Method -- how z/OS's chat) objects.
The CDB exists in a separate table space in the DB2 Catalog, named SYSDDF.
In a distributed environment, each DB2 subsystem is identified by a unique location name of up to 16 characters.
A location can be explicitly accessed via the CONNECT statement or implicit accessed via three-part table names in an SQL statement.

CDB Catalog Tables

SYSIBM.IPLIST -- IP addresses that are to be associated with a given LOCATION.
SYSIBM.LOCATIONS -- Contains a row for each remote DB2 subsystem to which SQL statements can be sent.
SYSIBM.LULIST -- contains additional LUNAMEs (logical unit names) for SNA ( system network architecture) are to be associate with a given locations.
SYSIBM.LUMODES -- defines session/conversation limits for VTAM LUs.
SYSIBM.LUNAMES -- contains a row for each remote SNA client or server that communicates with DB2.
SYSIBM.SYSMODESELECT -- Associates a mode name with any conversation created to support an outgoing SQL request.
SYSIBM.USERNAMES -- Translates local user names.

Methods of Accessing Distributed Data

Application-directed access (explicit)

Example:

CONNECT TO SANJOSE 
CONNECT TO CHICAGO
SET CONNECTION SANJOSE
... 
SQL Statement 
... 
RELEASE SANJOSE

System-directed access (implicit)

Using three-part name