среда, 1 декабря 2010 г.

Утилита клонирования ifxclone не работает в Innovator-C

Новая утилита ifxclone упрощает процедуру клонирования серверов для репликации. Для того чтобы создать клон сервера, достаточно скопировать конфиг исходного сервера, создать файлы чанков на целевом сервере и запустить на нем команду ifxclone с нужными параметрами. Т.е. не надо делать сначала бэкап, передачу архива и затем восстановение, с новой утилитой все можно сделать в одно действие. Проблема в том что клонирование не работает на Innovator-C: успешно клонируется rootdbs, а затем делается попытка запустить параллельное восстановление сервера, но не проходит поскольку в Innovator-C разрешено только последовательное восстановление.

Вот кусок журнала:

11:53:17  Physical Restore of rootdbs Completed.
11:53:17  Checkpoint Completed:  duration was 0 seconds.
11:53:17  Tue Nov 30 - loguniq 26, logpos 0x4540b0, timestamp: 0x1b3b54 Interval: 3035

11:53:17  Maximum server connections 0
11:53:17  The edition of Informix Dynamic Server currently running does not support
 parallel backup or restore. Stopping the current process.
11:53:17  Physical restore failed for dbspace number 3.
11:53:17  Snapshot instantiation failed, killing myself.
11:53:18  The Master Daemon Died
11:53:18  PANIC: Attempting to bring system down

Установка параметров отвечающих за параллельное бэкап/восстановление не помогает.

пятница, 12 ноября 2010 г.

IDS 11.70 вышел!

что нового:

Flexible Grid - нечто загадочное и в чем я еще не разобрался,
Быстрое клонирование Primary Server - обещают что теперь для инициализации репликации будет достаточно одной команды, которая автоматизирует процедуру архивации, передачи архива на другую систему и инициализации репликации.
Улучшения ER для поддержки Flexible Grid
Обновление и миграция с помощью ER - позволят избежать отключения серверов HA-кластера в процессе обновления версии ПО.
Улучшение поддержки высокой доступности: возможность продолжить начатые транзакции после сбоя и восстановления Primary Server. Единая команда для мониторинга HA-кластера. Возможность запуска на Secondary Servers операторов определения данных DML (т.е. create, alter и drop теперь можно запускать не только на Primary Servers).

Утилита для создания снапшотов экземпляров Informix (и/или их данных) для дальнейшего распространения.

Расширенная поддержка инфраструктуры хранилищ данных: новые директивы оптимизации, alter fragment online (без блокировки таблицы), новые стратегии фрагментации таблиц, дефрагментация таблиц имеющих много экстентов, отложенное распределение первого экстента при создании таблиц, можно задавать размер первого и следующего экстентов при
создании индекса, автоматическое выделение дискового пространства, статистика по фрагментам

Улучшения для разработки приложений:
- автоматическая регистрация датаблейдов
- отладка SPL в IBM DataStudio, IBM Optim Development Studio (ODS, version 2.2.1.0 or later), или Microsoft Visual Studio
- улучшения SQL синтаксиса, в т.ч. поддержка create table if not exists
- автоматическое отключение сессий, которые долгое время ничего не делают
- другие улучшения

- Выборочный потабличный аудит

и другие возможности. Более подробно читайте в документации по IDS 11.70

вторник, 26 октября 2010 г.

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

No JFS, no RAID5 ?


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

вторник, 12 октября 2010 г.

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

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

четверг, 30 сентября 2010 г.

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, предварительно надо зарегистрироваться.

понедельник, 31 мая 2010 г.

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

Начиная с версии 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.

суббота, 8 мая 2010 г.

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

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


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

вторник, 4 мая 2010 г.

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

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

суббота, 27 февраля 2010 г.

Keep watch over it!

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


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

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

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

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

Итак, задача. Есть тестовый сервер 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к, дальнейшее увеличение прироста скорости не дало.