При загрузке данных в куб, возникает ошибка о нехватке места для внутренних таблиц "No roll storage space of length 2965512 available for internal storage.
" ошибка TSV_TNEW_BLOCKS_NO_ROLL_MEMORY.
Происходит это когда в start routine куба выполняется такой вот select



В общем, ничего особенного, нужно читать все данные которые соотв. тем что в source package.
Данных в DSO довольно много, соответсвенно понятно почему такая ошибка может возникать. Увеличить место для внутреннего хранилища на севервере пока невозможно, соотв. нужно искать другое решение.
Вопрос - можно ли как-нибудь изменить размер source package? Если можно, то где?
Я пытался менять размер пакета в DTP, однако это никак не влияет (по умолчанию стоит 50.000, ставил 20.000 и 5.000 и даже 1.000, ошибка одна и та же почти мгновенно после запуска).

1. Не забывайте к тому же проверять Internal Table на условие IS INITIAL.


Вы используете FOR ALL ENTRIES IN если вы не проверяете на условие IS INITIAL, то будут считаны все записи. Кроме того без этой проверки не будет уверенности, что переменная глобального кэша была заполнена корректна предыдущим пакетом.
2. Можно ли изначально грузить данные частями? Например не по годам, а помесячно?

Частями было бы хорошо. Но в фильтре никакие значения по датам недоступны (даже непонятно каким образом выбираются поля в фильтр DTP). А менять start routine и там фильтровать.. как-то даже не знаю.. в смысле поменять start routine на определённый диапазон дат, прогрузить, потом следующий и т.п.?

А чем поможет is initial в данном случае?

1. .
Я потому и сказал что изначально возможно ли ограничить диапазон загрузки. Уж если нельзя увеличить память, то копайте в сторону уменьшения исходной выборки данных, и по пакетам.
2.
Хмм, тот кто будет потом сопровождать систему хорошим словом не помянет. Однозначно нет.
3.
Смотри выше.

Имхо, пояснить бы задачу. Неясно чем вызвана необходимость зачитать во внутреннюю таблицу сразу все.

В этом плане IS INITIAL проверяется..

Вот именно в этом и вопрос - как уменьшить размер пакета. Я так понял что опция Package size указанная в DTP, никакого отношения к этому не имеет, это какая-то чисто техническая характеристика, уменьшал и увеличивал результат один и тот же. Вся проблема в собственно размере внутренней таблицы SOURCE_PACKAGE, почему-то данные считанные по ключу из SOURCE_PACKAGE в другую внутреннюю таблицу, уже не не помещаются в памяти. Как менять её размер и загружать пакетами или фильтровать порциями по возрастанию - непонятно

Задача довольно неинтересна чтобы пояснять подробно и ничего это не прояснит. Это было сделано до меня якобы для "увеличения производительности", потом в рутинах при обновлении конкретных полей читается каждый раз именно внутренняя таблица а не делается каждый раз SELECT. Причём для меня это не особо аргумент, если SELECT обычный и не вложенный, он порядочно кешируется и толку от переписывания его результата во внутреннюю таблицу - не много. На самом деле, этого селекта который читал всё, уже нет. Но за ним есть ещё один, нечто вроде первого но вложенный и с условиями - читает в таблицу далеко не всё, и даже не половину. Но даже в этом случае есть переполлнение. Менять его и менять логику возможности как бы нет. Всё сводится к тому что надо как-то фильтровать размер SOURCE_PACKAGE, номерами пакетов, датами, чем-нибудь. Но как это сделать - непонятно.

Возможно, глупость, но я бы проверил tablespace.
Еще смущает величина 2965512, она далека как от того объема, который обычно может быть выделен под внутреннюю таблицу, так и от предполагаемой максимальной длины селекта.

Это в первую очередь было проверено. Ответили что для того чтобы это изменить, нужно перезагружать сервер, а в данный момент сделать невозможно.

Кусок программы из дампа приведите.

SQL запрос тот что выше написан и есть тот самый кусок программы на который указывал дамп. Каким-то образом памяти сервера не хватает чтобы заполнить таблицу анологичную размеру таблицы SOURCE_PACKAGE?
Перед запросом есть проверка типа IF SOURCE_PACKAGE IS NOT INITIAL.

Памяти не хватает, потому что параметры системы, например roll_area у вас выставлены соответствующим образом. В данном конкретном случае вам не хватило ~3Мб.
Что можно сделать, если никак не изменить параметры? Потреблять меньше памяти. В частности, под внутренние таблицы.
К сожалению, очень мало информации. Стоило бы обратить внимание на lt_dso. Возможно, стоит проанализировать ее структуру и оставить там только реально необходимые поля, select * заменить на список полей.
Посмотрите where-условие. В DSO, из активной таблицы которого идет чтение данных, ключ специфицирован полностью? Положительный ответ гарантирует, что записей в результате запроса будет не больше, чем в source_package.
Также проверьте перед этим оператором select никакие внутренние таблицы больше не заполняются и не определяются ли с тысячами записей в подпрограмме запуска?
Попробуйте ради эксперимента удалить перед селектом записи в source_package, оставив 100, например. Потом постепенно увеличивая количество записей. Так опытным путем найдете количество записей при которых система не падает.
И еще select single вам в помощь. Скорость загрузки потеряете, но зато с памятью будет все ok.

Помогла замена IF SOURCE_PACKAGE IS NOT INITIAL на IF SOURCE_PACKAGE[] IS NOT INITIAL. Правда нихрена непонятно почему, никаких хеадер-лайнов в том типе таблицы уже нет, и когда дебагил ещё раньше, проверка на пустую таблицу работала и без скобочек.