Subj.
Собираемся провести тесты в конфигурации:

NW BI - отчет (BEX Web, BEX, Excel, Cognos)
^
|
Виртуальный BW - куб (Virtual InfoCube)
^
|
... (здесь многоточие, т.к. пока неясности с терминологией и конкретным составом стека)
^
|
Oracle ХД (партиции, массивная индексация, и т.п.)

Как видно из схемки, данные лежат в Oracle и не прокачиваются физически в SAP-овские PSA/ODS/кубы.
Есть ли у кого опыт работы в такой конфигурации, с реально большими (миллиарды, сотни млн. записей фактов, миллионы в измерениях) объемами данных?
По некоторым источникам, это работоспособно.
Почему нам это интересно - потому что BW тормозит. И на процессинге (в нем это называется активацией), и на отчетах, и тем более, на интерактивном OLAP-анализе.
Мнения, почему это не будет работать по каноническим подходам SAP (в которых эта технология не рассматривается вообще), или так нельзя делать, не нужны. Нужен только конструктив/детали, где/как это работает.

В Лукойлe, по моему очень много на виртуальных кубах, и общая схема вреде того, что вы нарисовали...
Не могу гарантировать что сейчас там все так и осталось, но 2 года имела место быть такая тенденция.

Основные данные в BI тоже грузить не будете?
В принципе если грамотные люди и бюджет хороший есть, работать все можно заставить

А какие будут советы? Желательно, основанные на практике.
Я склоняюсь к тому чтобы грузить, чисто интуитивно.

Мне вот одно не понятно. Если вы так настойчиво хотите все делать на виртуальных кубах - откуда же тогда возьмется прирост производительности? все это разобьется о банальный ABAP который будет тискать вашу базу на каждый чих пользователя как малое дитя...
хм, а у вас вообще есть представление (кроме интуиции) как работает хранилище sap bw - что такое основные данные, почему тексты отдельно, что такое 60 символов и почему, что такое DSO и какие 3 вида их бывает, чем они отличаются, что такое виртуальные и транзакционные кубы?
Вместо проявления здравого логического мышления выражающегося в развитии мысли о том, как это сделать вы хотите:
По практике напрашивается такой совет:

Коллега Bkmz, вы сваливаетесь во флейм. Диагностирую у вас синдром утенка, и отсутствие знаний по существу моей темы.
Какая польза от стандартного (RT)FM, где об этом сильно нестандартном подходе нет даже страницы? Или, если вы знаете конкретный (RT)FM, где есть, так скажите же, мне не нужен ваш сарказм.

Поясните для чего Вы собираетесь производить тест? Сравнивать что с чем? Какие у Вас альтернативные варианты? Чем продиктован выбор такой схемы?

Тест будет для сравнения этого подхода со стандартом BW.
Стандарт не устраивает скоростью активации и формирования отчетов.

Что Вы конкретно имеете в виду под активацией? Активацию данных в DSO?
С какой конкретно стандартной схемой Вы собираетесь сравнивать?

Как у Вас организован стейжинг в оракле? Вы рассматривали вариант загрузки данных в кубы BI напрямую(без PSA, DSO)?

Коллега, очень много вопросов, и все имеют в конце "вы не умеете использовать стандарт". Спасибо, умеем. Просьба по теме. Тема - по вопросу, который задал я.
Вы владеете таким методом работы?

Методом владею, но на таких объемах к сожалению/к счастью нет.


Если Вас интересует только критерии производительности при работе пользователей с запросами (т.е. Условия такие что считаем сроки, трудозатраты, деньги неограничены, дальнейшая поддержка - по барабану ), то на мой взгляд особой разницы не будет, т.к. не принципиально откуда данные подкачиваются на app-сервер в olap-процессор.
Далее идут мои сугубо теоретические измышления . Узкое место скорее всего будет в том, что Olap cache c виртуальными провайдерами либо совсем не работает, либо ограничено.
Тут правда (см Условия) все равно можно изголяться - например :
1.Доабапить Olap cache.
2.Использовать BI Accelerator, раз денег то много (если он поддерживает виртуальные провайдеры )

To Гликоген:

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

По существу вашей темы у меня за плечами несколько банковских проектов с обработкой первички (миллоны записей/день) с расчетами остатков, трансформацией в МСФО и т.д. в SAP BW. Но увы, синдром утенка не позволяет мне вам помочь.

2 Гликоген
Ваша реакция напоминает DBA Oracle, который в первый раз увидел BW, нахватался терминологии и пытается соорудить что-то понятное ему одному.
BW - это отдельная система и среда. Тот вариант, который Вы предлагаете, слегка кособок.
Хотите задействовать SQL, партиции и прочее - определите транзакционный ODS, на уровне oracle сделайте ему партиции, индексы, загрузки и прочее. Но тот вариант через виртуальный куб реально плохой и медленный.
И зря так высказываетесь в отношении коллег - у многих реальный опыт работы с сотнями миллионов записей и они почему-то старались решить эти проблемы средствами BW, а не пойти самым легким путем. Многие из специалистов сами вышли из SQL среды и дорасли до OLAP. А OLAP это не просто БД с десятком таблиц и отчетов - это целостная система, со своими сущностями, контролем данных, дельтами и журналами. И всё это не от хорошей жизни. Созданное Вами на проекте должен легко подхватить другой консультант в случае увольнения.

Думаю, вам и нечем. Я уже раза три написал - станадарт не нужен.