Я не администратор баз данных и очень новичок, когда дело касается DB2, поэтому на этот вопрос приветствуются даже «очевидные» ответы:
Мне нравится db2top, но иногда мне не удается запустить его, если средняя загрузка db2 LUW высока.
Этим утром я столкнулся с проблемой, из-за которой средняя нагрузка внезапно выросла, я не мог запустить db2top, и мне нужно было выяснить, что происходит.
Что я могу сделать, чтобы узнать, кто чем занимается в этой ситуации? Я подозревал, что кто-то выполняет ужасно плохой запрос ... есть ли хороший способ найти информацию о неэффективном SQL на лету в такой ситуации?
Есть ли какие-либо хорошие способы собрать хорошую, действенную статистику, откуда / откуда приходит плохой sql в случае, если средняя загрузка настолько высока? Я знаю о db2pd, но не уверен, как его эффективно использовать, и просмотр десятков тысяч строк необработанных данных, вероятно, не самый эффективный способ разобраться в сути проблемы.
Какие-нибудь советы или ресурсы?
Я тоже не специалист по DB2. Но мой добрый фу силен. В поисках
force db2 LUW long running query
Находит ТОННЫ отличных данных, включая ту, которая выглядит именно так, как вы хотите, хорошо написанное руководство о том, как учиться:
http://www.dbisoftware.com/blog/db2_performance.php?id=122
Они также продают какое-то безумно завышенное программное обеспечение, которое делает то же самое за вас. Вот самые пикантные моменты:
db2 "list applications show detail"
Это даст вам подсказку о том, какие соединения в настоящее время выполняются, и есть ли несколько соединений в состоянии ожидания блокировки.
Если вы наблюдаете ожидания блокировок, вам следует глубже изучить конфликт блокировок с помощью команды:
db2 "get snapshot for locks on DBNAME"
Этот подробный отчет покажет вам, какие соединения приложений удерживают блокировки, а какие ждут. Ситуация усугубляется тем, что на некоторых из ожидающих соединений могут быть другие соединения. Настоящий эффект снежного кома может возникнуть, если для параметра LOCKTIMEOUT установлено значение -1 (бесконечность, никогда не истекает время ожидания) или установлено значение более 30 секунд.
В случае конфликта блокировок ваше решение обычно включает убийство слона с помощью команды:
db2 "force application (application-handle) "