Query Patroller

Actualizaciones de definiciones para estados de consultas gestionadas

Los significados de los estados de consulta 8Cancelada y Realizada 8se han actualizado como se indica a continuación:

8

Cancelada

8

La consulta la ha cancelado, utilizando Query Patroller Center o la 8línea de mandatos de Query Patroller, el administrador, el emisor o un 8operador cuyo perfil tiene el privilegio MONITORING con autorización de edición. Sólo 8pueden ser canceladas las consultas 8en ejecución, 8retenidas, liberadas 8y en cola. 8

8

Realizada

8

La consulta se ha completado satisfactoriamente. 8 8

Nota:

8

Aunque 8la consulta se haya completado sin ningún error, la aplicación puede recibir un 8error si la finalización la ha causado un suceso externo como, por ejemplo, 8una aplicación force de DB2.

8

8

Creación de tablas de explicación antes de ejecutar el generador de datos históricos de Query Patroller

Cuando se ejecuta el generador de datos históricos para Query Patroller, si las tablas 5de explicación aún no existen, el generador las creará. Sin embargo, es muy 5recomendable crear las tablas de explicación antes de ejecutar el generador de 5datos históricos. Al crear las tablas de explicación, asegúrese de crearlas en 5la misma partición. La creación de las tablas de explicación en la misma 5partición mejora el rendimiento del recurso Explain. Esta mejora aumenta el 5rendimiento del generador de datos históricos.

Comprobación de los archivos de anotaciones cronológicas de Query 5Patroller para el análisis histórico

Si la columna Explain Run del informe Query Activity 5over Time (Historical Analysis) muestra un estado Ran unsuccessfully (Ejecución no satisfactoria), los datos históricos no se habrán generado 5para esta consulta. Por lo tanto, la consulta no aparecerá en ningún informe o gráfico 5de análisis histórico. Como ya se documentó en la Versión 8, para determinar 5por qué la consulta no ha sido satisfactoria, puede examinar el archivo qpuser.log.

Además de examinar el archivo qpuser.log, debería examinar también el archivo 5qpdiag.log.

Conclusión anormal del generador de datos históricos

Si ejecuta el generador de datos históricos y lo concluye de forma anormal, 6recibirá un error la próxima vez que intente ejecutar el generador de datos históricos. Ejemplos de conclusión anormal son:

6
• DB2 Universal Database se detiene inesperadamente
6
• Emisión de un mandato db2stop force
6
• Emisión de un mandato killdb2

Cuando el generador de datos históricos concluya anormalmente, debe emitir el 6mandato siguiente antes de intentar ejecutarlo de nuevo:

    qp -d basedatos generate historical_data stop

donde basedatos identifica la base de 6datos para la que se ejecuta el mandato.

Actualizaciones de clases de consultas dinámicas

Ciertas operaciones con clases de consultas ya no requieren que Query 6Patroller se detenga y reinicie para ser efectivas.

En la tabla que sigue, una consulta activa es una consulta cuyo estado es 6En ejecución o En cola.

Comportamiento de las consultas anidadas

Las consultas anidadas no pueden colocarse en cola. En lugar de ello, 6una consulta anidada se ejecutará inmediatamente si sobrepasa un umbral que, 6normalmente, causaría su colocación en cola.

Limitaciones por el tipo de sentencia de SQL

Al contrario de lo indicado en la documentación anterior, las consultas con 6las sentencias siguientes pueden colocarse en cola:

6
• Consultas que contienen SQL estático con variables del lenguaje 6principal
6
• Consultas que contienen una función de valor de identidad 6(IDENTITY_VAL_LOCAL) o una función de valor de secuencia, como, por ejemplo, 6NEXT VALUE FOR o PREVIOUS VALUE FOR

Limitación en la resolución cuando se utiliza el Cliente de servicios de terminal

Cuando se utiliza el Cliente de servicios de terminal a una resolución de 640x480 para conectar con un 7escritorio remoto 7que ejecuta Query Patroller Center, es posible que la ventana Preferencias de emisión aparezca en blanco. Para que la ventana Preferencias de emisión se visualice correctamente, 7debe tener una resolución mayor que 640x480.

Soporte de nuevos grupos para las emisiones de consultas

A partir de la Versión 8.2, 7DB2 Universal Database (UDB) da soporte a grupos 7de usuarios además de grupos de sistemas operativos. Por lo tanto, hay un 7pequeño cambio en la lista desplegable Submitter Profile to Use (Perfil de emisor a utilizar) de la ventana Query 7Submission Preferences (Preferencias de emisión de consultas) de Query 7Patroller Center.

Si está conectado pero no tiene autorización DBADM o privilegio de edición para 7la administración de usuarios de Query Patroller, sólo puede añadir o 7actualizar una preferencia de emisión para usted mismo. En este caso, la lista 7desplegable Submitter Profile to Use 7(Perfil de emisor a utilizar) contiene perfiles de emisor existentes de grupos 7de DB2 UDB a los que pertenece, en lugar de contener únicamente los grupos de 7sistemas operativos a los que pertenece.

Si está conectado y tiene autorización DBADM o de edición para la administración de 7usuarios de Query Patroller, puede añadir o actualizar preferencias de emisión 7para otros usuarios. En este caso, la lista desplegable Submitter Profile to Use (Perfil de emisor a utilizar) contiene todos los 7perfiles de emisores de grupos existentes.

Limitaciones de planificación de Query Patroller

Cuando trabaje con planificaciones en Query Patroller Center, puede utilizar 7la ventana Schedule (Planificar) para guardar planificaciones en un archivo e 7importarlas más adelante. Si tiene una planificación guardada con FixPak 6 o 7anterior, no puede importar la planificación con la Versión 8.2 o posterior. Esta 7limitación se debe al cambio en la serialización entre los niveles de JDK que 7se ha incorporado en DB2 UDB Versión 8.2.

Autorización necesaria para utilizar el mandato RUN IN BACKGROUND QUERY

Para ejecutar el mandato RUN IN BACKGROUND QUERY, debe ser el emisor que ha emitido la consulta original.

Creación de un alias para una tabla de resultados

Desde Query Patroller Versión 8.1 FixPak 5, Query Patroller ha dejado de crear tablas de resultados 7en el esquema que coincidían con el ID de autorización del emisor de la consulta. En su lugar, Query Patroller ha empezado a crear tablas de resultados en un esquema 7DB2QPRT común. Para permitir que se haga referencia a tablas de resultados utilizando 7el esquema del emisor, 7Query Patroller Versión 8.2 incorpora una opción para crear automáticamente un alias para cada nueva 7tabla de resultados creada por 7Query Patroller. La tabla de resultados se crea en 7el esquema DB2QPRT y el alias se crea en un esquema que coincide con el ID de autorización del emisor.

Para activar o desactivar esta opción, emita el mandato UPDATE QP_SYSTEM con la opción 7CREATE_RESULT_TABLE_ALIASES:

7>>-UPDATE QP_SYSTEM USING--------------------------------------->
7
7>--+-DEFAULT------------------------------+--------------------><
7   '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
7                                  '-'N'-'
7

Eliminación de alias de tablas de resultados huérfanos

Los alias creados con la opción CREATE_RESULT_TABLE_ALIASES se eliminan automáticamente cuando 7se elimina una tabla de resultados. Sin embargo, hay dos situaciones en las que se puede eliminar una tabla de resultados sin que se elimine 7el alias correspondiente.

7
• Cuando la tabla de resultados se elimina de forma manual sin utilizar la línea de mandatos qp ni 7Query Patroller Center.
7
• Cuando la tabla de resultados se elimina mediante la línea de mandatos qp 7o Query Patroller Center bajo la autorización de un operador que no es el emisor de la consulta 7y no tiene autorización 7DBADM.

Para limpiar los alias que no tienen tablas de resultados correspondientes, se ha creado un nuevo mandato, 7REMOVE RESULT_TABLE_ALIASES. Este mandato se ejecuta automáticamente cuando se depuran 7tablas de resultados como parte del proceso planificado de depuración de tablas 7de resultados de Query Patroller. El mandato REMOVE RESULT_TABLE_ALIASES muestra la lista de alias que hay que depurar utilizando la siguiente consulta:

7with a as (select tabschema, tabname from syscat.tables 
7           where type = 'A' and tabname like 'QUERY%_RESULTS'), 
7     t as (select tabname from syscat.tables 
7           where type = 'T' and tabname like 'QUERY%_RESULTS')
7  select all tabschema, tabname from a 
7  where not exists (select * from t where t.tabname=a.tabname)

7>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
7

El ID de usuario delimitado requiere acceso de grabación para el archivo 8qpdiag.log y su vía de acceso

Query Patroller utiliza algunos procedimientos almacenados delimitados que 8pueden anotar entradas en el archivo qpdiag.log. Por lo tanto, el ID de usuario 8delimitado debe tener acceso para grabar en el archivo qpdiag.log y la 8vía en la que reside el archivo qpdiag.log.