Mejora del rendimiento para aplicaciones que acceden a datos distribuidos

La clave para mejorar el rendimiento de las aplicaciones que acceden a datos remotos es limitar el número de transmisiones de red.

Para maximizar el rendimiento de una aplicaciónque acceda a datos distribuidos, utilice los métodos siguientes:

• Escriba cualquier consulta que acceda a datos distribuidos de acuerdo con las recomendaciones siguientes para limitar el número de mensajes que estas consultas envían por la red:
  • Reduzca el número de columnas y filas de la tabla de resultados, para lo que debe mantener las listas de selección lo más cortas posibles, y utilice las cláusulas WHERE, GROUP BY y HAVING para eliminar datos no deseados en el servidor remoto.
  • En el caso de consultas que devuelven miles de filas, especifique la cláusula FOR FETCH ONLY o FOR READ ONLY si es posible. A continuación, puede enlazar las aplicaciones que contienen esas consultas con la opción DBPROTOCOL(DRDACBF) para permitir que Db2 utilice la captación de bloques continuos basada en paquetes para recuperar las filas. Con este tipo de captación de bloque continuo, el peticionario abre una conexión secundaria con el servidor para cada cursor. Luego el servidor puede enviar los datos para todos los cursores de forma simultánea.

    El uso de esta forma de captación de bloque continuo puede resultar en un mejor rendimiento que el uso de la captación de bloque continuo basada en SQL.

• Para consultas que tengan tablas de resultados potencialmente grandes, pero que solo necesiten un número limitado de filas, especifique la cláusula FETCH FIRST n ROWS ONLY.
  Esta cláusula limita el número de filas que se devuelven a un programa cliente.
  Por ejemplo, supongamos que solo necesita una fila de la tabla de resultados. Puede añadir la cláusula FETCH FIRST 1 ROW ONLY, como se muestra en el ejemplo siguiente:

  SELECT * FROM EMP  OPTIMIZE FOR 1 ROW ONLY  FETCH FIRST 1 ROW ONLY;

  En este caso, la cláusula FETCH FIRST 1 ROW ONLY evita 15 captaciones previas innecesarias.
• Si el programa accede a columnas LOB de una tabla remota, utilice las técnicas siguientes para minimizar el número de byte que se transfieren entre el cliente y el servidor:
  • Utilice localizadores LOB en lugar de variables host LOB.

    Si tiene que almacenar solo una parte de un valor LOB en el cliente, o si el programa cliente manipula los datos LOB pero no necesita una copia de ellos, los localizadores LOB son una buena opción. Cuando un programa cliente recupera una columna LOB de un servidor en un localizador, Db2 solo transfiere el valor del localizador de 4 bytes al cliente, no todo el valor LOB.

  • Utilice conjuntos de resultados de procedimientos almacenado.

    Cuando devuelva datos de LOB a un programa cliente desde un procedimiento almacenado, utilice conjuntos de resultados en lugar de pasar los datos de LOB al cliente en parámetros. El uso de conjuntos de resultados para devolver datos provoca menos materialización de LOB y menos movimiento de datos entre espacios de direcciones.

  • Establezca el registro especial CURRENT RULES en Db2.

    Cuando un servidor de Db2 recibe una solicitud OPEN para un cursor, el servidor utiliza el valor del registro especial CURRENT RULES para determinar el tipo de variables de lenguaje principal que la sentencia asociada utiliza para recuperar valores LOB. Si especifica un valor de Db2 para el registro especial CURRENT RULES antes de ejecutar CONNECT y la primera sentencia FETCH para el cursor utiliza un localizador LOB para recuperar valores de columna LOB, Db2 permite utilizar únicamente localizadores LOB para todas las sentencias FETCH posteriores de dicha columna hasta que cierre el cursor. Si la primera sentencia FETCH utiliza una variable del lenguaje principal, Db2 permite utilizar únicamente variables del lenguaje principal para todas las sentencias FETCH posteriores de dicha columna hasta que cierre el cursor. Sin embargo, si establece el valor de CURRENT RULES en STD, Db2 le permite utilizar el mismo cursor abierto para captar una columna LOB en un localizador LOB o en una variable de lenguaje principal.

    Aunque un valor de STD para el registro especial CURRENT RULES ofrece más flexibilidad de programación cuando se recuperan datos LOB, obtendrá un mejor rendimiento si utiliza un valor de Db2. Con la opción STD, el servidor debe enviar y recibir mensajes de red para cada sentencia FETCH para indicar si los datos que se están transfiriendo son un localizador LOB o un valor LOB. Con la opción Db2, el servidor conoce el tamaño de los datos LOB después del primer FETCH, por lo que no es necesario un mensaje adicional sobre el tamaño de los datos LOB. El servidor puede enviar varios bloques de datos al peticionario a la vez, lo que reduce el tiempo total para la transferencia de datos.

  Por ejemplo, supongamos que un usuario desea examinar un conjunto grande de registros de empleados y mirar las imágenes de solo unos pocos de ellos. En el servidor, establezca el registro especial CURRENT RULES en Db2. En la aplicación, se declara y se abre un cursor para seleccionar registros de empleados. Luego la aplicación capta todos los datos de imagen en localizadores LOB de 4 bytes. Como Db2 sabe que se devuelven 4 bytes de datos LOB para cada sentencia FETCH, Db2 puede llenar los almacenamientos intermedios de red con localizadores para muchas imágenes. Si un usuario desea ver la imagen de una persona concreta, la aplicación puede recuperar dicha imagen del servidor mediante la asignación del valor al que hace referencia el localizador LOB a una variable host LOB. Esta situación se implementa en el código siguiente:

  SQL TYPE IS BLOB my_blob[1M];
  SQL TYPE IS BLOB AS LOCATOR my_loc;
  ⋮
  FETCH C1 INTO :my_loc;    /* Fetch BLOB into LOB locator  */
  ⋮
  SET :my_blob = :my_loc; /* Assign BLOB to host variable */

• Asegúrese de que cada cursor cumple una de las siguientes condiciones cuando sea posible, para que Db2 utilice la captura de bloques para minimizar el número de mensajes que se envían a través de la red:
  • El cursor se declara con una cláusula FOR FETCH ONLY o FOR READ ONLY.
  • El cursor es un cursor no desplazable, y la tabla de resultados del cursor es de sólo lectura.
  • El cursor es un cursor desplazable que se declara como INSENSITIVE, y la tabla de resultados del cursor es de sólo lectura.
  • El cursor es un cursor desplazable que se declara como SENSITIVE, la tabla de resultados del cursor es de sólo lectura y el valor de la opción de enlace CURRENTDATA es NO.
  • La tabla de resultados del cursor no es de sólo lectura, pero el cursor es ambiguo y el valor de la opción de enlace CURRENTDATA es NO.
    Un cursor es ambiguo cuando se cumple cualquiera de las siguientes condiciones:

    • No está definido con las cláusulas FOR FETCH ONLY, FOR READ ONLY o FOR UPDATE.
    • No está definido en una tabla de resultados de sólo lectura.
    • No es el destino de una cláusula WHERE CURRENT en una sentencia de SQL UPDATE o DELETE.
    • Está en un plan o paquete que contiene las sentencias de SQL PREPARE o EXECUTE IMMEDIATE.
• En el caso de aplicaciones ODBC y JDBC, utilice el parámetro rowset para limitar el número de filas que se devuelven de una operación de captación.
  Si un solicitante de DRDA envía el parámetro de conjunto de filas a un servidor de Db2 , el servidor realiza las siguientes acciones:

  • Devuelve no más del número de filas del parámetro rowset.
  • Devuelve bloques de consulta extra si el valor del campo EXTRA BLOCKS SRV del panel de instalación DISTRIBUTED DATA FACILITY PANEL 2 del servidor permite que se devuelvan bloques de consulta extra.
  • Procesa la cláusula FETCH FIRST n ROWS ONLY si se ha especificado.
  • No procesa la cláusula OPTIMIZE FOR n ROWS.
• Utilice los valores recomendados para determinadas opciones de enlace.
  Para obtener más información sobre las opciones de enlace recomendadas, consulte Opciones de ENLACE para aplicaciones distribuidas.