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:
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.
Los significados de los estados de consulta Cancelada y Realizada se han actualizado como se indica a continuación:
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.
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.
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:
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.
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.
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.
Al contrario de lo indicado en la documentación anterior, las consultas con las sentencias siguientes pueden colocarse en cola:
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.
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.
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.
Para ejecutar el mandato RUN IN BACKGROUND QUERY, debe ser el emisor que ha emitido la consulta original.
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'-'
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.
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)
Debe tener autorización DBADM.
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.
>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
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 ]