Partition Pruning not working with "Transformation"

Question

Hello,
we have a 10gR2 RAC at our customer and because every Report is reporting on Monthly-Basis, we partitioned the Fact-Tables by Month.
That's working fine for our "normal" queries, where the Dimension-Table is joined to the Fact-Table and the Filter is on one Dimension-Column.
Example:
select     Dim.LT3_KEY,
     sum(Fact.VPR_GC_PER_FULL1) metric
from     MART.V_PDM_RU_AGG_PROK_03     Fact
     join     MART.L_PERIODS     Dim
     on      (Fact.LT3_KEY = Dim.LT3_KEY)
where Dim.LT3_SEQ_MARK = -2
group by Dim.LT3_KEY
The Fact-Table is "pruned" and only the one partition selected by "Dim.LT3_SEQ_MARK = -2" is read.
This leads to 1.9 seconds runtime.
Now the Problem:
We have special Transformation-Metrics. This leads to a second join of the same Dimension to the Fact-Table.
Problem: The Filter/Where-Clause is on the Second Dimesnion-Table and with this, Oracle will no longer prune.
Example:
select     Dim2.LT3_KEY,
     sum(Fact.VPR_GC_PER_FULL1) metric
from     MART.V_PDM_RU_AGG_PROK_03     Fact
     join     MART.L_PERIODS     Dim1
     on      (Fact.LT3_KEY = Dim1.LT3_KEY)
     join     MART.L_PERIODS     Dim2
     on      (Dim1.LT3_KEY = Dim2.LT3_SM_LYEAR_1)
where Dim2.LT3_SEQ_MARK = -2
group by Dim2.LT3_KEY
This SQL needs 26 Seconds, because it reads all data, not only the relevant.
Of course, I can re-write that query but this is not possible in our environ,ment.
Question: Is there any trick, hint, index to build, configuration or something else I can do to get the Oracle to prune also with the second query. The query should remain exactly the same as it is now?
Thanks in advance.
Frank
P.S.: I now, that following query delivers the same and is working with pruning. But I can not change the build-process of the query.
select     Dim.LT3_KEY,
     sum(Fact.VPR_GC_PER_FULL1) metric
from     MART.V_PDM_RU_AGG_PROK_03     Fact
     join     MART.L_PERIODS     Dim
     on      (Fact.LT3_KEY = Dim.LT3_SM_LYEAR_1)
where Dim.LT3_SEQ_MARK = -2
group by Dim.LT3_KEY

Answer 1

Hi Frank,
it seems that the second join "on (Dim1.LT3_KEY = Dim2.LT3_SM_LYEAR_1)" on the same table (L_PERIODS as dim1 and dim2) forced the oracle optimizer to read the whole table instead of using indexes.
There are several ways to tune this statement. Here are a few things i would try:
If both columns (LT3_KEY) and (LT3_SM_LYEAR_1) are indexed with a single index you may force the optimizer with an oracle hint:
/*+ INDEX (DIM2 <indexname for LT3_SM_LYEAR_1>) INDEX (DIM1 <indexname for LT3_KEY)> */
to use them.
You may switch both "index-Hints" to see, if there are different results in runtime.
Another hint could help the optimizer first to join DIM1 with DIM2 and join the against the fact table:
/*+ LEADING(dim2 dim1 fact) */
You may test the statement with a new combined index (LT3_KEY, LT3_SM_LYEAR_1) or in reverse order ( LT3_SM_LYEAR_1, LT3_KEY). after this you may experience with the given optimizer hints and rerun the query.
Maybe its a good idea to make indexes more "useful" to the optimizer as "full table scans". This worked good with oracle version prior 10, so maybe you want to try this hint to force oracle to use indexes in your query:
/*+ OPT_PARAM('optimizer_index_cost_adj' 'xx') */
where xx is a value lower than 100, try with 40 to see if there are changes to the execution plan.
Don't forget to use the ALIAS object-names instead of physical names in optimizer hints, because otherwise they never work ...
And sometimes FULL SCANS are not that bad ...