понедельник, 27 августа 2012 г.

Установка JDBC драйвера

При установке новой версии JDBC драйвера Informix может возникнуть проблема - не запускается инсталлятор. Если используется Java 7, то можно попробовать запустить инсталлятор в версии Java 6, поскольку версия 7 пока не поддерживается.
Подробнее см. http://www.stuart-taylor.net/2011/12/ibm-informix-jdbc-driver-version-3-50-install-error-could-not-load-wizard-fixed/
У меня этот способ сработал при установке драйвера версии 3.50

вторник, 17 января 2012 г.

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

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

Встроенный мониторинг (оповещение о событиях) в 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, про который я писал недавно.

четверг, 22 декабря 2011 г.

OAT Health Advisor

В Informix OpenAdminTool появился модуль HealthAdvisor, который позволяет производить мониторинг сервера баз данных и отправляет уведомления если происходят определенные события. Кроме того сам OAT теперь включен в ClientSDK и его не надо скачивать отдельно!
Данная статья сопровождается картинками, но я не знаю как сделать чтобы при нажатии на картинку появлялось увеличенное изображение. Поэтому пока оставляю так как есть.
HealthAdvisor конфигурируется для каждого экземпляра Informix отдельно. Всего для конфигурации представлено 4 вкладки:

Конфигурация HealthAdvisor Profile
На вкладке Profile отображаются доступные профили. Всегда есть профиль default, можно добавить свои профили, которые настраиваются.


Health Advisor Alarms
На вкладке Alarms можно просмотреть предупреждения, которые сгруппированы по категориям. Порог для каждого предупреждения можно сконфигурировать, а само предупреждение можно отключить.


Health Advisor Schedule

Вкладка Shedule позволяет настроить расписание запуска задачи для данного профиля. Не забыть поставить флажок "Enable Task".


Health Advisor Notification
На вкладке Notification конфигурируются почтовые адреса для отправки уведомлений и уровни оповещения (поле When).
Также указана команда (почтовый клиент) которая будет срабатывать на сервере где находится экземпляр Informix при отправке оповещения. Если у вас Informix находится на Windows, то возможно придется изменить эту команду.
Отдельно надо обратить внимание на поле заголовка (subject) письма: гораздо удобнее будет если сделать его как '$INFORMIXSERVER [SUBJECT]' подставив вместо $INFORMIXSERVER имя экземпляра Informix. Тогда в почтовом клиенте будет сразу видно от какого сервера пришло письмо, если у вас их несколько.
Можно сделать рассылку одновременно нескольким адресатам, либо через перечисление адресов в поле "To" на вкладке Notification, или указать адресата informix, а список адресов сделать через файл /home/informix/.forward по одному адресу в каждой строке файла.

После того как Health Advisor настроен, жмем кнопку Run Health Advisor. Здесь есть небольшой баг: время ожидания работы скрипта может быть превышено, и после запуска может появится сообщение об таймауте. Если такое происходит, надо увеличить параметр max_execution_time в файле %PATH_TO_OAT%\PHP_5.2.4\php.ini (этот файл находится на сервере где установлен OAT), например сделать 120 секунд.

четверг, 1 декабря 2011 г.

Мониторинг свободного пространства в dbspace

Всем хорош мониторинг состояния сервера с помощью alarmprogram.sh, но он к сожалению не позволяет устанавливать пороги оповещения о свободном пространстве в dbspace. Параметр STORAGE_FULL_ALARM позволяет задать уровень оповещения и срабатывание когда dbspace оказывается уже полностью занят.
Написал небольшую процедуру на SPL с помощью которой можно осуществлять мониторинг свободного пространства в dbspace. Пороги срабатывания задаются для каждого dbspace отдельно. При уменьшении размера свободного места ниже установленного порога, процедура в момент очередного запуска обнаруживает это и высылает email с подробной информацией. Для работы необходимо наличие на сервере клиента mailx. Думаю что не проблема переписать процедуру если почтовый клиент другой.

Исходный код проекта как выложил на GoogleCode проект idsmon.

Установка:
- зайти на сайт проекта и скачать исходный код процедуры и таблицы
- создать в базе sysadmin таблицу и заполнить ее значениями alarm levels для каждого dbspace;
- создать в базе sysadmin процедуру проверки и оповещения;
- создать в планировщике informix расписание для запуска процедуры;

Схема работы:



Процедура протестирована и работает на версии 11.50.UC8. В ней используется тип row, поэтому думаю что будет работать и с предыдущими версиями, где есть данный тип. Конечно должна работать и на более новых версиях :)
Расписание запуска процедуры можно установить например 1 раз в каждые полчаса.

суббота, 26 ноября 2011 г.

MSL готовится к старту на Марс

Через полчаса произойдет историческое событие - старт миссии MSL на Марс. Прямую трансляцию можно смотреть здесь.

среда, 23 ноября 2011 г.

Informix SPL и тип запись

Прдолжение истории. Вкратце: в SPL (язык для создания хранимых процедур) приходится работать с многими полями из таблицы, или вообще со всей записью целиком. Это не проблема если в таблице немного полей, но если полей много - возможны ошибки, как синтаксические так и чисто логические. В некоторых СУБД можно объявлять переменную типа запись, основанную на записи таблицы, и работать с этой переменной (и отдельными полями из нее), например так:


define
  row_emp employees%rowtype;
...
  select * into row_emp from employees  where employee_id = Val1;
...
  insert into employees values row_emp
...

Причем тип row который есть в Informix, таких фокусов не допускает. Т.е. в нем можно обращаться к отдельным полям через точечную нотацию, но например выбрать всю запись из таблицы в переменную без перечисления отдельных полей не получится. Точно также не работает вставка в таблицу из переменной типа row без указания каждого поля. А еще при объявлении такого типа приходится указывать все поля, что ничуть не способствует сокращению размеров кода. 
Пообщался с техподдержкой, сказал что хочу такой синтаксис в SPL, что упрощает разработку процедур, уменьшает вероятность появления ошибок в коде, и вообще это удобно. Человек из техподдержки написал мне, что создаст запрос (видимо выше) для реализации новой функциональности. Может набраться наглости и попросить чтобы сделали реализацию PL/SQL в Informix ? :)

среда, 14 сентября 2011 г.

Защита данных при обновлении на новую версию

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

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

По умолчанию в onconfig.std параметр CONVERSION_GUARD установлен в значение 2, что означает продолжить конвертацию даже в случае ошибки создания данных точки восстановления. В документации же указано значение по умолчанию 1, т.е. остановить конвертацию на новую версию в случае ошибки создания данных точки восстановления. Из-за таких нестыковок лучше выставить этот параметр в onconfig явно, причем в значение 1. Для параметра RESTORE_POINT_DIR следует выбрать каталог на ФС с достаточным кол-вом свободного места. Например, при обновлении с 11.50.FC5 до 11.50.FC8 было использовано примерно 500Мб для данных восстановления. Но эта цифра может зависеть от различных факторов.