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 человекодней на устранение примитивного косяка... а Вы говорите цербер... :)

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

andrey_anonymousд0kХДБА должен показать веселые картинки .
Смотрите вот пик бизнес активности внешних потребителей сервиса,
что бы не мешать бизнесу расти и зарабатывать деньги , я принял решение
притормозить внутренние регламентные процедуры не зарабатывающие деньги явным образом.
Это и будет ответ из серии "пинг-понг".
Просто потому, что установка idle_time в профиле активно работающего приложения не имеет никакого отношения ни к "пику бизнес-активности", ни - уж тем более - к "притормаживанию регламентных процедур".
Это скорее что-то из разряда "вставить запись в dual" в ранних версиях сервера.

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

Если кто то принял решение что то поменять , то для этого есть

2 категории причин .

1. Ранее расследованный инцидент.
2. Подкладывание соломы под риски
( что бы начать делать бекапы не обязательно сначала потерять данные).

То есть, нужно высянить в какую категорию попадает изменения
idle_time профиле.

andrey_anonymousд0kХДБА должен показать веселые картинки .
Смотрите вот пик бизнес активности внешних потребителей сервиса,
что бы не мешать бизнесу расти и зарабатывать деньги , я принял решение
притормозить внутренние регламентные процедуры не зарабатывающие деньги явным образом.
Это и будет ответ из серии "пинг-понг".
Просто потому, что установка idle_time в профиле активно работающего приложения не имеет никакого отношения ни к "пику бизнес-активности", ни - уж тем более - к "притормаживанию регламентных процедур".
Это скорее что-то из разряда "вставить запись в dual" в ранних версиях сервера.

andrey_anonymousд0kХ1. Ранее расследованный инцидент.
2. Подкладывание соломы под риски

Или просто желание отсечь простаивающие (idle) сессии.
Но выбранный механизм работает не совсем очевидным образом:
Я это все к тому, что не каждый инцидент может быть легко расследован на базе "картинок" под руководством "цербера".
Иногда картинки в норме, а система не работает.

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

andrey_anonymousд0kХон должен
решить проблему
Вопрос не в этом.
Вопрос - в диагностике когда "оно само" и у всех "все хорошо", включая "веселые картинки".
А также - о ценности "шашки" как диагностического инструмента.
Любой нормальный человек, оказавшись под "домокловой шашкой" не в первый раз, в первую очередь будет не решать проблему, а прикрывать пятую точку.
DBA не исключение - у них тоже хобби, семьи, дети.
А решение по прикрытию пятой точки не всегда совпадает с решением проблемы.
Отсюда - "пинг-понг".
И чем злее "судья" размахивает шашкой - те изощреннее "спортсмены" переводят стрелки.

В любых вопросах есть перегибы.

Шашка не есть диагностическим инструментом.

Шашка это административно организационный инструмент .

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

andrey_anonymousд0kХон должен
решить проблему
Вопрос не в этом.
Вопрос - в диагностике когда "оно само" и у всех "все хорошо", включая "веселые картинки".


Если так, то опять же категоризируем.
Либо это реализация рисков,
либо оно не само ( другая категория рисков).

Задача собрать дополнительную информацию ,
что бы стало ясны причины какие риски реализовались.

Возвращаясь в топик в свете описанного, рентабельнее
инветсировать в собствнную систему мониторинга организации,
чем использоваать покупную.

andrey_anonymousд0kХдолжен иметь набор инструкций и документов
для круглосуточного дежурного персонала
И какое отношение имеет инструкция для ночных дежурных к решениям, принимаемым DBA?
Правильно, никакого.
DBA участвует в сочинении тех самых инструкций, согласно которым ночной дежурный должен действовать (как правило - это первичная классификация проблемы, регистрация инцидента и информирование ответственного).

Ну вот и смотрим предметно:
0. ДБА в рамках мероприятий по оптимизации-чего-то-там лепит idle_time.
1. Ночной дежурный (НД) регистрирует инцидент - в DWH полегли ETL по источнику "И", рестарт не помогает.
2. (НД) информирует ответственного за загрузку данных из "И" в DWH (ОDWH).
3. (НД) вписывает строчку в отчет и спокойно сдает смену.
4. (ОDWH) некоторое время тупит, затем чтит логи, видит "ORA-02396", понимает что раньше не встречал и отписывает ДБА "разберитесь там со своей базой"
5. (ДБА) отписывает "база работает штатно, картинки красивые, проблем нет"
6. (ОDWH) командует сотруднику ТП рестартовать процесс.
... проходит два часа, в течение которых идет выгрузка
7. (ТП) отписывает, что "в DWH полегли ETL по источнику "И", рестарт не помогает"
8. (ОDWH) видит "ORA-02396" и отписывает ДБА "разберитесь там со своей базой"
9. (ДБА) отписывает "база работает штатно, картинки красивые, проблем нет", ORA- обозначает, что аппликуха ничего не делает и потому отрубается по timeout - разбирайтесь в своем ETL сами.
10. (ОDWH) эскалирует проблему на руководителя ТП (РТП)
11. (РТП) привлекает техподдержку подрядчика (ПТП)
12. (ПТП) пишет, что подрядчик не проводил никаких работ, на тесте все отрабатывает штатно
13. (ОDWH) эскалирует проблему на руководителя ТП (РТП)
14. (РТП) ласково журит ТП подрядчика и грозит шашкой
15. (ПТП) в конечном итоге передает проблему на 3 линию... разрабам ETL, которые про idle_time и прочую dbaшню не в курсе.
16. (3 линия) отписывает, что проблема не воспроизводится.
17. (РТП) вспоминает, что были работы на сети и привлекает сетевиков
18. (Сетевики) ругаются и говорят, что их работы не имеют отношения к проблеме
19. (РТП) грозит шашкой
20. (Сетевики) ставят новый маршрутизатор и списывают расходы на бюджет ТП
21. (РТП) командует ODWH, тот командует ТП поднять процессы
22. (ТП) отписывает, что "в DWH полегли ETL по источнику "И", рестарт не помогает"
23. (ОDWH) эскалирует проблему на руководителя ТП (РТП)
24. (РТП) грозно машет шашкой и собирает очную ставку между руководителями подразделений
.... время идет, шторм крепчает, представители вендора рекомендуют пропатчиться и - желательно - обновить жлезку...

...в это время DBA осознает, что причина переполоха - п.0, а также то, что п.8 закрыл перед ним возможность корректно вырулить, не попав под "шашку".
И начинает операцию "прикрытие":
78. (DBA) Предлагаю рестартовать базу. Прошу согласовать окно 40 минут.
79-88 - идут согласования
89. (DBA) база рестартована, пробуйте.
90. (ОDWH) ...
91. (ТП) - заработало
92. (вендор, подрядчик, РТП хором) непонятный глюк, сам пришел, сам ушел, база "И" - говно, давайте патчиться/апгрейдиться
93. (DBA) ...пронесло... да и новую железку давно хотел...
Всеобщий консенсус и хеппиэнд :)

После пункта я не читал
автор4. (ОDWH) некоторое время тупит, затем чтит логи, видит "ORA-02396", понимает что раньше не встречал и отписывает ДБА "разберитесь там со своей базой"

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

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

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

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

andrey_anonymous...в это время DBA осознает, что причина переполоха - п.0, а также то, что п.8 закрыл перед ним возможность корректно вырулить, не попав под "шашку".

Всеобщий консенсус и хеппиэнд :)

При правильно построенных ITIL & ITSM процессах ,
когда все коллеги Админы видят в системе мониторинга ORA-02396
и могут ее нагуглить , как это сделал я никогда до этого с ней не персекавшийся
у ДБА с мозгами нет смысла усугулять
совое положение "планом прикрытие" .

У него даже не возникнет мысли п 8 сказать база работает нормально

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

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

Поэтому еще раз повторю свою ИМХО позицию переходя от фотопика в топик.
Бизнес организации не выгодно инвестировать в производителей систем
мониторинга, а рентабельнее создавать свою ИТ интеллектуальную собственность.

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

Valergrad
заббикс - интересная вещь. Но кажется что это сугубо админская вещь, или я неправ?





Да,
он быстро учится выполнять sql запросы и читать логи на предмет ORA-XXXX
и прочих абракадабр, на которые должна реагировать система мониторинга.