Цепочка загрузки построена таким образом, что данные в целевой куб попадают в несколько этапов.
Основные процессы за один цикл загрузки следующие:

Удаление индексов
1-й запрос
2-й запрос
Создание индексов
Сжатие куба

Процесс загрузки происходит 5 раз в день. Пользователи активны в течение всего рабочего дня.
Каким образом синхронизировать доступ пользователей к отчетам? То есть пользователи должны всегда
видеть данные в кубе после этапа сжатия. Грубо говоря все пять этапов должны представлять собой транзакцию,
иначе отчеты поплывут. Как этого добиться? Заранее спасибо

А чем по вашему будут отличаться данные после 3-го этапа и 5-го???

После 3 и 5 ничем, за исключением того факта, что отсутствие индексов (а также их построение) приведет к
замедлению выполнения запросов со стороны пользователей. А вот после второго пользователи получат несогласованные данные,
так как сразу после загрузки 1-го запроса он получит статус "доступен для отчетов" (как загрузить данные в куб и оставить их
недоступными для отчетов я не понял, если честно). Пока идея использовать ограничеие в отчетах по ид. запросов = 0, то есть сжатых.
Может есть другие решения? Не охота все отчеты редактировать

Через другую цель грузить?

Зачем же искусственно увеличивать время загрузки?

При ограничении запроса по 0REQUID = 0 (не присвоено) выскакивает сообщение про отключенный кэш (чую, что это плохо) и актуальность от 0 -> 9. Фиг поймешь, чем BEX не доволен ... Может кто знает о чем речь?

Если делать через дополнительную цель... то придется сначала 1-й запрос гнать в некий промежуточный куб, затем 2-й туда же... а затем из промежуточного делать полное обновление в целевой? А в это случае запросы из промежуточного ложатся как один?

Просто решаю что же делать... то ли запросы править, то ли промежуточные кубы вводить

А почему 2 запроса? из разных источников идут?

Схема загрузки сложная... два это еще мало... может будет и три

Имхо, ожидание сжатия запросов тоже отодвигает момент доступности данных. Если решите все же править отчеты, то можно попробовать извратиться и на переменной-экзите исключать из рассмотрения один-два последних запроса в зависимости от их состояния.

Вводить промежуточные кубы.

Попробовал 0REQUID = # (не присвоено) сделать не в фильтре а в значениях по умолчанию, вроде не ругается

Да, вроде не ругается... знать бы еще почему

Еще проблемка такая. Кубов шесть штук... они все объединены в мультикуб.
В процессе загрузки данные в каждом из кубов становятся доступны для отчетов
в разное время... следовательно, в какой-то момент времени пользователь обратившись
к мультикубу через отчет получит несогласованные данные?! А тут как быть?!

Не ругается потому как данные из куба сначала выбираются все, а потом то что выбралось фильтруется по 0REQUID = #

Это не объясняет "почему не ругается"

А как насчет второй части вопроса?

По второму вопросу придумал

Тогда схема будет иная, без фильтрации по 0REQUID = #. Можно сделать виртуальный признак, который для новых запросов всегда 1. Как только все загрузки одного этапа завершились успешно, признак принимает значение 0. В отчете настроен фильтр по значению признака. Прийдется немного поабапить ))

Если данных много, то эта схема может не прокатить
Тогда, как вариант, остается грузить через промежуточную цель


А так возможно будет даже быстрее