Los significados de los estados de consulta 8Cancelada y Realizada 8se han actualizado como se indica a continuación:
8Cuando 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.
5 5 5Si 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.
5Además de examinar el archivo qpuser.log, debería examinar también el archivo 5qpdiag.log.
6 6 6Si 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:
6Cuando el generador de datos históricos concluya anormalmente, debe emitir el 6mandato siguiente antes de intentar ejecutarlo de nuevo:
6 qp -d basedatos generate historical_data stop
donde basedatos identifica la base de 6datos para la que se ejecuta el mandato.
6 6 6Ciertas operaciones con clases de consultas ya no requieren que Query 6Patroller se detenga y reinicie para ser efectivas.
6En la tabla que sigue, una consulta activa es una consulta cuyo estado es 6En ejecución o En cola.
6 66 6 6Las 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.
6 6 6Al contrario de lo indicado en la documentación anterior, las consultas con 6las sentencias siguientes pueden colocarse en cola:
6Cuando 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.
7 7 7A 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.
7Si 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.
7Si 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.
7 7 7Cuando 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.
7 7 7Para ejecutar el mandato RUN IN BACKGROUND QUERY, debe ser el emisor que ha emitido la consulta original.
7 7 7Desde 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.
7Para activar o desactivar esta opción, emita el mandato UPDATE QP_SYSTEM con la opción 7CREATE_RESULT_TABLE_ALIASES:
7 77 7 77>>-UPDATE QP_SYSTEM USING---------------------------------------> 7 7>--+-DEFAULT------------------------------+-------------------->< 7 '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-' 7 '-'N'-' 7
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.
7Para 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:
77with 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
Debe tener autorización DBADM.
Este mandato elimina todos los alias existentes después de que se hayan eliminado sus tablas 7de resultados correspondientes. Los alias se crearon originalmente mediante Query Patroller 7para tablas de resultados.
77>>-REMOVE RESULT_TABLE_ALIASES--------------------------------->< 7
7
7 7Query 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.
[ Principio de página |Página anterior | Página siguiente | Contenido ]