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

План запроса? Легко!

Informix складывает план запросов в файл в домашнем каталоге пользователя на сервере. Поэтому возникает некоторое неудобство когда требуется получить план запроса: надо запустить запрос, затем переключится в консоль, подключится к серверу, открыть файл и смотреть полученный файл с планом запроса. Дополнительные вопросы возникают если пользователи не заведены на сервере где запущен экземпляр Informix и соответственно не имеют домашних каталогов. Я решил эту задачу таким образом, что теперь не надо переключаться в консоль и идти на сам сервер, чтобы посмотреть план запроса. Планы запросов теперь складываются в отдельную таблицу в базе и их можно смотреть с помощью обычных sql-запросов. Но обо всем по порядку. Схема работы для получения плана запроса в данном случае такая (предварительно надо установить две функции):

1. Запускаем функцию start_explain() которая производит некоторые подготовительные действия и включает explain
2. Запускаем анализируемый запрос (или несколько запросов)
3. Запускаем функцию stop_explain() - план запроса возвращает функция.

На самом деле на шаге 2 лучше запускать 1 запрос, просто из-за удобства дальнейшего просмотра плана.

Итак, что же делает функция start_explain() ? Все очень просто: она готовит файл для плана запроса на сервере, и включает explain.
Функция stop_explain() читает данный файл и возвращает его содержимое. Этот текст можно скопировать и работать с ним.

Функции start_explain и stop_explain следует устанавливать либо в базу где они будут использоваться, или например в какую то отдельную базу и обращаться к ним из любой базы по имени dbname:start_explain() и dbname:stop_explain. Для обращения из другой базы надо выдать пользователям привилегию connect на базу где эти функции находятся.

Исходные коды функций start_explain и stop_explain можно взять на сайте проекта. Поддерживается версия Informix 11.50.xC6 и выше, поскольку использует external table. Пока работает только на Unix-платформах.

Контроль версий конфигураций

Администрированию ... необходима
технология фиолетовых проводов

Слегка необычный вариант использования VCS (Version Control System) - контролировать изменения конфигураций ПО.
В Informix контролировать можно следующие конфигурационные файлы: onconfig.$INFORMIXSERVER и файл sqlhosts. Это именно те файлы которые администратор меняет руками и они текстовые, в отличие от конфигов некоторых других СУБД. Для конфигов помещение их в VCS автоматически означает наличие их архивной копии, причем со всеми фишками присущими VCS, а именно возможностью посмотреть когда почему (и возможно кем!) был изменен тот или иной параметр конфига. Процедура контроля версии может быть такой: правим конфиг, после этого копируем его в репозиторий VCS и коммитим, не забывая про описание изменения в комментарии. Все на самом деле очень просто и несложно. Выбор VCS в данном случае дело вкуса и привычки, тут уж кто что знает, я например считаю что лучше всего тут бы подошли Mercurial или Bazaar (только потому что я их знаю и умею с ними работать).

Как это может выглядеть в случае с тем же Mercurial:

1. Создаем каталог, например IDSvercfg. В этом каталоге создаем подкаталоги с именами экземпляров Informix
2. В каждом таком подкаталоге инициализируем репозиторий командой hg init
3. Копируем конфиги каждого сервера в соотв. каталог, затем в каждом каталоге, добавляем конфиги под контроль версий с помощью hg add, делаем hg commit и пишем комментарий что поместили конфиги данного экземпляра под контроль версий, ну или что там хотите написать
4. В случае изменения конфига копируем его в соотв. каталог, снова делаем hg commit и комментируем изменения.
5. Обнаружили что через некоторое время некоторый запрос стал работать медленнее (а может наоборо быстрее, или чекпоинты увеличились или еще что то), смотрим на историю правок конфига в VCS и возможно получаем ответ на вопрос об изменении работы системы.

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

"Маленькие" проблемы больших систем или когда бэкап ломается

Рассмотрим процесс повышения надежности бэкапа на больших системах. Сам процесс бэкапа может быть длительным. И неприятно когда этот достаточно долгий процесс может завершится с ошибками. Что значит отсутсвие бэкапа или старый бэкап думаю понятно. Причины по которым бэкап может не пройти до конца могут быть различными, и в таком случае надо предпринять действия для того чтобы спасти хотя бы его часть. Здесь и далее речь идет про бэкап выполненный с помощью onbar, и дальше вы поймете почему. Рассмотрим бэкап запущенный на выполнение с помощью простой команды "onbar -b -L 0".




Такой бэкап выполняется как некий единый процесс и в случае если произойдет ошибка и процесс завершится (например прервется соединение с storage manager), то что onbar успел сохранить в TSM будет потеряно, информация об уже сохраненных объектах будет недоступна информиксу, в файле ixbar не будет записано никаких сведений об сохраненных объектах. Как быть в таком случае? На помощь приходит т.н. раздельный бэкап по dbspace. При запуске в onbar указываются dbspace которые должны быть архивированы. Т.е. скажем если в системе есть несколько dbspace c именами rootdbs, phylog, data, test, bigdata то можно процесс бэкапа запустить последовательно:



Т.о. небольшие dbspace rootdbs, phylog, data, test будут архивированы быстро и вероятность отказа при малом промежутке времени достаточно мала, затем будет запущена архивация большого dbspace bigdata, и даже если во время этого процесса произойдет сбой, информация о предыдущих dbspace не будет потеряна. Поэтому придется заново запустить бэкап только для dbspace bigdata.
Восстановление из такого бэкапа выполняется как обычно. Такой бэкап также можно использовать для физического восстановления при инициализации репликации HADR.
Единственный минус этого способа - надо быть внимательным при перечислении всех имеющихся в системе dbspace.

Копирование данных без длинных транзакций

Как быть если требуется перенести большой объем данных из одной таблицы в другую? Можно воспользоваться например выгрузкой данных в промежуточный файл. Если данных не очень много то можно попробовать использовать прямую вставку с помощью insert into ... select ... from ... однако такой способ не будет работать если данных очень много, поскольку высока вероятность длинной транзакции. Напрашивается способ использования таблицы без журналирования (raw table) однако он не подходит если сервер используется в паре HDR.
Следующий способ был бы универсальным однако он не реализован:

insert into t1 select ... from t2 where ... commitrows N;


Таким образом приходится придумывать свои способы. Один из таких способов это использование хранимой процедуры и объявления курсора через foreeach. Этот способ позволяет делать commit через нужное число вставленных строк. Вот примерная реализация этого способа (нечто подобное обсуждали как то на конференции comp.databases.informix):

CREATE PROCEDURE batch_move(commitrows int);
...
DEFINE count_rows INT;
...
LET count_rows = 0;
BEGIN WORK;
...
lock table table2 in exclusive mode;
FOREACH cur_ins WITH HOLD FOR
SELECT список полей INTO список переменных FROM table1
LET count_rows = count_rows + 1;
INSERT INTO table2 values (список переменных);
IF mod(count_rows, commitrows) = 0 THEN
COMMIT WORK;
BEGIN WORK;
lock table table2 in exclusive mode;
END IF;
END FOREACH;
COMMIT WORK;
...
END PROCEDURE;


commitrows в параметре процедуры это число записей, через которые последует очередной commit. Таким способом можно перенести любое число записей не опасаясь длинной транзакции, надо лишь задавать реалистичное значение commitrows, которое выбирается индивидуально исходя из настроек сервера и размера записи в таблице-источнике. Опционально можно эксклюзивно блокировать таблицу источник и таблицу приемник, выставлять нужный уровень изоляции и т.д.

Сбор статистики по фрагментированной таблице

Как то обсуждая на sql.ru сбор статистики по большим таблицам один из участников обсуждения пожаловался что нельзя собирать статистику отдельно для каждого фрагмента таблицы. Действительно, предположим что есть фрагментированная таблица (или например разбитая на partitions). Если данные в такой таблице меняются только в некоторых фрагментах, а остальные остаются неизменными, то нет смысла запускать сбор статистики по всей таблице. Гораздо рациональнее было бы собирать статистику только по фрагментам с измененными данными. Однако такая возможность сбора статистики в информиксе не реализована.