Trying to tune a statement without success.

Question

Dear all,
I got this statement in production:
SELECT a.ID, a.order_date, b.NAME, a.customer_total_price, a.department_name,
a.gilboa_no, a.currency_id
FROM orders a, order_statuses b
WHERE a.is_local = 0
AND a.order_date > TRUNC (SYSDATE, 'YEAR')
AND a.status_id = b.ID
-- AND a.status_id IN (7, 43, 62)
it runs very fast, see execution plan:
SELECT STATEMENT, GOAL = CHOOSE                         
NESTED LOOPS                         
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDERS               
INDEX RANGE SCAN     Object owner=D90STORYSERVER     Object name=IDX_DEPT_ID_ORDER_DATE               
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDER_STATUSES               
INDEX UNIQUE SCAN     Object owner=D90STORYSERVER     Object name=STATUS_PK               
When I unremark the last AND condition, it became extremly slow:
SELECT a.ID, a.order_date, b.NAME, a.customer_total_price, a.department_name,
a.gilboa_no, a.currency_id
FROM orders a, order_statuses b
WHERE a.is_local = 0
AND a.order_date > TRUNC (SYSDATE, 'YEAR')
AND a.status_id = b.ID
AND a.status_id IN (7, 43, 62)
execution plan:
SELECT STATEMENT, GOAL = CHOOSE                         
CONCATENATION                         
NESTED LOOPS                         
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDERS               
INDEX RANGE SCAN     Object owner=D90STORYSERVER     Object name=ORDER_1_STATUS_FK_I_1               
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDER_STATUSES               
INDEX UNIQUE SCAN     Object owner=D90STORYSERVER     Object name=STATUS_PK               
NESTED LOOPS                         
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDERS               
INDEX RANGE SCAN     Object owner=D90STORYSERVER     Object name=ORDER_1_STATUS_FK_I_1               
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDER_STATUSES               
INDEX UNIQUE SCAN     Object owner=D90STORYSERVER     Object name=STATUS_PK               
NESTED LOOPS                         
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDERS               
INDEX RANGE SCAN     Object owner=D90STORYSERVER     Object name=ORDER_1_STATUS_FK_I_1               
TABLE ACCESS BY INDEX ROWID     Object owner=D90STORYSERVER     Object name=ORDER_STATUSES               
INDEX UNIQUE SCAN     Object owner=D90STORYSERVER     Object name=STATUS_PK     
THE field a.status_id is an INDEX.
Appriciate a lot yuor help!!!!!

Answer 1

Here is how I see your 2 queries:
Query 1:
SELECT a.ID, a.order_date, b.NAME,
FROM orders a, order_statuses b
WHERE a.is_local = 0
AND a.order_date > TRUNC (SYSDATE, 'YEAR')
AND a.status_id = b.ID
SELECT STATEMENT, GOAL = CHOOSE                         
NESTED LOOPS                         
TABLE ACCESS BY INDEX ROWID     Object Object name=ORDERS
INDEX RANGE SCAN     Object name=IDX_DEPT_ID_ORDER_DATE
TABLE ACCESS BY INDEX ROWID     Object Object name=ORDER_STATUSES
INDEX UNIQUE SCAN     Object Object name=STATUS_PKPresuming that the first index access listed is done first, then it is using an index on the order date on ORDERS, and then joining out to ORDER_STATUSES using its primary key index for each matching row.
Query 2:
>
SELECT a.ID, a.order_date, b.NAME,
FROM orders a, order_statuses b
WHERE a.is_local = 0
AND a.order_date > TRUNC (SYSDATE, 'YEAR')
AND a.status_id = b.ID
AND a.status_id IN (7, 43, 62)
SELECT STATEMENT, GOAL = CHOOSE
CONCATENATION
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID Object name=ORDERS
INDEX RANGE SCAN Object name=ORDER_1_STATUS_FK_I_1
TABLE ACCESS BY INDEX ROWID Object name=ORDER_STATUSES
INDEX UNIQUE SCAN Object name=STATUS_PK
[Above NESTED LOOP repeated another 2 times]Again, presuming the first index access is done first, then it is applying the Status ID constraint using the ORDER_1_STATUS_FK_I_1 index, and then joining out to ORDER_STATUSES using its primary key index.
My guess is that there are many rows matching these 3 status id values i.e. not just 3 rows, but many hundreds or thousands of rows. And I am also guessing that fewer rows match the date constraint than match the status id values - probably tens of rows with the right dates versus thousands of rows with the right status ids. You can verify this by counting how many rows match each condition:
SELECT count (*) FROM orders a WHERE a.order_date > TRUNC (SYSDATE, 'YEAR')
SELECT count (*) FROM orders a WHERE a.status_id IN (7, 43, 62)
I am guessing that the second SELECT will retrieve many more rows than the first.
In the first query the date constraint was applied using an index BEFORE the data row in the table was accessed. In the second query the date constraint is applied AFTER the data row in the table has been accessed i.e. Oracle has to read the data row in the table to get the date value to check if it matches the constraint in the WHERE clause.
So the first query uses an index on date, which is quite compact, quickly identifies any matching rows, and then ONLY retrieves the matching rows from the table.
The second query uses an index on status id, has to go to the table to retrieve many hundreds or thousands of matching rows, to then reject them because their date value does not match the constraint. This second query is doing a lot more disk I/O than the first one, if my guess about the data distributions and matching rows is correct.
Why is Oracle doing this? Probably because it considers an '=' constraint to be more restrictive (will match fewer rows) than a '>' constraint (an open ended number of rows may match). Without full statistics or a histogram of data distribution, Oracle believes that using the index on status_id is BETTER than using the index on order_date. It may be wrong, but Oracle doesn't know this before it runs the query. It can only use the information available to it at the time of parsing the query. And this makes it think that the status_id index should be better than the order_date index.
You don't mention which version of Oracle you are using. This will affect how many statistics it can collect, and how well the optimiser uses them when parsing SQL. 10g collects more statistics and tries to use them better.
The solution? Create a composite index on (status_id, order_date, is_local). Query 1 will still execute using the original order_date index. Query 2 should now prefer this new index as it has BOTH status_id and order_date in it. Oracle can now test the rows using the data in the index WITHOUT retrieving the data rows from the table. This will drastically reduce the amount of disk I/O being done and improve performance. Only the matching data rows will be retrieved from the table, having already matched all 3 major constraints. Furthermore, because the index is ordered, all the relevant matching rows will be in the same index blocks when retrieved - which is one of the main benefits of an index: row density within the index and packing.
John