Вообще, алерты на то и алерты, чтобы на них обращать внимание. Но т.к. критичность может быть разная, то можно фильтровать по градации
Есть 2 полезные вьюхи в _SYS_STATISTICS:
1. STATISTICS_ALERTS
2. STATISTICS_CURRENT_ALERTS
первая содержит список всех алертов, вторая за текущий день.
Соответственно, чтобы отработать все алерты, можно делать селекты типа:
Code:
select * from _sys_statistics.STATISTICS_ALERTS where alert_rating > 3
- отобразит все алерты уровня High и выше.
В индекссервере есть функциональность почтового агента, соответственно, он может слать сообщения на почту по определенным типам алертов.
По описанию есть отдельная
нота, 2147247Разумно быстро реагировать на алерты уровня выше 3го (High and over)
Что точно надо мониторить:
1,3,4,30,36,38,42,47-49,52,54,61,73,74
Помимо этого, имеет смысл мониторить [indexserver|nameserver|whatever]_alert.trc файлы, которые содержат техническую информацию об ошибках потенциальных и существующих проблемах.
Параметр отбора очень непростой. Т.к. HANA спроектирована с учетом максимально эффективного потребления имеющихся аппаратных мощностей, я бы не рассчитывал на предсказание "чтобы не проседала производительность" по алертам. Тут разумнее workload management настроить.
Мониторинг ФС лучше проводить с уровня ОС, причем средствами файловой системы, т.к. от нее очень много зависит (особенно, если она не родная для Linux, как, например GPFS).
По памяти - также имеет смысл настроить workload management и установить разумный statement_memory_limit. Это позволит избежать большинства потенциальных Out-of-Memory ситуаций. Но в целом мониторить database used memory и indexserver memory used - хорошая идея.
Кстати, при желании, можно оперативно реагировать на текущие показатели производительности, периодически опрашивая специальную системную вьюху следующим селектом:
Code:
select * from m_load_history_service order by time desc
- содержит все то же, что доступно в Administration-Performance-Load HANA студии, но только в табличном виде и доступном для опроса через SQL. Потребляя этот вывод в каком-нибудь обработчике данных, с помощью парсинга и простейших скриптов можно вполне себе наколенную систему мониторинга БД сделать, если стандартные не подходят по к.-л. причинам
Кроме того, важное значение для производительности имеет количество т.н. uncommitted versions в MVCC, при превышении определенных значений (over 1M versions) доступное в виде алерта, попадающее в indexserver_alert файл. Текущее значение можно посмотреть в вышеупоминавшейся вьюхе (m_load_history_service, метрика MVCC_VERSION_COUNT) либо в отдельной вьюхе, M_MVCC_OVERVIEW (соответствующие алерты 47,48,73,74)