Скажи нет JFS и RAID5 для файлов баз данных

No JFS, no RAID5 ?

Интересная заметка в блоге Art Kagel на тему использования журналируемых ФС для файлов баз данных. Вообще я давно подозревал что дополнительное журналирование на уровне файловой системы (ФС) ухудшает производительность СУБД. Во первых СУБД и так обеспечивает журналирование и восстановление данных, это заложено в ее архитектуру. Может быть журналирование на уровне ФС обеспечит дополнительную защиту? Но оказывается что это не так. Дополнительный слой в виде журналирования ФС может снизить надежность хранения данных. Даже если производится только журналирование метаданных - результат скажется на производительности базы, поскольку на уровне ФС блоки файлов данных базы могут оказатся в разных местах диска и возрастет фрагментация.
Автор заметки предлагает использовать для хранения файлов базы либо сырые устройства, что логично, или старую добрую ext2 которая не имеет журналирования.
Вот что касается опции журналирования - ее что, совсем нельзя отключить на ext4 например? А JFS в AIX, у нее как обстоят с этим дела?

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

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-платформах.

IBM выпустила бесплатную версию Informix

Мощный двигатель вашего бизнеса - бесплатно

Informix Innovator-C - бесплатная редакция СУБД Informix. Новость немного устарела, поскольку эта редакция была выпущена IBM еще в июне этого года. Эта версия имеет следующие возможности:

- использует 1 физический процессор с не более чем 4 ядрами (вы можете запустить его и на более мощных процессорах, но использоваться будут только максимум 4 ядра)
- использование не более 2 Gb RAM на установку
- неограниченное! дисковое пространство для базы данных
- бесплатна для разработки, тестирования и производства
- поддерживает HDR включая обновляемый Secondary сервер (обновляемый Standby в терминологии других СУБД)
- поддерживает ER (потабличная репликация)
- поддержка Continuous Log Restore (CLR) secondary
- а также поддержка DataBlade и Java UDR
- Informix Innovator-C поддерживает платформы: Linux 32 и 64bit, Windows, AIX, Solaris, Mac

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

Немного информации для тех кто не знаком ранее с технологиями Informix.

Технология HDR (High-availability Data Replication) обеспечивает поддержку высокой доступности данных, это возможность реплицировать данные всего сервера баз данных по сети на вторичный сервер в синхронном или асинхронном режимах, что позволяет иметь запасной резервный сервер баз данных на случай сбоя основного сервера СУБД. Кроме того вторичный экземпляр СУБД может выполнять запросы только для чтения или даже обновлять данные. HDR проста в установке и обслуживании.

Технология ER (Enterprise Replication) это потабличная репликация данных на удаленный сервер с разными режимами. Innovator-C поддерживает Multu-Master репликацию, т.е. в обе стороны.

Continuous Log Restore (CLR) secondary позволяет подключить дополнительный экземпляр СУБД, на который передавать журналы транзакций, что обеспечивает систему дополнительной копией данных основного сервера.

Лицензия позволяет использовать для Informix Innovator-C с 1 основным и 1 вторичным сервером HDR. Также можно включить ER репликацию с двумя узлами.

Скачать Informix Innovator-C для разных платформ можно на сайте IBM, предварительно надо зарегистрироваться.

Динамический запуск листенеров

Начиная с версии 11.50.xC6 в Informix появилась возможность динамического создания листенеров. Предыдущие версии позволяли конфигурировать и запускать новые листенеры только путем перезапуска всего экземпляра сервера, что иногда создавало определенные неудобства. Теперь можно проводить запуск-останов листенера без перезапуска всего сервера. Для этого используется команда  

onmode -P [start|stop|restart] servername

перед ее использованием надо чтобы в файле $INFORMIXDIR/etc/sqlhosts был определен необходимый алиас (алиас можно занести в файл sqlhosts также без перезапуска сервера). Т.е. сценарий работы такой: определяем необходимый алиас srvname в файле sqlhosts, если хотим запустить новый листенер, затем запускаем этот алиас с помощью команды onmode -P start srvname и подключаем к нему клиентские приложения. Если небходимо остановить этот алиас, то запускаем команду onmode -P stop srvname. В online.log при этом будут появлятся сообщения о запуске или останове этих алиасов.
Посмотреть какие листенеры запущены в данный момент можно с помощью команды onstat -g ntt.

День Победы - 65 лет Великой Победе

Пол-Европы прошагали, пол-Земли ...


Памяти всех, кто сражался за Победу и победил, благодаря которым мы есть на свете и можем жить в мире ...
Посвящаю двум моим дедам, прошедшим войну, и победившим. Они дошли до Берлина и вернулись. Вечная память.

Оптимизация использования буферных пулов и нагрузки на диски

В любой базе данных есть таблицы которые занимают много и даже очень много места на дисках. Также есть таблицы которые на дисках занимают места мало. В старой модели использования буферного пула в Informix, все таблицы должны были разделять один и тот же буферный пул. Существенный минус такой модели состоит в том, что при частом использовании больших таблиц, возникал эффект вытеснения страниц остальных таблиц в буферном пуле, в результате чего увеличивалась нагрузка на диски, поскольку требовалось повторное чтение страниц таблиц, которые были замещены страницами больших таблиц. Частично эта проблема в Informix решалась с помощью использования Light Scan, когда страницы больших таблиц считывались в специальные пулы в разделяемом сегменте памяти, но не в буферный пул. Однако такое поведение работает далеко не всегда, должен соблюдатся целый ряд условий, чтобы Light Scan работал. Начиная с 10 версии Informix появилась возможность размещать таблицы в dbspace с размером страницы 2, 4, 8, 16, 32Кб, и назначать таким dbspace соответствующий буферный пул. Таким образом можно разделить большие таблицы и все остальные, и снизить конкуренцию за буферный пул между таблицами.
На практике это делается так. Сначала анализируем базу на предмет наличия больших таблиц, которые часто читаются или модифицируются. Либо на этапе проектирования выявляем таблицы, которые в будущем существенно вырастут по сравнению с остальными. Затем создаем непосредственно хранилище для таких таблиц. Допустим на данной платформе размер страницы по умолчанию в Informix 4Кб. Для больших таблиц надо создать dbspace с размером страницы например 8Кб а также создать буферный пул с таким же размером страницы 8Кб.

Предварительно конфигурируем буферный пул, например размером 512Мб или 65536 буферов по 8Кб в файле $ONCONFIG:

BUFFERPOOL size=8K,buffers=65536,lrus=127,lru_min_dirty=50,lru_max_dirty=60

Создаем dbspace с именем bigdata8k, размером страницы 8Кб и размером первого чанка 25 Gb:

onspaces -c -d bigdata8k -k 8 -p /informix/data/bigdata8k.000 -o 8 -s 26214384

Теперь можно либо перенести в новый dbspace большие таблицы, либо создать в нем новые.

Upd. Для версии Informix начиная с 11.50.UC6 можно глобально включить Light Scans с помощью параметра конфигурации BATCHEDREAD_TABLE, или же то же самое можно сделать для отдельной сессии с помощью set environment IFX_BATCHEDREAD_TABLE "1";
Это конечно же не отменяет преимуществ использования больших таблиц в отдельных dbspace с буферными пулами, а прекрасно дополняет эту возможность.

Keep watch over it!

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

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