Notas del release


10.5 Variables de registro y de entorno de DB2

10.5.1 Correcciones a variables relativas al rendimiento


Tabla 5. Variables relativas al rendimiento

Nombre de variable Sistema operativo Valores
Descripción
DB2_BINSORT Todos Valor por omisión=NO

Valores: YES o NO

Permite un nuevo algoritmo de clasificación que reduce el tiempo de CPU y el tiempo transcurrido de las clasificaciones. Este nuevo algoritmo amplía la técnica de clasificación de enteros extremadamente eficiente de DB2 UDB a toda clase de tipos de datos, por ejemplo BIGINT, CHAR, VARCHAR, FLOAT y DECIMAL, así como a combinaciones de estos tipos de datos. Para habilitar este nuevo algoritmo, utilice el mandato siguiente:
db2set DB2_BINSORT = yes
DB2_BLOCK_BASED_BP
Entorno operativo Solaris Valor por omisión=None

Valores: según los parámetros

Especifica los valores necesarios para crear un área de bloques en una agrupación de almacenamientos intermedios. El ID de la agrupación de almacenamientos intermedios es necesario y se puede ver en la columna BUFFERPOOLID o en la vista de catálogos del sistema SYSCAT.BUFFERPOOLS. Se debe indicar el número de páginas que se asignarán a la E/S basada en bloques en la agrupación de almacenamientos intermedios. El número de páginas a incluir en un bloque es opcional, con un valor por omisión de 32.

El formato para usar esta variable de registro es:

DB2_BLOCK_BASED_BP=BUFFER POOL ID,BLOCK AREA SIZE,[BLOCK SIZE];...

Es posible definir varias agrupaciones de almacenamientos intermedios como basadas en bloques mediante la utilización de la misma variable, con un signo de punto y coma para separar las entradas.

El valor de BLOCK SIZE puede ir de 2 a 256. Si no se especifica BLOCK SIZE, el valor por omisión utilizado es 32.

Si el BLOCK AREA SIZE especificado es mayor que el 98% del tamaño total de la agrupación de almacenamientos intermedios, la agrupación no se creará basada en bloques. Es buena práctica disponer siempre de una porción de la agrupación de almacenamientos intermedios en el área basada en páginas, puesto que existe la posibilidad de que se necesiten páginas individuales aunque la mayor parte de la E/S del sistema se realice con captación previa secuencial. Si el valor especificado para BLOCK AREA SIZE no es múltiplo de BLOCK SIZE, se reduce al próximo límite del tamaño de bloque. Para obtener más información sobre la E/S basada en bloques, consulte el apartado 10.2.1, Agrupación de almacenamientos intermedios basada en bloques.

DB2_NO_FORK_CHECK
UNIX Valor por omisión=OFF

Valores: ON u OFF

Cuando esta variable sea "ON", el proceso del cliente no se protegerá a sí mismo frente al hecho de que una aplicación cree una copia del proceso que se debe ejecutar (se denomina creación y arranque de otro proceso). Cuando tienen lugar la creación y el arranque de otro proceso (la acción de fork), los resultados son imprevisibles. El rango de los resultados puede ir desde la ausencia de efectos a algún resultado anómalo, a la devolución de algún código de error o a una ruptura en la aplicación. Si está seguro de que la aplicación no efectuará un fork y desea un mejor rendimiento, debe cambiar el valor de esta variable por el valor "ON".
DB2_MINIMIZE_LIST_PREFETCH Todos Valor por omisión=NO

Valores: YES o NO

La captación previa de lista es un método de acceso a tabla especial que incluye la recuperación de los RID de calificación del índice, clasificándolos por número de página y luego captando previamente las páginas de datos.

A veces, el optimizador no tiene información precisa para determinar si la captación previa de lista es un buen método de acceso. Esto puede producirse cuando las selectividades de predicado contienen marcadores de parámetro o variables de sistema principal que impiden al optimizador utilizar estadísticas de catálogo para determinar la selectividad.

Esta variable de registro impedirá al optimizador tener en cuenta la captación previa de lista en estas situaciones.

DB2_INLIST_TO_NLJN Todos Valor por omisión=NO

Valores: YES o NO

En algunas situaciones, el compilador SQL puede volver a escribir un predicado de lista IN en una unión. Por ejemplo, la consulta siguiente:
    SELECT *
     FROM EMPLOYEE
     WHERE DEPTNO IN ('D11', 'D21', 'E21')
	  
puede escribirse como:
    SELECT *
     FROM EMPLOYEE, (VALUES 'D11', 'D21', 'E21) AS V(DNO)
     WHERE DEPTNO = V.DNO
	  

Esta revisión puede proporcionar un rendimiento mejor si hay índice en DEPTNO. Primero se deberá acceder a la lista de valores y ésta deberá unirse a EMPLOYEE con una unión de bucle anidada utilizando el índice para aplicar el predicado de unión.

A veces el optimizador no tiene información precisa para determinar el mejor método de unión para la versión reescrita de la consulta. Esto puede producirse si la lista IN contiene marcadores de parámetro o variables de sistema principal que impiden al optimizador utilizar estadísticas de catálogo para determinar la selectividad. Esta variable de registro hará que el optimizador favorezca las uniones de bucle anidadas para unir la lista de valores, utilizando la tabla que contribuye en la lista IN como la tabla interna de la unión.

10.5.2 Nuevos parámetros para la variable de registro DB2BPVARS

La variable de registro DB2BPVARS da soporte a dos nuevos parámetros: NUMPREFETCHQUEUES y PREFETCHQUEUESIZE. Estos parámetros son aplicables a todas las plataformas y pueden utilizarse para mejorar la captación previa de datos de una agrupación de almacenamientos intermedios. Por ejemplo, tome en consideración una captación previa secuencial en la que el parámetro PREFETCHSIZE deseado se divide en peticiones de captación previa de PREFETCHSIZE/EXTENTSIZE. En este caso, las peticiones se colocan en colas de captación previa desde las que se despachan servidores de E/S para realizar E/S asíncrona. Por omisión, DB2 mantiene una sola cola de tamaño max( 100 , 2*NUM_IOSERVERS ) para cada partición de base de datos. En algunos entornos, el rendimiento mejora con más colas y/o colas de diferente tamaño. El número correspondiente a las colas de captación previa debería ser, como máximo, la mitad del número correspondiente a los servidores de E/S. Cuando establezca estos parámetros, tome en consideración otros como PREFETCHSIZE, EXTENTSIZE, NUM_IOSERVERS, el tamaño de agrupación de almacenamientos intermedios y DB2_BLOCK_BASED_BP, así como características de la carga de trabajo, tales como el número de usuarios actuales.

Si piensa que los valores por omisión son demasiado bajos para su entorno, primero aumente los valores sólo en pequeña medida. Por ejemplo, puede establecer NUMPREFETCHQUEUES=4 y PREFETCHQUEUESIZE=200. Realice los cambios en estos parámetros de manera controlada a fin de poder supervisar y evaluar los efectos del cambio.

Tabla 6. Resumen de los nuevos parámetros

Nombre de parámetro Valor por omisión Rango válido
NUMPREFETCHQUEUES 1 De 1 a NUM_IOSERVERS

si se establece como inferior a 1, se ajusta a 1

si se establece como superior a NUM_IOSERVERS, se ajusta a NUM_IOSERVERS

PREFETCHQUEUESIZE max(100,2*NUM_IOSERVERS) De 1 a 32767

si se establece como inferior a 1, se ajusta al valor por omisión

si se establece como superior a 32767, se ajusta a 32767

10.5.3 Correcciones y adiciones a variables de registro diversas

La variable de registro DB2_NEWLOGPATH2 está disponible para todos los sistemas operativos. Se ha incorporado una nueva variable, DB2_ROLLFORWARD_NORETRIEVE. A continuación, aparece la información correcta sobre ambas variables.

Tabla 7. Variables diversas

Nombre de variable Sistema operativo Valores
Descripción
DB2_NEWLOGPATH2 TODOS Valor por omisión=NO

Valores: YES o NO

Este parámetro le permite especificar si se debe utilizar una vía de acceso secundaria para implementar la anotación cronológica dual. La vía de acceso utilizada se genera añadiendo un "2" al valor actual del parámetro de configuración de base de datos logpath.
DB2_ROLLFORWARD_NORETRIEVE
TODOS Valor por omisión=(no establecido)

Valores: YES o NO

Si se habilita el parámetro de configuración de base de datos USEREXIT, se recuperan automáticamente archivos de anotaciones cronológicas del archivo de archivar durante las operaciones de recuperación en avance. La variable DB2_ROLLFORWARD_NORETRIEVE permite especificar que las operaciones de recuperación en avance no recuperen archivos de anotaciones cronológicas del archivo de archivar. Esta variable está inhabilitada por omisión. Establezca esta variable en YES si no desea que la recuperación en avance recupere archivos de anotaciones cronológicas automáticamente. Por ejemplo, establezca la variable en YES en una configuración en espera activa cuando desee impedir que registros cronológicos creados por una aplicación con anomalías corrompan el sistema de copia de seguridad.

10.5.4 Correcciones y adiciones a variables de registro generales

Se ha incorporado una nueva variable, DB2_REDUCED_OPTIMIZATION.

Tabla 8. Variable de registro general

Nombre de variable Sistema operativo Valores
Descripción
DB2_REDUCED_OPTIMIZATION TODOS Valor por omisión=NO

Valores: YES, NO o cualquier entero

Esta variable de registro le permite inhabilitar algunas de las técnicas de optimización utilizadas en niveles de optimización específicos. Si reduce el número de técnicas de optimización utilizadas, también reducirá el tiempo y la utilización de recursos durante la optimización.
Nota:
Aunque se pueden reducir el tiempo de optimización y la utilización de recursos, aumenta el riesgo de generar un plan de acceso a los datos menos mejorado.
  • Si se establece en NO

    El optimizador no cambia sus técnicas de optimización.

  • Si se establece en YES

    Si el nivel de optimización es 5 (el valor por omisión) o menos, el optimizador inhabilita algunas técnicas de optimización que pueden consumir tiempo de preparación y recursos significativos, pero que normalmente no generan un plan de acceso mejor.

    Si el nivel de optimización es exactamente 5, el optimizador recorta el número de técnicas adicionales o inhabilita algunas de ellas, de tal forma que se pueden reducir más el tiempo de optimización y la utilización de recursos pero también aumentará en mayor medida el riesgo de un plan de acceso menos mejorado. Para los niveles de optimización inferiores al 5, algunas de estas técnicas pueden no tener efecto en ningún caso. No obstante, si están presentes, permanecen en la práctica.

  • Si se establece en cualquier entero

    El efecto es el mismo que si el valor se establece en YES, con el siguiente comportamiento adicional para las consultas preparadas dinámicamente cuya optimización es de nivel 5: Si el número total de uniones en cualquier bloque de consulta sobrepasa el valor, el optimizador conmuta a la enumeración escasa de uniones en lugar de inhabilitar técnicas de optimización adicionales tal como se ha descrito antes respecto al nivel de optimización 5, lo que implica que la consulta se optimizará a un nivel similar al nivel de optimización 2.

    A fin de obtener información sobre la enumeración de uniones escasa y dinámica, consulte la sección acerca de las estrategias de búsqueda para la selección de la unión óptima, en el manual Administration Guide: Performance.

Tenga en cuenta que la reducción de la optimización dinámica en el nivel de optimización 5, descrita en la sección sobre el ajuste de la clase de optimización en el manual Guía de administración: Rendimiento, toma preferencia sobre el comportamiento descrito para el nivel de optimización de exactamente 5 cuando DB2_REDUCED_OPTIMIZATION se establece en YES, así como sobre el comportamiento descrito para el valor entero.


[ Principio de página | Página anterior | Página siguiente | Contenido | Índice ]