Долго делается отчет по реализации товаров : Oracle

Есть в супермаге отчет:
"Отчет по реализации товаров"
торговый отдел начал жаловаться что долго делает
и действительно чуть ли не 30 мин
висит на запросе:

SQL Statement from editor:

select s.grouptree, crd.name, crd.article,s.qty, 0 sumorder,s.sumspec,s.sumspecnotax from supermag.smcard crd, (select '' grouptree,s.article,round(sum(decode(d.doctype,'CR',-1,'WI',-1,1)*s.quantity), 3) qty, round(sum(decode(d.doctype,'CR',-1,'WI',-1,1)*s.totalprice), 2) sumspec,round(sum(decode(d.doctype,'CR',-1,'WI',-1,1)*nvl(s.totalpricenotax,0)), 2) sumspecnotax from supermag.smdocuments d, supermag.smspec s where d.createdat between to_date('17.06.2009','DD.MM.YYYY') and to_date('01.07.2009','DD.MM.YYYY') and nvl(d.LocationFrom,d.LocationTo)=30 and d.docstate>=3 and d.opcode in (1, 3) and d.doctype in ('WO','WI','CS','CR') and d.id=s.docid and d.doctype=s.doctype and s.article in (select article from supermag.ttidgroup) group by '',s.article) s where crd.article = s.article ORDER BY 1 ASC,5 ASC,2 ASC
------------------------------------------------------------

Statement Id=0 Type=SELECT STATEMENT
Cost=285 TimeStamp=01-07-09::21::24:07

(1) SELECT STATEMENT ALL_ROWS
Est. Rows: 1 Cost: 285
(14) SORT ORDER BY
Est. Rows: 1 Cost: 285
(13) HASH GROUP BY
Est. Rows: 1 Cost: 285
(12) NESTED LOOPS
Est. Rows: 1 Cost: 283
(9) NESTED LOOPS
Est. Rows: 1 Cost: 281
(5) MERGE JOIN CARTESIAN
Est. Rows: 1 Cost: 272
(2) INDEX (UNIQUE) INDEX FULL SCAN SUPERMAG.TTCIDGROUP_PK [Analyzed]
Est. Rows: 1
(4) BUFFER SORT
Est. Rows: 49814 Cost: 272
(3) TABLE TABLE ACCESS FULL SUPERMAG.SMCARD [Analyzed]
(3) Blocks: 1132 Est. Rows: 49814 of 49814 Cost: 272
Tablespace: USERS
(8) PARTITION LIST INLIST
Est. Rows: 1 Cost: 9
(7) TABLE TABLE ACCESS BY LOCAL INDEX ROWID SUPERMAG.SMSPEC [Analyzed]
Blocks: 544050 Est. Rows: 1 of 62592575 Cost: 9
(6) INDEX INDEX RANGE SCAN SUPERMAG.SMSPEC_ARTB [Analyzed]
Est. Rows: 1 Cost: 8
(11) TABLE TABLE ACCESS BY GLOBAL INDEX ROWID SUPERMAG.SMDOCUMENTS [Analyzed]
Blocks: 21710 Est. Rows: 1 of 1799452 Cost: 2
(10) INDEX (UNIQUE) INDEX UNIQUE SCAN SUPERMAG.SMCDOCUMENTS_PK [Analyzed]
Est. Rows: 1 Cost: 1


В принципе запрос то простенький, а что ему надо понять не могу

В отчете выбирал:
промежуток: 15 дней
место хранения: магазин №1
только дни продаж
виды продаж: все
сорт: по наименованиям
группа: ассортимент №ХХХ

Если выставить optimizer_index_cost_adj=1
то отчет делается в секунды
У меня стоит 100

посоветуйте где копать

собсно, по этому плану мало что можно сказать, поскольку темповая табличка в нем, план пополз, надо искать причину... Над этим и предлагаю подумать.

Так при выставленном "optimizer_index_cost_adj=1" тот же самый план получается? или всё же нет?

Планы разные
Прикол не в этом.
Я решил сегодня все таки посмотреть на чем он подвисает, т.к. при пустой временной висяка нету. Убил табличку ttidgroup, создал ее но как постоянную. И отчет сделался за секунды. Затем я снова ее убил, опять создал как была (временной). Все работает, считает отчет в секунды.
Если совсем честно, то я не понял в чем причина :(
Я предполагаю что был кривой индекс :)
хотя проверка на валидность ничего не показала :(
пересоздание супермагом тоже ничего не дало :(, только ручками
Вообщем проблемма решена, всем спасибо

А что за параметр optimizer_index_cost_adj=1? Просто у нас в системе электронного документооборота "ДЕЛО" (если кто трогал) после очередного обновления версии стала довольно сильно тормозить работа с программой на клиентских станциях. После сбора статистик и параметров БД и отсыла их в службу техподдержки от них в конце концов пришел скрипт, меняющий старые значения параметров:

SQL> select command, sqltext from sqlcommands
2 where command like '%connect';
connect
alter session set optimizer_index_cost_adj = 25
eapi_connect
alter session set optimizer_index_cost_adj = 25

на optimizer_index_cost_adj=1. И все снова стало летать. А на что влияет изменение этого параметра?

Лучше бы завел новую тему.
Параметр влияет на то, как оптимизатор будет строить план запроса. Стоимость использования индекса.
Огорчу тебя, но =1, это временное и неправильное решение. Это я посоветовал Mr_Vito попробовать его выставить. Для пробы - подходит. Для постоянной работы - редко.