Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Agenda
Agenda
Repository design best practices
Physical Layer
Business Model
Presentation Layer
Dashboards and reports design best practices
Reading query log
Performance tuning (relational database)
Performance tuning (multi-dim database)
Troubleshooting
10g Upgrade considerations
Original tables
VS Aliases
Query Limits
A user who has access to Answer can significantly slow
down the BI Server and the database with a bad report
that extracts millions of records. To prevent that, enable
query limits. If there is no specific users requirement, use
100 000 rows and 1h as a starting point.
Agenda
Repository design best practices
Physical Layer
Business Model
Presentation Layer
Dashboards and reports design best practices
Reading query log
Performance tuning (relational database)
Performance tuning (multi-dim database)
Troubleshooting
10g Upgrade considerations
OLAP
OLTP
Dimensions
Facts
ODBC
CSV
XML
Logical Tables
Use a separate dimension logical
table for each dimension dont
combine/merge them into one
The same goes for facts, we dont
want to end up with a single fact
logical table called Facts Stuff!
Have a separate logical table for
Compound facts (which combine
facts together from multiple LTS)
Prefix logical table names with
either:
Dim
Fact
Fact Compound
Level Keys
The primary key of each level must always be
unique
The primary key of the lowest level of the
hierarchy must always be the primary of the
logical table
Content Level
Always specify the content level in all logical table
sources, both in facts an dimensions.
It will allow BI Server to select the most optimized LTS
in queries.
It will help consistency checker finding the issues in
RPD configuration, preventing runtime errors.
Implicit fact
Set up an implicit fact column for each presentation
folder.
It prevents users from getting wrong results if they create
a report without fact column.
Use a constant as the implicit fact column to optimize
performance
Agenda
Repository design best practices
Physical Layer
Business Model
Presentation Layer
Dashboards and reports design best practices
Reading query log
Performance tuning (relational database)
Performance tuning (multi-dim database)
Troubleshooting
10g Upgrade considerations
Object Descriptions
Add descriptions to presentation folders to explain the
purpose of each folder within Answers
Add descriptions to presentation tables and columns so
that they appear in Answers when users roll-over them
with the mouse. For each column, explain the data
content with for instance calculation formula...
Global Recommendations
To satisfy all your drill-down requirements, you dont need to have all your
reporting objects in a single Subject Area / Presentation Folder
For example, if you want to drill from a summary Orders report down to
Order Item level, you dont need to create a single Subject Area that
contains both Order and Order Item objects
You can start by creating a report against the Orders Subject Area and
then you can drill-down to another report defined against Order Items
Subject Area
You just need to ensure the Presentation Table/Column names that are
being prompted have the same names in both Subject Areas
If the Presentation Table/Column names arent the same then use Aliases
to make them the same!
Agenda
Selection Steps:
Are applied only if the corresponding column is included
in the view.
May generate additional logical and physical queries.
Agenda
2
3
4
5
6
Log Level
In production environment, set BI Server log level
to 0. When there is a lot of reports running in
parallel, query logging may cause performance
issues.
Agenda
Methodology
Methodology
3. Look at the physical SQL for a first level of verifications:
Are all tables included in this query really necessary ? Do we
have tables that are joined but are not included in select
clause and do not have filters applied (real filters, not join
conditions) ?
How many physical queries/sub-queries are generated ?
More precisely, how many times do we read a fact table ? In
a perfect world, we read only 1 fact table and only once. If
there are more, find out why and see if some could be
removed. Check for excluded columns, non-additive
aggregation rules (REPORT_AGGREGATE,
count(distinct)...), selection steps, sub-query in the report, set
operators (UNION), totals, sub-totals, multiple views, etc.
Are there any outer joins ? Where do they come from ? Could
they be removed by changing the design ?
Methodology
Methodology
Reducing the volume of data read can be done by reviewing the data
model, for instance:
Aggregate table creation
Fragmentation. For instance if most of the time only data of
current year/Quarter/Month are selected, we can split the fact
into two tables.
Denormalization (to reduce the number of joins).
Normalization (to reduce number of columns in the table). For
instance a big table with 500 columns could be split into two
tables, one with columns often used and another with columns
rarely used.
Level-Based Hierarchies
Queries using Level-based hierarchies generate in logical
SQL one sub-query for each level used in the report.
Therefore the cost on performance can be important.
Level-Based Hierarchies
With relational databases the number of physical subqueries is usually proportional to the number of logical
sub-queries. In the previous example 3 physical subqueries are generated.
The number of physical sub-queries can sometimes be
reduced by BI Server cache. If sub-request caching is
enabled (DISABLE_SUBREQUEST_CACHING=NO in NQSConfig.ini),
BI Server can re-use previously cached data and execute
only the physical sub-queries for data that are not in
cache.
Skipped/Ragged Hierarchies
Selecting Skipped/Ragged options increase significantly
the cost of hierarchies on performance. Additional logical
SQL sub-queries are required in case there is a null value
in a level displayed or at any lower level. The example
below generates 5 logical SQL sub-queries although only
3 levels are displayed.
Value-Based Hierarchies
With value-based hierarchies, there is only 1 logical SQL
query no matter how many levels are displayed.
Value-Based Hierarchies
On physical side, even with relational database, there is
only one sub-query executed on the fact table. Multiple
sub-queries are usually required on the dimension table,
but these should be very fast since they read the
dimension only. Value-based hierarchies are very efficient
regarding performance.
Database Features
Depending on your configuration, you may enable some
parameters in database feature:
Count(distinct)
Whenever it is possible, replace it by Count().
Count(distinct) has a high cost on performance on the
database.
If there are multiple LTS, the aggregation rule must be
specified for each LTS.
Benefits
Downside
Rank
Base Measure
-Flexible
-Perfectly Optimized
-Good for users
education
-Cannot be always
used, depending
on report
configuration
1 Should be
used most of the
time
Case When
2 Should be
used from time to
time
Filter Using
3 Should be
used rarely
-Where clause
quickly becomes
HUGE
IndexCol
Sometimes the formula or columns used vary depending on a
session/presentation variable.
If you use a case when statement then the entire formula is pushed
to the physical query. But by using function IndexCol only the required
column/expression is pushed to the database.
Combined with the new 11g features in prompts (allow selection in a list
of custom values), it allows users to modify very significantly reports
structure without any increased cost on performance. This function can
be used in the RPD or directly in reports.
INDEXCOL( CASE VALUEOF(NQ_SESSION."PREFERRED_CURRENCY") WHEN 'USD' THEN 0 WHEN 'EUR'
THEN 1 WHEN 'AUD' THEN 2 END , "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Usd", "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Eur", "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Aud")
Mini-Dimensions
Mini-dimension tables include combinations of the most
queried attributes of their parent dimensions.
They must be small compared to the parent dimension,
so they can include only columns that have a relatively
small number of distinct values.
Mini-Dimensions
Mini-dimensions are joined both to main fact table and to
aggregate tables.
Mini-Dimensions
They improve query performance because BI Server
will often use this small table instead of the big parent
dimension.
They increase the usage of aggregate tables. Due to
the level of aggregation, aggregate tables cannot be
joined to the parent dimension. But they can be joined
to the mini-dimension instead. It allows reports to use
the aggregate table even if they use some columns
from the corresponding dimension.
Excluded columns
Delete columns that are excluded from all views
They increase the volume of data retrieved
They make BI Server computing results at multiple
levels of aggregation, impacting resources needed
both on database and BI Server
They may have
an impact on
results when
using complex
aggregations.
Agenda
Methodology
When OBIEE uses Essbase as data source, there are
additional design considerations that may have big impact
on performance.
The design solutions to improve performance change
depending on the use case. So the objective here is not to
provide best practices that should always be applied.
Instead, the following slides will present tuning methodology
and multiple techniques. It is up to the developer to study
multiple options, study OBIEE session log, and select the
best one for his use case.
Methodology
1. Simplify the MDX generated.
2. Reduce the number of MDX queries generated.
3. Make sure that optimal filters/selections are applied in
MDX.
4. Perform tuning with DBA on Essbase side and/or
check on Essbase why performance is still bad.
5. Modify OBIEE report based on feedback from
Essbase DBA.
Pre-requisites: being able to understand MDX queries
and OBIEE session logs
Case statement
Case statement is not supported in MDX. It is always
applied on BI Server.
The main benefit of using Case statement in reports formulas is
that it cannot be included in MDX and therefore may help
simplifying MDX query.
Case statement
There are restrictions:
If the case statement does not combine multiple members, the
base column used in case statement should also be included in the
query and in the views as a separate column (hidden).
If the case statement combines multiple members, then base
column cannot be included in the view without impacting the level
of aggregation. In this case:
if the aggregation rule of measure is not External Aggregation,
the base column should not be in the query.
If the aggregation rule of measure is External Aggregation,
base column must be included in the query and should be
excluded from the view. Aggregation rule of measure must be
changed from Default into a simple internal aggregation rule
(SUM, MAX, MIN). This works only if the internal aggregation
rule can be used to combine members and provides correct
results.
FILTER function
Unlike Case statement, FILTER function can be shipped to
Essbase.
The main benefit of using FILTER function in reports formulas is
that the selection is applied in MDX query and therefore may
reduce the volume of data calculated/retrieved in Essbase.
FILTER_METRIC_SPLITTING_LEVEL
Starting from 11.1.1.7.140425, a new parameter can be
used to modify MDX generation.
When this is activated, BI Server will generate multiple
simpler MDX queries instead of a single complicated query.
Tests showed significant performance improvements in unit
testing with this solution.
However, the high number of MDX queries generated may
cause scalability issues in environment with many
concurent users. So this setting must be tested properly
with high concurrency level.
FILTER_METRIC_SPLITTING_LEVEL
This new feature is managed by a variable
FILTER_METRIC_SPLITTING_LEVEL: value 0 means
disabled, 1 means enabled.
This variable can be created as a session variable, or in
opmn.xml file:
<ias-component id="coreapplication_obis1" inheritenvironment="true">
<environment>
<variable id="FILTER_METRIC_SPLITTING_LEVEL" value="CHANGE ME">
Security filters
Usually in OBIEE, security filters are defined in Application
role permission under Manage/Identity using Administration
Tool.
When Essbase is the data source, this is not recommended.
Instead, security filters should be defined directly in
Essbase.
As a consequence, users login must be provided to
Essbase in connection pool and BI Server cache becomes
user specific.
Database Features
IndexCol
Sometimes the formula or columns used vary depending on a
session/presentation variable.
If you use a case when statement then the entire formula is pushed
to the physical query. But by using function IndexCol only the required
column/expression is pushed to the database.
Combined with the new 11g features in prompts (allow selection in a list
of custom values), it allows users to modify very significantly reports
structure without any increased cost on performance. This function can
be used in the RPD or directly in reports.
INDEXCOL( CASE VALUEOF(NQ_SESSION."PREFERRED_CURRENCY") WHEN 'USD' THEN 0 WHEN 'EUR'
THEN 1 WHEN 'AUD' THEN 2 END , "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Usd", "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Eur", "01 - Sample App Data (ORCL)".""."BISAMPLE"."F19 Rev.
(Converted)"."Revenue_Aud")
Agenda
Troubleshooting
When a report returns an error message, or provides wrong results,
follow these steps:
1. Simplify (or ask customer to simplify) the report as much as
possible. Keep the smallest number of columns, union, the most
simple formulas, just one view Even the remaining view should
be as simple as possible (no total/sub-total, no sort order, etc.).
The objective is to get the most simple report possible that still
allows to reproduce the issue.
2. Using this simplified version of the report, retrieve a screenshot
of the results, the corresponding query log, report XML, and
RPD.
3. Analyze the log. If the issue seems to come from the RPD, check
the definition of corresponding columns and LTS. Verify that best
practices are applied.
Troubleshooting
4. If the issue comes from reports structure or if the cause is
unknown, try reproducing it on SampleApp. To do so, edit the
report XML. Replace in the XML the name of the subject area
and names of columns by SampleApp subject area and columns.
Modify the filters in order to retrieve data.
5. If the issue is reproducible on SampleApp, it means that it either
comes from a bug or from reports definition. You can run
additional tests in this simple environment to find the cause and
a solution or a workaround. If you are stuck raise an SR or a
Bug.
6. If the issue is not reproducible on SampleApp, then it probably
comes either from the RPD or from data. You can search for
special data (special characters, null values) by running
queries directly on the database and/or by running the logical
SQL query in Administration/Issue SQL.
Agenda
Calculated Items
Calculated Items
10g
11.1.1.7
Calculated Items
To replicate 10g behavior in 11g, you must:
Add a new column identical to the one used to compute the
calculated item.
In all views except in the one that includes the calculated item,
replace the old column by the new one.
Calculated Items
To identify 10g reports with Calculated Items and option
hide details selected, you can run a basic search in
all 10g catalog files (*. To select reports files only).
To identify all reports with calculated items, search for
string:
calcItem
To identify reports with calculated items and option hide
details selected, search for:
hideDetails="true
Report-Based Totals
This option did not work in 10g and is fixed in 11g. It is
selected by default.
It may change significantly the values. 11g values are often better
than 10g, but not always
Depending on the report, it may be hard to explain the results to
users.
It may be removed from tables and pivot tables, but not from
charts.
Report-Based Totals
What really does Report-Based Total option ?
Sort Orders
Sort orders in 11g are very often different from 10g.
Sort Orders
10g bugs are fixed when a sort key is created in RPD
configuration (example: month name, sorted by month
number). In 10g, sometimes the sort was not applied if
the sort column was not included in the report. In 11g,
even if the sort column is not included in your report,
the sort key defined in RPD is always applied.
Sort Orders
In some circumstances, the sort order defined in 10g
was not applied properly. For instance you select the
sort order Ascending, and instead result is sorted in
descending order. Users in 10g automatically adapted
their sort orders in reports often without even noticing
the issue, just by looking at results. This is fixed in 11g.
So sometimes, in the report definition the sort order is
Descending, in 10g the results are sorted Ascending, in
11g the results are sorted Descending.
Sort Orders
Sort in Graph: In 11g it is not possible to sort data in a
graph using a column that is not included in the view.
You have to add the column in the view (it can be
hidden) to apply the sort order defined on this column.
Generated SQL
The SQL generation in 11g is different from 10g. The
objective is to get more optimized SQL in 11g. However
this may lead to differences in results if the RPD
configuration or tables content is not consistent.
10g
11g
Graph Engine
The software used for the graph engine in 11g is not the
same as the one in 10g.
Although the upgrade process tries to match as much as
possible the graph properties selected in 10g with the
ones available in 11g, a number of differences have to be
expected.
11g graph engine has some new options that were not
available in 10g, and some options that existed in 10g
are not available anymore.
11g