пятница, 30 октября 2009 г.

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

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


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

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

понедельник, 6 июля 2009 г.

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

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

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

среда, 6 мая 2009 г.

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

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

четверг, 2 апреля 2009 г.

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

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

среда, 1 апреля 2009 г.

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

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

вторник, 24 февраля 2009 г.

Бэкап: Что еще я должен зарезервировать?

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

  • Файл конфигурации сервера ONCONFIG
  • Emergency boot file, известный как ixbar.$SERVERNUM
  • sm_versions описывающий storage manager
  • sqlhosts
  • Файл oncfg_severname.servernum
  • Конфигурации storage manager

Однако как показывает практика, даже этого недостаточно чтобы быть кое в чем уверенным!

понедельник, 16 февраля 2009 г.

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

Недавно сервер, на котором работал инстанс информикса упал и пришлось в срочном порядке поднимать его на другом сервере. Однако на новом сервере не оказалось линков на чанки с данными информикса. В таком случае всю конфигурацию устройств информикса можно узнать, даже если он будет выключен. Для этого надо воспользоваться командой oncheck -pr. Она выдаст необходимую информацию, включая линки на устройства с данными. Конечно перед запуском команды надо установить переменные окружения INFORMIXDIR и INFORMIXSERVER, а также ONCONFIG.

среда, 4 февраля 2009 г.

Скоро очередное обновление Informix 11.50.UC4

IBM предлагает поучаствовать желающим в тестировании беты перед выходом основной версии. Что нового собираются включить в UC4:
  • сжатие данных
  • упрощенное администрирование, установка и мониторинг ER с помощью OpenAdmin Tool
  • поддержка вычислительного окружения Amazon EC2
  • поддержка виртуализации VMWare
Подробнее читайте здесь

понедельник, 12 января 2009 г.

Работа с разделами в 11.50.xC3

В версии информикса 11.50.xC3 обнаружил неприятный баг (а когда баги бывают приятными?): при попытке добавить новый раздел (partitions) к фрагментированной по условию таблице, либо при попытке удалить раздел, происходит (не всегда) полное сканирование таблицы, и сам процесс удаления/добавления разделов происходит очень долго либо приводит к длинной транзакции если таблица большая. В предыдущих версиях такая операция даже на больших (размер каждого фрагмента десятки гигабайт) занимала неск.секунд.
Однако такой баг уже вроде бы исправили в версии 11.50.xC3W1 Fix List см. очень похожий APAR IC59271 ADDING A FRAGMENT USING THE BEFORE CLAUSE SCANS ALL FRAGMENTS