Господа!
Поделитесь ссылками на статьи о миграции RealTime OLAP-решений в MS SQL 2000 в MS SQL 2005.

Надо мигрировать большое решение в котором 40 кубов Real-Time.
Не хочется на грабли наступить.

Встроенные indexed view из MS AS 2000 отключены и сгенерированны своим тулзом. Встроенные механизмы отловления событий MS AS 2000 подавлены, используются свои мониторы потери актуальности данных.

2 Моша. Может какой white paper есть? Как миграцию завершим, клиент купит на 8 сайтов MS SQL 2005 Enterprise Edition.

Спасибо за квалифицированный ответ безусловно достойный профессионала и модератора. Ваш совет безусловно помог разрешить все технические риски.

Общие ссылки по теме тут
http://www.microsoft.com/technet/prodtechnol/sql/2005/BI/default.mspx

На самом деле информации очень мало, особенно с учетом того что RT в MS AS 2005 работал если все в ручную сделать.

RT в MS AS 2005 работал

Описался. Конечно MS AS 2000.

Отвечу на вопрос наверно который встал у многих.
Как были отключены indexed view и мониторы MS AS 2000 Ent Ed.

Очень просто - путем создания view и Arr=0%.
Монитор на view не создается.

Вы вроде экспериментировали с RT в MS SQL 2005.
Впечатления?

авторВозможно я Вас неправильно понял, но если это сделать, то ведь AS2000 real-time полностью отключается.

Поясню. Все таблицы закрыты view, потому не создаются встроенные мониторы. Но созданы таблички типа RealTimeMonitor, в которых делается update когда по бизнес-логике решается, что отчет более не актуален.


авторВообще то я советую почитать про Proactive Caching в AS2005 - ведь RealTime это в сущности один из вариантов этого Proactive Caching - когда Latency=0. В зависимости от задачи вам могут подойти другие настройки. Моя любимая, например, это Automatic MOLAP.

Читал обзорную статью весной.
Есть ссылки на более новый материал?

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

Уточнение
На view помоему мониторы и в MS SQL 2005 не создаются.
Однако вы можете сделать pull-монитор типа count(*)
если под view таблица с индексом запрос будет проходить мгновенно.

Никаких ROLAP! Нафига нам эти indexed view?
Рулит Real Time HOLAP.

Все настройки найдете в настройке партиции.

Вот кусочек моей рекомендации для RT решения которую я выдал несколько дней. Может поможет. В вашем случае возможно Scheduled Pooling удобен будет.

авторScheduled Pooling - НЕИСПОЛЬЗОВАТЬ, прямой монитор таблиц
Не очень понял почему в измерениях стояли запросы по count(*)
Это более ресурсоемко, не замечает update, а главное не сразу OLAP соображал, что произошли изменения. Я перевел все на прямой мониторинг изменений (Specify Tracking Tables). В том числе перевел на прямой мониторинг Ресурсы зависящие от группы таблиц.

Silence Interval - 2 sec (обновить данные если пользователи перестали модифицировать их, что определяется по "тишине" в изменениях 2 сек)

Silence Override Interval - 5 sec (если пользователи продолжают менять данные без конца, все равно обновится через 5 сек)

Drop cache periodicaly - 1 day (раз в день перестраивать измерение)

авторя пытаюсь настроить notifications для обновления куба. Вариант куба, как писал выше, выбрал holap, далее выбираю вариант SQL Server, и хочу выбрать таблицу для мониторинга, но выбрать можно только из того источника данных, на котором построен куб, а я хочу выбрать таблицу из другой базы. Это вообще возможно или нет? Комбик с источниками данных на форме присутствует, но он disabled.

Не пробовал такую конструкцию.
А вы 2й источник создали?

Если не получается есть workaround. Сделайте триггер работающий между БД, который будет менять вам табличку в БД куба.