What index types do you suggest when you have...

Question

If you have tables A, B, C and they are all partitioned range by created_date where that is a timestamp
If nearly all queries can only specify created_date on C only because the B's that belong to A and the C's that belong to B can all be in different partitions relative to their children. So if you have weekly partitions for A, B, C the C's the belong to B and the B's the belong to A can be in different weeks partitions. Now A, B and C all use surrogate keys and there's an index on all of them. You have one to many b/w A->B and one to many b/w B->C where any C has a 1 B parent and that B parent can have one and only one A parent.
When doing the join you end up doing something like
select * from A, B, C
where A.a_id = B.a_id
and B.b_id = C.b_id
and C.created_date >sysdate - 1
The problem is that the indexes on A and B are all global non partitioned as are the indexes on C
Right now we get partition elimination on C on a good day but when the optimizer decides go to A first we get none. Whenever the optimizer goes to A it often does partition range all scans because there is no partition key on A or B
used in the query.
How can we get the query plan to reliably use C first so that partition elimination is always guaranteed.
Currently our thinking is to use /*+ ORDERED */ where the from is C, B, A
Unfortunately the programs cannot introduce bind variables so where we can use Baselines to manage the plan for a given sql_id the only way we can do this is to use CURSOR_SHARING=force via login trigger on their session. This forces the
introduction of bind variables in to the query but Their queries are formed dynamically from a GUI screen that optionally can provide different parameters. So not only do you have N's items in an IN clause to worry about you also have other optional parameters that can show up in the query depending on whether they are used or not.
Q. Has anybody solved this problem by wrapping the query in a procedure so that you can pin the plan to the procedure where all that differs in the procedure is how the arguments are specified? This seems tedius to me because the procedure would have to take comma separate lists of values whenever you want to pass the values to be used in an IN clause.
Only if you wrap a query that can have optional parameters and N values for any parameter can you manage the plan for that procedure thru a baseline otherwise you simply end up with too many plans to manage because of the different combinations of the size of the IN clauses and the optional parameters that can be specified.
When joining b/w A, B, C etc what indexes should be partitioned?
The typical query uses column values on A to limit the C's associated with the B's that are associated with the A's that match those columns. Those fields on A have global indexes so often when the plan is one where it starts at A first and works it's way down it has to consider far too many rows from A that are unrelated to the eventual partition narrowed to from the C.created_date predicate.
Edited by: steffi on Mar 8, 2011 8:56 PM
Edited by: steffi on Mar 8, 2011 8:57 PM
Edited by: steffi on Mar 8, 2011 8:58 PM

Answer 1

Dear Steffi,
The problem is that the indexes on A and B are all global non partitioned as are the indexes on CWhy are you saying that this is a problem?
What are the definition of your primary index on A, B, and C?
You can eventually add the partition key (created_date) to those primary keys and hence locally partition their corresponding PK indexes
As far as you wrote that there is no relation ship between A.created_date, B.created_date a and C.created_date, then I beleive you can't benefit from the partition wise join because in such case you need to join A,B and C on the same partition key which is created_date
Currently our thinking is to use /*+ ORDERED */ where the from is C, B, AUsing /*+ ORDERED */ is not a guarantee that the Oracle Optimiser will obey this hint.
Use the hint /*+ Leading(C) */ instaedYou know that when you wrap your query into a static PL/SQL procedure you don't have to care then about the use bind variable. It will be used;
that is how static PL/SQL wroks. But when you are using dynamic sql into this PL/SQL procedure you need in this case to take care about using bind variable.
The auto-binding trick which is represented by the cursor_sharing=force (or similar) is not highly recommended as far as there exist side effects like the one that cames to my mind now which is when you have function based indexes based on litteral (for example a function based index like substr(a,2,4)) will be rewritten, when cursor_sharing is set to force, to be substr(a, :SYS_B0, :SYS_B1) which will not mach your original query and will not use the function based index anymore
Best Regards
Mohamed Houri