ValergradЕсть достаточно большой проект ( набор клиентских сервисов + БД ) на который собираются кратно увеличить нагрузку в виде обрабатываемых данных, хотя БД не сказать, что и сейчас отдыхает. Есть капасити для оптимизации проекта какая понадобится ( от тюнинга конкретных запросов, до изменения архитектуры и даже переписывания тормозящих кусков). Предварительно, конечно, нужно узнать слабые места, и уметь в дальнейшем быстро видеть какие ресурсы окажутся боттлнеками при увеличении нагрузки.
Следуя принципу "know your tools" - какие инструменты вы используете для анализа производительности на уровне сервера БД? Подозреваю, что многие скажут "пользуюсь отлаженным за годы набором запросов", но не использует ли кто-нибудь какой-нибудь GUI?
Наборы запросов, это, конечно, хорошо, но грамотный GUI нередко позволяет экономить свое время ( т.к. грамотно организованная графическая информация, гиперссылки и вкладки не зря придумали). Хотя и ссылка на хороший, тщательно отобранный пак диагностических запросов тоже будет в тему.

Бейслайны, триггеры, комплексные экраны в оракловом профиле заббикс
начиная от нагрузки на CPU и диски , виртуальную память,
заканчивая сетевым трафиком.
Бейслайны Оракла по сессиям, ожидания, задержки стендбая ,
бекапы итд где то посредине.


По сработке триггеров ( инцидент) можно автоматом
отстегивать ссылку на сайт с AWR -ом для более глубокого расследования.
Мы пока не отстегиваем.

Но ближайших планах автоматизировать
отлов объектов БД по триггеру на ожидании buffer busy waits.

kinky catoem, ash-awr, [pl/]sql developer, set events, strace/dtrace, vi ) вроде все, если чисто применительно к oracle, пока хватало) Еще есть конечно общемониторные тулзы, и у схдшников свои пироги, но это уже не моя ЗО )

авторБейслайны Оракла по сессиям, ожидания, задержки стендбая ,
бекапы итд где то посредине.
Завис немного на этой фразе, потом понял что тут другие бейслайны)

У нас те, которые подразумеваются по топику - Performance Measurement Baseline (PMB).
А вы о каких других подумали ?

В терминологии забикса Performance Measurement Baseline (PMB) называются
atest_data - статистика изменений нагрузок.

Расследование инцедента начинается с формирования комплексного экрана , если его
еще не сущетсвует , в котором собраны бейслайны всех компонент с взаимным влиянием, друг на друга.

А вобще , шо это я тут офтоплю , это не оракл , это ITIL и ITSM.

kinky catд0kХ,
угадайте) у оракла не много вещей официально назвается baseline'ом

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

andrey_anonymousд0kХа те в свою очередь начинают играать этой расслыкой в пинг понг.
К сожалению, именно так и будет.

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

Тяжело лепить горбатого , когда человека тыкают носом в тренд бейслайна,
в процессе расследовния, следить за которым прямая должностная обязанность этого человека.

andrey_anonymousд0kХНет, потому как у этого процесса цербер
Ну вот ситуация: начали падать выгрузки из оракеля в хранилище.
Тулза, выливающая данные, на середине выгрузки начала обижаться в логах на ORA-02396.
Разумеется, "Никто ничего не делал" (с) и "У нас все в порядке" ^tm
Все бейслайны в норме :)


Наверное будет задан вопрос кто был инициатором
на основании какой информации был изменен профиль.
В звисимости от ответа на этот вопрос есть куча вариантов для действий,
начиная с пересмотра регламентов ,
заканчивая эскалацией инцидента в проблему
на уровень проектного офиса и разработчиков, с переформулирокой вопроса
бизнесовым языком :

У нас автотранспорт перестал укладывается
в лимиты бюджетов по ГСМ , покрывает ли повышение прибыли текущего периода
разницу фактических и забюджетированных затрат ?
Покрывает - отлично.
Не покрывает - скажите какие риски реализовались ?
.....

andrey_anonymousд0kХпропущено...

Наверное будет задан вопрос кто был инициатором
на основании какой информации был изменен профиль.
В общем верно - в той ситуации именно решение DBA об установке idle_time в профиле приложения привела к спецэффекту.
Однако "веселые картинки" этого не покажут.
Лишь тот факт, что система была в ОПЭ и разработчик имел доступ ко всем компонентам + слышал кое что про администрирование позволила диагностировать проблему достаточно оперативно.
Случись такое в проме - не уверен, что решение вопроса заняло бы менее 2-х дней - и это при наличии при весьма компетентного "цербера" в конкретном случае.
Первый день был бы потрачен на пинг-понг между тремя подразделениями Заказчика и двумя - у подрядчика, второй - на согласование доступов разрабов на прод, диагностику и постановку DBA задачи на устранение.
Два дня * 5-6 человек => 10-12 человекодней на устранение примитивного косяка... а Вы говорите цербер... :)

ДБА должен показать веселые картинки .
Смотрите вот пик бизнес активности внешних потребителей сервиса,
что бы не мешать бизнесу расти и зарабатывать деньги , я принял решение
притормозить внутренние регламентные процедуры не зарабатывающие деньги явным образом.
Ему скажут маладец , ты пока иди бери с полки пирожок ,
а мы сейчас у бизнес аналитиков спросим ,
заработывал ли бизнес на этой активности деньги ,
кто овнер проекта , и все ли риски он учел когда давал отмашку
запускать бизнес процесс ( услугу для клиента ) в продуктив.
Если это результат рекламной акции прорывного продукта
и виден стратегический бизнес профит
то забюджетировать инвестиции новое железо на основании расследования
инцидента сам Бог велел.