Там 2 места где расчет ведется — часть рассчитывается в базе до заливки в куб, часть в самом кубе. Надо смотреть расчет, это уже вопрос оптимизации. Я стараюсь всё рассчитать в витрине в базе данных, а уже оттуда забираю всё в куб. Та же история с распределенными данными, попытаться собрать всё в одну витрину. Хотя проект куба весь в xml, отсюда кое-что можно в нем менять на лету.
Не совсем понял вопрос. На вход партиции подается селект. А вот база, откуда селект, может стоять на нескольких серверах. А у Вас тормозит обработка партиций?
Обновление данных — партиции делаются.
Изменение структуры — тут перестроить надо будет. Поэтому для куба делается витрина в базе (набор таблиц под куб, с максимально близкой структурой).
Просто соберите куб. Это OLAP там всё по другому если вкратце. Главное — это построить факты и измерения по схеме звезда, без снежинок. Можно вьюхи сделать, чтобы как звезда были. Куб в процессе построения сам всё разобьёт на агрегаты и фактически будет хранить уже готовые значения (OLAP). 1 день на данный момент строиться 7 минут. Но построение идёт в отдельной транзакции. Т.е. работать с кубом пользователь может постоянно, просто с каким-то интервалом в нём формируются новые данные. Т.е. отставание от реальных данных будет около часа. В задачи которую я решал отставание могло быть 1-2 дня, т.к. просрочка по кредиту не сразу начисляется, пока там разберутся — точно клиент не заплатил или технический сбой какой-то дня 3 проходит.
Советую попробовать, благо триал версия ASPXPivotGrid есть, Analysis Services достать тоже не сложно. Я поэтому и написал, что действительно очень неплохой выход при малых затратах получился.
Для кубов под Analysis Services серьезного железа не надо. Я сейчас в отпуске и параметры сервера точно не скажу. Однако, пилотный проект разворачивали на клиентской машине они уже вертелись нормально. То же могу сказать и про AspxPivotGrid, он тоже неприхотлив (его правда настраивать посложнее, чтобы он работал шустро, в частности сортировку по умолчанию отключать).
Oracle стоит на 64 процессорном сервере, но производительность машин связанна не с этой задачей. В компании где я работаю все железо довольно мощное и обновляется раз в 3 года, это политика компании.
Про xcopy я тоже много чего знаю. А в реестре лезли не затем чтобы править, а чтобы tnsnames 2-жды не писать. В дровах для оракла я просто хотел акцент сделать на обязательность перезагрузки. Можно и без неё, только возни побольше.
Изменение структуры — тут перестроить надо будет. Поэтому для куба делается витрина в базе (набор таблиц под куб, с максимально близкой структурой).
Oracle стоит на 64 процессорном сервере, но производительность машин связанна не с этой задачей. В компании где я работаю все железо довольно мощное и обновляется раз в 3 года, это политика компании.