DRDA stands for Distributed Relational Database Architecture.
It is a protocol set that allows multiple database systems and application programs to work together.
Any combination of relational database management products that use DRDA can be connected to form a distributed database management system.
DRDA describes the architecture for distributed relational databases. It defines the rules for accessing the distributed data, but it does not provide the actual application programming interfaces (APIs) to perform the access.
It was first used in DB2 2.3.DRDA was designed by a workgroup within IBM in the period 1988 to 1994. The messages, protocols, and structural components of DRDA are defined by the Distributed Data Management Architecture.
Steps to Implement DRDA
The following two steps are required to implement DRDA:
- For data modeling:Set a flag on a CA 2E file to indicate that it is distributed (refer to the Using Shipped DRDA Values section in this article). Set the Distributed File I/O control function option for the function to either S (CA 2E) or U (User) control. Set this option from Edit Function Options, using the Distributed File I/O Control field.
- If you specified S (CA 2E) control for the function, enter the file locations in the Distributed File Configuration Table. This entry associates the file with the name of the application server and, optionally, the collection name in which it is located, allowing a different configuration at each location on which the application is implemented.
Creation (compilation) of the program is via an extended form of CRTSQLxxx (where xxx = HLL language). Use the YGENRDB model value as the RDB in the CRTSQLxxx command.
Running CRTSQLxxx results in:
- An application program, which resides on the application requester.
- An SQL package, which resides on the application server and contains the SQL statements for accessing the AS database.
Components of DRDA
- Application Requester: Accepts SQL requests from applications and sends them to appropriate application servers for processing. Application programs can access remote data using this function.
- Application Server: Receives requests from application requesters and processes them. The application server acts on the portions of requests that can be processed, and forwards remainder to database servers for further processing.
- Database Server: Receives requests from the application server and other database servers. This server also supports distributed requests and forwards parts of the request to the database server to fulfill the request.
Databases supporting DRDA
- Apache Derby (Java RDBMS)
- DB2
- Informix Dynamic Server v11.10
- Oracle Database Gateway for DRDA – enables Oracle database to act as a DRDA client, accessing remote non-Oracle databases (primarily DB2)
- Oracle Database Provider for DRDA – enables Oracle database to act as a DRDA server, providing Oracle database access to remote clients (e.g. IBM i systems using DB2/400 DRDA client library)
Advantages of DRDA
- Local/remote transparency. Application programs can be easily redirected from local data to remote data. Specialized programs that access and manage data in remote systems are not needed.
- Reduced data redundancy. Data need be stored in only one location in a network.
- Better security. By eliminating redundant copies of data, access to the data in a network can be better limited to authorized users.
- Data integrity. Updates by concurrent local and remote users are not lost because of conflicts.
- More timely information. Users of multiple computers in a network always have access to the most recent data.
- Better resource management. The data storage and processing resources of a network of computers can be optimized.
Disadvantages of DRDA
- Complexity
- Cost
- Security
- Integrity control more difficulty
- Lacks of standards
- Lack of experience
- Database design more complex