Ага. Резюме того, что есть.
IDS 9.31FC1
HP A500 9000, 1 x HP PA-RISC 64bit Processor at 440Mhg,
1Gb RAM,
HP SCSI320 INTEGRATE CONTROLLER
2 x 36Gb 15k rpm, организованных в RAID 1 (striping size 16K)

Набор железок слабоват, но жить вполне можно.
К сожалению, с таким обьемом памяти и количеством процессоров, многие радости 9 версии буду не доступны. Поэтому нужно идти по пути экономии, где только можно.

Сразу хочется заметить, что в такой конфигурации железа вы за Informix переплачиваете, так как большая часть его возможностей вам недоступна. Минимум 2 CPU, более менее серьезная система начинается от 4 ну и память конечно. Возможно, что использование старой версии Informix OnLine для вас окажется экономически выгоднее сначало, да и работать она на таком железе будет быстрее, а потом мигрировать на девятку. Ну да это мысли в слух.

Вернемся к прозе. Старые патчи ставить не нужно. Они уже включены в поставку, тут есть нюансы при подготовке рабочего сервера, но для тестового вполне сойдет и так. KAIO надеюсь включили ?

Еще немного о конфигурации железок.
stripping size лучше увеличить до 32К/64К т.к. настроенной базе где то такими блоками и будет происходить чтение.
HP имеет не лучшую архитектуру shared memory, поэтому чем меньше сегментов тем лучше.Старайтесь, что бы у вас было максимум три/четыре сегмента по onstat -g seg.

Еще немного лирики. Идеологически тестовый сервер должен настраиваться как рабочий, т.е. уровень затрат ДБА на настройку почти такой же, поэтому начальная настройка любой серьезной базы достаточно муторное дело, зато потом система стоит 24х7 и если вы думаете, что конфигурация Informix'a сложна и недружелюбна (не один клик), то могу вас уверить, что это неправда ;) это еще очень просто, если мы будем сравнивать с Oracle,DB2.

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

Собственно, приведенный тест можно разделить на три части:
-Создание и загрузка таблиц
-поиск по таблицам
-временные таблицы.
Подозреваю, что все три пункта на стороне Informix'a были выполнены с грубыми ошибками.

1. Создание и загрузка таблиц
Для таблиц принято сначало рассчитывать extent size, чтобы данная таблица лежала в одном непрерывным куском и время не тратилось на переходы по extents
В данном extents случае _должны_ быть рассчитаны для
TaxClassification
ReportData_Operations

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

Тэкс, на пальцах
TaxClassification (500000) + index ~350000K
ReportData_Operations(1000000) +indexes ~170000K
Это очень грубый подсчет(мог чего нибудь и не учесть), если интересно, то более точно пересчитайте сами, но лучше хоть так, чем вообще никак

Далее, не совсем понятна идея тестировани , т.к. это не очень похоже на стандартную загрузку данных, тут Informix будет медленнее, потому что каждый записывается три раза - физический журнал, логический журнал, собственно база, а так как оба журнала и база у вас на одном несчастном RAIDe, это усугубляет, Размер логов уже рекомендовали увеличить, что бы избежать частого переключения.

M$ не имеет/ел(насколько я знаю) понятия физический журнал. Они его только сейчас открывают. :)

Более корретным бы было сравнение утилит загрузки bcp от MS и HPL от Informix'a.
В любом случае, вставки такой интенсивности делаются обычно через курсоры.

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

2. поиск по таблицам
Сбор статистики в правило. Возмите например mkupdstats с http://iiug.org/software/index_DBA.html
и собирайте статистику после окончания загрузки.

3. временные таблицы.
Добавте еще минимум два dbspaces для временных таблиц, умеет работать с ними параллельно и с включенными KAIO, может существенно помочь.
По умолчанию временные таблицы в Informix'e _журналируемые_, обязательно создаваюте временную таблицы с WITH NO LOG.

Конфигурация:

LOGSIZE 8192 (Тут есть разные подходы, но в принципе для теста можно и увеличить до 50-100Мб)
TBLSPACE_STATS 1 (В 0)
NOAGE 0 (в 1)
RESIDENT 0 (-1) (Какой смысл от буферов лежащих в свопинге ? )
BUFFERS 15000 (Уже увеличили по моему и даже без свопинга.)
NUMAIOVPS 1 (Включить KAIO, а этот параметр в 2 или 4)
CLEANERS 1 (8-10)

Вот тут масса вариантов, да еще и связанных с возможностями железок
Можно попробовать выставить
LRUS 1 (127)
LRU_MAX_DIRTY 60 (2)
LRU_MIN_DIRTY 50 (1 )
CKPTINTVL 300 (6000)
Более полно можно почитать дискуссии в newsgroup

RA_PAGES 4 (16)
RA_THRESHOLD 2 (8)
(Уже поменяли, в принципе нужно высчитывать по статистике и типам запросов, в данном тесте особой роли не играет)

DBSPACETEMP tmpdbs (tmpdbs,tmpdbs1,tmpdbs2)

MAX_PDQPRIORITY 100 (0) (Проще выключить, у вас нет процессоров и памяти потдерживать эту роскошь)

OPTCOMPIND 2(0) (По тестовым запросам не видно, что вы нуждаетесь в сверхоптимизации. Этот параметр в OLTP обычно 0)
OPT_GOAL -1 (0 (?) ) (Можно попробовать выставить в 0)

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