Mecanismo de seguimiento de tiempo de ejecución de SQL actual

InfoSphere Master Data Management Collaboration Server - Collaborative Edition proporciona una opción mediante el mecanismo log4j para realizar el seguimiento de sus SQL generados y el tiempo de ejecución de archivos de registro aparte. Existen dos valores de configuración distintos que afectan al comportamiento de anotaciones.

El nivel de anotaciones en el directorio $TOP/etc/default/log.xml.
El valor de prioridad del adicionador DB define en qué nivel de detalle se realiza un seguimiento de los SQL ejecutados y sus tiempos de ejecución en los archivos db.log en cada directorio de anotaciones de servicios de InfoSphere Master Data Management Collaboration Server - Collaborative Edition.
- Utilice la modalidad de depuración para realizar un seguimiento de todos los SQL
- Utilice niveles de anotaciones inferiores como informativo o aviso para realizar un seguimiento solo de las "consultas retrasadas"
Excerpt from $TOP/etc/default/log.xml: <category name="com.ibm.ccd.common.db" additivity="false"> <priority value="debug" /> <appender-ref ref="DB" /> </category>
Este valor se puede modificar en cualquier momento y InfoSphere Master Data Management Collaboration Server - Collaborative Edition lo aplicará sin necesidad de reiniciar.
Nota: Si se establece el valor de prioridad del adicionador de base de datos en depuración, esto podría afectar al rendimiento global debido a la sobrecarga de anotaciones, pero debe ser inferior al 5%.
El parámetro de common.properties profiling_query_delay_threshold.
Define un umbral de tiempo de ejecución, en el que las consultas se marcan como "consultas retrasadas".
profiling_query_delay_threshold= <milisegundos>
Sólo los SQL con tiempos de ejecución mayores al umbral definido se marcarán como consultas retrasadas y se realizará su seguimiento.

Se pueden distinguir dos tipos distintos de consultas en los archivos db.log.

Consultas estáticas: Este tipo de consulta lo identifica la palabra clave Static Query junto con un nombre y por lo tanto se puede distinguir de forma exclusiva, por ejemplo: Static Query [name: GET_DOC_STORE_REAL_FILES_WITH_ATTRIBUTE]
Consultas dinámicas: Este tipo de consulta se crea dinámicamente y el número de argumentos y la lista de parámetros variará. Se identifican mediante la palabra clave Dynamic Query, pero solo las puede distinguir el propio cuerpo de SQL. No obstante, es posible alguna agrupación general de las consultas dinámicas si se utilizan los primeros n caracteres como diferenciadores. Este mecanismo se utiliza en Programa de utilidad Sumall ($JAVA_RT com.ibm.ccd.common.wpcsupport.util.Sumall) cuando se utiliza la opción leng.

El siguiente archivo db.log de ejemplo muestra esto. Muestra:

una consulta estática GEN_SEC_CMP_COMPANY_GETBYID con un tiempo de ejecución de 1 milisegundo
una consulta dinámica con un tiempo de ejecución de 1146 milisegundos.

2011-04-06 08:15:03,916 [Thread-36] DEBUG com.ibm.ccd.common.db.Query - Time: (1 ms) Static Query [name: GEN_SEC_CMP_COMPANY_GETBYID] [id: 934] SELECT * FROM tsec_cmp_company WHERE cmp_company_id = 1 2011-04-06 08:49:10,818 [jsp_82: invoker.jsp] DEBUG com.ibm.ccd.common.db.Query - Time: (1146 ms) Dynamic Query [ SELECT itm_id, itm_primary_key, itm_version_id, itm_next_version_id, itm_status, itm_collab_info FROM tctg_itm_item WHERE (itm_id in (2818133)) AND itm_version_id <= 999999999 AND itm_next_version_id >= 999999999 AND itm_container_id = 12002 AND itm_company_id = 60001] 2011-04-06 08:49:10,818 [jsp_82: invoker.jsp] WARN com.ibm.ccd.common.db.Query - CWPCM0018W:The query is delayed: ( 1,146 ms)\n Dynamic Query [ SELECT itm_id, itm_primary_key, itm_version_id, itm_next_version_id, itm_status, itm_collab_info FROM tctg_itm_item WHERE (itm_id in (2818133)) AND itm_version_id <= 999999999 AND itm_next_version_id >= 999999999 AND itm_container_id = 12002 AND itm_company_id = 60001]

Atención:

Cuando se utiliza la modalidad de depuración para el adicionador de base de datos, considere establecer profiling_query_delay_threshold en un valor muy alto para evitar las anotaciones duplicadas de consultas lentas.
profiling_query_delay_threshold es un valor ambiguo. Se aplicará a todas las consultas, pero mientras que 50 milisegundos puede ser bastante lento para una consulta simple utilizada con mucha frecuencia, marcaría una consulta compleja como lenta, para la que es normal ejecutarse durante segundos.
Los tiempos de ejecución de los que se realiza un seguimiento en los archivos db.log no representan el tiempo que necesita la propia base de datos para completar el SQL, sino que en lugar de ello mide el periodo de tiempo entre la emisión de la consulta en el código de InfoSphere Master Data Management Collaboration Server - Collaborative Edition y el momento en que InfoSphere Master Data Management Collaboration Server - Collaborative Edition puede obtener el resultado.
Por lo tanto, en determinadas situaciones donde los servicios de InfoSphere Master Data Management Collaboration Server - Collaborative Edition no pueden obtener resultados de SQL devueltos con la rapidez suficiente (por ejemplo, cuelgues de hebras de JVM, tráfico de red retrasado entre el servicio de InfoSphere Master Data Management Collaboration Server - Collaborative Edition y el servidor de bases de datos), los tiempos de ejecución notificados podrían ser mucho mayores que el tiempo de ejecución real en la base de datos.

Al examinar los tiempos de ejecución anotados, tenga en cuenta las directrices siguientes:

una única consulta lenta o unas pocas podría no ser significativo, básese preferiblemente en el método estadístico (programa de utilidad Sumall ($JAVA_RT com.ibm.ccd.common.wpcsupport.util.Sumall)
observe si hay variaciones del tiempo de ejecución a lo largo del tiempo durante una única consulta (programa de utilidad Sumall ($JAVA_RT com.ibm.ccd.common.wpcsupport.util.Sumall)
en caso de duda, ejecute algunas de las consultas de ejecución lenta identificadas fuera de la conexión JDBC de InfoSphere Master Data Management Collaboration Server - Collaborative Edition, por ejemplo, ejecútelas mediante el procesador de línea de mandatos de DB2, sqlplus, respectivamente, y realice la prueba en ambos servidores, donde InfoSphere Master Data Management Collaboration Server - Collaborative Edition esté instalado y directamente en el servidor de bases de datos.

Última actualización: 11 Mar 2019