Performance Tuning

Extracting data quickly from data source to the reporting tool is the main task in performance tuning. Clients will not satisfy if the tool works slowly. OBIEE tool has to work fast; to work the tool fast in OBIEE we have 3 major performance tuning techniques.

Major Performance tunings

OBIEE Side: 1. Partition and Fragmentation 2. Aggregate Tables 3. Cache Management 4. Other Techniques OBIEE side a) Maintaining dedicated connection pools b) Disabling logging levels in production environment c) Avoid complex calculations in RPD side d) Avoid too many Alias tables (mostly use to avoid circular joins) e) Avoid Snow flake schema Data Base Side (Other Performance tuning techniques): 1. Creating Index: Indexes are created on Columns not on Tables. Every unique column should have an index. What column we are using in reporting part, those columns should have index. Indexes are mandatory on columns which have join condition. Indexs are 2 types -Bitmap Index (Single Column) [we mostly used Bitmap] -Cluster Index (Group of Columns) [In real time we use TOAD instead of SQL. It is a GUI which is easy to use] 2. Gathering Statics: It means Preparing Cache. This is mostly done whenever there is a data load. 3. Dont use stored procedures 4. Avoid outer join 5. Filters to restrict the data

Aggregate
Q: I have 3 reports Month, Quarter and Year; when I pull the data I am getting data after very long time, what kind of performance tuning we can do? Ans: We can create Aggregate tables, we have to create aggregate table at month level. When we have month level data it can made into Quarter and Year level, so one aggregate table is enough. If we create 3 aggregate tables Month level, Quarter level and Year level, then we need to have space and also more number of joins. Performance will be degraded.

Partition and Fragmentation Business Challenge

Data is often partitioned into multiple physical sources for a single logical table. Organizations need to seamlessly and efficiently access and process data from multiple sources to satisfy user requests. Business applications must know where to go for what type of data and under what conditions.

Business Solution: Oracle BI Server

Oracle BI repository can be configured so that Oracle BI Server handles the navigation to the appropriate source. Oracle BI Server seamlessly and efficiently accesses and processes data from multiple sources to satisfy user requests.

Partitioning
Splitting one large table into multiple small tables is called as Partitioning Partitioning is done by the DBA to improve the performance. Partition is a subset of data, a data fragment, that contains part of a fact or a dimension data. Example: In a Product Table we have 2laksh records of Product A and 3lakh records of Product B. At present the client dont want the data of Product B. So we can do Partitioning based on product A and B (Value Base partitioning) and get only Product A data.

Situation 1 Becomes Multiple Smaller Tables

One Large Table

Oracle BI Server must decide which table(s) to access and combine the results as necessary.

Situation 2 Use

Older Data

or

Latest Data

or

Both

Oracle BI Server must decide when to access which data or if both are required.

Situation 3 Detailed Table or Aggregate Table

Oracle BI Server must decide when it is appropriate to access an aggregate table instead of a detailed table.

Fragmentation
Fragmentation means merging the tables. Partitioning and Fragmentation are quite opposite to each other. Fragmentation is the process, based on this BI Server will understand from which table it needs to pull the results. Depends on the situation we go for Partition and Fragmentation

Partitioning types
We can split tables mainly 4 ways o Fact-based o Value-based o Level-based o Complex