This action might not be possible to undo. Are you sure you want to continue?
Antony Heljula Technical Architect
© Peak Indicators Limited
Aim of Presentation Test Scenario Performance Tests Summary & Conclusion And Finally….
© Peak Indicators Limited
Aim of Presentation
© Peak Indicators Limited
the queries would probably still run just as slowly BI Server It would therefore be more accurate to say that it is the databases that are not performing well! © Peak Indicators Limited 4 .OBIEE Performance Issues When reports take a long time to return results. end users tend to say “OBIEE does not perform well” WebLogic “Analytics” BI Plug-In The truth is that most (99%?) of the processing typically takes place on the underlying data sources BI Presentation Services If another BI tool was used to deliver the same reports.
hopefully by the end of it we’ll have decent performance! The aim will be to get all reports to return in less than 10 seconds The performance test results will be captured and reported on using Usage Tracking © Peak Indicators Limited 5 .Aim of Presentation We are going to investigate how a set of OBIEE Dashboard queries can be tuned to deliver satisfactory performance We’ll begin testing with a set of dashboards that perform very poorly We’ll then implement a number of tuning features one-by-one to see how things improve….
Aim of Presentation We are going to assume that the database has an optimum and balanced configuration. so that any performance issues are “software” related and not “hardware” © Peak Indicators Limited 6 .
Aim of Presentation On an Oracle database. For example: Gather statistics Remove snow-flakes Star Transformation Partitioning Bitmap Indexes Bitmap Join Indexes Compression Parallel Query Aggregation Denormalization We will attempt to answer the following questions: Do they actually work? What performance gains do they actually deliver? In what situations are they most effective? © Peak Indicators Limited 7 . there are many known ways to improve query performance.
Aim of Presentation Notes The aim is to deliver satisfactory performance using standard relational database features The customer won’t be happy if they are told mid-way through UAT that they need to purchase additional software licenses e. Oracle OLAP / Essbase We will however be looking at “Partitioning”. although this option does require additional license cost it is generally purchased by most/all customers who have large data volumes We are going to avoid the use of “hints” Hints effectively hard-code the optimization rules for database queries Hints are “old” technology dating back to the Rule Base Optimizer (RBO). they do not take into account the size and complexity of the query in the way that the Cost Based Optimizer (CBO) does Hints should always be the last resort (in my view) © Peak Indicators Limited 8 .g.
Test Scenario © Peak Indicators Limited 9 .
3 © Peak Indicators Limited 10 .1.1.Test Scenario Hardware Dell Latitude E6400: Windows 7 64-bit 2.200 RPM) Software: Oracle Database Enterprise Edition 11g R2 Oracle BI Enterprise Edition 11.54Ghz dual-core CPU 8GB RAM 250GB SATA internal hard disk (7.
Test Scenario Data-Model To conduct the investigation. a database data-model was built entirely from scratch: Product Dimension Customer Dimension Time Dimension Fact (Daily Summary) Organization Dimension © Peak Indicators Limited 11 .
000 9.000 5.Test Scenario Data Volumes The tables were then populated with a completely fabricated set of data Number of records in each table is show in red Approximately 10GB total volume 500 5.000 11.000 1.000 © Peak Indicators Limited 12 .000 30 Million 500.000 10.
Test Scenario Fabricated Data Examples of the fabricated data that was generated: © Peak Indicators Limited 13 .
Test Scenario RPD An RPD was developed using all the modern best-practices for a starschema data-model: © Peak Indicators Limited 14 .
Test Scenario Dashboards A “Sales Orders” dashboard was created containing 6 pages with only 1 analysis per page 4 pages contained a “summary” analysis (month level or above) 2 pages contained a “detail” analysis (day/week level) © Peak Indicators Limited 15 .
To ensure every performance test was fair. Log off 1. the following steps were taken before each test was conducted: Restart database (to purge all database cache) Purge BI Server cache Purge BI Presentation Services cache © Peak Indicators Limited 16 . Go to each dashboard page one-by-one (in the same order every time) 3. Only move to the next page once the current page has returned results 4.Test Scenario Test Rules Each performance test was conducted manually but in a strict sequence: Log on 2.
the timings could vary by about 5-10 seconds or 10%. we had no indication as to what the results would be – there was no certainty any firm conclusions could be made afterwards No attempt was made to “prepare” the data-model or the performance tests so that the final results would look good or bad When each feature was tested.Test Scenario Final Notes Before starting the tests. no effort was made to tune the particular feature – we simply used the default settings to see if it would work straight “out of the box” If we ran the exact same test twice. We will therefore assume that timings have to be different by 10% or >10 seconds in order to conclude that any tuning feature has made a difference © Peak Indicators Limited 17 .
© Peak Indicators Limited
1. Starting Point Overview
To begin with, the data-model had the following features / issues:
Plenty of snow-flaking No statistics generated (RBO is therefore in use) B-Tree indexes used throughout Star Transformation disabled
© Peak Indicators Limited
1. Starting Point Result
446 seconds in total to run all 6 dashboard pages in sequence
The 4 “summary” reports all perform poorly The 2 “detail” reports are returning in less than 10 seconds
© Peak Indicators Limited
tabname => 'WH_CUSTOMER'. otherwise the “Rule Based Optimizer” (RBO) is used With large data warehouses. Gather Stats 30% Overview If you have a performance issue with a database query. estimate_percent => 30). © Peak Indicators Limited 21 . one of the first questions you will get asked is “have you analysed your tables and indexes?” The Oracle Database comes with a “Cost Based Optimizer” (CBO) which determines the most appropriate way to process your query based on the size and contents of the required tables and their indexes But you need to analyze your tables (or “gather statistics”) in order for the CBO to be used. so this first test will see if gathering statistics using only a 30% sample of data is sufficient to make the CBO work efficiently EXEC DBMS_STATS.GATHER_TABLE_STATS (ownname => 'PEAKTEST'. it is sometimes not possible to analyze all the data and indexes as the process will take too long.2.
Gather Stats 30% Result © Peak Indicators Limited 22 .2.
performance got worse overall by 52%! “Summary” Reports 2 reports had significant improvements >65% 2 reports did not change more than 10% “Detail” Reports Both detail reports suffered worse performance.2. one of them actually took 125 times longer than before! The over-use of “hash joins” is causing the issue © Peak Indicators Limited 23 . Gather Stats 30% Summary Surprisingly.
3. Gather Stats 100% Overview If you have performance issues after gathering statistics using a 30% sample of data.GATHER_TABLE_STATS (ownname => 'PEAKTEST'. it is quite likely that Oracle Support or a DBA will recommend that you try gathering statistics using a greater sample of data So this next test will provide an indication as to whether gathering statistics using a “full” 100% sample will make a significant difference… EXEC DBMS_STATS. tabname => 'WH_CUSTOMER'. © Peak Indicators Limited 24 . estimate_percent => 100).
Gather Stats 30% Result © Peak Indicators Limited 25 .2.
Gather Stats 100% Summary Performance improved overall by 9% “Summary” Reports Performance was essentially the same as with a 30% statistics sample Performance levels are still far from acceptable “Detail” Reports Performance did improve overall by 14% Performance levels are still far from acceptable © Peak Indicators Limited 26 .3.
all the foreign key columns on your fact tables should have “bitmap indexes” created and not just “b-tree indexes”: This test will see what the effect is if you don’t have bitmap indexes on your foreign key columns… 27 © Peak Indicators Limited . it is enabled by setting the following parameter: STAR_TRANSFORMATION_ENABLED = TRUE It is however often overlooked that the documentation recommends that. for this feature to work properly. Star Transformation (No Bitmaps) Overview The Oracle database has a special tuning feature designed for optimising “star schemas” queries.4.
4. Star Transformation (No Bitmaps) Result © Peak Indicators Limited 28 .
but not by much “Summary” Reports Enabling Star Transformation without bitmap indexes had no real effect “Detail” Reports 1 report improved by 50% (11 seconds) but overall there was no significant difference © Peak Indicators Limited 29 . Star Transformation (No Bitmaps) Summary Performance overall got slightly worse.4.
Star Transformation (Bitmaps) Overview This test will see what the impact is when Star Transformation is enabled with bitmap indexes created for the foreign keys on the fact table (as recommended by Oracle) CREATE BITMAP INDEX WH_SALES_FACT_DAY_XFK_1 ON WH_SALES_FACT_DAY_XFK (CUSTOMER_KEY). CREATE BITMAP INDEX WH_SALES_FACT_DAY_XFK_3 ON WH_SALES_FACT_DAY_XFK (ORG_KEY).5. © Peak Indicators Limited 30 . CREATE BITMAP INDEX WH_SALES_FACT_DAY_XFK_2 ON WH_SALES_FACT_DAY_XFK (PRODUCT_KEY). CREATE BITMAP INDEX WH_SALES_FACT_DAY_XFK_4 ON WH_SALES_FACT_DAY_XFK (TIME_DAY_KEY).
5. Star Transformation (Bitmaps) Result © Peak Indicators Limited 31 .
but we still need to do better “Summary” Reports 15% overall improvement 2 of the reports had significant improvements “Detail” Reports A 78% improvement overall.5. Star Transformation (Bitmaps) Summary Performance improved overall by 50%! Finally things are starting to get under control. although one of the reports increased from 8 to 60 seconds © Peak Indicators Limited 32 .
6. Remove Snow-Flakes (Dim Cols.) Overview Snow-flaking occurs when you have a chain of Dimension tables joined together The Oracle Data-Warehousing states that performance can be improved (especially with “Star Transformation”) if you data-model does not consist of snow-flakes So this test will show what happens when we eliminate snow-flaking by combining the snow-flaked tables into the main dimension table (forming a pure star-schema): © Peak Indicators Limited 33 .
6.) Result © Peak Indicators Limited 34 . Remove Snow-Flakes (Dim Cols.
just a few seconds worse overall “Detail” Reports Moving snow-flaked dimension columns into the main dimension table had no real effect. no reports showed improvement! “Summary” Reports Moving snow-flaked dimension columns into the main dimension table had no real effect.6. it made things slightly worse. just a few seconds worse overall © Peak Indicators Limited 35 . Remove Snow-Flakes (Dim Cols.) Summary Surprisingly.
this time we will try a slightly different approach In this test we will eliminate snow-flakes by adding extra foreign keys to the central fact table which join directly to the snow-flaked dimension tables (with “bitmap indexes” created) Will this more perfect “star-schema” improve performance significantly? © Peak Indicators Limited 36 . Remove Snow-Flakes (Add FKs) Overview As the previous method of eliminating snow-flakes did not work.7.
7. Remove Snow-Flakes (Add FKs) Result * Test 6 was backed out © Peak Indicators Limited 37 .
Remove Snow-Flakes (Add FKs) Summary It made things much worse…. making it longer to scan? More FKs more complexity? “Summary” Reports 136% worse overall “Detail” Reports 90% worse overall © Peak Indicators Limited 38 .response times more than doubled! Adding more FKs made the fact table much larger.7.
For example.8.TIME_DAY_KEY = TD. PER_NAME_MONTH. PER_NAME_QTR. For this test 8 bitmap join indexes were created to store the join results of all the joins made between the fact and dimension tables across the 6 dashboard pages © Peak Indicators Limited 39 .PER_NAME_WEEK) WH_SALES_FACT_DAY F. WH_TIME_DAY TD F. Bitmap Join Indexes Overview Oracle promote “bitmap join indexes” as a way of increasing performance by “orders of magnitude” A bitmap join index is a bitmap index which stores the actual results of a join between two or more tables. here is a bitmap join index that stores the result of the joins from the fact table to four columns in the “Day” dimension table: CREATE ON FROM WHERE BITMAP INDEX WH_SALES_FACT_DAY_BMJ_8 WH_SALES_FACT_DAY (PER_NAME_YEAR.TIME_DAY_KEY.
Bitmap Join Indexes Result * Tests 6 and 7 were backed out © Peak Indicators Limited 40 .8.
Bitmap Join Indexes Summary Bitmap join indexes improved performance overall by 55 seconds (18%) However only 1 “detail” report actually used a bitmap join index It seems the Oracle database will only use a bitmap join index if it deems the query is at a low enough granularity to make it worthwhile “Summary” Reports No changes in performance Bitmap join indexes did not get used for any of the summary reports! “Detail” Reports One report reduced from 60 down to only 3 seconds. bitmap join indexes did not get used © Peak Indicators Limited 41 .8. A massive improvement! The other detail report did not change.
Bitmap Join Indexes Overview Bitmap Join indexes do have some restrictions: © Peak Indicators Limited 42 .8.
the database will lookup the TIME_DAY_KEY values in the “Time” dimension table and know exactly which fact table partitions to scan: TIME_DAY_KEY TIME_DAY_KEY © Peak Indicators Limited 43 . it is in YYYYMMDD format When OBIEE queries for a specific time period. This means that. On a data warehouse the most obvious thing to do is partition your large fact tables by Day / Week / Month It is essential to make sure that your partition strategy will result in effect “partition pruning”. rather than scanning the whole table In our case. when OBIEE runs a query. Partition by Month Overview Table “partitioning” is a very common recommendation when dealing with very large tables. we test out partitioning tables by “Month” based on the existing “TIME_DAY_KEY” foreign key column on the fact table.9. the database will know it only needs to scan a sub-set of the table partitions.
Partition by Month Overview Here is the SQL statement used to build our partitioned fact table which has a partition for each of the 24 months of data that exist: © Peak Indicators Limited 44 .9.
CREATE BITMAP INDEX WH_SALES_FACT_DAY_4 ON WH_SALES_FACT_DAY (TIME_DAY_KEY) LOCAL. you need to create “LOCAL” bitmap indexes on the foreign key columns “LOCAL” means that the bitmap index will also be broken down into partitions. Remember to analyze / gather statistics afterwards! © Peak Indicators Limited 45 . potentially improving performance even further as the smaller index partitions will not take so long to process: CREATE BITMAP INDEX WH_SALES_FACT_DAY_1 ON WH_SALES_FACT_DAY (CUSTOMER_KEY) LOCAL. Partition by Month Overview Note that when you partition a table. CREATE BITMAP INDEX WH_SALES_FACT_DAY_3 ON WH_SALES_FACT_DAY (ORG_KEY) LOCAL. CREATE BITMAP INDEX WH_SALES_FACT_DAY_2 ON WH_SALES_FACT_DAY (PRODUCT_KEY) LOCAL.9.
Partition by Month Result * Tests 6 and 7 were backed out © Peak Indicators Limited 46 .9.
This report contains two “Year Ago” and “Year-to-Date” calculations which meant that most/all the table partitions had to be scanned (scanning lots of small partitions may therefore be less efficient than scanning a smaller number of larger partitions) “Detail” Reports A good overall improvement of 6 seconds (35%) © Peak Indicators Limited 47 . Partition by Month Summary Overall performance improved by 57 seconds (23%) “Summary” Reports 3 out of the 4 summary reports had excellent improvement >50% 1 summary report took 30 seconds (33%) longer.9.
is the Oracle database can easily process each partition in parallel On our test environment we have 1 CPU and 1 disk – not the most appropriate environment for testing parallel query For this test. we are enabling parallel query simply by enabling the “auto tuning” parallel query feature for the Oracle Database 11g R2 This feature ignores any “parallel” degree settings you may have manually set for your tables: alter system set PARALLEL_DEGREE_POLICY=AUTO. © Peak Indicators Limited 48 .10. the idea being that one sequential task can be broken down in the multiple tasks running in parallel Parallel query is a good contender once you have implemented table partitioning. Parallel Query (Auto) Overview The Oracle database offers parallel query capability.
Parallel Query (Auto) Result * Tests 6 and 7 were backed out © Peak Indicators Limited 49 .10.
10. our single disk was already operating at >80% capacity So by enabling parallelism there was not much for improvement as our disk was already near to bottlenecking It would be better to run this test on a system with >1 CPU and >1 disk “Summary” Reports The longest running report showed the best improvement of 30 seconds (25%) “Detail” Reports The detail reports had no change. Parallel Query (Auto) Summary A slight performance improvement overall to the “Summary” reports. the “Detail” reports were unaffected NOTE: Even with no parallelism enabled. the explain plans showed that the Oracle Database did not attempt to use parallel query for the granular queries (an excellent feature) 50 © Peak Indicators Limited .
Parallel Query (Auto) Explain Plans with PARALLEL_DEGREE_POLICY=AUTO “Summary” report has parallel query “Detail” report has no parallel query © Peak Indicators Limited 51 .10.
with three possible benefits: Reduced overall storage requirements Performance improvement due to less disk reads (each record uses less space) Improved memory efficiency (data is stored in memory in compressed format) The potential drawback is with higher CPU activity since all data blocks have to be uncompressed at run-time in order to be processed Compression may be a good option in our test environment. since the CPU usage is small compared to the disk usage (20-40% versus 80-100%) Compressing our fact table reduced the data volume from 1. Compression Overview The Oracle database allows you to store data in a compressed (zipped) format.09GB. increasing to 32/64K could increase the compression ratio significantly NOTE: bitmap indexes always store data in compressed format 52 © Peak Indicators Limited . a reduction of about 25% Database was given a default 8K block size.11.46GB down to 1.
insert records with the hint: INSERT /*+ APPEND */ © Peak Indicators Limited 53 .g. Compression Overview Here is the SQL statement used to build our compressed and partitioned fact table: NOTE: There are limitations! e.11.
11. Compression Result * Tests 6 and 7 were backed out © Peak Indicators Limited 54 .
11. although it had more effect on the “Summary” reports where more data was being extracted from disk NOTE: Oracle also has an “Advanced Compression” feature which is designed to provide even greater compression ratios “Summary” Reports Approximately 15% improvement “Detail” Reports No real change © Peak Indicators Limited 55 . performance improved by about 15% across the board. Compression Summary With a 25% compression ratio.
an average of 41 seconds each (with only 1 user!) Apart from adding more hardware (CPUs/memory/disks).. what is the next option? Sometimes there is no alternative to summarising the data in order to reduce the amount of data being processed © Peak Indicators Limited 56 . Aggregation (MVs) Overview Many customers can find themselves in this situation: we have already implemented several different tuning mechanisms but our “Summary” dashboards are still taking far too long….12.
Aggregation (MVs) Overview Implementing an aggregate strategy is often a balancing act: You want to keep the number of aggregates to an absolute minimum You want to summarise the data as much as possible BUT You want aggregates that can serve multiple reports/dashboards (plus ad hoc) You want aggregates to support multiple drill-down levels across many hierarchies Sometimes you have no choice other than to create an aggregate for each dashboard (in which case you may need to consider cube engines. more hardware etc): © Peak Indicators Limited 57 .12.
Aggregation (MVs) Overview In our test environment. we have managed to build a single aggregate which can: Reduce the number of records from 31M down to 8M Support all 4 “Summary” dashboards Provide at least 2 levels of drill-down across all the hierarchies © Peak Indicators Limited 58 .12.
12. Aggregation (MVs) Overview HINT: Use the “Number of Elements” in the RPD to help you determine how much more efficient an aggregate table could be © Peak Indicators Limited 59 .
then please note: Do not rely too heavily on the “Query Rewrite” feature as OBIEE can generate queries that are too complex for the database to rewrite It is often better to model the MVs into the RPD as if they were normal physical aggregate tables (so you rely on OBIEE “aggregate navigation” rather than database “query rewrite”) Remember to partition your MVs and create bitmap indexes on any foreign keys © Peak Indicators Limited 60 . Aggregation (MVs) Overview Aggregate tables on an Oracle database can be either: Standard physical tables (updated or rebuilt during ETL) Materialized Views In theory there is no difference between the two options as they both contain snapshots of the summarised data Materialized Views are easier to maintain and quicker to develop If you use Materialized Views.12.
Aggregation (MVs) Overview s MV partitioned by month LOCAL bitmap indexes (don’t forget to analyze) © Peak Indicators Limited 61 .12.
Aggregation (MVs) Result * Tests 6 and 7 were backed out © Peak Indicators Limited 62 .12.
running over 7 times faster than before! (a total of 143 seconds down to 23) “Detail” Reports The aggregate MVs were designed for the summary reports. Aggregation (MVs) Summary Finally! All queries are now taken 10 seconds or less “Summary” Reports All reports improved. so the detail reports were unaffected and perform exactly the same as before © Peak Indicators Limited 63 .12.
Summary & Conclusion © Peak Indicators Limited 64 .
Summary The biggest gains for “Summary” reports: • Gathering Stats 30% • Aggregation • Star Transformation • Partitioning The biggest gains for “Detail” reports: • Star Transformation • Bitmap Join Indexes • Partitioning © Peak Indicators Limited 65 .
Conclusion The Oracle database provides a wide variety of tuning features. but you need to adopt a combination of tuning features The various tuning mechanisms suit different types of reports If you have performance issues with “Summary” reports then consider: Gathering statistics 30/100% Star Transformation Partitioning Parallel Query Aggregation Compression If you have performance issues with “Detail” reports then consider: Gathering statistics 100% (as opposed to 30%) Star Transformation Partitioning Bitmap Join Indexes 66 © Peak Indicators Limited .
there can be surprises where specific reports suffer worse performance (sometimes significantly worse): © Peak Indicators Limited 67 .Conclusion Always test thoroughly! Whilst the various tuning mechanisms can lead to an overall positive improvement.
And Finally…. What happens if none of the tuning mechanisms discussed give you the desired level of performance? Buy bigger/better hardware (more CPUs+Disks+Memory) Archive data to reduce volume Oracle OLAP (now properly supported with OBIEE 11.1.5) Oracle Essbase Oracle Exadata © Peak Indicators Limited 68 .1.
Questions? © Peak Indicators Limited .
Helping Your Business Intelligence Journey © Peak Indicators Limited .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.