CBO: OWB Dimension Performance Isssue (DIMENSION_KEY=DIM_LEVEL_ID)

Question

Hi
In my opinion the OWB Dimensions are very useful, but sometimes there are some Performance Issues.
I am working with the OWB Dimensions quite a lot and with the big Dimensions ( > 100.000 rows) , i often get some Performance problems when OWB generates the code to Load (Merge Step) or Lookup these Dimensions.
OWB Dimensions have a PK on DIMENSION_KEY and Level Surrogate IDs which are equal to the DIMENSION_KEY if the The Row is an Element of that Level (and not a Parent Hierarchic Element)
I am hunting the Problem down to the Condition DIMENSION_KEY= (DETAIL_)LEVEL_SURROGATE_ID. The OWB does that to get only the Rows with (Detail-) Level Attributes.
But it seems, that the CBO isn´t able to predicted the Cardinality right. The CBO always assume, that the Result Cardinality of that Condition is 1 row. So I assume that Conditon is the reason for the "bad" Execution Plans, the Execution Plan
"NESTED LOOPS OUTER" With the Inline View with Cardinality = 1;
Example:
SELECT COUNT(*) FROM DIM_KONTO_TAB  WHERE DIMENSION_KEY= KONTO_ID;
--2506194
Explain Plan for:
SELECT DIMENSION_KEY, KONTO_ID
FROM DIM_KONTO_TAB where DIMENSION_KEY= KONTO_ID;
+| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |+
+| 0 | SELECT STATEMENT | | 1 | 12 | 12568 (3)| 00:00:01 | | |+
+| 1 | PARTITION HASH ALL | | 1 | 12 | 12568 (3)| 00:00:01 | 1 | 8 |+
+|* 2 | TABLE ACCESS STORAGE FULL| DIM_KONTO_TAB | 1 | 12 | 12568 (3)| 00:00:01 | 1 | 8 |+
Predicate Information (identified by operation id):
+2 - STORAGE("DIMENSION_KEY"="KONTO_ID")+
filter("DIMENSION_KEY"="KONTO_ID")
Or: For Loading an SCD2 Dimension:
+|* 12 | FILTER | | | | | | Q1,01 | PCWC | |+
+| 13 | NESTED LOOPS OUTER | | 328K| 3792M| 3968 (2)| 00:00:01 | Q1,01 | PCWP | |+
+| 14 | PX BLOCK ITERATOR | | | | | | Q1,01 | PCWC | |+
+| 15 | TABLE ACCESS STORAGE FULL | OWB$KONTO_STG_D35414 | 328K| 2136M| 27 (4)| 00:00:01 | Q1,01 | PCWP | |+
+| 16 | VIEW | | 1 | 5294 | | | Q1,01 | PCWP | |+
+|* 17 | TABLE ACCESS STORAGE FULL | DIM_KONTO_TAB | 1 | 247 | 489 (2)| 00:00:01 | Q1,01 | PCWP | |+
I tried a lot:
- statistiks are gathered often, with monitoring Informations and (Frequencey-)Histograms and the Conditions Colums
- created extend Statistiks DBMS_STATS.CREATE_EXTENDED_STATS(USER, 'DIM_KONTO_TAB', '(DIMENSION_KEY, KONTO_ID)')
- created combined idx one DIMENSION_KEY, LEVEL_SURROGATE_ID
- red a lot
- hinted the Querys in OWB ( but it seems the inline View is to complex to use a Hash Join)
Next Step:
-Tracing the Optimizer CBO Events.
Does some one has an Idea how-to help the CBO to get the cardinality right?
If you need more Information, please tell me.
Thanks a lot.
Moritz

Answer 1

Hi Patrick,
For a relational dimension, these values must be unique within the LEVEL. It is not required to be a numeric ID (although that follows the best practices of surrogate keys best).
If you use the same sequence for the dimension you have insured that each entry in the entire dimension is unique. Which means that you can move your data as is into OLAP solutions. We will do this as well in the next major release.
Hope that helps,
Jean-Pierre