Happy new year!

Unfrozen!
С рождеством!
Всем привет! "Многие" спрашивают: почему нет новых постов и вообще будут ли? Отвечаю - будут! Немного про Informix, больше про СУБД с которыми имею дело сейчас, а также про матстатистику, анализ данных, и прочее. Your comments welcome!

Установка JDBC драйвера

При установке новой версии JDBC драйвера Informix может возникнуть проблема - не запускается инсталлятор. Если используется Java 7, то можно попробовать запустить инсталлятор в версии Java 6, поскольку версия 7 пока не поддерживается.
Подробнее см. http://www.stuart-taylor.net/2011/12/ibm-informix-jdbc-driver-version-3-50-install-error-could-not-load-wizard-fixed/
У меня этот способ сработал при установке драйвера версии 3.50

Используем встроенный мониторинг

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

Встроенный мониторинг (оповещение о событиях) в Informix позволяет отслеживать различные важные события которые могут повлиять на доступность датасервера, такие как отказы дисков, ошибки доступа к таблицам, ошибки базы данных, ошибки резервного копирования и т.д.

В Informix встроенный мониторинг управляется параметром ALARMPROGRAM конфигурационного файла $ONCONFIG. Этот параметр задает путь к скрипту ($INFORMIXDIR/etc/alarmprogram.sh для UNIX-систем или %INFORMIXDIR%\etc\alarmprogram.bat для Windows), который выполняется в случае возникновения событий датасервера. Кроме стандартных действий оповещения о событиях, можно создавать свои сценарии обработки событий.
В случае возникновения какого либо события Informix запускает этот скрипт с параметрами важности события, класс события, сообщение а также некоторые другие. Скрипт анализирует переданные параметры и выполняет необходимые сценарии.

Посмотрим как настраивается стандартный скрипт alarmprogram.sh. Здесь под параметрами понимаются переменные в скрипте, если это не сказано иначе.

Прежде всего уровень важности событий, при которых происходит отправка оповещения определяется с помощью параметра ALARMADMIN. Всего уровней 5, и можно гибко настроить тот уровень важности событий который нужен. Если происходит событие с уровнем важности >= значению ALARMADMIN то скрипт отправляет письмо с информацией о событии. Адрес куда отправляется оповещение задается параметром ADMINEMAIL. Если хочется чтобы письма уходили на несколько адресов, можно например сделать ADMINEMAIL=informix а в домашнем каталоге пользователя informix создать файл .forward в котором записать необходимые адреса, по одному в каждой строке.
Тут же можно задать пейджер PAGEREMAIL и утилиту которая отправляет письма с оповещениями MAILUTILITY.

Если требуется автоматическая архивация журналов транзакций, то надо установить параметр BACKUPLOGS=Y и параметр LTAPEDEV=значение (даже если используется onbar вместо ontape, поскольку скрипт анализирует LTAPEDEV из файла конфигурации $ONCONFIG на /dev/null и в зависимости от этого значения запускает или нет команду BACKUP_CMD). Если параметр LTAPEDEV=/dev/null архивация журналов производится не будет (журналы транзакций будут просто циклически перезаписываться).

Параметр BACKUP_CMD определяет чем будет производится архивация журналов транзакций (если BACKUPLOGS=Y). Могут быть варианты onbar или ontape.

Кроме того, запуском самого скрипта ALARMPROGRAM можно управлять. Делается это с помощью параметра $ONCONFIG ALRM_ALL_EVENTS=[0|1]. Если установлено значение ALRM_ALL_EVENTS 0 то скрипт будет запускаться только в случае возникновения событий с уровнем важности выше 1, если ALRM_ALL_EVENTS 1 то для всех событий.

Идентификаторы классов оповещений о событиях для версии 11.50 можно посмотреть здесь.
Идентификаторы классов оповещений для версии 11.70 можно посмотреть здесь.

Этот мониторинг можно применять вместе с мониторингом средствами HealthAdvisor из OpenAdmin, про который я писал недавно.

OAT Health Advisor

В Informix OpenAdminTool появился модуль HealthAdvisor, который позволяет производить мониторинг сервера баз данных и отправляет уведомления если происходят определенные события. Кроме того сам OAT теперь включен в ClientSDK и его не надо скачивать отдельно!
Данная статья сопровождается картинками, но я не знаю как сделать чтобы при нажатии на картинку появлялось увеличенное изображение. Поэтому пока оставляю так как есть.
HealthAdvisor конфигурируется для каждого экземпляра Informix отдельно. Всего для конфигурации представлено 4 вкладки:

Конфигурация HealthAdvisor Profile

На вкладке Profile отображаются доступные профили. Всегда есть профиль default, можно добавить свои профили, которые настраиваются.

Health Advisor Alarms

На вкладке Alarms можно просмотреть предупреждения, которые сгруппированы по категориям. Порог для каждого предупреждения можно сконфигурировать, а само предупреждение можно отключить.

Health Advisor Schedule

Вкладка Shedule позволяет настроить расписание запуска задачи для данного профиля. Не забыть поставить флажок "Enable Task".

Health Advisor Notification

На вкладке Notification конфигурируются почтовые адреса для отправки уведомлений и уровни оповещения (поле When).
Также указана команда (почтовый клиент) которая будет срабатывать на сервере где находится экземпляр Informix при отправке оповещения. Если у вас Informix находится на Windows, то возможно придется изменить эту команду.
Отдельно надо обратить внимание на поле заголовка (subject) письма: гораздо удобнее будет если сделать его как '$INFORMIXSERVER [SUBJECT]' подставив вместо $INFORMIXSERVER имя экземпляра Informix. Тогда в почтовом клиенте будет сразу видно от какого сервера пришло письмо, если у вас их несколько.
Можно сделать рассылку одновременно нескольким адресатам, либо через перечисление адресов в поле "To" на вкладке Notification, или указать адресата informix, а список адресов сделать через файл /home/informix/.forward по одному адресу в каждой строке файла.

После того как Health Advisor настроен, жмем кнопку Run Health Advisor. Здесь есть небольшой баг: время ожидания работы скрипта может быть превышено, и после запуска может появится сообщение об таймауте. Если такое происходит, надо увеличить параметр max_execution_time в файле %PATH_TO_OAT%\PHP_5.2.4\php.ini (этот файл находится на сервере где установлен OAT), например сделать 120 секунд.

Мониторинг свободного пространства в dbspace

Всем хорош мониторинг состояния сервера с помощью alarmprogram.sh, но он к сожалению не позволяет устанавливать пороги оповещения о свободном пространстве в dbspace. Параметр STORAGE_FULL_ALARM позволяет задать уровень оповещения и срабатывание когда dbspace оказывается уже полностью занят.
Написал небольшую процедуру на SPL с помощью которой можно осуществлять мониторинг свободного пространства в dbspace. Пороги срабатывания задаются для каждого dbspace отдельно. При уменьшении размера свободного места ниже установленного порога, процедура в момент очередного запуска обнаруживает это и высылает email с подробной информацией. Для работы необходимо наличие на сервере клиента mailx. Думаю что не проблема переписать процедуру если почтовый клиент другой.

Исходный код проекта как выложил на GoogleCode проект idsmon.

Установка:
- зайти на сайт проекта и скачать исходный код процедуры и таблицы
- создать в базе sysadmin таблицу и заполнить ее значениями alarm levels для каждого dbspace;
- создать в базе sysadmin процедуру проверки и оповещения;
- создать в планировщике informix расписание для запуска процедуры;

Схема работы:

Процедура протестирована и работает на версии 11.50.UC8. В ней используется тип row, поэтому думаю что будет работать и с предыдущими версиями, где есть данный тип. Конечно должна работать и на более новых версиях :)
Расписание запуска процедуры можно установить например 1 раз в каждые полчаса.

MSL готовится к старту на Марс

Через полчаса произойдет историческое событие - старт миссии MSL на Марс. Прямую трансляцию можно смотреть здесь.

Informix SPL и тип запись

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

define
  row_emp employees%rowtype;
...
  select * into row_emp from employees  where employee_id = Val1;

...

  insert into employees values row_emp

...

Причем тип row который есть в Informix, таких фокусов не допускает. Т.е. в нем можно обращаться к отдельным полям через точечную нотацию, но например выбрать всю запись из таблицы в переменную без перечисления отдельных полей не получится. Точно также не работает вставка в таблицу из переменной типа row без указания каждого поля. А еще при объявлении такого типа приходится указывать все поля, что ничуть не способствует сокращению размеров кода.
Пообщался с техподдержкой, сказал что хочу такой синтаксис в SPL, что упрощает разработку процедур, уменьшает вероятность появления ошибок в коде, и вообще это удобно. Человек из техподдержки написал мне, что создаст запрос (видимо выше) для реализации новой функциональности. Может набраться наглости и попросить чтобы сделали реализацию PL/SQL в Informix ? :)

Защита данных при обновлении на новую версию

При обновлении на новую версию Informix есть возможность в случае ошибки обновления, минимизировать время простоя системы. Для этого в версии 11.50 используется новый параметр CONVERSION_GUARD, который определяет возможность быстрого возврата к предыдущей версии системы при возникновении ошибки в процессе обновления на новую версию.
Быстрый возврат к предыдущей версии системы означает использование данных восстановления, которые создаются при конвертации на новую версию, в случае сбоя конвертации. Напомню что раньше при сбое конвертации приходилось делать восстановление сервера из бэкапа.

За использование этой возможности отвечают два параметра конфигурации: CONVERSION_GUARD (режимы работы) и RESTORE_POINT_DIR (расположение создаваемых при обновлении данных для быстрого отката).

По умолчанию в onconfig.std параметр CONVERSION_GUARD установлен в значение 2, что означает продолжить конвертацию даже в случае ошибки создания данных точки восстановления. В документации же указано значение по умолчанию 1, т.е. остановить конвертацию на новую версию в случае ошибки создания данных точки восстановления. Из-за таких нестыковок лучше выставить этот параметр в onconfig явно, причем в значение 1. Для параметра RESTORE_POINT_DIR следует выбрать каталог на ФС с достаточным кол-вом свободного места. Например, при обновлении с 11.50.FC5 до 11.50.FC8 было использовано примерно 500Мб для данных восстановления. Но эта цифра может зависеть от различных факторов.

Установка Informix 11.50 Innovator Edition на Linux

Если при запуске инсталлятора Informix 11.50 Innovator Edition на Linux в консольном режиме получаете ошибку

The wizard cannot continue because of the following error: could not load wizard specified in /wizard.inf (104)

можно попробовать в параметрах запуска инсталлятора указать флаг -javahome и в качестве значения путь к установленной Java Runtime Environment.

truncate и delete: что лучше и когда использовать

Когда требуется полностью удалить все данные из таблицы, прибегают к оператору delete. Его можно использовать в транзакции. Но если данных в таблице много то их удаление может занять продолжительное время, поскольку удаление каждой записи будет записываться в журнал транзакций. Кроме того, место занимаемое таблицей на диске, не будет освобождено: оно останется занято пустыми экстентами таблицы.
На помощь приходит оператор truncate. Он не записывает в журнал транзакций удаление каждой записи, выполняет удаление всех данных из таблицы практически моментально, и для него можно указать освободить занимаемое таблицей место на диске, или оставить с помощью опций drop storage или reuse storage. Однако минусом использования truncate является то что если в транзакции после truncate попытаться выполнить другие действия то получим ошибку: 26021: No operations allowed after truncate in a transaction. Т.е. truncate должен быть либо последним оператором в транзакции, либо выполнятся вне блока транзакции begin ... commit.

Статистика на уровне фрагментов и не только

Есть настолько очевидные вещи, 

что иногда удивляешься, 

почему их сделали 

совсем недавно

Как то я писал, что при работе с фрагментированными таблицами статистика обновляется целиком на всю таблицу. Получается что сервер делает лишнюю работу, если например новые данные добавляются в новые фрагменты, а старые данные, которые находятся в старых фрагментах не меняются. Если схема работы с данными в таблице такова, что данные добавляются и изменяются только в новом фрагменте, то в этом случае ясно, что статистика будет менятся только для этого фрагмента, а для старых фрагментов статистика не меняется. И вот в версии 11.70xC1 сделали статистику на уровне фрагментов. Для использования этой возможности надо при создании таблицы указать опцию STATLEVEL FRAGMENT. Непонятно только как делать обновление статистики по такой таблице, поскольку в UPDATE STATISTICS я не нашел как указывать что статистику надо обновлять на фрагмент. Возможно это делается автоматически, т.е. определяется процент измененных данных во фрагменте и после этого обновляется статистика по фрагментам где было много измененных данных.
Кстати сам процент изменений при которых статистика будет считаться устаревшей на таблице, можно определить при создании таблицы с помощью опции STATCHANGE (действует на уровне экземпляра и на уровне таблицы), и при запуске UPDATE STATISTICS AUTO статистика будет обновляться только для таблиц у которых она устарела. Это свойство относится не только к фрагментированным таблицам. Процент изменений по умолчанию равен 10, но его можно изменить при создании таблицы.

Управляй дисками в Informix легко

В Информиксе начиная с версии 11.70 можно автоматизировать управление дисковым пространством. Теперь можно сконфигурировать Informix на автоматическое изменение размеров чанков или пространств данных, причем дисковое пространство будет браться из одного или нескольких заранее определенных дисковых пулов (storage pool). Чанки для которых разрешено автоматическое расширение, имеют в статусе флагов в 5-й позиции букву E (expanded ?), а для автоматических dbspace в поле flags в 5-й позиции будет стоять буква A (Automatic ?). Дисковый пул (их может быть несколько) может состоять из файлов, сырых устройств или каталогов, для него можно задавать приоритет по которому будет выделятся первоочередной пул.

По умолчанию все dbspace являются автоматически расширяемыми, за это отвечает параметр конфигурации сервера SP_AUTOEXPAND. Также можно настроить тип автоматического расширения: проактивный, при котором пространства расширяются заранее или реактивный, при котором расширение происходит только после полного заполнения пространства с данными, см. параметр SP_THRESHOLD. Эти два параметра действуют на уровне экземпляра Informix.
Также настраивается размер автоматически создаваемого чанка (параметр create size) и размер расширения (параметр extend size). Эти параметры действуют на уровне отдельного dbspace.

Для примера создадим дисковый пул размером 1 Gb в каталоге на файловой системе, размер каждого выделяемого чанка в нем сделаем 100 Мб, и приоритет пула 1:

execute function sysadmin:task('storagepool add', '/datafs/informixdata/storagepool/', '0 MB', '1 GB', '100 MB', '1');

Кстати для каталогов нельзя задать максимальный размер пула, если задать отличный от 0 размер то будет выдана ошибка.

Затем создадим dbspace размером 100 Мб и размером страницы 4 Кб который возьмет место для себя из этого пула:

execute function sysadmin:task ('create dbspace from storagepool', 'testdbs', '100 MB', 4, 0);

Посмотреть какие дисковые пулы есть в Informix можно в таблице sysadmin:storagepool

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

Утилита клонирования 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

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

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

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