Oracle Query SQL Tuning? - sql

Question

select round(avg(et_gsm_sınyal)) as sinyal,mahalle_kodu,ilce_kodu,sebeke
from
(select et_gsm_sınyal,sozlesme_no,SUBSTR(et_operator,1,5) as sebeke
from thkol316old
where tarih >= ADD_MONTHS (TRUNC (SYSDATE, 'MM'), -1)
AND tarih < TRUNC(SYSDATE, 'MM')) okuma,
(select sozlesme_no,ilce_kodu,mahalle_kodu from commt020) bilgiler
where okuma.sozlesme_no=bilgiler.sozlesme_no
group by mahalle_kodu,ilce_kodu,sebeke;
commt020 -> customer table
thkol316old -> old bill table
This query is works but it's works very slow.
It's about 550 seconds response time.
What am I supposed to do this query work faster ?
It's the execution plan
SELECT STATEMENT 7547
HASH
GROUP BY 7547
FILTER
Filter Predicates
ADD_MONTHS(TRUNC(SYSDATE#!,'fmmm'),-1)
NESTED LOOPS
NESTED LOOPS
7546
TABLE ACCESS
COMMT020 BY GLOBAL INDEX ROWID 3 ROW LOCATION ROW LOCATION`

Answer 1

First of all I would try with ordinary table joins instead of the more awkward inline view - joining, I hope the following will work (I haven't created tables and tried it):
select round(avg(okuma.et_gsm_sınyal)) as sinyal,
bilgiler.mahalle_kodu,bilgiler.ilce_kodu, SUBSTR(okuma.et_operator,1,5) as sebeke
from thkol316old okuma
inner join commt020 bilgiler on okuma.sozlesme_no=bilgiler.sozlesme_no
where okuma.tarih >= ADD_MONTHS (TRUNC (SYSDATE, 'MM'), -1)
AND okuma.tarih < TRUNC(SYSDATE, 'MM')
group by bilgiler.mahalle_kodu,bilgiler.ilce_kodu, SUBSTR(okuma.et_operator,1,5);
Then, if things still are slow:
Verify that there is an index where bilgiler.sozlesme_no is the
first column in the index
Verify that there is an index where okuma.sozlesme_no is the first column in the index
Verify that there is an index where okuma.tarih is the first column in the index

Answer 2

Clearly
column tarih is not indexed for table thkol316old
create index tarih_idx on thkol316old (tarih);
Then
analyze table commt020 compute statistics;
analyze table thkol316old compute statistics;
In Oracle analyzing tables produce information that is used in creating query execution plans. Every time you alter a table you may want to also analyze it. Many big systems do it on a schedule.

Answer 3

First of all, you don’t need BILIGILER inline view just to select a few columns from COMMT020 table, you’ll be perfectly fine selecting from that table directly:
SELECT ROUND(AVG(et_gsm_s1nyal)) AS sinyal,
mahalle_kodu,ilce_kodu,sebeke
FROM (
SELECT et_gsm_s1nyal,
sozlesme_no,
SUBSTR(et_operator,1,5) AS sebeke
FROM thkol316old
WHERE tarih >= ADD_MONTHS (TRUNC (SYSDATE, 'MM'), -1)
AND tarih < TRUNC(SYSDATE, 'MM')
) okuma, commt020
WHERE okuma.sozlesme_no = commt020.sozlesme_no
GROUP BY mahalle_kodu,ilce_kodu,sebeke
/
Then, let’s rewrite the join using ANSI join expression. I prefer ANSI joins over old Oracle-style joins because they allow separating join conditions from filtering conditions, therefore providing more clarity into what’s actually going on. Also, it is a good style to assign aliases to the tables and clearly indicate which columns we select from which table.
SELECT ROUND(AVG(o.et_gsm_s1nyal)) AS sinyal,
c.mahalle_kodu, c.ilce_kodu, o.sebeke
FROM (
SELECT th.et_gsm_s1nyal,
th.sozlesme_no,
SUBSTR(th.et_operator,1,5) AS sebeke
FROM thkol316old th
WHERE th.tarih >= ADD_MONTHS (TRUNC (SYSDATE, 'MM'), -1)
AND th.tarih < TRUNC(SYSDATE, 'MM')
) okuma o
JOIN commt020 c ON o.sozlesme_no = c.sozlesme_no
GROUP BY c.mahalle_kodu, c.ilce_kodu, o.sebeke
/
Now it is clearer than the remaining inline view is redundant too. Although it's hard to tell without knowing the details of those tables, but you will probably be better off “unwrapping” that inline view and replacing it with a straight join:
SELECT ROUND(AVG(th.et_gsm_s1nyal)) AS sinyal,
c.mahalle_kodu,
c.ilce_kodu,
SUBSTR(th.et_operator,1,5) AS sebeke
FROM commt020 c
JOIN thkol316old th ON c.sozlesme_no = th.sozlesme_no
WHERE th.tarih >= ADD_MONTHS (TRUNC (SYSDATE, 'MM'), -1)
AND th.tarih < TRUNC(SYSDATE, 'MM')
GROUP BY c.mahalle_kodu, c.ilce_kodu, SUBSTR(th.et_operator,1,5)
/
Unfortunately optimizing this query further requires additional information, such as:
The new execution plan.
The version of Oracle you’re using.
Numbers of rows in THKOL316OLD and COMMT020 tables.
What indexes exist on those tables.