АнатоЛойRent_y
4541c2c8 4 0x1001 5 2 N informix tempdbs_log
4541c7e8 8 0x2001 14 10 N T informix tempdbs

Темп пространства два - но одно из них логируемое, а второе - нет.
Следовательно, для временных таблиц с "WITH NO LOG" будет задействовано только одно: tempdbs, для временных таблиц без "WITH NO LOG " опять таки только одно: tempdbs_log.
Соответственно и для "внутренних нужд" информикс будет брать только одно.
Для распараллеливания стОит завести ещё хотя бы по одному (temp2dbs и temp2dbs_log)
tempdbs_log горячую актуальность уже потерял (много лет назад он был очень даже нужен :) и его ни увеличивать (зачем было создавать аж 4Гб ?) ни добавлять для распараллеливания второй не нужно. По статистике i/o можно увидеть. что операций там минимум (если они вообще есть).
А вот tempdbs2 я бы все таки настоятельно рекомендовал создать еще один (именно временный dbspace , а не еще один чанк к существующим 10 - зачем, опять таки, столько ? 20Гб временного пространства при базе в 20Гб ??).

zaiets
Судя по диалогу, система у вас от Срфтлайн на их сервере приложений.
Если єто так - в свое время сталкивался краем уха с подобной системой.
Насколько помню - там все достаточно просто - есть некое средство
для построения функционала, которое банально не всегда строит нужніе индексі.
Ага, "просто" и "проще некуда" :)
А индексов там, обычно, с избытком благодаря Информиксу, который обязательно строит индексы на все внешние ключи.
zaiets
Относительно емких статотчетов - пробовали ли смотреть плані запросов?
часто помогает, при чем вставляйте в sqexplain.out периодически запись со временем

Они даже это (получить и проанализировать план запросов) не могут сделать в силу ряда причин.
Не забывай про версию сервера, квалификацию на местах и разработчиков в Киеве, сотни инсталляций с синхронизацией информации вплоть до центра, "старость" проекта, который только сапортится и разработку нового...
Да и ты, если бы увидел один из таких отчетов, в котором задействовано несколько десятков таблиц с десятками процедур - думаю, поскучнел бы :)
zaiets
Возможно, да, нету универсального способа решения проблемі, но можно найти частній, которій удовлетворит на 100% данного клиента.
Денис прав - нужно ріть в сторону запросов.
Если вдруг будете искать стороннего человека - пишите. (мой ник на gmail.com)
Частный способ для конкретного клиента для данной системы не подходит - только для всех систем сразу.
P.S. Топикстартеру - сведите разработчиков с zaiets, если у него есть такое желание - пусть попробует...

Rent_yto vasilis: Во время работы возникают ситуации когда по 14-15Гб tempdbs заполнены - взял с запасом что бы не возникло из-за нехватки места проблем.
Когда еще раз увидите такое заполнение - покажите мне, а то как то с трудом верится (хотя система "развивается" и требования к отчетам растут, т.ч. все может быть :)
Rent_yс tempdbs_log тоже перестраховался - потому что имел не так давно проблемы с не хваткой места в нем правда на региональном сервере.
Ну если там был случайно создан размер в 500К (видел я и такое), то может быть...
Но вы же сами можете проследить заполняемость и активность этого постранства и сделать выводы.
Кстати, т.к. это все таки не настоящее временное пространство, то периодически (после зависаний М и И) там могут оставаться таблицы, коорые со временем могут накапливаться. Но это больше теоретически - на практике за много лет переполнения tempdbs_log (рекомендованных размеров) не видел.

Rent_yto vasilis: Размер был 2Гб. Выполнялась загрузка большого блока данных при помощи набора скриптов - при этом вся работа велась именно с логируемым tempdbs - в результате места в нем не хватило.
Явный баг конкретного скрипта, коорый должен был проявиться не только у вас (если скрипт не ваш :) Где гарантия, что следующий "скрипт" не захочет 10Гб ?
Ну да ладно, убедили - место есть, резервируйте.
Только не думайте, что размеры чанков никах не влияют на производительность.

Журавлев Денисvasilisнастоятельно рекомендовал создать еще один (именно временный dbspace , а не еще один чанк к Тут кстати есть один подводный камень (однажды напоролся), временные таблицы станут фрагментированными (rr), и все запросы select rowid , .... from temp_table будут падать с ошибкой.
Запросы с rowid были с самого начала запрещены, как нарушающие "религию" (да и я к этому "руку приложил" :). А последующие поколения девелоперов о такой фиче даже не подозревали...