Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Помогите разобраться с запросом

0 views
Skip to first unread message

Tolik K.

unread,
Jan 4, 2004, 3:52:04 PM1/4/04
to
Доброго времени суток!
Сабж!
Имеем запрос, в котором две таблицы связаны между собой подзапросом.
Текст и план (планы для двух вариантов запроса) ниже.
Таблицы opr и opr_crg (по сути одна и таже таблица в разных срезах) связаны
через подзапрос oprvag. Хинты вроде заданы так, чтобы выполнялся сначала
oprvag, а затем к нему цеплялись opr и opr_crg. Запрос выполняется ну
ооочень долго. Временное табл. пространство разрастается немерянно...
Теперь: если связать (так тоже можно) подзапрос oprvag с opr, а вот opr уже
с opr_crg (то есть раскомментировать вторую строчку where во внешнем запросе
и закомментировать первую, то запрос выполняется в момент. План вроде
кардинально не меняется. Правда, исчезает фулскан на opr...
В общем, если охота размять мозги и помочь ближнему ;) гляньте на запрос и
варианты планов к нему с первой строкой условия и со второй. Ведь, как я
понимаю, в любом из вариантов подзапрос oprvag должен выполниться сначала и
один раз?..
Таблица operations около полумиллиона записей, vagonrun около 80тыс.
Прошу прощения, если невнятно что сформулировал.
----------------------------------------------------------------------------
--------------------------------
select /*+ ordered USE_NL(oprvag opr opr_crg crg loc) */
count(distinct oprvag.vag_id) as qnt
from (
select /*+ ordered USE_NL(vag opr opt) */
vag_id, max(opr.id) last_opr_id
from vagonrun vag, operations opr, operation_types opt
where vag.id=opr.vag_id and
opr.opt_id=opt.id and
opt.otg_id = 1 and
opr.stop_stamp<To_date('30.12.2003 20:00','DD.MM.YYYY
HH24:MI') and
(vag.departure_stamp is null or vag.departure_stamp >=
To_date('30.12.2003 20:00','DD.MM.YYYY HH24:MI'))
group by vag_id
) oprvag, operations opr, operations opr_crg, cargoes crg, locations
loc
where
oprvag.vag_id = opr_crg.vag_id and -- ПЕРВЫЙ ВАРИАНТ УСЛОВИЯ -
oprvag с opr и oprvag с opr_crg
-- opr.vag_id = opr_crg.vag_id and -- ВТОРОЙ ВАРИАНТ УСЛОВИЯ -
oprvag с opr, а opr с opr_crg
opr_crg.opt_id = 10 and
opr_crg.crg_id=crg.id and
crg.car11_code_carg in (32423, 31405) and
oprvag.last_opr_id=opr.id and
opr.loc_id = loc.id and
loc.rw_frt_id =7

Планы для первого и второго вариантов связывания:
----------------------------------------------------------------------------
--------------------------------
SELECT STATEMENT, GOAL = CHOOSE 279789418 1 13
SORT GROUP BY 1 13
VIEW SYS 279789418 1 13
FILTER
SORT GROUP BY 279789418 1 97
NESTED LOOPS 279789396 1899 184203
NESTED LOOPS 279712792 76604 6358132
NESTED LOOPS 267877635 11835157 792955519
NESTED LOOPS 89223 66947103 3414302253
NESTED LOOPS 2353 146 5110
NESTED LOOPS 1794 559 17329
TABLE ACCESS FULL WAREHOUSE VAGONRUN 86 427 5124
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATIONS 4 1 19
INDEX RANGE SCAN WAREHOUSE OPR_VAG_FK_I 2 7
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATION_TYPES 1 1 4
INDEX UNIQUE SCAN WAREHOUSE OPT_PK 8
TABLE ACCESS FULL WAREHOUSE OPERATIONS 595 459653 7354448
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATIONS 4 1 16
INDEX RANGE SCAN WAREHOUSE OPR_VAG_FK_I 2 7
TABLE ACCESS BY INDEX ROWID WAREHOUSE CARGOES 1 1 16
INDEX UNIQUE SCAN WAREHOUSE CAR_PK 155
TABLE ACCESS BY INDEX ROWID WAREHOUSE LOCATIONS 1 1 14
INDEX UNIQUE SCAN WAREHOUSE LOC_PK 41

----------------------------------------------------------------------------
--------------------------------
SELECT STATEMENT, GOAL = CHOOSE 3155 1 65
SORT GROUP BY 1 65
NESTED LOOPS 3155 1 65
NESTED LOOPS 3154 1 58
NESTED LOOPS 3143 11 539
NESTED LOOPS 2647 124 4960
VIEW WAREHOUSE 2355 146 3796
SORT GROUP BY 2355 146 5110
NESTED LOOPS 2353 146 5110
NESTED LOOPS 1794 559 17329
TABLE ACCESS FULL WAREHOUSE VAGONRUN 86 427 5124
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATIONS 4 1 19
INDEX RANGE SCAN WAREHOUSE OPR_VAG_FK_I 2 7
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATION_TYPES 1 1 4
INDEX UNIQUE SCAN WAREHOUSE OPT_PK 8
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATIONS 2 1 14
INDEX UNIQUE SCAN WAREHOUSE OPR_PK 1 1
TABLE ACCESS BY INDEX ROWID WAREHOUSE OPERATIONS 4 1 9
INDEX RANGE SCAN WAREHOUSE OPR_VAG_FK_I 2 7
TABLE ACCESS BY INDEX ROWID WAREHOUSE CARGOES 1 1 9
INDEX UNIQUE SCAN WAREHOUSE CAR_PK 155
TABLE ACCESS BY INDEX ROWID WAREHOUSE LOCATIONS 1 1 7
INDEX UNIQUE SCAN WAREHOUSE LOC_PK 41
----------------------------------------------------------------------------
--------------------------------

--
Tolik.
!!! FOR REPLY remove first letter from my e-mail
---------------------------------


Tolik K.

unread,
Jan 4, 2004, 3:54:35 PM1/4/04
to
Вдогонку: цифры в плане - по порядку: cost, cardinality, bytes ;)

Tolik K.

unread,
Jan 4, 2004, 4:00:19 PM1/4/04
to
Еще раз вдогонку: Оракул 9.2.0.1 Enterprise.

Tolik K.

unread,
Jan 8, 2004, 10:35:49 AM1/8/04
to
Сорри, разобрался. :)
Просто хинт надо было по-другому поставить: /*+ ordered USE_NL(oprvag
opr_crg crg) USE_NL(oprvag opr loc) */ . Так уж точно оптимизатору понятно,
что с чем надо связывать.
А кстати 8й оракул этот запрос (первый вариант) выполняет и с тем хинтом
быстро и, я так понимаю, выполняет сначала подзапрос, а потом к нему цепляет
по очереди две таблицы.
А вот 9-ка делает что-то мне непонятное. Если кто-то объяснит мне первый
приведенный мной план запроса - буду очень-очень признателен.

--
Tolik.
!!! FOR REPLY remove first letter from my e-mail
---------------------------------

"Tolik K." <wk...@port.odessa.ua> wrote in message
news:bt9til$a45$1...@toster.Te.NeT.UA...

0 new messages