Everything You Need To Know About DB2 Distributed Computing

What is Distributed computing environments: typically involve requests from users at one DBMS client that are processed by a DBMS server.

The server DBMS is typically remote to the client.

Excellent job opportunities, if  you are good at Distributed Computing. Certain programming techniques and performance implications apply to distributed computing environments.

Today’s Fortune 500 companies are embracing distributed techniques to access mainframe data on DB2.

Although online transaction processing (OLTP) workloads still dominate DB2’s local processing, more applications, such as data warehousing analytics, run remotely as distributed tasks.

The interesting part of distributed DB2 is the terminology; it has its own set. If you spend time dealing only with the local side, some of these terms may be new, maybe even confusing in some rare cases.

Distributed Computing
Distributed Computing

The DB2® distributed environment supports both a two-tier and a multitier architecture.

  • A DBMS, whether local or remote, is known to your DB2 subsystem by its location name.
  • Remote systems use the location name, or an alias location name, to access a DB2 subsystem.
  • You can define a maximum of eight location names for a DB2 subsystem.

The location name of the DB2 subsystem is defined in the BSDS during DB2 installation. The communications database (CDB) records the location name and the network address of a remote DBMS. The CDB is a set of tables in the DB2 catalog.

The primary method that DB2 uses for accessing data at a remote server is based on Distributed Relational Database Architecture™ (DRDA®).

What to know about DB2 DDF:

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.
If your application performs updates to two or more DBMSs, a transaction manager coordinates the two-phase commit process and guarantees that units of work are consistently committed or rolled back.
If DB2 requests updates to two or more DBMSs, DB2 acts as the transaction manager. The distributed commit protocols that are used on the network connection dictate whether both DBMSs can perform updates or whether updates are restricted to a single DBMS.


The examples that follow show statements that you can use to access distributed data.

Begin general-use programming interface information.

Example 1: To access data at a remote server, write statements like the following example:

EXEC SQL
CONNECT TO CHICAGO;
SELECT * FROM IDEMP01.EMP
WHERE EMPNO = ‘000030’;

You can also accomplish the same task by writing the query like the following example:

SELECT * FROM CHICAGO.IDEMP01.EMP
WHERE EMPNO = ‘000030’;

Before you can execute either query at location CHICAGO, you must bind a package at the CHICAGO server.

Example 2: You can call a stored procedure to access data at a remote server. Your program executes these statements:

EXEC SQL
CONNECT TO ATLANTA;
EXEC SQL
CALL procedure_name (parameter_list);

The parameter list is a list of host variables that is passed to the stored procedure and into which it returns the results of its execution. The stored procedure must exist at location ATLANTA.

Related Post: DB2 Connect-Interfacing with distributed systems

Advertisements

Author: Srini

Experienced software developer. Skills in Development, Coding, Testing and Debugging. Good Data analytic skills (Data Warehousing and BI). Also skills in Mainframe.