Keep watch over it!

"Они построили самый высокий в мире мост
который сложно поддерживать в надлежащем состоянии...
Множество датчиков позволяют отслеживать
изменения параметров в реальном времени.
И контролировать сооружение"

Для наблюдения за изменениями каких либо показателей сервера Informix в команде onstat можно использовать флаг -r с интервалом обновления в секундах. Однако при этом вывод изменений получается не очень информативным, точнее приходится запоминать предыдущие значения, чтобы оценить изменения. Если Informix установлен в ОС Linux или другой, где есть команда watch, то оценивать изменения значений при выводе команд onstat можно гораздо проще и элегантнее. Команда watch может выводить информацию от других команд в неизменном виде на экран, показывая в дальнейшем только изменения в выводе. Результат чем то напоминает вывод линуксовой команды top. Попробуйте позапускать на сервере например watch -d onstat -D, watch -d onstat -u и вы поймете как это бывает удобно.

Копирование чанков

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

Итак, задача. Есть тестовый сервер Informix с некоторыми тестовыми данными, необходимо перенести его на другую машину. Конечно раз сервер тестовый, никаких бэкапов не делается. Это раз. И на новой машине мы хотим использовать для чанков вместо raw device (которые на старом сервере) обычные файлы. Это два. Для такой задачи можно попробовать использовать утилиту dd. Перед реальным копированием чанков можно протестировать это на каком нибудь одном чанке на этой же машине. Перед копированием чанка надо остановить экземпляр. Для начала я указал исходный девайс, и файл в который будет скопировано все содержимое этого девайса. Например так:

dd if=/dev/roottestdbs of=/informix/data/filerootdbs

Как вы успели заметить, по названию исходного девайса, нетрудно предположить что копируется чанк из ROOTDBS. После копирования изменяю символическую ссылку (пути к чанкам я всегда указываю через символические ссылки) на новый файл, полученный с помощью dd. Запускаю тестовый экземпляр. Он запустился нормально! На всякий случай запускаю всевозможные проверки баз которые находятся в rootdbs (sysmaster, sysutils, sysuser) с помощью oncheck, они тоже показывают что данными все в порядке. Т.е. такой способ работает.

Upd. Для повышения скорости копирования необходимо установить размер блока с помощью параметра bs (man dd) и он должен быть кратен размеру страницы информикса. Размер блока следует подбирать экспериментально, т.к. скорость при выбранном размере блока зависит от многих факторов (например копирование осуществляется с диска на диск локально, или наоборот на другой сервер через NFS). Я делал копирование через NFS и выставлял размер блока 512к, дальнейшее увеличение прироста скорости не дало.

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

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

Слегка необычный вариант использования 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 и возможно получаем ответ на вопрос об изменении работы системы.

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

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

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

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

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

Рассмотрим процесс повышения надежности бэкапа на больших системах. Сам процесс бэкапа может быть длительным. И неприятно когда этот достаточно долгий процесс может завершится с ошибками. Что значит отсутсвие бэкапа или старый бэкап думаю понятно. Причины по которым бэкап может не пройти до конца могут быть различными, и в таком случае надо предпринять действия для того чтобы спасти хотя бы его часть. Здесь и далее речь идет про бэкап выполненный с помощью 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.

Как качать фикспаки для информикса

Многие спрашивают: где взять очередное обновление Informix ? Отвечаю: на сайте ibm :)
Ну а если точнее то на сайте IBM Fix Central
Выбираем в списке Product Group группу InformationManagement, появляется список Product в котором выбираем Informix Dynamic Server. В следующем списке выбираем нужную версию и затем платформу. Далее жмем Continue. Будет предложено ввести ваш логин и пароль (или зарегистрируйтесь). После успешной регистрации можно будет найти обновление по номеру или тексту, либо посмотреть все рекомендуемые обновления для выбранной версии, если такие имеются. Если обновление найдено, то его можно будет скачать.

Вышел фикспак 11.50.xC3W2

Список обновлений можно почитать здесь
Особенно важными считаю исправления проблем, связанных с добавлением или отсоединением разделов на фрагментированных таблицах.