IDS_adminНастало время мигрировать сервер БД.
Рекомендую обязательно прочитать соответствующий документ типа Migration Guide для target версии. Можно потом сэкономить кучу времени не наступая на старые грабли.
Напомню, что миграция (и способ) сильно зависит от того "с какой и на какую версию" и с какой платформы на какую.
IDS_admin Рассматриваем вариант с Linux (RH-подобный, скорее всего CentOS 5.3) и 10ый информикс.
Все таки 10-ке уже много лет и ее "End of Support" наступает всего лишь через год (сентябрь 2010).
IDS_admin Памяти в новый сервер не жалеем, планируем 8-32 ГБ. Хотим отдать максимум IDS, поэтому целим на x64.
Большой объем ОП для IDS не всегда панацея, а для некоторых систем (типа чистого DW) даже и не нужен. Не забывайте, что с увеличением буферного пула возрастает и время КТ, что для некоторых систем может быть критично. Т.е. требуется тщательное тестирование системы на новой конфигурации и тонкая настройка.
IDS_admin 1) Уважаемые, подскажите п-та, есть ли какие-нибудь особенности работы с IDS на 64 битной платформе?
есть мелкие, но не существенные. Помню, некоторые утилиты в той же 10-ке не всегда адекватно видели предоставленный объем памяти, ...
IDS_admin 3) Есть ли вообще смысл отдавать много памяти IDS? Понимаю, что зависит от конкретных задач, но как понять, что увеличение ОП даст прирост в скорости?
Для OLTP систем обычно смысл есть хотя бы за счет увеличения буферного пула (можно даже все активные таблицы и индексы туда затолкать), ускорения сортировок и PDQ, уменьшения физического вв/выв на tempdbs. Есть различные ухищрения по переносу временных пространств на виртуальные диски (например, в памяти организовать парочку tempdbs по 2Г), что может очень существенно ускорить некоторые запросы.
А прирост (или падение :) в производительности нужно просто измерять - методику тестирований/измерений/бенчмарков много раз описывали, но только на своей конкретной системе. Для этого берете или ряд типичных, наиболее часто используемых прикладных запросов, или ряд длинных отчетов или просто пишете свою тестовую приблуду с использованием прикладной системы, которая зафиксирует время многократного выполнения и вычислит среднее. Естественно. на старой системе это надо сделать обязательно до миграции. Заодно, с помощью своего бенчамарка, сможете и отконфигурировать (покрутить параметры) Информикс в нужном направлении.

IDS_admin
Миграция основная с 9.40. И еще несколько табличек из 7ки. Думал мигрировать через dbexport/dbimport. Время позволяет. Есть ли другие варианты, если таргет-версия - 11.50FC4?
Варианты всегда есть :)
Как минимум, есть еще HPL и собственные скрипты для больших объемов и ограничений по времени. Можете посмотреть следующие статьи из FAQ - надеюсь, найдете полезные советы.
http://www.sql.ru/faq/faq_topic.aspx?fid=710 (особенно п.4)
http://www.sql.ru/faq/faq_topic.aspx?fid=587
http://www.sql.ru/faq/faq_topic.aspx?fid=588

IDS_adminvasilis Есть различные ухищрения по переносу временных пространств на виртуальные диски
Да, об этом тоже думал. Даже хотел сделать отдельный dbspace на виртуальном диске, и скинуть туда read-only таблички. Копии, естественно, держать на диске и при загрузке наполнять виртуальный диск.
Я бы этого не советовал. При крахе сервера или его восстановлении у Информикса "голова может закружиться".
Я имел ввиду именно временные пространства, которые используются для временных таблиц и файлов.
IDS_admin А при каких операциях активно используются tempdbs? На что хоть примерно рассчитывать?
Во многих системах половина вв/выв приходится на временные пространства.
На эту тему много написано, как здесь, так и в руководстве администратора.
см. http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp
В Руководстве администратора:
"Создание временного пространства баз данных"
"Временные пространства баз данных"
а также "DBSPACETEMP" из Справочника алминистратора.
затем Performance Guide.

zaiets9. При миграции с 9.40 для частистраниц будет изменено bitmap mode.
если не трудно, поподробней.

IDS_admin
Т.е. у меня есть 2 постоянно работающие: БД 7.31 и 9.40. Я хочу сделать миграцию всех таблиц в одну БД на сервере 11.50. Но я не хочу "лежать" N часов, пока у меня на 11.50 загрузятся данные и построятся индексы.
Базы одной структуры для одной и той же прикладной системы или это разные БД ?
IDS_admin
2) Я не совсем понимаю ситуацию с физическим экспортом. Есть у меня БД. Данные постоянно меняются (OLTP). Я делаю в 12:05 ontape -s . Экспорт закончился в 14:05.
Затем делаю физический импорт на другой сервер с той же версией IDS и тем же лейаутом . будут ли у меня данные, актуальные на 12:05? Т.е. если в момент физ. экспорта прошел какой-либо INSERT, он попадет/не попадет/может попадет на мою ленточку?
Исходная БД в unbuffered mode.
Вам уже ответили, что все данные у вас будут на момент начала выполнения архива.
Для вашей задачи (максимально точно сделать копию данных на другом сервере) может помочь HDR. Почитайте в руководстве администратора, как его включить и потом выключить после полной синхронизации в любой удобный момент.