Все метаданные, описывающие правила трансформации данных из физических источников (DWH, файлы и т.д.) в витрины (предметные области) Oracle BI, содержатся в репозитории Oracle BIServer.
Очевидно, что в ходе создания этих правил могут быть допущены ошибки. Либо в процессе доработки репозитория могут быть допущены неточности, приводящие к некорректной работе трансформаций данных. И как результат - несмотря на корректные данные в физических источниках, пользователи будут получать ошибочные данные в отчетах BI.
Данная статья описывает настройки автоматизированного тестирования репозитория метаданных BI с помощью DBFit.
Основная идея решения по тестированию заключается в том, что по каждой предметной области репозитория BI создается пара SQL запросов:
один к BIServer (тот логический SQL запрос, который отправляет BIPresServer к BIServer; его можно увидеть на вкладке "Дополнительно" в режиме редактирования анализа BI),
другой к DWH (запрос-эталон).
Результаты выполнения запросов сравниваются и возвращается дельта. Если дельта не пустая, то тест считается проваленным.
В этой конструкции основным элементом является Java Stored Procedure, созданная в БД Oracle (DWH) и осуществляющая доступ к BIServer по протоколу JDBC. Полученные из BIServer данные процедура записывает в global temporary table.
В дальнейшем вспомогательная PL/SQL процедура генерирует курсор, сравнивающий данные из gtt-таблицы и результаты запроса-эталона к DWH.
DBFit же является удобным инструментом по быстрому созданию и запуску таких тестов.
4 февр. 2015 г.
BIEE 11g: запрет просмотра результатов анализа без фильтров
Часто вижу, что пользователи Oracle BI при создании новых анализов
работают с моделью данных сразу на вкладке "Результаты" редактора.
В идеальном мире это не несет проблем. Если у вас устойчивый к нагрузкам репозиторий (нет сложных логических схем - одни "звезды"), если у вас используется хранилище данных (с партиционированием; с шардингом; с агрегатами и query rewrite).
В таком случае запустите вы запрос по всем данным - произойдет переписывание запроса к таблице-агрегату (ROLAP).
Но реалии таковы, что применяются сложные модели данных, нет агрегатов, либо они некорректно применяются.
И тогда подобная привычка - строить анализы в режиме Preview без каких-либо фильтров - пагубно влияет на общую производительность системы. Особенно, когда много одновременно работающих пользователей.
Предлагаю простое решение, которое препятствует пользователям переходить на вкладку "Результаты" анализа без применения фильтров.
работают с моделью данных сразу на вкладке "Результаты" редактора.
В идеальном мире это не несет проблем. Если у вас устойчивый к нагрузкам репозиторий (нет сложных логических схем - одни "звезды"), если у вас используется хранилище данных (с партиционированием; с шардингом; с агрегатами и query rewrite).
В таком случае запустите вы запрос по всем данным - произойдет переписывание запроса к таблице-агрегату (ROLAP).
Но реалии таковы, что применяются сложные модели данных, нет агрегатов, либо они некорректно применяются.
И тогда подобная привычка - строить анализы в режиме Preview без каких-либо фильтров - пагубно влияет на общую производительность системы. Особенно, когда много одновременно работающих пользователей.
Предлагаю простое решение, которое препятствует пользователям переходить на вкладку "Результаты" анализа без применения фильтров.
2 февр. 2015 г.
BIEE 11g: instanceconfig.xml (11.1.1.7.1)
Так и не нашел в документации и блогосфере полной структуры файла instanceconfig.xml
В итоге выкладываю сам для версии OBIEE 11.1.1.7.1 со значениями по умолчанию.
В итоге выкладываю сам для версии OBIEE 11.1.1.7.1 со значениями по умолчанию.
Подписаться на:
Сообщения (Atom)