Comments 8
Спасибо за доклад. Мне показалось, что представленный подход пересекается с методом R, описанным Cary Millsap в книге «Optimizing Oracle Performance», «Mastering Oracle Trace Data» и др., и описывает интересные варианты его практического применения.
Вообще, я не считаю оптимизацию топ-запросов именно проактивной оптимизацией. Я, конечно, понимаю, что это сейчас слишком обширное понятие, но все же, как мне кажется, под по-настоящему проактивной оптимизацией должен подразумеваться более глобальный подход с анализом трендов в различных разрезах и оптимизацией на опережение, а не постфактум, когда какой-то новый запрос вылех в топ. Обычно при долгой работе и на больших базах(если это, конечно, не специфические dwh и прочий постоянно меняющийся data mining), то топы запросов достаточно стабильны и остаются одними и теми же. Примитивный пример: топовый запрос жрет 5% — даже если его вообще убрать, то мы выиграем лишь 5%, в то время как часто оказывается, что проанализировав архитектуру чуть более детально и сделав, к примеру, какую-нибудь одну маленькую денормализацию, то можем выиграть 15%, но на сотнях мелких быстрых запросов.
В первую очередь мне, как автору доклада, хотелось бы сказать слова благодарности организаторам HighLoad++ Siberia 2018. Первая версия доклада по этой теме была сделана в 2016 году, и сначала этот материал прошел обкатку внутри ЦФТ на разного рода внутренних мероприятиях. Благодаря этому был приобретен бесценный опыт, и понимание важности данной темы. Поэтому, когда HL++ появился в Сибири, то я предложил данный доклад.
Метод R является реактивным. Он строится на жалобах клиентов на работу важных для них операций и направлен на минимизацию времени отклика этих конкретных операций (https://method-r.com/faq/).
Метод R является реактивным. Он строится на жалобах клиентов на работу важных для них операций и направлен на минимизацию времени отклика этих конкретных операций (https://method-r.com/faq/).
… where o.type_oper = 'proc'
а сколько из 5 млн записей с такой операцией
и сколько дает distinct type_oper?
а сколько из 5 млн записей с такой операцией
и сколько дает distinct type_oper?
Очень рад, что с такими темами начинают выступать и кто-то, как и я, тоже занимается чисто производительностью БД! У самого куча наработок, например, по этой статье у меня есть заготовка презентации «Performance tuning and troubleshooting баз данных в наши дни», в которой я как раз говорю о том, что, к сожалению, никто не держит инженеров по производительности баз данных и обращаются за помощью либо слишком поздно, собственно тогда, когда нужен уже troubleshooting, либо вообще не обращаются, а сразу закупают еще более и более мощное железо… Жаль только времени все время не хватает на презенташки. Был бы кто-нибудь кто б выступил с ними :D
По теме же, проактивности из своего опыта я бы посоветовал кое-что улучшить и автоматизировать:
1. На предыдущей работе я автоматизировал поиск запросов из AWR, которые стали выполняться медленнее. Сейчас это искать лень, но можете глянуть эту «рыбу», которую я сейчас набросал: gist.github.com/xtender/ade3d05eba1011f173d6deec81560093
2. При постоянном анализе производительности, создание AWR-отчета слишком медленное, поэтому для просмотра топа запросов я использую такой скрипт: github.com/xtender/xt_scripts/blob/master/awr/top_sql.sql
3. При добавлении очередной базы для анализа, я обычно сразу меняю настройку AWR на минимум 35 дней хранения(чтобы можно было глянуть эту же дату за предыдущий месяц), Top N SQL увеличию до 100, а интервал оставляю прежним — 1 час. В случае же, если есть проблемы с местом под AWR, то сохраняю бейслайны за пиковые часы. Мой скрипт для изменения настроек: github.com/xtender/xt_scripts/blob/master/awr/settings_modify.sql
4. Чтобы узнать пиковые дни/часы я использую такие скрипты:
по CPU: github.com/xtender/xt_scripts/blob/master/awr/db_cpu_by_days_hours.sql
целиком по DB Time: github.com/xtender/xt_scripts/blob/master/awr/db_time_by_days_hours.sql
5. для более онлайнового и детального мониторинга желательно настроить мониторинг и уведомления о:
5.1 долгих запросах: select * from v$sql_monitor r where elapsed_time>…
5.2 топe row-sources из ASH: gist.github.com/xtender/710b210bc455617cfd9531524ac3a1c6
5.3 оттуда же о новых фулсканах, например: gist.github.com/xtender/e771daf5581a12db15e3708c54678f5b
5.4 если же нет DIAG+TUNING и не стоит альтернативных ASH, то хотя бы о долгих операциях (v$session_longops)
6. Для более качественной информации о производительности, еще желательно логически разделить нагрузки по разным сервисам(v$services) и соответственно разрулить клиентов по ним и уже будет удобнее анализировать в разрезе сервисов, например в v$servicemetric, а если есть и свои разработчики, то разделить и бизнес-логику по module/action/client_id
В принципе, при работе с одними и теми же базами этого будет достаточно для начала, но в случае, если база еще и неизвестная, то там уже нужен полноценный performance data mining: анализ нагрузки и производительности уже с учетом архитектуры, связей про предикатам, горячим/холодным данным, и тд и тп, но это вообще огромная тема, тут одним комментарием не отделаться…
По теме же, проактивности из своего опыта я бы посоветовал кое-что улучшить и автоматизировать:
1. На предыдущей работе я автоматизировал поиск запросов из AWR, которые стали выполняться медленнее. Сейчас это искать лень, но можете глянуть эту «рыбу», которую я сейчас набросал: gist.github.com/xtender/ade3d05eba1011f173d6deec81560093
2. При постоянном анализе производительности, создание AWR-отчета слишком медленное, поэтому для просмотра топа запросов я использую такой скрипт: github.com/xtender/xt_scripts/blob/master/awr/top_sql.sql
3. При добавлении очередной базы для анализа, я обычно сразу меняю настройку AWR на минимум 35 дней хранения(чтобы можно было глянуть эту же дату за предыдущий месяц), Top N SQL увеличию до 100, а интервал оставляю прежним — 1 час. В случае же, если есть проблемы с местом под AWR, то сохраняю бейслайны за пиковые часы. Мой скрипт для изменения настроек: github.com/xtender/xt_scripts/blob/master/awr/settings_modify.sql
4. Чтобы узнать пиковые дни/часы я использую такие скрипты:
по CPU: github.com/xtender/xt_scripts/blob/master/awr/db_cpu_by_days_hours.sql
целиком по DB Time: github.com/xtender/xt_scripts/blob/master/awr/db_time_by_days_hours.sql
5. для более онлайнового и детального мониторинга желательно настроить мониторинг и уведомления о:
5.1 долгих запросах: select * from v$sql_monitor r where elapsed_time>…
5.2 топe row-sources из ASH: gist.github.com/xtender/710b210bc455617cfd9531524ac3a1c6
5.3 оттуда же о новых фулсканах, например: gist.github.com/xtender/e771daf5581a12db15e3708c54678f5b
5.4 если же нет DIAG+TUNING и не стоит альтернативных ASH, то хотя бы о долгих операциях (v$session_longops)
6. Для более качественной информации о производительности, еще желательно логически разделить нагрузки по разным сервисам(v$services) и соответственно разрулить клиентов по ним и уже будет удобнее анализировать в разрезе сервисов, например в v$servicemetric, а если есть и свои разработчики, то разделить и бизнес-логику по module/action/client_id
В принципе, при работе с одними и теми же базами этого будет достаточно для начала, но в случае, если база еще и неизвестная, то там уже нужен полноценный performance data mining: анализ нагрузки и производительности уже с учетом архитектуры, связей про предикатам, горячим/холодным данным, и тд и тп, но это вообще огромная тема, тут одним комментарием не отделаться…
Ах, да, ещё забыл написать, что вместо plsql функции лучше бы сделали виртуальный столбец с case when… then...else… end и уже его бы индексировали, а если версия слишком старая и не поддерживает виртуальные колонки, то просто функциональный индекс по выражению (тому же case), это позволило бы избежать ненужных переключений контекста sql-pl/sql
За какие из этих фич надо платить дополнительные деньги, помимо лицензии за Enterprise?
Sign up to leave a comment.
Проактивная оптимизация производительности БД Oracle