Index usage and nested views

Question

We've got some performance problems when using a complex view that queries against a couple nested views.
We need to use views because we have two outer joins against the same table.
Here's a simplified version:
create or replace view_b as
select a1, b1, c1, d1
from table_c, table_d, view_a
where table_c.c1 = view_a.a1(+)
and table_c.c2= table_d.d1
create or replace view_a as
select a1
from table_a, table_b
where table_a.a1 = table_b.b1(+)
A query that may present problems with large amounts of data is:
select a1, b1
from view_b
where a1 = 1234;
Do indexes of nested views get utilized? Any suggestions?
Thanks

Answer 1

How selective is INSTRUMENT_ID? Is that a primary key? Or are there many rows in the INSTRUMENT table with an INSTRUMENT_ID of 1?
Are the statistics on your table and your index up to date? How, precisely, were statistics gathered?
What version of Oracle are you using? If you are using something earlier than 11.1, it's entirely possible that you have a bind variable peeking problem.
Realistically, you would want Oracle to use two different query plans for this statement depending on the value of the bind variable. If you pass in a NULL, you'd want Oracle to do a table scan. If you pass in a value, you'd want Oracle to do an index scan. Prior to 11.1, when this statement is first parsed, Oracle looks at the bind variable you passed in and picks the best plan for that bind variable value. When you subsequently execute this statement with other bind variable values, that first query plan is used. Thus, if the first time this code was executed you passed in a NULL, it would have made sense for Oracle to choose the table scan and all subsequent executions (until the query was aged out of the shared pool) would continue to use that query plan.
Oracle 11.1 introduced the ability to have multiple query plans for the same query depending on the bind variable values that were passed in which may well alleviate the problem you're seeing.
Justin