Используем встроенный мониторинг

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

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

В Informix встроенный мониторинг управляется параметром ALARMPROGRAM конфигурационного файла $ONCONFIG. Этот параметр задает путь к скрипту ($INFORMIXDIR/etc/alarmprogram.sh для UNIX-систем или %INFORMIXDIR%\etc\alarmprogram.bat для Windows), который выполняется в случае возникновения событий датасервера. Кроме стандартных действий оповещения о событиях, можно создавать свои сценарии обработки событий.
В случае возникновения какого либо события Informix запускает этот скрипт с параметрами важности события, класс события, сообщение а также некоторые другие. Скрипт анализирует переданные параметры и выполняет необходимые сценарии.

Посмотрим как настраивается стандартный скрипт alarmprogram.sh. Здесь под параметрами понимаются переменные в скрипте, если это не сказано иначе.

Прежде всего уровень важности событий, при которых происходит отправка оповещения определяется с помощью параметра ALARMADMIN. Всего уровней 5, и можно гибко настроить тот уровень важности событий который нужен. Если происходит событие с уровнем важности >= значению ALARMADMIN то скрипт отправляет письмо с информацией о событии. Адрес куда отправляется оповещение задается параметром ADMINEMAIL. Если хочется чтобы письма уходили на несколько адресов, можно например сделать ADMINEMAIL=informix а в домашнем каталоге пользователя informix создать файл .forward в котором записать необходимые адреса, по одному в каждой строке.
Тут же можно задать пейджер PAGEREMAIL и утилиту которая отправляет письма с оповещениями MAILUTILITY.

Если требуется автоматическая архивация журналов транзакций, то надо установить параметр BACKUPLOGS=Y и параметр LTAPEDEV=значение (даже если используется onbar вместо ontape, поскольку скрипт анализирует LTAPEDEV из файла конфигурации $ONCONFIG на /dev/null и в зависимости от этого значения запускает или нет команду BACKUP_CMD). Если параметр LTAPEDEV=/dev/null архивация журналов производится не будет (журналы транзакций будут просто циклически перезаписываться).

Параметр BACKUP_CMD определяет чем будет производится архивация журналов транзакций (если BACKUPLOGS=Y). Могут быть варианты onbar или ontape.

Кроме того, запуском самого скрипта ALARMPROGRAM можно управлять. Делается это с помощью параметра $ONCONFIG ALRM_ALL_EVENTS=[0|1]. Если установлено значение ALRM_ALL_EVENTS 0 то скрипт будет запускаться только в случае возникновения событий с уровнем важности выше 1, если ALRM_ALL_EVENTS 1 то для всех событий.

Идентификаторы классов оповещений о событиях для версии 11.50 можно посмотреть здесь.
Идентификаторы классов оповещений для версии 11.70 можно посмотреть здесь.

Этот мониторинг можно применять вместе с мониторингом средствами HealthAdvisor из OpenAdmin, про который я писал недавно.

Программируем на шелл

"Бросая в воду камни, наблюдай за кругами,
которые они оставляют"

Эта небольшая заметка про то как правильно вести лог выполняемых команд SQL. Как правило небольшие скрипты sql, не требующие интерактивной обработки проще всего реализовать с помощью программирования на шелле и dbaccess. Результат выполнения (или журнал) для дальнейшего анализа направляется в файл например так:

dbaccess test test.sql >test.log 2>&1


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

Например есть такой скрипт:

create table t1 (id int);

insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);

insert into t1 values (1, 2);

select * from t1;

drop table t1;

тогда журнал выполнения скрипта будет таким:

Database selected.


Table created.


1 row(s) inserted.


1 row(s) inserted.


1 row(s) inserted.


236: Number of columns in INSERT does not match number of VALUES.
Error in line 7
Near character position 24


id

1
2
3

3 row(s) retrieved.


Table dropped.


Database closed.



Чтобы включить в файл журнала инструкции SQL, надо воспользоваться флагом -e для dbaccess:

dbaccess -e test test.sql >test.log 2>&1


Тогда журнал выполнения будет таким:


Database selected.

create table t1 (id int);
Table created.



insert into t1 values (1);
1 row(s) inserted.


insert into t1 values (2);
1 row(s) inserted.


insert into t1 values (3);
1 row(s) inserted.



insert into t1 values (1, 2);
236: Number of columns in INSERT does not match number of VALUES.
Error in line 7
Near character position 24


select * from t1;

id

1
2
3

3 row(s) retrieved.



drop table t1;
Table dropped.



Database closed.


Как видим, здесь перед каждым результатом выполнения инструкции SQL идет сама инструкция, что очень удобно при дальнейшем просмотре журнала.

Получаем список нитей для процесса

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


#!/bin/bash
# getuthbypid.sh
# Получение всех пользовательских нитей по заданному PID

if [ ${#*} -ne 1 ]
then
echo Get all user threads by PID
echo USE: getuthbypid PID
echo where PID is process ID
exit
fi

# Получение всех SID по заданному PID
sids=`onstat -g ses|egrep "$1"|awk '{print $1}'`
# Преобразование набора SID в строку с разделителями
siddelim=`echo $sids |sed -e 's/ /|/g'`
# Список user threads
onstat -u|egrep "address|$siddelim"



запускаем данный скрипт с параметром в качестве которого указан process ID клиентского процесса и получаем список нитей с их свойствами (флаги, SID, сколько читает/пишет и т.д.)

Активность транзакций и статистика на уровне таблицы

Иногда требуется посмотреть статистику (чтения, записи, блокировки и т.д.) по конкретной таблице или индексу. Конечно можно воспользоваться выводом команды onstat -g ppf, но если известен partnum (в десятичном или шестнадцатиричном формате) можно использовать мой скрипт. Он принимает в качестве параметра partnum и выдает статистическую информацию по объекту:

onprtninfo --
Usage: onprtninfo [-h hex_partnum|-d dec_partnum]

а вот и сам скрипт:

if [ "$1" == "-h" ]; then
export decpartn=`echo $(($2))`
elif [ "$1" == "-d" ]; then
export decpartn="$2"
else
echo "Usage: onprtninfo [-h hex_partnum|-d dec_partnum]"
exit
fi

dbaccess sysmaster - </dev/null
output to pipe "sed -e '/^$/d' " without headings
set isolation to dirty read;
select * from sysptprof
where partnum=$decpartn;
!

скрипт написан на bash и без проблем работает в AIX и Linux.