Подобный глюки бывают. В смысле смотрится как аппратный сбой, а дело в девелоперской части. Любопытно, что подобное отмечается часто на дисках с SATA (особенно с новым "хищником" от WD). Вероятно не успевает писаться агрегация в диск. Другой теории у меня нет.

Пробуйте следующее.
1) Перейти на Lazy Aggregation. Вероятно уже глюк уйдет.
2) На всех измерениях поставить Custom Aggregation. На мало используемых измерениях Top Level Only, на часто используемых отключить агрегирование последнего уровня.
3) Понизить % агрегации. 15-20% для обычных кубов, 2-5% для Distinct Count (DC это правда отдельная песня)

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

2backfire. Вы все шумите, а ваши ответы показывают ваш ограниченный опыт в MS AS. Не люблю я халявных советов, но у Павла действительно проблема, поэтому отойду от правила.

1) Надо знать, что серьезные транзакционные системы Microsoft при записи информации на диски используют низкоуровневый доступ почти в обход ОС. Это нужно для транзакционной целостности и записи chekpoint мимо кеша ОС. Из-за незнания этого погорела масса админов. Microsoft c MS SQL 6.5 всем без устали твердит об этом и просит либо отключить собственный кеш RAID, либо на худой конец поставить туда батарейку. В противном случае ни кто вам не гарантирует востановимость БД в случае аварии. Точнее мне как минимум 1 раз в год приходится с Сергеем Быковым склеивать из секторов убитую БД для MS SQL. Однако эта работа уже делается на фоне уволенного админа и стоит эта чертова работа весьма не дешево.
Если говорить об MS AS иногда видны сбои в стиле "Connection to MSSQL broken", "I\O Error". Все это часто возникает в тот момент, когда на SATA серверу MS AS надо записать 100-200M, а процессор занят расчетом агрегатов и не успевает отдавать время шине SATA. В результате все высыпается на системных таймаутах. Правда на SCSI такого еще не встречал. Все сказанное моя интерпретация сообщения об ошибках. Обычно в таких случаях я снимаю пиковую нагрузку на SATA через переход к отложенной агрегации (Lazy Aggregation). Эта опция переключается в параметрах куба. Еще плюс этой опции быстрое завершение процесирования и быстрая готовность куба к работе.

2) Агрегации на 60% и 90% как правило бессмысленны. Есть известное правило агрегации "1/3". Фактически всегда победит 30%. Дело в том, что накладные расходы на чтение агрегатов с диска будут больше чем их расчет on-fly, особенно на горячем кеше. Поэтому почти всегда лучше 30% и затем разогрев кеша MDX-запросами в DTS-пакете. Плюс большой выигрыш на процессировании, плюс экономия места на дисках. Агрегаты свыше 30% лучше добавлять вручную по Usage Base Optimization (включите в опциях MS AS регистрацию всех query'й) или через DSO, но не "везде" как делает мастер Design Storage. Самая типовая проблема тормозов MS AS у новичков это "переагрегация".

2задний_огонь. :)
Хотите убедиться что MS AS манипулирует с дисками на низком уровне?
Сделайте такой тест.
1) Создайте таблицу фактов примерно 200 тыс.
2) Создайте измерение из 100 тыс элементов.
3) Копируя измерение сделайте 40 таких измерений
4) Закажите куб из 40 таких измерений и попросите 50% агрегатов.
5) Пока будет строится MOLAP подождите минут 30 и нажмите Cancel.

Если бы я был злой человек, я бы не сказал, что произойдет. Скорее всего сервер погиб. Повезло вам если отделаетесь сносом MS AS. Догадайтесь почему.

2Моша. Надеюсь вы прочтете это сообщение и повторите этот тест в лабе Microsoft. На моих тестовых серверах я получал весьма разрушительный эффект.

2задний огонь. Да будет вам шуметь. На самом деле интересно почему вас пронесло. Вы подождали хотя бы 30 мин? Вероятно вы прервали процесс сразу и MS AS смог откатиться.
Для креша нужно прервать БОЛЬШУЮ транзакцию MS AS в процессе и когда довольно много сделано. В результате MS AS сваливается с катушек.
Любопытно, что перегрузка сервера проблему не лечит, MS AS мертв.
Если все равно нормально, можно спецификацию на софт и хард вашей станции? Сервер с двумя ксеонами и SCSI RAID5 валится.

2Alex Fox. Ну вот видете хоть кому-то помог. Ленивые агрегаты вам будут помогать до тех пор, пока у вас не будет 20 млн. фактов. За этой чертой стратегия оптимизации меняется.

2backfire. Я не внимательно прочел ваш репорт о тесте. В говорите что куб построился за ШЕСТЬ минут? Вы понимаете, что был заказан куб с пространством 100 тыс в 40ковой стенени? При 50% агрегации результатом должно быть гигантское MOLAP-хранилище! Если за "шесть минут" у вас все вышло пошлите мне по почте архив вашей MOLAP-базы. Я буду очень благодарен ivanov-soft@inbox.ru

К слову, интересное наблюдение SATA с WD Raptor против SCSI RAID5. Два сервера один под SATA однопроцессорный для тестов, другой новье на двух ксеонах с дорогими дисками. Разница в цене платформ 6 раз. Однако платформа под SATA отстает на процессировании только на 50% и на MDX-запросах только на 30%. Правда это все после наших оптимизаций. До этого решение под SATA просто валилось.
Выводы такие
1) Хороший девелопер всегда лучше хорошего сервера
2) Новые SATA диски на 10 тыс весьма перспективны и потеснят SCSI в нише малых и средних решений. Заметим также что текущие чипсеты пока еще не поддерживают новые очереди SATA.

2Alex Fox. Для анализа причин слета включите логи на MS AS и DTS пакетах. Там все будет написано. Логи включаются в опциях MS AS и опциях DTS пакета.

2backfire. У меня не осталось креш базы. Я делал тест на 2х серверах результат примерно одинаковый сходный с взрывом атомной бомбы. В результате гибнет репозитарий MS AS и все OLAP-базы теряются. У меня хватило ума в первый раз подобный тест сделать на сервере где мы тестировали базы для 2х клиентов. Весьма сексуальное было занятие по ручному восстановлению баз (архивов их не было). Если у вас куб спросировался за 6 минут он не может быть большим, что говорит о другом проведении теста. Если можно пошлите его почтой или выложите на Web. Очень интересно посмотреть. Мне креш базу надо восстанавливать, но если вы все делали правильно, я легко ее сделаю из вашей базы.