Distributed Data

Using DB2's Distributed Data Facility (DDF) provides access to data held by other data management systems or to make your DB2 data accessible to other systems. A DB2 application program can use SQL to access data at other database management systems (DBMSs) other than the DB2 at which the application's plan is bound. This DB2 is known as the local DB2. The local DB2 and the other DBMSs are called application servers. Any application server other than the local DB2 is considered a remote server, and access to its data is a distributed operation.

DB2 provides two methods of accessing data at remote application servers: DRDA and DB2 private protocol access. For application servers that support the two-phase commit process, both methods allow for updating data at several remote locations within the same unit of work.

The location name of the DB2 subsystem is defined during DB2 installation. The CDB records the location name and the network address of a remote DBMS. The tables in the CDB are part of the DB2 catalog.

Distributed Relational Database Architecture

With DRDA, the recommended method, the application connects to a server at another location and executes packages that have been previously bound at that server. The application uses a CONNECT statement, a three-part name or, if bound with DBPROTOCOL(DRDA), an alias to access the server.

Queries can originate from any system or application that issues SQL statements as an application requester in the formats required by DRDA. DRDA access supports the execution of dynamic SQL statements and SQL statements that satisfy all the following conditions.

• The static statements appear in a package bound to an accessible server.

• The statements are executed using that package.

• The objects involved in the execution of the statements are at the server where the package is bound. If the server is a DB2 subsystem, three-part names and aliases can be used to refer to another DB2 server.

DRDA access can be used in application programs by coding explicit CONNECT statements or by coding three-part names and specifying the DBPROTOCOL(DRDA) bind option. For more on bind options, refer to Chapter 11.

DRDA access is based on a set of DRDA protocols. (These protocols are documented by the Open Group Technical Standard in DRDA Volume 1: Distributed Relational Database Architecture (DRDA).) DRDA communication conventions are invisible to DB2 applications and allow a DB2 to bind and rebind packages at other servers and to execute the statements in those packages.

For two-phase commit using SNA connections, DB2 supports both presumed-abort and presumed-nothing protocols that are defined by DRDA. If you are usingTCP/IP, DB2 uses the sync point manager defined in the documentation for DRDA Level 3.

DB2 Private Protocol

With private protocol, the application must use an alias or a three-part name to direct the SQL statement to a given location. Private protocol works only between application requesters and servers that are both DB2 for z/OS subsystems.

A statement is executed using DB2 private protocol access if it refers to objects that are not at the current server and is implicitly or explicitly bound with DBPROTOCOL(PRIVATE). The current server is the DBMS to which an application is actively connected. DB2 private protocol access uses DB2 private connections. The statements that can be executed are SQL INSERT, UPDATE, and DELETE and SELECT statements with their associated SQL OPEN, FETCH, and CLOSE statements.

In a program running under DB2, a three-part name or an alias can refer to a table or a view at another DB2. The location name identifies the other DB2 to the DB2 application server. A three-part name consists of a location, an authorization ID, and an object name. For example, the name NYSERVER.DB2USER1.TEST refers to a table named DB2USER1.TEST at the server whose location name is NYSERVER.

Alias names have the same allowable forms as table or view names. The name can refer to a table or a view at the current server or to a table or a view elsewhere. For more on aliases, refer to Chapter 4.

NOTE

Private protocol does not support many distributed functions, such as TCP/IP or stored procedures. The newer data types, such as LOB or user-defined types, are also not supported by private protocol. It is not the recommended method to use and is no longer being enhanced or supported from version 8 forward.

Communications Protocols

DDF uses TCP/IP or SNA to communicate with other systems. Setting up a network for use by database management systems requires knowledge of both database management and communications. Thus, you must put together a team of people with those skills to plan and implement the network.

TCP/IP

Transmission Control Protocol/Internet Protocol (TCP/IP) is a standard communication protocol for network communications. Previous versions of DB2 supported TCP/IP requesters, although additional software and configuration were required. Native TCP/IP eliminates these requirements, allowing gatewayless connectivity to DB2 for systems running UNIX System Services.

SNA

System Network Architecture (SNA) is the description of the logical structure, formats, protocols, and operational sequences for transmitting information through and controlling the configuration and operation of the networks. It is one of the two main network architectures used for network communications to the enterprise servers.

VTAM

DB2 also uses Virtual Telecommunications Access Method (VTAM) for communicating with remote databases. This is done be assigning two names for the local DB2 subsystem: a location name and a logical unit (LU) name. A location name distinguishes a specific database management system in a network, so applications use this name to direct requests to the local DB2 subsystem. Other systems use different terms for a location name. For example, DB2 Connect calls this the target database name. DB2 uses the DRDA term, RDBNAM, to refer to non-DB2 relational database names.

Communications Database

The DB2 catalog includes the communications database (CDB), which contains several tables that hold information about connections with remote systems. These tables are

• SYSIBM.LOCATIONS

• SYSIBM.LUNAMES

• SYSIBM.IPNAMES

• SYSIBM.MODESELECT

• SYSIBM.USERNAMES

• SYSIBM.LULIST

• SYSIBM.LUMODES

Some of these tables must be populated before data can be requested from remote systems. If this DB2 system services only data requests, the CDB does not have to be populated; the default values can be used.

When sending a request, DB2 uses the LINKNAME column of the SYSIBM.LOCATIONS catalog table to determine which protocol to use.

• To receive VTAM requests, a LUNAME must be selected in installation panel DSNTIPR.

• To receive TCP/IP requests, a DRDA port and a resynchronization port must be selected in installation panel DSNTIP5. TCP/IP uses the server's port number to pass network requests to the correct DB2 subsystem. If the value in the LINKNAME column is found in the SYSIBM.IPNAMES table, TCP/IP is used for DRDA connections. If the value is found in the SYSIBM.LUNAMES table, SNA is used.

• If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is used to connect to the location.

NOTE

A requester cannot use both SNA and TCP/IP to connect to a given location. For example, if SYSIBM.LOCATIONS specifies a LINKNAME of LU1, and if LU1 is defined in both the SYSIBM.IPNAMES and SYSIBM.LUNAMES tables, TCP/IP is the only protocol used to connect to LU1 from this requester for DRDA connections. For private protocol connections, the SNA protocols are used. If private protocol connections are being used, the SYSIBM.LUNAMES table must be defined for the remote location's LUNAME.