Не знаю, о каких "системных ресурсах" идёт речь - но подозреваю, что это не DB2 жалуется.
Temporary tablespace используется для сортировок и группировок, если результат не влезает в ОЗУ. Если в запросе ничего изменить нельзя (скажем, сделать так, чтобы количество обрабатываемых данных было меньше), надо хотя бы попытаться изменить план выполнения этого запроса. Скажем, возможна такая ситуация, когда есть подходящий индекс, который и решил бы проблему, но статистика несвежая и потому выбирается неправильный план. Отсюда надо было бы выяснить, собирается ли на базе статистика, и как. Возможно, инсталлятор 1С как-нибудь настраивает автосбор. То есть, надо почитать документацию 1С по этой теме.
Положим худший случай - этот вопрос игнорируется и 1с, и DBA. Тогда я попробовал бы запустить скрипт типа такого, чтобы сгенерировать другой скрипт, чуть подправив, и запустить его тоже:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CONNECT
TO имябазы
USER имяюзера
USING пароль;
SELECT
'RUNSTATS ON TABLE '
||'"'||trim(t.tabschema)||'"'|| '.' ||'"'|| t.tabname||'"'
||' WITH DISTRIBUTION AND DETAILED INDEXES ALL;'
FROM SYSCAT."TABLES" T
WHERE t.type = 'T'
ORDER BY t.tabschema, t.tabname;
Ну, или в Control Center по менюшечкам полазить, не забыв отметить сбор статистики распределения и по индексам...
Второе - возможно, подходящих индексов нет, но их можно было бы попробовать создать. Для начала надо идентифицировать проблемный запрос. Есть разные способы, но в этом случае, поскольку выполнение длится очень долго и пухнет tempspace, это должен быть один запрос, и, наверное, вполне сойдёт программа с
http://members.tripod.com/chuzhoi_files/index.html
Потом надо скормить этот запрос, скажем, штатной db2-шной утилитке db2advis. (Предварительно придётся создать explain tables). Есть значительные шансы (хотя и нет гарантии), что он предложит создать полезные индексы для большого-большого ускорения.
