Mientras que el bloqueo de filas del conjunto de resultados de una consulta no es nada nuevo, DB2 para z/OS (anteriormente llamado DB2 para OS/390) tenía, desde el release de la Versión 6.1, la posibilidad de devolver varios bloques de consulta en respuesta a una petición OPEN o FETCH efectuada a un cliente remoto, como por ejemplo DB2 Connect. En lugar de enviar repetidamente peticiones al servidor DB2 para z/OS, solicitando un bloque de datos de fila cada vez, ahora el cliente puede solicitar, opcionalmente, que el servidor le envíe un número adicional de bloques de consulta. Estos bloques de consulta adicionales reciben el nombre de bloques de consulta extra.
Esta nueva característica permite que el cliente minimice el número de rodeos por la línea de la red, lo cual tiene un importante efecto sobre el rendimiento de la red. La disminución en el número de peticiones de bloques de consulta enviadas por el cliente al servidor se traduce en un incremento significativo del rendimiento, puesto que la conmutación entre un envío y una petición es una operación cara en términos de rendimiento. Ahora, DB2 Connect se puede aprovechar de esta mejora en el rendimiento solicitando bloques de consulta extra, por omisión, a un servidor DB2 para z/OS.
Para aprovecharse plenamente de la devolución de bloques de consulta extra (cada uno de los cuales puede llegar a tener una longitud de 32 Kbytes) para el protocolo de red preferido de TCP/IP, también se han habilitado las extensiones de Window Scaling tal como se realiza en el RFC-1323 de DB2 Connect. Esta característica permite que TCP/IP ajuste de forma dinámica y eficaz los tamaños de las ventanas de envío y recepción para acoger las grandes cantidades potenciales de datos devueltas por medio de los bloques de consulta extra.
El soporte de bloques de consulta extra en servidores DB2 para z/OS en las Versiones 6.1 o posteriores se configura por medio del parámetro EXTRA BLOCKS SRV del panel de instalación de DB2 DDF. Este parámetro controla el número máximo de bloques de consulta extra que DB2 puede devolver a un cliente para una petición, y se puede establecer con un valor entre 0 y 100. Si el valor de este parámetro se establece en 0, se inhabilita la devolución de bloques de consulta extra. Se debe utilizar el valor por omisión, que es de 100, para obtener el máximo provecho de esta característica, salvo las posibles idiosincrasias de la red que hagan que este valor sea inferior al ideal.
En la parte del cliente, en que la aplicación accede a DB2 para z/OS directamente a través de una instalación DB2 Connect co-ubicada, o a través de una instalación de servidor DB2 Connect separada, existen diversos métodos para activar el soporte de DB2 Connect correspondiente en base al cursor o a las sentencias, mediante el uso de:
La opción 1 no se trata en este apartado porque ya se había implantado formando parte de DB2 para z/OS Scrollable Support en el FixPak 2 de DB2 Connect Versión 7.1. Aquí nos centramos en el uso de las opciones 2 y 3, en lugar de habilitar el soporte de bloques de consulta extra utilizando distintas API de SQL, del modo siguiente:
Se soporta Window Scaling como parte del FixPak 4 en todas las plataformas Windows y UNIX que soportan las extensiones del RFC-1323 para TCP/IP. Se puede habilitar esta característica en DB2 para Windows y UNIX por medio de la variable de registro DB2SORCVBUF de DB2. Para habilitar Window Scaling, establezca la variable de registro DB2SORCVBUF de DB2 con cualquier valor por encima de 64 K (por ejemplo, en DB2 para Windows o UNIX, puede emitir db2set DB2SORCVBUF =65537). Los tamaños máximos de los almacenamientos intermedios de envío y recepción dependen del sistema operativo en concreto. Para asegurarse de que se han aceptado los tamaños de almacenamiento intermedio configurados, el usuario puede establecer el parámetro de configuración DIAGLEVEL del gestor de bases de datos en 4 (informativo) y ver si hay mensajes en el archivo db2diag.log.
Para que Window Scaling surta efecto, tiene que estar habilitado en ambos extremos de una conexión. Por ejemplo, para habilitar Window Scaling entre la estación de trabajo DB2 Connect y el sistema principal, esta característica debe estar activa tanto en la estación de trabajo como en el sistema principal, ya sea directamente a través de la pila TCP/IP del sistema operativo o indirectamente a través del producto DB2. Por ejemplo, para DB2 para z/OS, actualmente sólo se puede activar Window Scaling a través del sistema operativo, estableciendo TCPRCVBUFRSIZE con cualquier valor por encima de 64 K.
Si se utiliza un cliente DB2 remoto para acceder al DB2 del sistema principal a través de una estación de trabajo servidor DB2 Connect, también se puede habilitar Window Scaling en el cliente. Del mismo modo, también se puede habilitar Window Scaling entre un cliente DB2 remoto y un servidor DB2 de estación de trabajo cuando no haya ningún sistema principal DB2 implicado.
Aunque Window Scaling ha sido diseñado para mejorar el rendimiento de la red, la mejora esperada en dicho rendimiento no siempre se materializa. Una vez que se ha habilitado Window Scaling, la interacción de factores tales como el tamaño de trama utilizado para el adaptador de LAN Ethernet o de Red en anillo, el tamaño de MTU de IP y otros valores establecidos en direccionadores del enlace de comunicación, pueden ocasionar incluso una disminución del rendimiento. Por omisión, Window Scaling está inhabilitado con los almacenamientos intermedios de envío y recepción establecidos con 64 K. El usuario deberá estar preparado para valorar el impacto de una activación de Window Scaling y para realizar los ajustes necesarios en la red. Para ver una introducción al ajuste de la red a fin de obtener un rendimiento mejorado de la misma, consulte el documento que se encuentra en http://www.networking.ibm.com/per/per10.html.