Rendimiento de consultas para sentencias SQL comunes

Se han realizado una serie de mejoras de rendimiento para mejorar la velocidad de muchas consultas. Estas mejoras son automáticas. No hay valores de configuración ni cambios en las sentencias SQL necesarias.

Diferenciación anticipada parcial (PED)

Ahora, se utilizará una función hash eficiente para eliminar parcialmente los duplicados al principio del proceso de consulta. Es posible que no elimine todos los duplicados, pero reducirá la cantidad de datos que deberán procesarse más tarde en la evaluación de la consulta. Eliminar algunas de las filas duplicadas iniciales acelerará la consulta y reducirá la posibilidad de que ésta se quede sin memoria de almacenamiento dinámico de clasificación, lo que elimina la necesidad de utilizar el espacio en disco relativamente lento para el almacenamiento temporal. Esta mejora se denomina diferenciación anticipada parcial (PED).

Para determinar si esta mejora se utiliza para una consulta determinada, active el recurso Explain y ejecute la consulta. Un nuevo valor en la tabla EXPLAIN_ARGUMENT indica cuándo se ha aplicado esta nueva funcionalidad en una consulta:
  • Columna ARGUMENT_TYPE = UNIQUE
  • La columna ARGUMENT_VALUE ahora también puede tener el valor: HASHED PARTIAL que indica que se ha utilizado la nueva característica
La herramienta db2exfmt también mostrará HASHED PARTIAL en la salida, tal como se muestra en el siguiente ejemplo:
6) UNIQUE: (Unique)
      Cumulative Total Cost: 		132.519
      Cumulative CPU Cost: 		1.98997e+06
      ...
      ...
      Arguments:
      ---------
      JN INPUT: (Join input leg)
            INNER
      UNIQKEY : (Unique Key columns)
            1: Q1.C22
      UNIQKEY : (Unique Key columns)
            2: Q1.C21
      pUNIQUE  : (Uniqueness required flag)
            HASHED PARTIAL

Agregación anticipada parcial (PEA)

Similar a la diferenciación anticipada parcial (PED), la agregación anticipada parcial (PEA) es un intento de realizar una agregación parcial de datos anticipada en el proceso de la consulta. Aunque es poco probable que toda la agregación tenga lugar en este punto, como mínimo reducirá la cantidad de datos que deberán procesarse posteriormente en la evaluación de la consulta.

Para determinar si está utilizándose la agregación anticipada parcial para una consulta en particular, active el recurso Explain y ejecute la consulta. Un nuevo valor en la tabla EXPLAIN_ARGUMENT indica cuándo se ha aplicado esta nueva funcionalidad en una consulta:
  • Columna ARGUMENT_TYPE = AGGMODE
  • La columna ARGUMENT_VALUE ahora también puede tener el valor: HASHED PARTIAL que indica que se ha utilizado esta nueva característica
La herramienta db2exfmt también mostrará HASHED PARTIAL en su salida para las secciones GRPBY , junto con un pGRPBY en la vista de árbol, si esta nueva funcionalidad se ha aplicado dentro de esa parte de la consulta.

Ahora el optimizador de consultas selecciona la unión hash para una selección más amplia de consultas de SQL

El optimizador de consultas selecciona entre tres estrategias de unión básicas al determinar cómo ha de ejecutarse una consulta de SQL que incluye una unión. En la mayoría de los casos, la unión hash es el método más eficiente, y con este release puede utilizarse en más situaciones.
Discrepancias en el tipo de datos
Ahora, se considerará una unión hash, aunque las dos columnas de la unión no sean del mismo tipo. Este será el caso general, excepto en las situaciones más extremas.
Expresiones utilizadas en el predicado de unión
Los predicados de unión que contienen una expresión ya no restringen el método de unión a una unión de bucle anidado. En este release, se considera una unión hash en aquellos casos en los que la cláusula WHERE contiene una expresión, como: WHERE T1.C1 = UPPER(T1.C3)
En estos casos, la unión hash se considera automáticamente. No es necesario cambiar ninguna consulta de SQL existente para poder beneficiarse de esta funcionalidad mejorada. Tenga en cuenta que las uniones hash utilizan la memoria de almacenamiento dinámico de clasificación.

Estimaciones de coste mejoradas del tráfico de comunicación de la red que una consulta genera

El optimizador de consultas utiliza información diversa para seleccionar un plan de acceso que sea lo más eficiente posible. Los costes de comunicación estimados de las consultas ahora se han mejorado, lo que permite al optimizador considerar y comparar con más precisión todos los costes de CPU, de E/S y de comunicación. En la mayoría de los casos, esto dará como resultado un rendimiento de la consulta más rápido.

Los costes estimados de comunicación por nodo de una consulta, que devuelven los elementos Explain COMM_COST y FIRST_COMM_COST, se han mejorado. Ahora son más coherentes con los cálculos por nodo de los costes de CPU y de E/S. Esto permite al optimizador de consultas equilibrar con eficiencia estas tres estimaciones de costes al evaluar distintos planes de acceso. También contribuye a incrementar el paralelismo cuando es posible, pues permite que el tráfico de la red se distribuya de forma más equitativa en varios adaptadores de red. En concreto:
  • Si interviene más de un adaptador de red, se devuelve el coste de comunicación acumulado para el adaptador con un valor más alto. En los releases anteriores se devolvía el número total de tramas transmitidas por toda la red.
  • Los valores sólo incluyen los costes de tráfico de red entre máquinas físicas. No incluyen los costes de comunicación virtual entre particiones de nodo en la misma máquina física en un entorno de base de datos particionada.