Query Patroller

Actualización del funcionamiento de clase de consulta

Se devuelve un mensaje de aviso cuando se realiza una de las siguientes tareas a través de Query Patroller Center o de la línea de mandatos de Query Patroller:

Adición de una clase de consulta
Eliminación de una clase de consulta
Actualización del coste máximo de una consulta para una clase de consulta

El mensaje de aviso es:

DQP1024W  La creación, cambio o eliminación de una clase de consulta 
          no tendrá lugar hasta que se reinicie el servidor de Query Patroller.

Similarmente, el manual DB2 Query Patroller^(TM) Guide: Installation, Administration, and Usage, Versión 8.2, indica que debe reiniciar el servidor de Query Patroller después de crear, cambiar o eliminar clases de consulta para que los cambios entren en vigor.

El mensaje y la sentencia incluidas en el manual ya no son exactas. Las tres tareas de clase de consulta listadas anteriormente entrarán en vigor inmediatamente a menos que haya consultas en cola o en ejecución. Si hay consultas en cola o en ejecución, incluidas las consultas enviadas recientemente, los cambios de la clase de consulta entrarán en vigor cuando las consultas en cola o en ejecución se completen. Si no desea esperar a que todas las consultas en cola o en ejecución se completen, deberá reiniciar el servidor de Query Patroller.

Nota:

Al igual que con las versiones anteriores de Query Patroller, la actualización del número máximo de consultas para una clase de consulta entrará en vigor de forma inmediata.

Actualizaciones de definiciones para estados de consultas gestionadas

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

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

Aunque la consulta en sí misma se haya completado sin errores, la aplicación puede recibir uno si la finalización se ha debido a un suceso externo, como por ejemplo, una aplicación force de DB2.

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 de explicación aún no existen, el generador las creará. Sin embargo, es muy recomendable crear las tablas de explicación antes de ejecutar el generador de datos históricos. Al crear las tablas de explicación, asegúrese de crearlas en la misma partición. La creación de las tablas de explicación en la misma partición mejora el rendimiento del recurso Explain. Esta mejora aumenta el rendimiento del generador de datos históricos.

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

Si la columna Explain Run del informe Query Activity over Time (Historical Analysis) muestra un estado Ran unsuccessfully (Ejecución no satisfactoria), los datos históricos no se habrán generado para esta consulta. Por lo tanto, la consulta no aparecerá en ningún informe o gráfico de análisis histórico. Como ya se documentó en la Versión 8, para determinar por 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 qpdiag.log.

Conclusión anormal del generador de datos históricos

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

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

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

    qp -d basedatos generate historical_data stop

donde basedatos identifica la base de datos 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 Patroller se detenga y reinicie para ser efectivas.

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

Tabla 38. Condiciones para que los cambios en las clases de consultas sean efectivos
Naturaleza del cambio	Condiciones para que el cambio sea efectivo
Adición, eliminación o actualización de una clase de consulta.	Si no hay consultas activas, los cambios son efectivos inmediatamente.
Una actualización de una clase de consulta que implica solamente un cambio en el Número máximo de consultas.	Es efectiva inmediatamente, aunque haya consultas activas.
Una actualización de una clase de consulta que implica solamente un cambio en el Coste máximo de una consulta.	Si hay consultas activas, la actualización es efectiva en uno de estos casos: Query Patroller se detiene y reinicia. No hay más consultas activas. Nota: Cuando exista un cambio pendiente para Coste máximo de una consulta, las actualizaciones de clases de consultas subsiguientes de cualquier tipo no serán efectivas hasta que se cumpla una de las dos condiciones anteriores.
Adición o eliminación de una clase de consulta.	Si hay consultas activas, la adición o eliminación es efectiva en uno de estos casos: Query Patroller se detiene y reinicia. No hay más consultas activas.

Comportamiento de las consultas anidadas

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

Limitaciones según el tipo de sentencia de SQL

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

Consultas que contienen SQL estático con variables del lenguaje principal
Consultas que contienen una función de valor de identidad (IDENTITY_VAL_LOCAL) o una función de valor de secuencia, como, por ejemplo, NEXT 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 escritorio remoto que 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, debe tener una resolución mayor que 640x480.

Soporte de nuevos grupos para las emisiones de consultas

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

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

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

Limitaciones de planificación de Query Patroller

Cuando trabaje con planificaciones en Query Patroller Center, puede utilizar la ventana Schedule (Planificar) para guardar planificaciones en un archivo e importarlas más adelante. Si tiene una planificación guardada con FixPak 6 o anterior, no puede importar la planificación con la Versión 8.2 o posterior. Esta limitación se debe al cambio en la serialización entre los niveles de JDK que se 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 en 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 DB2QPRT común. Para permitir que se haga referencia a tablas de resultados utilizando el esquema del emisor, Query Patroller Versión 8.2 incorpora una opción para crear automáticamente un alias para cada nueva tabla de resultados creada por Query Patroller. La tabla de resultados se crea en el 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 CREATE_RESULT_TABLE_ALIASES:

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

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 se elimina una tabla de resultados. Sin embargo, hay dos situaciones en las que se puede eliminar una tabla de resultados sin que se elimine el alias correspondiente.

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

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

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

Requisitos previos

Debe tener autorización DBADM.

Procedimiento

Emita el mandato REMOVE RESULT_TABLE_ALIASES

Este mandato elimina todos los alias existentes después de que se hayan eliminado sus tablas de resultados correspondientes. Los alias se crearon originalmente mediante Query Patroller para tablas de resultados.

Sintaxis del mandato

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

Nota:

Para obtener información sobre cómo especificar mandatos de Query Patroller utilizando la interfaz de línea de mandatos y para ver la sintaxis general de los mandatos de Query Patroller, consulte la interfaz de línea de mandatos de Query Patroller.

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

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

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