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
и прочих абракадабр, на которые должна реагировать система мониторинга.