Using Tableau for Oracle Performance analysis. Part 1.

На моей практике я чаще все не имею прямого доступа к системам, с производительностью которых приходится иметь дело. Я уже понял, что как бы такой доступ не ускорил дело, вне зависимости от важности задачи,  такой доступ скорее всего не дадут. Остается вариант - попросить какие то  данные предоставить в текстовом виде.

Популярное сейчас решение - попросить AWR и ставить диагноз по нему. Тут есть несколько проблем.

1. AWR содержит тексты SQL запросов - был случай,  когда мне сказали что это секретная информация
2. AWR собирается с какой то частой, по умолчанию 1 раз в час, и чаще всего, вместе с проблемным участком попадает и нормальный. Данные получаются размытыми.
3. Можно сделать  снимок (snapshot)  до начала проблемы и после, и сделать отчет между двумя этими снимками - но, встречаются случаи, когда это не очевидное действие для администраторов. 
4. Данные в AWR представлены в виде среднего по больнице. 40% база данных тратила на ввод-вывод, можно по Top SQL догадаться кто виноват (найти sql) но восстановить общую картинку, как чувствует себя тот или иной бизнес модуль, даже если код хорошо инструментирован, весьма сложно. 
5. Приходится писать много текста, который мало кто любит читать - все любят картинки. 

Не менее популярно (по крайне мере, было) написание своих скриптов для сбора нужной вам информации. Это отдельная песня - элементарно не разрешают, на основании того, что эти ваши скрипты погубят систему. 

Итого, идеальная стратегия для меня такова - одна команда Oracle, который дает мне возможность проанализировать, что происходит, презентовать промежуточные выводы, далее обоснованно запросить дополнительную информацию. 

И, как мне кажется,  я нашел эту команду ...

...Барабанная дробь…Это dump active session history!

SQL> alter system set events 'immediate trace name ashdump level 10'; 

level <число> обозначает за сколько времени вы хотите получить этот dump. Подробности см Metalink ID 243132.1

Полученный dump сразу содержит control file чтобы вы могли загрузить ASH в промежуточную таблицу на своей БД и внимательно рассмотреть. Тут правда, небольшая закавыка. Рассматривать то ..не очень удобно. Нужен инструмент. Опять таки можно написать своих скриптов, но как мне кажется я нашел другой интересный способ - Tableau.

Важно, у Tableau несколько платных продуктов, но также есть и  Tableau Public - бесплатный, но в котором присутствуют ограничения: 1M записей в одном файле и 1Gb пространства на сервере.

Еще одно, очень важное, содержится в FAQ: 'nothing is saved locally on your computer. All data saved to Tableau Public will be accessible by everyone on the internet'.   

Это значит что все в мире смогут узнать сколько логических чтений делает ваша БД и,  возможно, будут над вами смеяться.

Для начала посмотрим что может нам дать анализ с помощью Tableau. Посмотрим классическую картинку Top Wait Events.

Log file sync на втором месте. Кажется, нет сомнений,  что это проблема, с которой нужно бороться.

А теперь посмотрим распределение wait events по модулям, на которые жалуется бизнес - нет там практически log file sync!  Tableau обладает фантастическими возможностями по фильтрации данных, можно мгновенно покрутить данные, как вам удобно.

 Достаточно классическая картинка, какой sql_id  создает наибольшую нагрузку.

Но теперь мы можем добавить к ней любое распределение, например, по модулям!

Мы видим, что sql_id 0w2qpuc6u2zsp потребляющий больше всего CPU относится к модулю New Order. Ну это можно были и из AWR понять. И все таки, понять из AWR и увидить за минуты на графике, и иметь возможность рассматривать данные с весьма гибкими фильтрами - это разные вещи.

Я еще не успел рассказать главного - ведь можно результаты ваших исследований передать ..на в виде картинки, а в виде живой ссылки, с которой можно работать дальше!

Ну об этом в следующих сериях!