База у вас маленькая
SCO - это уже не продукт. В случае возникновения проблем железяку найти на замену еще то занятие было даже лет 8 назад.
IDS 7.30 - тот еще продукт, хоть и работает.

Вам нужен на данный момент не столько специалист Informix, сколько админ SCO.
Как диски разбиваются в SCO уже не помню.
Но,
1. В устройстве /dev/rdbstore скорее всего уже нет места, а если и есть никто не отменял ограничение в 2Г.
2. Вам нужно найти место откуда добавить.

Наиболее простой способ - создать файл на ф.с.
например
touch /home/informix/workdbs_2
chmod 660 /home/informix/workdbs_2
chown informix:informix /home/informix/workdbs_2
и добавить новый чанк:
onspaces -a workdbs -p /home/informix/workdbs_2 -o 0 -s <size in kb>

На вашем месте я сейчас бы быстро добавил чанк на том, что есть
и менял бы платформу
например, если принципиальна лицензионная чистота, протестил бы бесплатную версиюю 11.70 и перешел бы на нее
В вашем случае SCO это ящик пандоры

Со времен 7.30 много чего изменилось как в железе так и в системном ПО.
А сколько видит ЦПУ ОС?
Рекомендовалось использовать либо VPCLASS либо NUMCPUVPS, AFF_SPROC и AFF_NPROCS.
И нужна ли эта привязка? ЦПУ, которое видит ОС, это далеко не всегда ядро, а планировщик Информикс желает лучшего.

aist-pskзагоняю запрос который работает без индексов , запускаю top
вижу :
4 ядра
100 % загружен только одно ядро и это ядро в течении времени скачет по кругу : cpu3->cpu2->cpu1..
соответственно на верху top висит одни oninit c 100 % загрузкой cpu
когда запускаю паралельно другую сессию - вижу что в топе вверх подскакивает второй oninit, который загружает другой core

вот как это всё правильно интерпретировать ?

Запуская 1 запрос, ві получаете 1 нить, которая связана с каким-то Informix Virtual CPU.
Помимо єтой активной нити есть еще куча процессов, которіе хотят процессорного времени.
Соответственно шедулер ОС и перенаправляет на кажущиеся ему подходящие ЦПУ
Шедулер информикса устроен по тупому, по моим наблюдениям в первую очередь нагружені первіе виртуал ЦПУ(для моего окружения).
Если действиельно есть предпосілки, чтобі привязать виртуал ЦПУ к конкретному ЦПУ - попробуйте сделать єто средствами ОС - команда taskset. На IDS 10.00, например, средствами Информикс привязка шла только до 32 virtual cpu. привязку делали средствами ОС(дурью маялись пока не нашли грузящие запросі).

Запуская вторую сессию, планировщик информикс вешает нить на другой виртуал ЦПУ.
Собственно он тоже хочет есть и загружает второе ядро.

Необходимость привязки ЦПУ - вещь довольно специфичная и не всегда нужна. То, что кочует процесс - не обязательно плохая примета.

Попробуйте привязать процесс к ядру средствами ОС и сравнить резельтаті віполнения операций на сервере с привязаннім процессом и нет.