如何识别DB2中的有毒sql

Question

我们要求识别在数据库中触发的有毒查询，并杀死它们，这样应用程序就不会因为它而受到影响。例如，一个使用更多CPU的长时间运行的查询应该被终止。我做了一些研究，发现在DB2企业版中有一个叫做WLM的东西。此外，我已经与一些DBA讨论过，并理解了以下内容，其中一些参数可以从WLM (工作负载管理器)进行监视。

ESTIMATEDSQLCOST、ACTIVITYTOTALTIME、SQLTEMPSPACE、UOWTOTALTIME

虽然我在继续学习更多关于这些问题的知识，但是否有人可以提供一些帮助或分享一些专业知识，这些参数可以用来识别会影响其他操作的此类有毒查询。

Answer 1

这个问题有点笼统，但我可以就您可能感兴趣的几个场景给出一些指导：

“有毒”查询现在正在数据库中执行。

对于那些人，你可以使用MON_GET_ACTIVITY。它为您提供了数据库中所有活动的详细指标。糟糕的SQL通常可以通过以下几个方面来识别：-长执行时间(TOTAL_ACT_TIME) -读取的行数( ROWS_READ )很高，甚至更好，ROWS_READ与ROWS_RETURNED的比率(例如，我们希望SELECT *读取很多行，但它也会返回那么多行)-数据读取(POOL_DATA_L_READS)与索引读取(POOL_INDEX_L_READS)的比率很高，这通常表明查询可以从更好的索引中受益。

示例查询可能如下所示：

db2 "select local_start_time, application_handle, total_act_time, rows_read, rows_returned, pool_index_l_reads, pool_data_l_reads, substr(stmt_text,1,100) as stmt_text from table(mon_get_activity(null, -2)) where member=coord_partition_num order by total_act_time desc"

LOCAL_START_TIME    APP_HANDLE TOTAL_ACT_TIME  ROWS_READ    ROWS_RETURNED POOL_I_L_READS POOL_D_L_READS STMT_TEX
------------------- ---------- -------------- ----------    ------------- -------------- --------------- -------
2019-09-26-10.31.57    3640333       66633923      78863           629729             32               0 SELECT 
2019-09-26-10.31.57    2329627       66627534     225535           629729             32               0 SELECT 
2019-09-26-10.31.57    1019395       66613118      95760           629729             18               0 SELECT 
2019-09-26-10.31.57    3640332       66608933      32607           302242              4               0 SELECT 

(当然还有更多有趣的指标可用，我只是展示了几个)一旦确定了查询，就可以包含EXECUTABLE_ID列并使用EXPLAIN_FROM_SECTION生成解释。

过去已执行但仍在包缓存中的查询。

对于这些执行，您可以使用MON_GET_PKG_CACHE_STMT并使用与1中类似的计数器。请注意，此计数器包含所有执行的累积指标，因此您可能需要将数字除以NUM_EXECUTIONS

将来可能执行的查询

要缩小此类查询的范围，您可以使用CREATE THRESHOLD，并在特定查询超过特定阈值(SQLROWSREAD、ACTIVITYTOTALRUNTIME等)时，使Db2收集诊断信息(COLLECT ACTIVITY DATA)甚至访问计划(WITH DETAILS SECTION)。此外，您还可以自动中断此类查询(STOP EXECUTION)。