В данный момент внедряем аналитический модуль для нашей системы управления предприятием, базирующейся на Oracle 9.2.0.7. В качестве платформы для реализации MOLAP решения был выбран standalone server Oracle 10.2.0.1, в соответствии c рекомендациями из документации и сайта Oracle использовать наиболее свежий релиз для OLAP (звучало это примерно так: OLAP – наиболее быстро меняющаяся опция Oracle Database, от релиза к релизу вносится очень много изменений). Подготовка данных для загрузки производится PL/SQL процедурами. Загрузка данных производится скриптом, сгенерированным AWM. Измерения и кубы проектируются с помощью AWM.

На стадии тестирования возникли следующие проблемы:
1. Невысокая производительность (загрузка, открытие рабочей книги, работа с рабочей книгой), по сравнению имеющейся у нас тестовой версией задачи, реализованной на MS Analysis Services 2000, причем параметры железа несопоставимы:
Oracle 10.2.0.1: Windows 2003, 2 x Opteron 1800 MHz, Memory 2G, 5 SATA винтов.
MSAS 2000: Windows 2003, AMD Athlon 2200+, Memory 512M, 1 IDE винт.
Статьи по настройке и оптимизации производительности Oracle OLAP были изучены (в частности, полезную ссылку на Риттмана дали на этом форуме), дела с производительностью после применения советов стали обстоять значительно лучше, по сравнению с тем, что было в самом начале, но выйти на приемлемый уровень так и не получилось.
2. Отвратительное качество AWM, про это я уже писал здесь:
/topic/235249&hl=
Работать с ним очень сложно, бывает падает после нескольких выполненных операций – приходится закрывать и открывать заново и т.п.
3. Неудобство использования SQL и OLAP DML для работы с кубом. MS MDX гораздо удобнее, проще и понятнее.
4. Самое главное: неудовлетворённость пользователей работой Oracle BI Discoverer for OLAP и Excel Add-in.
Discoverer
•\tработает очень медленно (медленная сортировка, иногда уровень разворачивается за 2 секунды, иногда за 30 секунд);
•\tпри выполнении некоторых операций наглухо зависает;
•\tодновременный выбор множества элементов из измерения в области среза невозможен;
•\tдля изменения сортировки необходимо ВРУЧНУЮ ОТМЕНЯТЬ предыдущую сортировку. В противном случае сортировка работать не будет;
•\tстолбцы, по которым произведена сортировка, никак не помечаются;
•\tпосле выполнения сортировки строки, содержащие пустые значения, отображаются в верхней части отчета независимо от направления сортировки;
•\tОЧЕНЬ затруднена фильтрация. Очень НЕУДОБНО, необходимо выполнять очень много операций;
•\tстолбцы, на основании значений которых произведена фильтрация, не помечаются;
•\tотсутствует возможность размещения на экране одновременно нескольких диаграмм;
•\tотсутствует возможность одновременного выбора множества элементов (Multiple items) из измерения, помещенного в область среза, и отображение на графике агрегированного (сумма, среднее и т.д.) представления для данных элементов.

Excel Add-in
•\tлюбую операцию приходится выполнять через меню, что занимает очень много времени, если сравнивать с MS PivotTable;
•\tотличающиеся в худшую сторону буквально все аспекты работы с Excel Add-In по сравнению с MS PivotTable (с которой пользователи активно работают и, в принципе довольны, и которая стала еще лучше в даже бете нового Офиса). Поэтому не хочется вдаваться здесь во все подробности о недостатках Excel Add-In, многие из которых аналогичны недостаткам Discoverer, многие же не имеет и Discoverer. Самое главное во всем этом деле – это ошеломленные глаза пользователей, работавших с MS Pivot Table, Panorama Nova View и прочими клиентами для MSAS, и увидевших средства анализа от Oracle. И, по справедливости, я их понимаю – при всем желании, ничего в защиту Oracle в этой ситуации сказать не могу. Все-таки главная задача внедрения OLAP решения – это удовлетворённость пользователей и соответствие их требованиям.

Поэтому, пока проект находится на начальной стадии тестирования, в данной ситуации напрашивается следующее решение:
хоть с MS никто у нас никогда серьезно не работал, но придется переносить все на MSAS, потому что отношение Oracle к OLAP не внушает оптимизма, и из общения со специалистами по MSAS и чтения статей вырисовывается не самая приятная для Oracle картина – отставание Oracle от лидера OLAP рынка, коим является MSAS, очень велико, особенно после выхода MSAS 2005, и проблемы Oracle OLAP видятся очень серьёзными.

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

Birkhoff
Я бы на вашем месте, если у вас действительно есть большой список претензий попробовал бы реализовать ту же задачу на MSAS+Excel и т.д. и дальше посмотрел бы что хуже и что лучше конкртено для вас. Идеального решения нет, а то все давно бы уже на него перелезли.
Склоняюсь именно к этому.

Birkhoff
P.S. О покупке лицензий разговора по видимому нет, так что вопрос сравнения по ценам не актуален :-)
Вопрос покупке лицензий тоже стоит, и здесь Oracle в 2 раза дороже

Интересует все-таки MOLAP, и здесь стоимости Oracle и MS несопоставимы даже для Enterprise Edition, не говоря о том, что для MS MOLAP доступен не только в Enterprise Edition (пусть с некоторыми ограничениями, но доступен), и с учётом этого стоимость MOLAP решений Oracle и MS получается просто несопоставимой - вполне реальной для MS, и неоправданно высокой (особенно если учесть ещё и технологическое отставание Oracle) для Oracle.

Сравним цены:

spaces.msn.com/members/mkozloff/Blog/cns!1p9PZ5XQ6AnXuazswiS9wMEg!344.entry

Для OLAP пока около 15-ти. Возможно что будет и больше

Birkhoff maxol67Для OLAP пока около 15-ти. Возможно что будет и больше15 рабочих мест- для этого не требуется 8 процессорный сервер. Да и OLAP, возможно тоже. Если брать Oracle, то сама СУБД EE ориентирована на минимум 25 пользователей на один процессор.

Ссылку я привел в качестве примера, для 2-х процессоров картина останется прежней.

По поводу MOLAP и ROLAP ссылка на документацию Oracle:

When to Use Analytic Workspaces
Analytic workspaces are the best choice for these requirements:
■ Exploratory, ad-hoc querying of all areas of the data
■ Advanced calculations such as models, forecasts, growth ratios, and trends
■ What-if scenarios
■ Time series calculations such as lead, lag, moving average, and year-to-date
■ Complex run-time calculations
■ High performance for calculating summary data and inter-row functions such as
share calculations
When to Use Relational Schemas
Star schemas may be preferable to analytic workspaces for these requirements:
■ Predictable querying patterns and prepared reports
■ No advanced calculations (such as forecasts)
■ Infrequent complex run-time calculations
■ Measures with a large number of dimensions
■ Dimensions with few aggregate levels
The following topics explore the technical differences between dimensional and
relational data stores that support these guidelines.

Для наших задач ROLAP не подходит в принципе. Нужен именно MOLAP. И здесь вполне можно обойтись MS Standard Edition, и получаем абсолютно разную картину в стоимости лицензий.

http://www.microsoft.com/sql/prodinfo/compare/oracle/pricecomparison.mspx

With Business Intelligence Features
Number of CPUs Oracle 10 Standard Edition SQL Server 2000 Standard Edition

1 Features are not available. $4,999 US

OLAP and data mining are not available with Oracle 10g Standard Edition. Customers will need to purchase Oracle 10g Enterprise Edition and then purchase the OLAP and data mining option. SQL Server 2000 includes integrated OLAP and data mining with both the standard and enterprise edition at no additional cost.

Представляю картину, как я должен объяснять генеральному директору необходимость потратить более 100000 USD вместо 10000 USD, чтобы купить продукт номер 1, который уступает наверное по всем показателям продукту номер 2. Интересная получается картина. Естественно, если человек продает Oracle, то он до последнего будет утверждать, что в этой ситуации надо брать именно Oracle, хотя сам думает по другому, потому что факты говорят сами за себя (на все вопросы о технологических преимуществах и цене получаем только один ответ - да Оракл очень дорог, и MOLAP у него плохой, и поэтому надо использовать Oracle ROLAP и упаси бог использовать что-то другое). Да не нужет мне ROLAP, и не являюсь я борцом за чистоту крови - типа использовать только Oracle - мне нужно нормальное решение аналитического хранилища за разумные деньги. Oracle в данной ситуации не может предложить ни нормальной реализации, ни тем более разумной цены. 100 с лишним тысяч - охрененть можно! А если мне Data Mining понадобится (а он непременно понадобится), то еще десятки тысяч платить. А если я проц подоткну? Ну т.д.

BirkhoffЕдинственный критерий истины - реализовать тоже самое на Microsoft и если по всем параметрам вас это будет устраивать - ну ради бога, кто же вас силком тянет? Не вижу никакой проблемы.

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

Sergey P. JuriiЕсли самостоятельно написать OLAP-клиента к OLAP-серверу Cognos - это будет бесплатно, но функциональности получится меньше, чем в стандартных OLAP-клиентах от Cognos. То же самое справедливо и для MS AS - можно брать бесплатных OLAP-клиентов, которые довольно слабы, можно покупать навороченные коммерческие OLAP-клиенты.

Ну, это просто открытие какое-то!
Собственный клиент! Может мои представления о Cognos сильно устарели.
Но я не понимаю, как можно написать клиента для Cognos, если у него нет API. Насколько я понимаю, это самодостаточный продукт, и то, что есть – то есть!
Если это не так, то можно ссылочку или пример, о том, как я могу подключиться к серверу Cognos из стороннего средства разработки, будь то Visual C, .Net, Delphi, Java ну хоть что ни будь, хоть библиотечка, или компонента.
Вот честное слово, буду благодарен!

JuriiПро MS не скажу, но у Cognos подключение внешних OLAP-клиентов - это бесплатная функциональность. А смысл покупать родные коменты Cognos в том, что с нуля написать нечно подобное достаточно сложно.

Так сложно, или все-таки невозможно!?

Хотелось бы услышать ответ Юрия. Просто интересно