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

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

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

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

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

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

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

IBM предлагает поучаствовать желающим в тестировании беты перед выходом основной версии. Что нового собираются включить в UC4:

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

Подробнее читайте здесь

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

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

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

Как быть если требуется перенести большой объем данных из одной таблицы в другую? Можно воспользоваться например выгрузкой данных в промежуточный файл. Если данных не очень много то можно попробовать использовать прямую вставку с помощью 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, которое выбирается индивидуально исходя из настроек сервера и размера записи в таблице-источнике. Опционально можно эксклюзивно блокировать таблицу источник и таблицу приемник, выставлять нужный уровень изоляции и т.д.

Вышло обновление Informix 11.50.xC3

Вышло очередное обновление ветки 11.50 Informix 11.50.xC3. В новой версии появились следующие возможности:

Использование SQL Admin API для установки конфигурационных параметров.
Это значит что можно через SQL команды SET ONCONFIG менять конфигурационные параметры. Раньше конфигурационные параметры можно было менять только командами onmode либо непосредственно с помощью текстового редактора.

Динамическое изменение параметров для длинных транзакций LTXEHWM, LTXHWM, и DYNAMIC_LOGS.
Теперь без перезагрузки сервера можно менять эти параметры, что очень необходимо в некоторых случаях.

Улучшенная трассировка SQL с помощью Admin API.
Теперь можно задавать уровень трассировки для отдельной базы и отдельной сессии, а также приостанавливать и возобновлять трассировку без перераспределения ресурсов.

Изменение первого экстента таблицы
Экстент может быть изменен при перестроении либо добавлении нового фрагмента таблицы.

Откат транзакции и Savepoint
Позволяет откатывать транзакцию к определенной точке, которая была заранее объявлена.

Capturing Transactional Data with the Change Data Capture API
Непонятно пока что это такое, надо читать документацию :)

А также ряд других улучшений.

Подробнее читать здесь IBM Informix Dynamic Server v11.50 Information Center

Разделяй и властвуй или когда данных ну очень много

Комментарий к статье Data Partitioning with Informix Dynamic Server от 2.09.2008 из IBM Database Magazine

Базы бывают маленькие, большие и ну очень большие. И любые вычислительные системы имеют свои ограничения, если это не ZFS (хотя и ZFS тоже имеет ограничения, но они трудно достижимы). И если в случае с маленькими базами проблем с ограничениями как правило не возникает, то для больших баз это становиться актуально. Одно из таких ограничений это кол-во страниц на фрагмент, т.е. Data pages per fragment 16,775,134. Если таблица состоит из одного фрагмента (не фрагментирована) то у нее может быть не более чем указанное выше число страниц. Как избежать такого ограничения? Фрагментировать таблицу по какому либо условию. Либо переложить таблицу в dbspace с размером страницы побольше (макс.кол-во страниц останется тем же, но максимально возможное кол-во записей конечно увеличится), а можно сделать и то и другое. В 10 версии информикса появилась такая удобная штука как разделы (partitions). По сути это те же фрагменты с одним отличием: разделы могут лежать не только в разных dbspace (как фрагменты) но и в одном. После того как таблица фрагментирована, очередной фрагмент можно добавить используя attach существующей таблицы такой же структуры, либо выполнив оператор alter fragment on table ... add partition partname expression in dbspace что конечно же проще, чем создавать вначале новую таблицу а затем присоединять ее к фрагментированной.