Вопрос в следующем.
Данные из одного Ods прогружаются в следующий Ods. В правилах обновления накрученная логика. Создается много внутренних таблиц куда выбираются данные еще из 2 Ods. Все это колбасится, сопоставляется, сравнивается и так далее. В итоге загрузка заканчивалась ошибкой по таймауту, увеличил параметр - теперь фоновые режимы могут висеть хоть двое суток. И все равно загрузка части пакетов заканчивается ошибкой. Ощущение такое что кому-то, где-то опять чего-то не хватает? Вообще есть ли параметр отвечающий за время существования временной таблицы? Или может есть еще какие параметры полезные? В каком направлении лучше копать данный вопрос?.
Сразу сообщу что данные корректны. Правила обновления оптимизированы до максимума.

ЭЭ, а какой параметр трогали ? Часть пакетов валится с той-же ошибкой(TIME_OUT) ?
Параметров отвечающих за существование временно табл в памяти нет. Это время определяется исполняемым кодом или временем жизни самого процесса.

увеличил параметр rdisp/max_wprun_time

Вообще данный параметр определяет время жизни DIA процессов. Загрузка я так понимаю проходит при живом участии данных процессов.
Как вариант, если есть возможность, делать загрузку более мелкими пакетами.

Прежде, чем менять параметры, было бы неплохо знать, что меняете. Пользуйте транзакцию RZ11.
Этот параметр имеет весьма маленькое отношение к фоновым процессам. Это максимальное время работы шага диалога. А фоновые и так весьма долго живут
Загрузка обязательно должна быть одним куском? Дробить нельзя?

Похоже в диалоге...

Используйте следующие ноты чтобы загружать данные в background и скажите нам результат:

Note 393545 - Termination 'TIMEOUT' when loading from ODS objects
Note 380003 - Updating ODS data into data targets in the background

Правда сомневаюсь это поможет процессу который идет сутками (судя по вашему описанию) уложиться в 2 часа (по названию топика).
PS:
Note 185770 - Updating data online in spite of background job scheduling

В инфопакете есть параметр, отвечающий за таймаут...