DB2 Version 9.7 for Linux, UNIX, and Windows

rqrioblk - Client I/O block size configuration parameter

This parameter specifies the size of the communication buffer between remote applications and their database agents on the database server. It is also used to determine the I/O block size at the Data Server Runtime Client when a blocking cursor is opened.

Configuration type
Database manager
Applies to
  • Database server with local and remote clients
  • Client
  • Database server with local clients
  • Partitioned database server with local and remote clients
Parameter type
Configurable
Default [range]
32 767 [4 096 - 65 535 ]
Unit of measure
Bytes
When allocated
  • When a remote client application issues a connection request for a server database
  • When a blocking cursor is opened, additional blocks are opened at the client
When freed
  • When the remote application disconnects from the server database
  • When the blocking cursor is closed

When a Data Server Runtime Client requests a connection to a remote database, this communication buffer is allocated on the client. On the database server, a communication buffer of 32 767 bytes is initially allocated, until a connection is established and the server can determine the value of rqrioblk at the client. Once the server knows this value, it will reallocate its communication buffer if the client's buffer is not 32 767 bytes.

The memory for blocked cursors is allocated out of the application's private address space, so you should determine the optimal amount of private memory to allocate for each application program. If the Data Server Runtime Client cannot allocate space for a blocking cursor out of an application's private memory, a non-blocking cursor will be opened.

Recommendation: For non-blocking cursors, a reason for increasing the value of this parameter would be if the data (for example, large object data) to be transmitted by a single query statement is so large that the default value is insufficient.

You should also consider the effect of this parameter on the number and potential size of blocking cursors. Large row blocks might yield better performance if the number or size of rows being transferred is large (for example, if the amount of data is greater than 4 096 bytes). However, there is a trade-off in that larger record blocks increase the size of the working set memory for each connection.

Larger record blocks might also cause more fetch requests than are actually required by the application. You can control the number of fetch requests using the OPTIMIZE FOR clause on the SELECT statement in your application.