Query Optimization Problem

Question

Hi
I have a optimization problem and wondering if you can help me, The problem is I am getting two diffrent costs for two diffrent users, when I login and run as the object owner the cost is normal but when I login and run the query as a diffrent user I have a dramatic increase in the costs.
For example to retrieve the rows from Work_Order_Coding_Tab as the object owner the cost is 1 while logged in as the other user the cost is 26070 :(.
views such as xxx_work_order_coding, active_work_order has got more than 2 million records.
The query is
SELECT a.wo_no "AOnr", a.customer_no "Kundnr", c.name "Kundnamn",
a.contact "Kontakt", a.reference_no "Referens",
a.err_descr "Kort_beskrivning", replace(a.err_descr_lo, chr(13) ||
chr(10), ' ') "Lång_beskrivning", a.mch_code "Objektnr",
b.mch_name "Objektnamn", replace(a.performed_action_lo, chr(13) ||
chr(10), ' ') "Utfört arbete", sum(b.amount) "Kostnad", sum(
b.sales_price_amount) "Kundpris", a.reg_date "Regdatum",
a.real_f_date "Utf_datum", a.work_master_sign "Arbetsbefäl",
a.work_type_id "Arbetstyp", a.state "Status"
FROM objown.active_work_order a, objown.xxx_work_order_coding b,
objown.cust_ord_customer c
WHERE b.work_order_account_type = 'Kostnad'
AND a.wo_no = b.wo_no
AND a.mch_code = b.mch_code
AND a.customer_no = b.customer_no
AND a.customer_no = c.customer_no
AND b.customer_no = c.customer_no
AND a.mch_code = b.mch_code
AND b.order_no IS NULL
AND a.agreement_id IS NULL
AND (a.work_type_id = 'L'
OR a.work_type_id = 'U'
OR a.work_type_id = 'S'
OR a.work_type_id = 'T'
OR a.work_type_id = 'UF')
AND a.customer_no < '5%'
AND a.customer_no LIKE '10027'
AND a.org_code LIKE '510'
AND a.state LIKE 'Av%'
GROUP BY a.wo_no, a.customer_no, c.name, a.contact, a.err_descr,
a.err_descr_lo, a.mch_code, b.mch_name, a.performed_action_lo,
a.work_master_sign, a.work_type_id, a.reference_no, a.state,
a.reg_date, a.real_f_date
When Running as the object owner I get the following costs, is
Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves a single ROWID from the B*-tree index CUST_ORD_CUSTOMER_PK. 1 1 0,007
2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index ACTIVE_WORK_ORDER_IX4. 1 1 --
3 This plan step retrieves rows from table ACTIVE_WORK_ORDER_TAB through ROWID(s) returned by an index. 1 1 0,198
4 This plan step loops through the query's IN list predicate, executing its child step for each value found.
5 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 2 1 0,205
6 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index WORK_ORDER_CODING_PK. 1 1 --
7 This plan step retrieves rows from table WORK_ORDER_CODING_TAB through ROWID(s) returned by an index. 1 1 0,053
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 3 1 0,258
9 This plan step retrieves a single ROWID from the B*-tree index ACTIVE_WORK_ORDER_PK. 1 1 --
10 This plan step retrieves rows from table ACTIVE_WORK_ORDER_TAB through ROWID(s) returned by an index. 1 1 0,014
11 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 4 1 0,271
12 This plan step has no supplementary description information.
13 This plan step designates this statement as a SELECT statement. 5 1 0,271
AND Running as end user brings the following costs!
1 This plan step retrieves a single ROWID from the B*-tree index CUST_ORD_CUSTOMER_PK. 1 1 0,007
2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index ACTIVE_WORK_ORDER_IX4. 1 360 --
3 This plan step retrieves rows from table ACTIVE_WORK_ORDER_TAB through ROWID(s) returned by an index. 29 10 1,982
4 This plan step loops through the query's IN list predicate, executing its child step for each value found.
5 This plan step represents the execution plan for the subquery defined by the view ACTIVE_WORK_ORDER. 29 1 4,095
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 30 1 4,102
7 This plan step retrieves all rows from table WORK_ORDER_CODING_TAB. 26 070 10 0,527
8 This plan step retrieves a single ROWID from the B*-tree index ACTIVE_WORK_ORDER_PK. 1 1 --
9 This plan step retrieves rows from table ACTIVE_WORK_ORDER_TAB through ROWID(s) returned by an index. 1 1 0,014
10 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 26 071 3 0,199
11 This plan step represents the execution plan for the subquery defined by the view XXX_WORK_ORDER_CODING. 26 071 3 17,748
12 This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. 26 102 1 10,018
13 This plan step has no supplementary description information.
14 This plan step designates this statement as a SELECT statement. 26 103 -- --

Answer 1

AND a.customer_no < '5%'
AND a.customer_no LIKE '10027'
AND a.org_code LIKE '510'
Does the query bring back the expected results? There appears to be an issue with your customer_no logic. The only customer_no that will meet your criteria is '10027', the < '5%' appears redundant.
with a as (
   select '10027' customer_no from dual union all
   select '10027x' customer_no from dual)
select *
from a
where a.customer_no < '5%'
and a.customer_no like '10027';Also, your LIKE operators can be rewritten as '=' if you do not use wildcards, ie '%' or '_'.
If the active_work_order table is larger than the others, you may want to use the smallest table when comparing the customer_no column as it may assist in the execution path.