Медленно выполняется запрос Oracle

Есть запрос:
SELECT zxp.rulon.ukey, n, nz, bz, zxp.rulon.ms, tz, ts, round(hz,2) HZ, hdm, hdp, zxp.rulon.h1, l, round(pf,2) PF, pt, pu, pdm, pdp, pbm, pbp, pe, zxp.mc.ukey, naim, LDM, LDP, LBM, LBP, H0, tr, tv, DOP, zxp.graph.irez as Broken, K_Z as Brigade FROM zxp.rulon, zxp.mc, zxp.graph WHERE ts BETWEEN to_date('02.01.2016 7:00:00', 'dd.mm.yyyy hh24:mi:ss') AND to_date('02.01.2016 15:00:00', 'dd.mm.yyyy hh24:mi:ss') AND zxp.rulon.ms = zxp.mc.ukey AND zxp.rulon.ukey = zxp.graph.u_rul AND k = ( SELECT min(k) FROM zxp.Graph WHERE zxp.rulon.ukey = zxp.graph.u_rul ) ORDER BY ts
Но его выполнение занимает от 4 секунд и выше. Можно ли его оптимизировать?
zxp.Rulon:
UKEY NUMBER N NUMBER ADR NUMBER NZ NUMBER MS NUMBER TR DATE TZ DATE TV DATE TS DATE TM NUMBER SK NUMBER DOP NUMBER BZ NUMBER HZ NUMBER HZZ NUMBER HDM NUMBER HDP NUMBER H0 NUMBER H1 NUMBER L NUMBER LDM NUMBER LDP NUMBER LBM NUMBER LBP NUMBER PF NUMBER PT NUMBER PDM NUMBER PDP NUMBER PBM NUMBER PBP NUMBER PU NUMBER PE NUMBER L_1 NUMBER L_2 NUMBER L_3 NUMBER L_4 NUMBER H1S NUMBER H2S NUMBER H3S NUMBER H4SI NUMBER H1SI NUMBER T1S NUMBER T2S NUMBER T3S NUMBER T4S NUMBER D1 NUMBER D2 NUMBER D3 NUMBER D4 NUMBER GH4N NUMBER GH4Z NUMBER GH4S NUMBER GH1Z NUMBER GH1S NUMBER L4 NUMBER D_RR NUMBER D_RV NUMBER K_T NUMBER K_Z NUMBER F_REZ1 NUMBER F_REZ2 NUMBER F_REZ3 NUMBER F_REZ4 NUMBER I_REZ1 NUMBER I_REZ2 NUMBER I_REZ3 NUMBER I_REZ4 NUMBER
Graph:
T2 NUMBER T3 NUMBER T4 NUMBER DL NUMBER IREZ NUMBER FREZ NUMBER LOGBITS NUMBER UKEY NUMBER U_RUL NUMBER K NUMBER T DATE H4 NUMBER H1 NUMBER V1 NUMBER V2 NUMBER V3 NUMBER V4 NUMBER
Это то что вы просили ? структура таблицы ?
Plan hash value: 515981838
-------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1653 | 663K| | 332 (2)| 00:00:04 | | 1 | SORT ORDER BY | | 1653 | 663K| 1672K| 332 (2)| 00:00:04 | |* 2 | VIEW | VW_WIF_1 | 1653 | 663K| | 184 (2)| 00:00:03 | | 3 | WINDOW SORT | | 1653 | 384K| 872K| 184 (2)| 00:00:03 | |* 4 | FILTER | | | | | | | | 5 | TABLE ACCESS BY INDEX ROWID | GRAPH | 3320 | 110K| | 88 (2)| 00:00:02 | | 6 | NESTED LOOPS | | 1653 | 384K| | 94 (2)| 00:00:02 | |* 7 | HASH JOIN | | 1 | 204 | | 7 (15)| 00:00:01 | | 8 | TABLE ACCESS BY INDEX ROWID| RULON | 1 | 195 | | 3 (0)| 00:00:01 | |* 9 | INDEX RANGE SCAN | I_RUL | 1 | | | 2 (0)| 00:00:01 | | 10 | TABLE ACCESS FULL | MC | 45 | 405 | | 3 (0)| 00:00:01 | |* 11 | INDEX RANGE SCAN | GRAPH_RUL | 3391 | | | 12 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id): ---------------------------------------------------
2 - filter("VW_COL_33" IS NOT NULL) 4 - filter(TO_DATE('02.01.2016 15:00:00','dd.mm.yy hh24:mi:ss')>=TO_DATE('2016-01-02 07:00:00', 'yyyy-mm-dd hh24:mi:ss')) 7 - access("RULON"."MS"="MC"."UKEY") 9 - access("TS">=TO_DATE('2016-01-02 07:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "TS"<=TO_DATE('02.01.2016 15:00:00','dd.mm.yy hh24:mi:ss')) 11 - access("RULON"."UKEY"="GRAPH"."U_RUL")
Индекс таблиц RULON:
Таблица Индекс Тип Колонки RULON RUL_UN UNIQUE UKEY RULON I_RUL NONUNIQUE TS
GRAPH:
GRAPH GRAPH_RUL NONUNIQUE U_RUL

Ответ

Оптимизатор оракла походу построил максимально эффективный план для данного запроса. Он по GRAPH идет всего один раз, строя оконную функцию и выбирая по ней запись с минимальным K. Но для поиска этого минимума ему приходится пройти много записей графа и просто изменением запроса это не лечится.
Как решения вижу:
Хранить минимальный K к рулону (и вести его триггерами), что бы исключить необходимость поиска минимума в графе. Как минус - собственно необходимость создания триггера, который при добавлении/модификации записей в GRAPH должен будет сверять K с хранимым в рулоне и менять его там, при необходимости. Построить на GRAPH составной индекс по колонкам (U_RUL, K), тогда оракл должен сходу находить записи с минимальным K, не заглядывая в данные. Как минус - индекс на 373кк записей займет много места и несколько замедлит создание новых записей в таблице GRAPH