Chapter 1. Overview. 1.1 DB2 Family of Products

Transcription

1 Chapter 1. Overview This chapter is an introduction to some of the concepts and terminology that will be used throughout the remainder of the book. We discuss how relational data is accessed in a distributed environment using Distributed Relational Database Architecture, or DRDA. The type of data accessed by DRDA is data in a relational database, such as DB2 Universal Database, DB2 for OS/390, DB2 for VSE/VM or DB2 for OS/400. Like a single relational database, a distributed relational database consists of tables. The difference is that the tables can be spread across a number of computers in a network. The tables can be stored at different locations, and managed by different database management systems. We ll start by looking at some of the IBM products that support DRDA. 1.1 DB2 Family of Products The term universal in DB2 Universal Database means the ability to store all kinds of electronic information. This includes traditional relational data as well as structured and unstructured binary information, documents and text in many languages, graphics, images, multimedia (audio and video), or information specific to operations like engineering drawings, maps, insurance claims forms, numerical control streams, or any other type of electronic information. The DB2 database products are collectively known as the DB2 Family. The DB2 family is divided into two main groups: DB2 for midrange and large systems. Supported platforms are OS/400, VSE/VM and OS/390. DB2 UDB for Intel and UNIX environments. Supported platforms include OS/2, Windows NT, Windows 95/98, AIX, HP-UX, and Sun Solaris. The features and implementations of the midrange and large system members of the DB2 Family are very similar to DB2 UDB. When there are differences, they are very often due to the differing features of the operating systems. DB2 UDB provides seamless database connectivity using the most popular network communications protocols, including NetBIOS, TCP/IP, IPX/SPX, Named Pipes, and APPC. The infrastructure (but not the protocol) that DB2 database clients use to communicate with DB2 database servers is provided by DB2. 1

2 1.1.1 DB2 Universal Database - The Scalable Database In Figure 2, all of the DB2 Universal Database Server products are shown. DB2 UDB is capable of supporting hardware platforms from laptops to massively parallel systems with hundreds of nodes. This provides extensive and granular growth. There are four different DB2 Database Server Products in Version 5. For simplicity, we will refer to the DB2 Universal Database family of products as DB2. DB2 UDB V5 Massively Parallel Processor (MPP) Enterprise-Extended Edition Enterprise Edition Workgroup Edition Personal Edition Figure 2. DB2 Universal Database Server Products 2 The DB2 Universal DRDA Certification Guide

3 1.2 DB2 UDB Family of Products There are three main DB2 UDB products, namely: DB2 Universal Database (UDB). There are four versions (known as editions) of the DB2 Universal Database product, as shown in Figure 2: DB2 UDB Personal Edition An RDBMS engine that will not support remote clients. This is available on the Intel platform only. DB2 UDB Workgroup Edition An RDBMS engine that will support remote clients. This is available on the Intel uniprocessor machines only. DB2 UDB Enterprise Edition Similar to the Workgroup Edition, but is also available for SMP machines. In addition, this product allows remote client applications to access data on a host database using DRDA. DB2 UDB Enterprise-Extended Edition Similar to the Enterprise Edition, with additional support for clusters of database servers in a partitioned database environment. DB2 Connect. This product provides the ability to access a host database using the Distributed Relational Database Architecture (DRDA). There are two versions of this product: DB2 Connect Personal Edition and DB2 Connect Enterprise Edition. We discuss these products in detail in DB2 Connect on page 5. DB2 Developer s Edition. This product provides the ability to develop and test a database application for one user. There are two versions of this product: DB2 Personal Developer s Edition (PDE) and DB2 Universal Developer s Edition (UDE). All DB2 products have a common component called the DB2 Client Application Enabler (CAE). Once a DB2 application has been developed, the DB2 Client Application Enabler component must be installed on each workstation where the application is executed. Figure 3 shows the relationship between the application, CAE and the DB2 Database Server. If the application and database are installed on the same workstation, the application is known as a local client. If the application is installed on a workstation other than the DB2 server, the application is known as a remote client. Overview 3

4 Executed Application CAE DB2 Client Workstation DB2 Server Figure 3. Remote Client Accessing DB2 Server Using CAE The Client Application Enabler provides functions other than the ability to communicate with a DB2 UDB server or DB2 Connect gateway machine. From the CAE, you can do any of the following: Issue an interactive SQL statement on a remote client which accesses data on a remote UDB server. Graphically administer and monitor a UDB database server. Run applications that were developed to comply with the Open Database Connectivity (ODBC) standard. Run Java applications that access and manipulate data in DB2 UDB databases using Java Database Connectivity (JDBC). There are no licensing requirements to install the Client Application Enabler (CAE) component. Licensing is controlled at the DB2 UDB server. The version of the CAE that you need to install depends on the operating system on the client machine. For example, if you have a database application developed for AIX, you will need to install the Client Application Enabler for AIX. There is a different CAE for each supported DB2 client operating system. The supported platforms are OS/2, Windows NT, Windows 95/98, Windows 3.x, AIX, HP-UX, MacIntosh, DOS and Sun Solaris. The CAE component should be installed on all end-user workstations. A complete set of CAEs is provided with Workgroup Edition, Enterprise Edition, Enterprise-Extended Edition, and with the DB2 Connect Enterprise Edition products. This set of CAEs is provided on a CD-ROM, and is referred to as the DB2 CAE Client Pack. 4 The DB2 Universal DRDA Certification Guide

5 1.3 DB2 Connect DB2 Connect, a member of IBM's industry-leading DB2 Universal Database family of products, is IBM's successor to IBM's Distributed Database Connection Services (DDCS). DB2 Connect provides extremely fast and robust connectivity to IBM mainframe databases for E-business and other applications running under the following Intel and UNIX operating systems: AIX HP-UX Microsoft Windows (all variants) OS/2 Sun Solaris The DB2 Connect product allows clients to access data stored on database servers that implement the Distributed Relational Database Architecture (DRDA). The target database server for a DB2 Connect configuration is known as a DRDA Application Server. Figure 4 shows the flow of database requests through DB2 Connect. The most commonly accessed DRDA application server is DB2 for OS/390. DB2 Connect supports the APPC communication protocol to provide communications support between DRDA Application Servers and DRDA Application Requesters. DB2 for OS/390 Version 5.1 (and higher) and DB2 for OS/400 Version 4.2 (and higher) support TCP/IP in a DRDA environment. Any of the supported network protocols can be used for the DB2 client (CAE) to establish a connection to the DB2 Connect gateway. The database application must request the data from a DRDA Application Server through a DRDA Application Requester. The DB2 CAE component is not a DRDA Application Requester. The DB2 Connect product provides DRDA Application Requester functionality. The DRDA Application Server accessed using DB2 Connect could be any of the following DB2 Servers: DB2 for OS/390. Only Version 5.1 or higher supports TCP/IP in a DRDA environment. DB2 for OS/400. Only Version 4.2 or higher supports TCP/IP in a DRDA environment. DB2 Server for VSE/VM Overview 5

6 DRDA Application Server DB2 for OS/390 DB2 Server for VSE/VM DB2 for OS/400 DRDA APPC, TCP/IP APPC, TCP/IP DB2 Connect DRDA Application Requester Figure 4. DRDA Application Flow DB2 Connect Personal Edition DB2 Connect Personal Edition is available only on the Intel platform: OS/2, Windows NT, Windows 95/98 and Windows 3.1. It provides access to host databases from the workstation where it is installed. Figure 5 shows the DRDA flow between the Application Requester and the Application Server using the DB2 Connect Personal Edition product. 6 The DB2 Universal DRDA Certification Guide

7 DB2 Connect Personal Edition DRDA Application Requester DB2 Connect Workstation DRDA Protocol DRDA Application Server Database Management System DRDA Server Figure 5. DRDA Flow in DB2 Connect Personal Edition DB2 Connect Enterprise Edition The DB2 Connect Enterprise Edition product provides the ability for multiple clients to access host data. A DB2 Connect gateway routes each database request from the DB2 clients to the appropriate DRDA Application Server database. Figure 6 shows the addition of a remote client. The remote client communicates with the DB2 Connect gateway using any of the supported communication protocols. Overview 7

8 Client Application Client Application Enabler (CAE) DB2 Connect Enterprise Edition DRDA Application Requester DB2 Connect Workstation DRDA Protocol DRDA Application Server Database Management System DRDA Server Figure 6. DRDA Flow in DB2 Connect Enterprise Edition DB2 Connect Features DB2 Connect is supported by the following IBM database products when running as DRDA Application Servers: DB2 for OS/400 Version or higher DB2 for MVS/ESA Version 3.1 and Version 4 DB2 for OS/390 Version 5.1 DB2 Common Server Version 2 DB2 Universal Database Version 5.0 or higher DB2 for VSE & VM Version 5 SQL/DS Version 3.5 Connectivity to host databases is provided over Systems Network Architecture (SNA) connections using IBM's Advanced Peer-to-Peer Connection (APPC) network protocol for DB2 for OS/400, DB2 for MVS, DB2 for OS/390, DB2 for VM & VSE, and SQL/DS. DB2 for OS/390 and DB2 for OS/400 V4.2 (or higher) also support database connections over TCP/IP. 8 The DB2 Universal DRDA Certification Guide

9 DB2 Connect offers many new features and improved functions compared to its predecessor, DDCS V2.3.1: Capability: New Level 3 ODBC driver with many improvements. Updated JDBC driver for better Java support. Support for stored procedures that return multi-row result sets and multiple result sets (requires DB2 for OS/390 Version 5.1). Built-in replication support. Generic bind option: you can specify any bind option supported by the host database. SYSPLEX exploitation (DB2 Connect Personal Edition only; requires DB2 for OS/390 Version 5.1). Usability: New installation method. TCP/IP database connections are much easier to configure (requires DB2 for OS/390 Version 5.1 or DB2 for OS/400 V4.2). Integrated SNA support with point-and-click configuration (DB2 Connect Personal Edition only). New point-and-click configuration utility for configuring host connections. Much easier process for connecting desktop client systems to DB2 Connect Enterprise Edition systems. Clients can discover DB2 Connect systems and all of the databases that are defined on each server or gateway. Improved ODBC traces with detailed information for performance analysis. Control Center and other GUI tools that simplify several DBA tasks. Security: DCE security (requires DB2 for OS/390 Version 5.1). Ability to run ODBC applications without having to authorize each user to base tables. Users can now bind their ODBC driver in such a way as to allow applications to run under the authority of the person that bound the ODBC driver. Performance: Faster access to the DB2 catalog for ODBC applications. Early close for cursors. Deferred prepare. Reduced byte count on Compound SQL. Several other network flow enhancements. Overview 9

10 Support for ASCII storage on the host (requires DB2 for OS/390 Version 5.1). Connectivity: Support for DRDA over TCP/IP connections to other IBM DRDA Application Servers, as they introduce support for TCP/IP. Native TCP/IP support currently requires DB2 for OS/390 Version 5.1 or DB2 for OS/400 V4.2. Support for additional SNA connectivity options: IBM Communication Server for Windows NT IBM Personal Communications Other: Ability to initiate 2-phase commit transactions over TCP/IP (requires DB2 for OS/390 Version 5.1). Ability for desktop applications to participate in a 2-phase commit transactions without the need for a gateway (TCP/IP only, requires DB2 for OS/390 Version 5.1). Ability to use DB2 for OS/390 for added reliability of transaction coordination (requires DB2 for OS/390 Version 5.1 and TCP/IP). There are also numerous other enhancements and fixes affecting all aspects of system performance, reliability, and usability. 1.4 Introduction to DRDA DRDA, or Distributed Relational Database Architecture, is a set of protocols that software manufacturers can follow to develop connectivity solutions between applications and relational database management systems (RBDMS). DRDA coordinates communication between systems by defining what must be exchanged and how it must be exchanged. Distributed Relational Database Architecture allows you to access data in a distributed relational database environment by using SQL statements in your applications. The architecture has been designed to allow distributed data access for systems in like and unlike operating environments. This means that your applications can access data residing on homogeneous or heterogeneous platforms. DRDA is based upon these IBM and non-ibm architectures: SNA Logical Unit Type 6.2 (LU 6.2) TCP/IP Socket Interface 10 The DB2 Universal DRDA Certification Guide

11 Distributed Data Management Architecture (DDM) Formatted Data Object Content Architecture (FD:OCA) Character Data Representation Architecture (CDRA) SQL as Common DRDA Database Access Language Structured Query Language (SQL) has become the most common data access language for relational databases in the industry. SQL was chosen as part of DRDA because of its high degree of standardization and portability. In a distributed environment, where you want to access data at remote locations, the SQL requests are routed to the remote systems and they are executed remotely. Prior to sending the remote SQL request, a DRDA application must establish a connection with the remote relational database where the data is located. This is the purpose of the SQL CONNECT statement provided by DRDA Application Requester and Application Server In a distributed relational database environment, the system running the application and sending the SQL requests across the network is called the Application Requester or AR. Any remote system that executes SQL requests coming from the Application Requester is known as the Application Server or AS. Some platforms are able to participate in a distributed database environment as both Application Requester and Application Server. Figure 7, shows the current Application Requester and Application Server capabilities of different database management systems. DB2 for MVS DB2 for VM DB2/400 DB2 UDB Non-IBM Application Requester (AR) Local Database DB2 for MVS DB2 for VM DB2/400 DB2 UDB Non-IBM Application Server (AS) Remote Database(s) Figure 7. Current AR and AS Support Overview 11

12 1.4.3 Unit of Work Unit of Work (UoW), Unit of Recovery (UR), or Logical Transaction are different ways to refer to the same concept. The DRDA terminology prefers the term Unit of Work. By Unit of Work, we mean a sequence of database requests that carry out a particular task such as, in a banking application, transferring money from your savings account to your checking account. This task has its logical independence and should be treated "atomically", which means that either all its components are executed or none of them; you do not want your savings balance to be updated without your checking balance being updated as well. A Unit of Work is generally terminated by a commit operation if the entire task completes successfully. DRDA defines the following levels of service regarding UoW: Level 0, Remote Request (RR): One request within one UoW to one DBMS. Remember that DB2/400 provides one DBMS; DB2 for OS/390 or DB2 UDB can provide multiple DBMSs on the same system. Level 1, Remote Unit of Work (RUW); One or more SQL requests within one UoW to a single DBMS. Switching to a different location is possible, but a new UoW must be started and the previous one must be completed. Remote Unit of Work is supported by both the SNA and TCP/IP implementations of DRDA. Level 2, Distributed Unit of Work (DUOW): Many SQL requests within one UoW to several DBMS. Two-phase commit is required. A single SQL request may only reference objects residing in the same DBMS. Distributed Unit of Work is currently supported only by the SNA implementation of DRDA, with the exception of DB2 for OS/390 Version 5.1, where it is supported over TCP/IP also. Level 3, Distributed Request (DR): In addition to the services provided by Distributed UoW, DR allows a single SQL request to include references to multiple DBMSs such as joining tables stored at different locations. This is an architected level and will be available in the future. 12 The DB2 Universal DRDA Certification Guide

13 1.4.4 Openness Many non-ibm relational database providers implement different levels of DRDA support in their products. DRDA offers the ability to access and exchange data in like and unlike system environments, thus contributing to the openness of IBM platforms in regard to interoperability Comparing DRDA-1 and DRDA-2 The difference between DRDA-1 and DRDA-2 from an application point of view is shown in Figure 8: DRDA-2 introduces: Two-phase commit protocol to keep multiple databases in synchronization. Sync Point Manager (SPM) to manage the two-phase commit. A new connection management. New SQL statements to manage multiple connections. DRDA-1 cannot maintain multiple connections in one unit of work. To connect to a different Application Server, the application must be in a connectable state, which is achieved by ending the unit of work with either an SQL COMMIT or ROLLBACK statement. In DRDA-2, we connect to multiple servers without losing the existing connections. A single unit of work can span multiple servers. Keep in mind that a single SQL statement still cannot address more than one server at a time so that, for instance, it is still not possible to join two tables residing on different systems. Overview 13

14 DRDA-1 Austin Austin DRDA-2 UOW 1 Request 1 Request 2 Toronto UOW 2 Request 3 Request 4 Request 5 Toronto Vienna UOW 3 Request 6 Request 7 Vienna Application Servers Application Requester Application Servers Figure 8. Remote Unit of Work (DRDA-1) vs. Distributed Unit of Work (DRDA-2) Figure 8 shows three units of work. The arrows pointing on the left indicate the only possible way to access data in a DRDA-1 application. The arrows on the right show the flexibility of a DRDA-2 application accessing multiple database systems in the same UoW. For example, the Toronto system on the right issues three requests, Request 2, Request 4, and Request 6. Each of these requests belong to a different Unit of Work. The Toronto system on the left-hand side also issues three requests (Request 3, Request 4, and 14 The DB2 Universal DRDA Certification Guide

15 Request 5), each targeting a different application server within one Unit of Work Controlling Two-Phase Commit Synchronizing multiple databases requires additional effort compared to the process of keeping data consistent on a single system. Since multiple physical locations are involved, the synchronization process is split into two phases to ensure data consistency across multiple locations. The database managers involved in the distributed unit of work must make sure that either all of them commit their changes or all of them roll all the changes back consistently. The way in which multiple database managers can keep their data synchronized is called two-phase commitment control. In an application using two-phase commit, the COMMIT statement generates a rather complex sequence of operations that allows the various agents in the network to keep their data in a consistent state. Also, two-phase commit protects your applications against network or system failures that might occur during the transaction. In these cases, the database managers involved in the unit of work automatically roll back their changes. LU 6.2 supports DRDA-2. When an LU 6.2 conversation supports a two-phase commitment control data flow, it may be called a protected conversation. Any LU 6.2 conversation not capable of a two-phase commitment control flow is called an unprotected conversation. DRDA-1 supports only unprotected conversations. To control the two-phase commit flow, a Sync Point Manager (SPM) is used The Sync Point Manager (SPM) SPM is a function that enables your distributed database applications to access multiple remote database application servers using DRDA-2 protocols. The SPM guarantees the integrity of the results in SNA environments. You need to install and use SPM if your distributed database applications will make use of the DRDA-2 Distributed Unit of Work (DUOW) known as two-phase commit, and you will use SNA connections between: DB2 Connect workstations accessing DRDA servers Host DRDA requesters accessing DB2 Universal Database servers. For example, your application programs running at DB2 clients can issue SQL requests that result in updates to databases at multiple remote database Overview 15

16 servers, or your DB2 for OS/390 application program can issue SQL requests that result in updates to multiple remote database servers where at least one of them is a remote DB2 Universal Database server. The LU 6.2 Syncpoint Manager is included in the following products: DDCS for AIX, OS/2 and Windows NT Multi-User Gateway Version DB2 Connect Enterprise Edition for AIX, OS/2 and Windows NT Version 5.0 or higher DB2 Universal Database Workgroup Edition for AIX, OS/2 and Windows NT Version 5.0 or higher DB2 Universal Database Enterprise Edition for AIX, OS/2 and Windows NT Version 5.0 or higher DB2 Universal Database Enterprise-Extended Edition for AIX and Windows NT Version 5.0 or higher There are several considerations for using SPM in a DB2 UDB environment: 1. SPM is not included with DB2 Connect Personal Edition (formerly DDCS Single User) or the DB2 Universal Database Personal Edition products. 2. In order to use SPM functions, DB2 clients must be at the Version code level, or higher. 3. Application programs that will issue two-phase commit requests must be pre-compiled with the CONNECT 2 and SYNCPOINT TWOPHASE options. 4. In DB2 Connect Enterprise Edition Version 5.0, the SPM continues to allow host databases to participate in two-phase commit transactions, but they cannot be the TM_DATABASE for such transactions. 5. DB2 Universal Database Servers include the SPM in order to provide two-phase-commit support for DRDA AS. 6. If you want one workstation to act as a server for both inbound and outbound two-phase commit support, you must install both DB2 Connect Enterprise Edition and DB2 Universal Database SPM Scenarios Figure 9 shows different scenarios where you can use SPM. In each case, the SPM logical unit runs on the DB2 Connect workstation. Note that these scenarios are only supported by the DB2 Connect Enterprise Edition products for AIX, and OS/2. 16 The DB2 Universal DRDA Certification Guide

17 Application Requestor Server and/or Gateway DRDA-2 Host DB2 CAE AR remote user DB2 Server DB2 Connect Enterprise Edition DRDA Host MVS or AS/400 Application plus DB2 Connect Enterprise Edition DRDA Host MVS or AS/400 Local user with DB2 Personal Edition DB2 Server DB2 Connect Enterprise Edition DRDA Host MVS or AS/400 Local user with DB2 Personal Edition DB2 Connect Enterprise Edition DRDA Host MVS or AS/400 Figure 9. DUOW Scenarios Participating in the Two-Phase Commit Process This section describes the roles played by systems that take part in SPM scenarios. Application Requester DB2 Connect assumes the syncpoint model defined by DRDA where only the Application Requester can initiate a commit. For this reason, syncpoint coordinator functions are included in the DB2 products. The role of the coordinator at an Application Requester is as follows: 1. It registers the DUOW request with a transaction manager. 2. It delegates further coordination of the DUOW to the transaction manager and the SPM. Overview 17

18 Transaction Manager Distributed units of work must always be registered with a transaction manager. This is done by the coordinator at the Application Requester. The transaction manager is responsible for: 1. Preserving the integrity of DUOW requests. 2. Providing registration, logging and decision-making services for DUOW requests. 3. Guaranteeing the integrity of the results of the DUOW. The SPM is always a partner with a transaction manager, which is assumed to be at an Application Requester. The transaction manager can be any of the following: A DB2 client/server DUOW TM. An XA-compliant TM, such as CICS for AIX. A DB2 for OS/390, DB2 for MVS/ESA, or DB2/400 Application Requester. A host-based TP Monitor such as CICS Transaction Server for OS/390. Note that for AIX and OS/2, earlier support in Transaction Processing Monitors via the Peer-to-Peer Communications gateway has been replaced by the SPM with DB2 Connect Enterprise Edition Version 5.0. Two-phase commit is not supported through the SPM with the Tuxedo Transaction Manager. Syncpoint Manager The SPM can serve as: The LU 6.2 coordinator on behalf of Application Requesters, the transaction manager database, and DRDA-2 Application Servers. This is the case when you connect from a DB2 UDB client to a DRDA server, such as DB2 for OS/390, through DB2 Connect. An LU 6.2 participant on behalf of DB2 UDB servers or DB2 Common servers. This is the case when you connect from a DRDA Application Requester, such as DB2 for OS/390, to a DB2 UDB server through a DB2 UDB server that has the SPM operational. For example, when an application issues a commit, it is the transaction manager that controls the ultimate success or failure of the commit on behalf of the application, but it is the SPM that propagates the unit of work decision to DRDA-2 Application Servers involved in the unit of work. 18 The DB2 Universal DRDA Certification Guide

19 The SPM is an independent logical unit and it communicates with DRDA servers using APPC protocols. However, communications from DB2 clients to DB2 Connect/SPM gateways or from a DB2 Universal Database/SPM server to remote DB2 Universal Database servers can use any protocol supported by DB2 (APPC, IPX/SPX, Named Pipes, NetBIOS, or TCP/IP, depending on the workstation s operating system). Overview 19

20 20 The DB2 Universal DRDA Certification Guide