DB2 Server for VSE & VM: Performance Tuning Handbook

Distributed Configuration Considerations

DB2 Server for non-DRDA Requestors can access:

• DB2 Server for VM Servers on the local processor or on a processor within a TSAF collection
• DB2 Server for VM Servers on a remote processor in an SNA network

DB2 Server for VM non-DRDA Servers can be accessed by:

• DB2 Server for VM non-DRDA Requestors on the local processor or on a processor within a TSAF collection
• DB2 Server for VM non-DRDA Requestors on a remote processor in an SNA network
• DB2 Server for VSE non-DRDA Requestors in a VSE guest machine in the local VM processor or on a processor within a TSAF collection (guest sharing)
• DB2 Server for VSE non-DRDA Requestors in a VSE guest machine on a remote processor in an SNA network (guest sharing to remote VM)

DB2 Server for VM DRDA Requestors can access:

• DB2 Server for VM DRDA Servers on the local processor or on a processor within a TSAF collection
• DB2 Server for VM DRDA Servers on a remote processor in an SNA network
• DB2 Server for VM DRDA Servers in an SNA network or in a TCP/IP network
• DB2 Server for VSE DRDA Servers in an SNA network (via the CICS AXE transaction) or in a TCP/IP network
• non-DB2 Server for VSE & VM DRDA Servers in an SNA network or in a TCP/IP network

DB2 Server for VM DRDA Servers can be accessed by:

• DB2 Server for VM DRDA and non-DRDA Requestors on the local processor or on a processor within a TSAF collection
• DB2 Server for VM DRDA Requestors on a remote processor in an SNA network or in a TCP/IP network
• DB2 Server for VSE non-DRDA Requestors in a VSE guest machine in the local VM processor or on a processor within a TSAF collection (guest sharing)
• DB2 Server for VSE Online (CICS) DRDA Requestors in an SNA network or in a TCP/IP network
• DB2 Server for VSE Batch DRDA Requestors in a TCP/IP network
• non-DB2 Server for VSE & VM DRDA Requestors in an SNA network or in a TCP/IP network

DB2 Server for VSE non-DRDA Requestors can access:

• DB2 Server for VSE DRDA and non-DRDA Servers on the local processor
• DB2 Server for VM DRDA and non-DRDA Servers via guest sharing from a VSE guest machine on the local processor or on a processor within a TSAF collection

DB2 Server for VSE non-DRDA Servers can be accessed by:

• DB2 Server for VSE non-DRDA Online (CICS) Requestors on the local processor
• DB2 Server for VM non-DRDA Batch Requestors on the local processor

DB2 Server for VSE DRDA Online (CICS) Requestors can access:

• DB2 Server for VSE DRDA and non-DRDA Servers on the local processor
• DB2 Server for VSE & VM DRDA Servers in an SNA network or in a TCP/IP network
• non-DB2 Server for VSE & VM DRDA Servers in an SNA network or in a TCP/IP network

DB2 Server for VSE DRDA Batch Requestors can access:

• DB2 Server for VSE DRDA and non-DRDA Servers on the local processor
• DB2 Server for VSE & VM DRDA Servers in a TCP/IP network
• non-DB2 Server for VSE & VM DRDA Servers in a TCP/IP network

DB2 Server for VSE DRDA Servers can be accessed by:

• DB2 Server for VSE DRDA and non-DRDA Requestors on the local processor (Online and Batch)
• non-DB2 Server for VSE & VM DRDA Requestors in an SNA network (via the CICS AXE transaction)
• non-DB2 Server for VSE & VM DRDA Requestors in a TCP/IP network

Performance Implications

How you configure a distributed system can have a significant impact on the performance of all the processors in the network. While this guide cannot describe all possible distributed installations, nor can it suggest the best possible installation for you, it does include some basic guidelines and several simple examples.

See the VM/ESA: Connectivity Planning, Administration, and Operation manual for your operating system for details on optimizing performance in a TSAF collection or SNA network. For information on both SNA networks and the connectivity issues that are relevant in IBM distributed database systems, see the Distributed Relational Database Connectivity Guide manual.

Applications Planning

If your application program needs to interact with a remote processor, there are several things that you can do to minimize the communication traffic between the requester and the server.

Fetch and Insert Blocking

Blocking groups multiple row insertions or retrievals into one request. Instead of sending a separate instruction for each insert or fetch done by a cursor, instructions are grouped together and sent in one communication block. This reduces message traffic and overhead. (However, it is not supported in single user mode, or with DRDA.) For more information, refer to Fetch and Insert Blocking.

Hold File

The creation of hold files is a technique allowing you to save the results of a query (database information) in CMS or CICS files. Subsequent requests for this information are satisfied by retrieving it from the CMS or CICS files.

Local Copy

If your application requires information from a database on another processor that is not periodically updated, consider copying the information into temporary tables in a local database. For example, if you need access to a monthly sales summary, simply unload the summary data from the remote server once a month and load it into your local server.

Stored Procedures

Your applications can use stored procedures on the remote server. This can reduce the amount of data that must be moved over the network. For more information, see the DB2 Server for VSE & VM Application Programming and DB2 Server for VSE & VM Database Administration manuals.