Как определить токсичные SQL в DB2

Question

У нас есть запрос, чтобы определить токсичные запросы, которые запускаются в базе данных, и уничтожить их, чтобы приложение не пострадало из-за этого.Например, длительный запрос, который использует больше ЦП, должен быть убитЯ провел некоторое исследование и обнаружил, что в корпоративной версии DB2 доступно нечто, называемое WLM.Кроме того, мы обсудили с несколькими администраторами баз данных и поняли ниже, что некоторые параметры можно отслеживать из WLM (Workload Manager).

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 и заставить Db2 собирать диагностические (COLLECT ACTIVITY DATA) или даже планы доступа (WITH DETAILS SECTION), когда конкретный запрос превышает определенный порог (SQLROWSREAD, ACTIVITYTOTALRUNTIME и т. Д.).Более того, вы можете автоматически прерывать такие запросы (STOP EXECUTION).