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

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

Connection Manager

Клиент информикса версия 3.5xC1 вышел (еще в мае). В клиенте появился новый компонент: Менеджер соединений (Connection Manager). Он позволяет автоматически перенаправлять соединения клиентов в зависимости от нагрузки на серверах к менеее нагруженному серверу в кластере HDR. Кроме того можно реализовать автоматический failover (перенаправление на работающий сервер) в случае сбоя одного из серверов HDR.
IBM - IBM Informix Client SDK v3.50.xC1: Release notes, documentation notes, and machine notes

btscanner и производительность: настраиваем range scan

Ранее я уже писал про btscanner. Сегодня расскажу как его настроить на тип сканирования range scan.
Не секрет что по умолчанию в информиксе btscanner настроен на очистку индексных страниц при помощи способа leafscan, который является довольно затратным и сильно влияет на общую производительность экземпляра при очистке больших индексов. В этом можно убедиться понаблюдав за работой btscanner'a при очистке индексов на больших таблицах: работа нити btscanner приводит к ощутимой нагрузке на диски и буферный пул при таком методе. Чтобы избежать существенного снижения производительности при очистке больших индексов, надо настроить btscanner на другой метод очистки, например range scan. Для настройки есть специальный параметр который надо добавить в файл $ONCONFIG. Например настроим btscanner следующим образом: 1 нитка, минимальный размер индекса для очистки методом range scan не менее 10000 страниц:

BTSCANNER num=1,rangesize=10000

Для того чтобы новые параметры вступили в силу надо перезапустить экземпляр информикса.
То же самое можно сделать и без перезапуска с помощью следующей команды:

onmode -C rangesize 10000

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

Через некоторое время когда накопится статистика, с помощью команды onstat -C можно посмотреть сколько индексов каким способом обрабатывалось, вот пример:

...
Number of leaves pages scanned 420428
Number of leaves with deleted items 23992
Time spent cleaning (sec) 631
Number of index compresses 3940
Number of deleted items 934612
Number of index range scans 100
Number of index leaf scans 562
Number of index alice scans 0

Как видим часть индексов (которые превысили установленный размер rangesize) обрабатываются методом range scan, остальные индексы чистятся как обычно методом leaf scan.

Получаем список нитей для процесса

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


#!/bin/bash
# getuthbypid.sh
# Получение всех пользовательских нитей по заданному PID

if [ ${#*} -ne 1 ]
then
echo Get all user threads by PID
echo USE: getuthbypid PID
echo where PID is process ID
exit
fi

# Получение всех SID по заданному PID
sids=`onstat -g ses|egrep "$1"|awk '{print $1}'`
# Преобразование набора SID в строку с разделителями
siddelim=`echo $sids |sed -e 's/ /|/g'`
# Список user threads
onstat -u|egrep "address|$siddelim"



запускаем данный скрипт с параметром в качестве которого указан process ID клиентского процесса и получаем список нитей с их свойствами (флаги, SID, сколько читает/пишет и т.д.)

Делаем поиск удобным

На домашней странице документации по информиксу 11.5 появились ссылки для добавления поисковых машин по документации в браузер. Установить поиск в браузер можно здесь.

HDR: как secondary сделать на время доступным для обновлений

Бизнес требует от ИТ инфраструктуры постоянной доступности ресурсов и данных. В то же время некоторые задачи (например обновление ПО, модернизация оборудования) требуют перерывов в работе ИТ-сервисов. И здесь встает задача минимальной задержки в обеспечении работы ИТ. HDR обеспечивает высокую надежность и доступность данных, даже когда primary сервер HDR недоступен в течение некоторого времени. В этом случае обновления данных принимает на себя secondary сервер, который на время недоступности primary делается стандартным. После запуска primary репликация HDR восстанавливается в прежнем виде. Далее по шагам объясню как это сделать.

1. Сервер primary выключаем (или он недоступен после устранимого сбоя оборудования)
2. secondary переводим в режим standard:

onmode -d standard

3. клиентские приложения теперь могут работать с бывшим secondary в режиме обновления данных
4. Через некоторое время запускаем primary: переводим стандартный (бывший secondary) сервер в режим quiescent, делаем его вновь secondary:

onmode -s (или -u если требуется немедленно отключить сессии)
onmode -d secondary prm_srv_name

5. Запускаем primary, который накатывает на себя все обновления сделанные на secondary который был в режиме standard

после этого репликация снова восстанавливается.

Данная процедура переключения secondary > standard > secondary при отключенном primary является стандартной и описана в документации.

Сбор статистики по фрагментированной таблице

Как то обсуждая на sql.ru сбор статистики по большим таблицам один из участников обсуждения пожаловался что нельзя собирать статистику отдельно для каждого фрагмента таблицы. Действительно, предположим что есть фрагментированная таблица (или например разбитая на partitions). Если данные в такой таблице меняются только в некоторых фрагментах, а остальные остаются неизменными, то нет смысла запускать сбор статистики по всей таблице. Гораздо рациональнее было бы собирать статистику только по фрагментам с измененными данными. Однако такая возможность сбора статистики в информиксе не реализована.