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. |
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 |
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.
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.
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. |