Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

В какую сторону можно оптимизировать запрос?

Страницы: < 1 2 3
k2 © (2004-12-29 14:41:00)
И вообще што неправильно(запрос рабочий, выдает правильные данные, но это первый запрос, с ораклом только начала работать, хотелось бы знать на што в первую очередь внимание обратить)

SELECT
CASE WHEN objs_name IS NULL AND GROUPING (cnt_class_modif) = 0 THEN 'Итого : ' ELSE inn END inn,
CASE WHEN GROUPING (cnt_class_modif) = 1 THEN 'Итого к строке баланса :' ELSE objs_name END objs_name,
SUM (sum_deb_zdl),
SUM (sum_deb_zdl_pr),
cnt_class_modif
FROM (SELECT cnt01.inn inn, objs_name,
NVL (sum_deb_val, 0) - NVL (sum_cred_val, 0) sum_deb_zdl,
NVL (sum_deb_val_pr, 0) - NVL (sum_cred_val_pr, 0) sum_deb_zdl_pr,
CASE
WHEN NVL (sum_deb_val, 0) - NVL (sum_cred_val, 0) < 1000 THEN 891 -- 891
WHEN NOT(cnt03cnt10.cnt10_id = 882 OR cnt03cnt10.cnt10_id = 883) THEN 890 -- 890
WHEN cnt03cnt10.cnt10_id IS NULL THEN 890 -- 890
ELSE cnt03cnt10.cnt10_id
END cnt_class_modif
FROM (SELECT val_set.objs_pk, val_set.objs_name,
val_set.objs_code,
SUM (CASE WHEN pr_type = 'deb' THEN val_int ELSE 0 END) sum_deb_val,
SUM (CASE WHEN pr_type = 'cr' THEN val_int ELSE 0 END) sum_cred_val,
SUM (CASE WHEN pr_type = 'deb' AND TRUNC (contr_posting_date) <= ADD_MONTHS (:end_date, -3) THEN val_int ELSE 0 END) sum_deb_val_pr,
SUM (CASE WHEN pr_type = 'cr' AND TRUNC (contr_posting_date) <= ADD_MONTHS (:end_date, -3) THEN val_int ELSE 0 END) sum_cred_val_pr,
MIN (contr_posting_date) min_posting_date
FROM (SELECT contr.val_int val_int, 'deb' pr_type,
contr.posting_date contr_posting_date,
objs.pk objs_pk, objs.NAME objs_name,
objs.code objs_code
FROM gl_contrecs contr,
gl_accounts acc,
gl_anlprops props,
gl_anlobjs objs
WHERE acc.pk = contr.acc_db_pk
AND acc.acpl_code = :acpl_code
AND acc.code LIKE :acc_code
AND contr.posted = :posted
AND contr.bu_code = :bu_code
AND props.crec_db_pk = contr.pk
AND objs.pk = props.anob_pk
AND objs.anca_code = :anca_code
AND TRUNC (contr.posting_date) <= :end_date
UNION ALL
SELECT contr.val_int val_int, 'cr' pr_type,
contr.posting_date contr_posting_date,
objs.pk objs_pk, objs.NAME objs_name,
objs.code objs_code
FROM gl_contrecs contr,
gl_accounts acc,
gl_anlprops props,
gl_anlobjs objs
WHERE acc.pk = contr.acc_cd_pk
AND acc.acpl_code = :acpl_code
AND acc.code LIKE :acc_code
AND contr.posted = :posted
AND contr.bu_code = :bu_code
AND props.crec_cd_pk = contr.pk
AND objs.pk = props.anob_pk
AND objs.anca_code = :anca_code
AND TRUNC (contr.posting_date) <= :end_date) val_set
GROUP BY objs_pk, objs_name, objs_code),
cnt_01_hoz_subjects cnt01,
cnt_cnt03_cnt10 cnt03cnt10,
cnt_03_contragents cnt03,
cnt_10_classes cnt10
WHERE NVL (sum_deb_val, 0) - NVL (sum_cred_val, 0) > 0
AND objs_code = cnt01.ID(+)
AND cnt03cnt10.cnt02_cnt01_id(+) = :balunit
AND cnt03cnt10.cnt01_id(+) = objs_code
AND cnt03.cnt01_id(+) = cnt01.ID
AND cnt03.cnt02_cnt01_id(+) = :balunit
AND cnt10.ID(+) = cnt03cnt10.cnt10_id)
GROUP BY
GROUPING SETS ((inn, objs_name, cnt_class_modif), ROLLUP (cnt_class_modif))
ORDER BY
cnt_class_modif, objs_name

Наталия (2004-12-29 15:22:00) [41]
А если серьезно, то, конечно, нужно смотреть планы, индексы, статистику, возможно, хинты подключать, хотя...
Опять посмотрела на твой запрос... :)))

Наталия (2004-12-29 15:21:00) [42]
Катя, привет!
Как я тебя зауважала! :)))
Такой ЗАПРОСИЩЕ!
У меня какой-то комлекс неполноценности начал вырабатываться - пойду поищу у себя самый большой запрос...

msguns (2004-12-29 15:18:00) [43]
>k2 © (29.12.04 14:41)
>И вообще што неправильно(запрос рабочий, выдает правильные данные, но это первый запрос, с ораклом только начала работать

НУ НИ ФИГА Ж СЕБЕ !!! И это ПЕРВЫЙ запрос !?!? И ТОЛЬКО НАЧАЛА ???!!!

Что же будет во втором ? А в 22-м ???
Все, ухожу в монастырь. Но сначала в пивную ;((((((

Sergey13 (2004-12-29 15:04:00) [44]
2[6] k2 © (29.12.04 14:59)
В догонку. А статистика собирается регулярно?

Sergey13 (2004-12-29 15:03:00) [45]
2[6] k2 © (29.12.04 14:59)
план безобразный :( два фулскана на самом нижнем уровне вложения :((
Если таблицы небольшие - тоже ничего страшного.

>cost вообще не скажу сколько штобы не пугать :)
Это то как раз ничего не значит - это аналог "а в попугаях то я гораздо длиннее". Он показателен только внутри всего вопроса, т.е. показывает относительныйвес, по сравнению с другими частями.

k2 (2004-12-29 14:59:00) [46]
план безобразный :( два фулскана на самом нижнем уровне вложения :(( cost вообще не скажу сколько штобы не пугать :)

Sergey13 (2004-12-29 14:53:00) [47]
2 k2 © (29.12.04 14:41)
А что конкретно не нравится то тебе? Если работает и правильно при том - уже хорошо.
Настораживает обилие CASE, NVL и (+), но ведь не зная таблиц - чего скажешь то?
Смотри план выполнения - все фул сканы на больших таблицах - повод для оптимизации.

Соловьев (2004-12-29 14:50:00) [48]
та нет, просто разобраться сложно. Надо долго сидеть и высматривать. С ораклом не знаком, потому конструции вида - select * from (select * from ) может и оправданы. но запутывают ужасно

Johnmen (2004-12-29 14:49:00) [49]
>k2 ©

Да. Это тяжело для понимания...
Я бы попробовал избавиться от вложенных запросов, левых/правых соединений...
И возможно будет понятней и быстрей, если раздробить на несколько мелких запросов с обработкой на клиенте, или эти мелкие запросы использовать в хранимой процедуре.

k2 (2004-12-29 14:48:00) [50]
to Соловьев © (29.12.04 14:44) [1]

Все настолько запущенно? :(((

Соловьев (2004-12-29 14:44:00) [51]
пипец.. я бы засстрелился :)

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »