среда, 10 декабря 2008 г.

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

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

пятница, 7 ноября 2008 г.

Вышло обновление 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

среда, 10 сентября 2008 г.

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

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

четверг, 31 июля 2008 г.

Connection Manager

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

вторник, 22 июля 2008 г.

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.

вторник, 1 июля 2008 г.

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

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

вторник, 24 июня 2008 г.

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

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

понедельник, 23 июня 2008 г.

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 является стандартной и описана в документации.

вторник, 29 апреля 2008 г.

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

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

пятница, 25 апреля 2008 г.

А вы все еще используете старые параметры VP?

Как известно, параметры виртуальных процессоров в информиксе задаются в $ONCONFIG с помощью параметров AFF_SPROC, AFF_NPROCS, NOAGE, NUMCPUVPS, и NUMAIOVPS. Так вот эти параметры давно (уже года два) не рекомендуется использовать. Вместо них предлагается использовать единые параметры конфигурации VPCLASS, в котором перечисляются все характеристики каждого определенного в информиксе класса виртуальных процессоров.
Приведу пример. Вот конфигурация с использованием старых параметров:

NUMCPUVPS 2 # Number of user (cpu) vps
NUMAIOVPS 2 # Number of IO vps
NOAGE 1

А вот та же конфигурация с использованием нового параметра VPCLASS:

VPCLASS cpu,num=2,noage
VPCLASS aio,num=2,noage

Исключение сделано для сетевых процессоров, для них как обычно используем параметр NETTYPE.

Как видим новая конфигурация позволяет более гибко управлять отдельными параметрами каждого класса VP. Также все параметры сосредоточены в одном месте что также повышает удобство конфигурации.

понедельник, 21 апреля 2008 г.

Используем CSM

Если требуется шифровать трафик от клиента к информиксу, то сделать это довольно просто с помощью Communication Support Module. Например рассмотрим настройку SPWDCSM на клиенте и сервере. Во первых следует уяснить, что если алиас информикса использует шифрование, то на клиенте тоже должен быть настроен CSM, иначе клиент не сможет подсоединиться к информиксу. Ну и во вторых, в Windows CSM стабильно работает на клиенте 2.90.TC6 и 3.00.TC2. На AIX например CSM работает также с использованием клиента 2.90.UC4. Старые версии клиентов, например 2.7 я бы не советовал использовать для работы с CSM.
Итак, настраиваем информикс. В каталоге $INFORMIXDIR/etc (или %INFORMIXDIR\etc для Windows) создаем текстовый файл concsm.cfg куда добавляем строку (пути при этом заменяем на реальные):


SPWDCSM("client=C:\Progra~1\IBM\Informix\Client-SDK\lib\
client\csm\ispws07a.dll,server=libixspw.so","","")


(перенос строки сделал потому что в блоге вся строка не влезает по ширине)

Далее в Setnet32 (для Windows) или в $INFORMIXDIR\etc\sqlhosts (для UNIX) находим нужный нам сервер где будет включен CSM, и в поле Options добавляем строку csm=(SPWDCSM)
Настройку клиента можно считать законченной. Настройка сервера практически не отличается от настройки клиента. В каталоге $INFORMIXDIR/etc создаем текстовый файл concsm.cfg где прописываем строку вида (путь к библиотеке libixspw.so заменить на тот который у вас):

SPWDCSM("server=/informix/test/lib/csm/libixspw.so","","")

и в sqlhosts для информикса в поле Options добавить строку csm=(SPWDCSM). После этого перезапустить информикс и проверить соединение.

Промежуточное обновление для Informix 11.10.UC2 вышло

Вот список исправлений в 11.10.xC2W2:

APAR
Description
IC56222 ABORTED TRANSACTION (ATS) OR DATA CORRUPTION POSSIBLE WITH UPDATE TRIGGER ON REPLICATED TABLE AND PARTIAL ROW REPLICATION
IC54613 BAD PERFORMANCE FOR A QUERY WHICH USES THE IN CONDITION IN THE WHERE CLAUSE
IC54917 THE START_ONPLOAD PROCEDURE IS NOT WORKING ON WINDOWS
IC54955 CONVERSION OF DECIMAL SEPARATOR IS NOT WORKING FOR PARAMETERIZED INSERT
IC55116 ASSERT FAILURE RELATED TO GET_FULL_QBUFH WHEN TSM STORAGE POOL IS FULL
IC55163 HPL: EXCEEDING THE 3^32 NUMBER OF ROWS, THE NUMBER OF ROWS PROCESSED GOES NEGATIVE.
IC55164 DBSCHEMA -D -HD CAUSES ERROR -1215 - VALUE EXCEEDS LIMIT OF INTEGER PRECISION
IC55213 AUTHENTICATION FAILURE ACCESSING REMOTE TABLES FROM TRIGGERS
IC55350 ONBAR REGRESSION ERROR CONNECTING TO IDS WITH LARGE SHARED MEMORY
IC55409 HUGE MEMORY ALLOCATION DURING INDEX BUILD
IC55416 CDR SYNC COMMAND HANGS WHEN COLUMN DATA VALUES ARE OUT OF THE FILTER RANGE IN THE REPLICATE
IC55419 QUERY USING OUTER JOIN RETURNS WRONG RESULT
IC55436 STANDARD MODE INFORMIX INSTANCE BECOMES PRIMARY AFTER RESTART IN A HDR/RSS ENVIRONMENT
IC55455 PHYSICAL RECOVERY CAN HANG IN V11, WHEN USING CONFIGURABLE PAGE SIZE
IC55490 INSTALLING IDS 11 ON A WINDOWS DOMAIN CONTROLLER FAILS WITH NOROLESEP_CREATEINFXUSER 3 ERROR
IC55661 DRDA: SELECT STATEMENTS WAIT FOR A LOCK TWICE THE TIME OF LOCK WAIT TIMEOUT PERIOD
IC55663 CRASH IN SQL WHEN USING SBLOBS IN MTS (XA) TIGHTLY COUPLED APPLICATION.
IC55673 RUNNING ONINIT -S ON HDR SECONDARY CRASHES THE SERVER
IC55983 WINDOWS DOMAIN USERS ARE ONLY ACCEPTED AS DOMAINUSERNAME NOT USERNAME.

пятница, 28 марта 2008 г.

btscanner будет подробно документирован?

Почитал исправления ошибок а также известные ошибки для версии информикса 10.00.UC8 и нашел любопытную запись:

...
IC54482 ONLINE-DOCUMENT DOCUMENTATION FOR BTREE SCANNER AND ALICE MODE IS INCOMPLETE
...

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

четверг, 20 марта 2008 г.

Комментарии в блоге

Включил добавление комментариев в блоге только для зарегистрированных пользователей сервиса blogger.com и для пользователей децентрализованной системы идентификации OpenID. Сделано это с целью защиты блога от спама. Если вы не являетесь пользователем сервиса blogger то для добавления комментариев можно зарегистрироваться у одного из провайдеров OpenID (совершенно бесплатно), после чего вы будете иметь право добавлять комментарии (причем не только в сервисе blogger.com но и в других сервисах, например livejournal, не регистрируясь на самом сервисе). Вот здесь очень подробно написано что такое и для чего нужен OpenID. Аккаунт OpenId можно получить например здесь myOpenID или здесь Verisign

вторник, 19 февраля 2008 г.

Вышел IDS 10.00.xC8

В release notes вроде ничего нового не написали. Значит отличается от предыдущих только исправлением ошибок?

пятница, 15 февраля 2008 г.

Краткое руководство по TLR

TLR - Table Level Restore, восстановление данных на уровне таблиц. Позволяет восстанавливать определенные таблицы на момент времени от нулевого бэкапа, не восстанавливая данные всего сервера. Это очень полезная функция, и появилась она впервые в 10 версии Информикса.
Для того чтобы иметь возможность использовать TLR, необходимо чтобы была включена архивация журналов транзакций в информиксе, а также наличие архива level-0. Таблицы, которые были созданы после архива level-0 не могут быть восстановлены с помощью TLR. Можно делать либо только физическое восстановление таблиц, или восстановление на момент времени после level-0. Также можно восстанавливать таблицы на другом сервере, что позволяет осуществлять миграцию выбранных данных между серверами информикс.

Подготовка к TLR

Вначале необходимо настроить конфигурационный файл $INFORMIXDIR/etc/ac_config.std. Положение этого файла может быть и другим, тогда его необходимо установить в переменной окружения AC_CONFIG.
Вот пример этого файла:

AC_MSGPATH /tmp/ac_msg.log # archecker журнал сообщений
AC_STORAGE /mnt/ac_storage # Каталог для временных файлов
AC_VERBOSE 1 # 1 вкл.сообщения 0 выкл.сообщения

Как видим все там очень просто и особых комментариев не требует. Каталог в AC_STORAGE должен иметь достаточно свободного дискового пространства для восстановления, иначе получим сообщение об ошибке в ходе восстановления.

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

database adm;
create table source (

id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in datadbs;

create table dest (

id serial,
fname varchar(15),
sname varchar(15),
station_id integer,
is_enabled boolean) in admdbs;

insert into dest select * from source;

restore to '2008-02-10 15:30:00';


При восстановлении на момент времени необходимо установить переменную окружения GL_DATETIME. Для таблиц необходимо указывать только список полей с типами данных и в каком dbspace они лежат. Остальные опции (констрейнты, индексы и т.д. игнорируются и их можно не включать). Как видим, исходная таблица source из базы adm восстанавливается в таблицу dest в той же базе но в другом dbspace, на момент времени '2008-02-10 15:30:00' после нулевого архива. При этом сама таблица source в ходе восстановления не затрагивается.

Запускаем TLR с помощью команды archecker -bvs -f cmdfile
Флаг -b предлагает искать данные и транзакции через интерфейс XBSA (т.е. если журнал транзакций архивируется с помощью onbar). Если используется ontape, то вместо флага -b надо использовать флаг -t.
Флаги -v и -s управляют выводом информационных сообщений. Флаг -f указывает расположение командного файла.

В ходе работы TLR вначале происходит поиск таблицы в архиве, затем таблица извлекается, и если надо, на нее накатываются транзакции. Сообщения о работе archecker пишет в лог который указан в AC_MSGPATH конфига.

Performans Tips:

Если требуется восстановить сразу несколько таблиц, их можно указать в одном командном файле и восстанавливать одновременно. Это быстрее поскольку сканирование архива и журналов происходит только один раз.
Можно делать физическое восстановление в external table, которая на самом деле является текстовым файлом с разделителями.
В командном файле можно указать другую базу для восстановленной таблицы, и например другой сервер.
В ходе восстановления можно фильтровать данные с помощью условия в операторе insert into ... select from ... where filter.

четверг, 31 января 2008 г.

Немного про btscanner

Итак, начну с того что настройки сканера по умолчанию (threshold 5000 и тип сканирования leaf scan) зачастую приводят к высокой нагрузке в системах где преобладают модификации данных. При таких настройках работа btscanner существенно нагружает процессоры и диски сервера, что совсем не в лучшую сторону сказывается на производительности пользовательских транзакций.
Информикс располагает двумя (начиная с версии 9.4) и тремя (начиная с версии 10) способами очистки индексных страниц:

1 способ это leaf scan, при котором каждая индексная страница перед очисткой загружается в буферный пул информикса. Эта особенность работы и является основным недостатком данного способа:
при больших размерах индексов происходит активное вытеснение страниц данных и индексов из буферного пула страницами очищаемого индекса, что в свою очередь приводит к высокой нагрузке на дисковую подсистему.

2 способ это range scan. Основное преимущество этого способа очистки индексов состоит в том что в буферный пул индексные страницы не загружаются. Вместо этого используется пул в виртуальном сегменте информикса, т.н. "легкое сканирование". В результате нет конкуренции за буферный пул между сканером и пользовательскими сессиями. Ограничение работы range scan: таким способом очищаются только detached-индексы, т.е. индексы находящие ся в собственном разделе (такие индексы появились впервые в версии 9.30). Attached-индексы как обычно будут очищаться методом leaf scan.

3 способ, который появился впервые в 10 версии информикса называется ALICE (Adaptive Linear Index Cleaning). Этот способ использует битовые карты для очистки индекса. Это позволяет загружать только определенные группы страниц индекса для очистки, что очень хорошо влияет на производительность btscanner.

Т.о. самым производительным является для btscanner режим работы ALICE. Тем не менее это новый тип сканирования и в нем могут быть свои баги.

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

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

Как создать файл

Многие спрашивают: как создать пустой файл для чанка на файловой системе?
Отвечаю: есть по крайней мере три способа это сделать. Первый способ это использовать команду touch. Второй способ - это команда cat. И третий способ, самый извращенный это использование текстового редактора, например vi. И это не полный список способов создания пустого файла :)))

вторник, 22 января 2008 г.

Используем символические ссылки вместо прямых путей

Есть очень хорошее правило которому я всегда следую: никогда не указывать прямых путей к чанкам при создании dbspace и добавлении новых чанков. Всегда указывать пути к чанкам через символические ссылки. Почему? Представим следующую ситуацию: сервер информикс имеет dbspace с чанком и при создании этот чанк был указан по прямому пути. Однажды диск где лежат чанки ломается. На сервере полно места на других дисках, но при создании dbspace был указан прямой путь и чтобы восстановить поврежденные чанки из бэкапа, надо указывать старый путь, которого больше нет. Например если поврежден диск /dev/sdb1 (при использовании сырых устройств в Linux) то надо вместо него поставить в систему исправный чтобы начать восстановление, а если его нет то восстановление затягивается. Немного проще если чанки лежали на файловой системе - тогда можно путь этой ФС подменить другой смонтированной по этому пути файловой системой.
Зато если использовать символические ссылки, то таких проблем не возникнет: имя ссылки может оставаться прежним, а направить ее можно в любое место на файловой системе или диске. Так можно делать в Unix (AIX, Linux и др. системах).
В Windows на NTFS символических ссылок вроде бы как и нет. Т.е. простых средств для их создания, которые бы шли вместе с системой я не знаю. Зато есть утилиты сторонних производителей, которые позволяют задействовать эту функциональность NTFS. Например программа junction фирмы Sysinternals. Но опыта использования этого средства для указания путей к чанкам в Windows я не имею.