Есть кубик Material Stocks/Movements(свой, немного изменен от стандарта добавлением полей)... в нем несколько некумулятивных показателей. Грузим Инит-запрос - 1млн 40 тыс. записей. Делаем сжатие - проходит - в таблице Е становится 2 млн записей(по доп. записи на поинтер). Но когда грузим следующие дельта запросы(по 5 тыс. записей), то не хватает памяти для сжатия - не хватает 20 Гигов...не получается сжать ни один запрос. размер Е таблицы - 1 Гиг.
Кто-нибудь знает как можно решить эту проблему?

Можно посоветовать попросить базисников посмотреть все логи БД. Надо попытаться понять, при выполнении какой операции система "валится". У меня было похожее, вычислили таблицу и вычислили undo-сегмент, который выдавал проблему. Решили простым расширением сегмента. Однако пришлось расширить до 200 гбайт. У меня Oracle.

...DB2... только 20 гигив это был максимум что естъ.....

Фишка здесь в том, что нам "кажется", что операция простая. Ну чо там, подумаешь, взять из одной F-таблицы и записать в другую, при этом просто ИД request-a просто удалить и сагрегировать как надо. А на самом деле, хрен поймёшь, что там действительно происходит, пока все логи не проанализируешь. Система, наверняка, прежде чем сжать, не только таблицы фактов, но еще и все таблицы измерений пытается в Undo-область забэкапить, да еще попутно с десяток операций делает, наверняка много сегментов задействовано... Я не знаю, к сожалению, как DB2 работает...