Зависание при выполнении скрипта.

[LOBsterr]

Зависание при выполнении скрипта.

Здраствуйте, господа, кто сможет дайте совет, мне нужно вытаскивать из базы статистику, и потом выводить в Excel, но до Excel у меня даже не доходит дело, потому что скрипт мой вешает не только браузер, но и всю систему. Выбора за неделю и за декаду нормально работает, за месяц уже выполнятся не хочет, а мне в будущем надо будет и за 12 месяцев считать. В Toad этот запрос выполняется от 20-30 сек зависит от количества месяцев. Запрос не сложный но подсчитывается сумма большого количества полей. Оптимизировать, у меня у самого не получилось. Если есть хоть какой нибудь совет, помогите

select trunc(sys_date,'MM'), sys_f_CODE, sys_r_CODE, sum(sys_cost)
from tb_services
where trunc(sys_date,'MM') >= trunc(add_months(sysdate,-5),'MM') and sys_date < trunc(sysdate)
and sys_f_code like 'TTT
and sys_r_CODE like 'SSS'
group by trunc(sys_date,'MM'), sys_f_CODE, sys_r_CODE

 

[chira]

сделай суммарную таблицу по месяцам и считай когда месяц заканчивается, тогда будет всё летать ....
ещё можешь сделать материзованный VIEW по месяцам и разрешить QUERY REWRITE, тогда будет всё прозрачно для скрипта.

 

[fisher]

>>материзованный
материализованный

>>where trunc(sys_date,'MM') >= trunc(add_months(sysdate,-5),'MM') and sys_date < trunc(sysdate)
это необходимо преобразовать к виду, чтоб использовался индекс по sysdate. пусть в предикате будет не функция sysdate!

>>and sys_f_code like 'TTT
>>and sys_r_CODE like 'SSS'
зачем like???? это же равенство если я ничего не путаю. и зачем тогда группировать по этим полям если они чётко заданы?

>>group by trunc(sys_date,'MM'), sys_f_CODE, sys_r_CODE

группировка по вычисляемому полю. либо funcion based index либо предлагаю просто сделать денорм-поле "месяц". далее избавиться от like, и индекс на denorm_month, sys_f_CODE, sys_r_CODE (но вообще есть ньюансы - если отчеты нужне редко а вставка в эту таблицу частая, то надо делать отдельную таблицу с индексами для отчетов, чтоб вставки на таких жирных индексах не тормозили).
будет летать.

 

[LOBsterr]

Да было предположение делать отдельной таблицой куда раз в день будут скидывать суммарнные данные, и выборку уже делать из нее. Почему Like потому что иногда используется %, а намного ли будет быстрей выполняться запрос если будет использоваться не LIKE 'TTT', а ='TTT' ? я что то не заметил ... чтобы скорость уменьшилась.

 

[fisher]

>>Почему Like потому что иногда используется %
вот когда используется - тогда и делайте LIKE и group by, а когда не используется - делайте = и не используйте этого в group by. насчет постоянного вырезания месяца из даты - сделайте денорм-поле, либо в этой таблице, либо в таблице отчетов - неважно, часть проблем у вас из-за того что у вас потоянно идут выборки-группировки по динамически вычисляемым полям.