A query with one additional condition slows down [message #299869] |
Wed, 13 February 2008 07:46 |
irremediable
Messages: 38 Registered: December 2007
|
Member |
|
|
Hello!
Here is a script that takes not more that a minute to complete
SELECT
TO_DATE('02.02.2008', 'DD.MM.YYYY') AS DT,
CC.ID_CONTRACTS,
B.ID_BALANCE,
S.SALDO,
C.NUM_CONTRACTS
FROM
FCT_PRCST_CRED P, DET_ACCOUNT A, DET_BALANCE B, FCT_ACOUNT_SALTRAN S, DET_CONTRACTS C,
CON_ASS_CONTR_ACC CC, DET_ORD_LIAB O, DET_TACC T, DET_SOURCE SR
WHERE A.ID_ACCOUNT = S.ID_ACCOUNT
AND A.ID_BALANCE = B.ID_BALANCE
AND A.ID_ACCOUNT = CC.ID_ACCOUNT
AND C.ID_CONTRACTS = CC.ID_CONTRACTS
AND CC.ID_TACC = T.ID_TACC
AND C.ID_SOURCE = SR.ID_SOURCE
AND C.ID_CONTRACTS = P.ID_CONTRACTS
AND P.ID_ORD_LIAB = O.ID_ORD_LIAB
--AND O.NL_ORD_LIAB = '1'
AND TO_DATE('02.02.2008', 'DD.MM.YYYY') BETWEEN P.DT_OPEN AND P.DT_CLOSE
AND TO_DATE('02.02.2008', 'DD.MM.YYYY') BETWEEN S.DT_OPEN AND S.DT_CLOSE
AND TO_DATE('02.02.2008', 'DD.MM.YYYY') BETWEEN CC.DT_OPEN AND CC.DT_CLOSE
AND SR.CODE_SOURCE = 'Loans'
AND C.CODE_CONTRACTS NOT LIKE '%gar%'
AND SUBSTR(B.CODE_BALANCE, 1, 1) IN ( '1', '2' )
AND T.CODE_TACC = '1'
AND A.IS_GK != '1'
AND S.SALDO <> 0
As soon as I uncomment the commented condition it takes more than 15 minutes to complete.
The NL_ORD_LIAB column is of VARCHAR2(250) type and the table
DET_ORD_LIAB contains about 500.000 records in it.
What can be the problem?
What could you please recommend to read in order to overcome a situation like this one?
Thank's is advance.
|
|
|
|
|
|
|
|
|
|
|
|
Re: A query with one additional condition slows down [message #299964 is a reply to message #299897] |
Wed, 13 February 2008 20:39 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
You haven't indicated how many rows the SQL returns with and without this predicate, but Oracle thinks that it will be a LOT less (say, <10%) with the predicate included.
As it thinks that so few rows will be returned, it uses indexes to access every table. Great for small volumes, rubbish for large volumes.
There are a number of different ways to tune this. I would try the following:
- Gather statistics with DBMS_STATS on all tables including the indexes
- If it still does not work, look through the Estimated Rows Returned in the plan. If Oracle is choosing the wrong plan, it usually means one of its estimates is way out. Find out which one (or more) is wrong, and provide a more accurate estimate with a /*+CARDINALITY(alias, rows)*/ hint.
- Still refuses to cooperate? Rearrange the FROM clause so that the tables are in the order that they should be optimally joined, and use the ORDERED hint in combination with FULL and USE_HASH hints to dictate the join order, join method and access method of every single table.
Ross Leishman
|
|
|
|