Время работы кода SQL в хр.процедуре и в Advantage отличаются на порядок (ASE 12.5).
Почему это возможно, что может влиять на это?
В хранимой процедуре на сервере ASE 12.5 создается курсор, открывается и затем обрабатываются результаты. Время выполнения (создание курсора и открытие) составляет порядка 9 сек (запускаю процедуру в Advantage). При выполнении тех же действий в Advantage время выполнения составляет порядка 1 сек. Из-за чего может быть такая разница?

Вот код:
Declare cur_my cursor for
select c.division,tn
from zt_register_charges c
where period>=@rp_p and period<=@rp and uperiod=@rp_p and c.enterprise_id = @eid
and c.division in (select div_id from #div)

open cur_my

Пытался вложенный select заменить на inner join - разницы никакой.

morisВыполните SP с опцией with recompile
Спасибо, проверил - не влияет на время.

Rubberselect c.division,tn
from zt_register_charges c
where period>=@rp_p and period<=@rp and uperiod=@rp_p and c.enterprise_id = @eid
and c.division in (select div_id from #div)

какой query plan показывает адантаж?

FROM TABLE
zt_register_charges
c
Nested iteration.
Index : ztui_register_charges_tnrpup
Forward scan.
Positioning by key.
Keys are:
enterprise_id ASC
period ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
#div
EXISTS TABLE : nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.


STEP 2
The type of query is SELECT.


FROM TABLE
Worktable1.
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.


Server Message: Number 3630, Severity 10
Server 'storm_ds', Line 1:
Total estimated I/O cost for statement 1 (at line 1): 176.


Parse and Compile Time 1.
SQL Server cpu time: 100 ms.
Table: zt_register_charges scan count 1, logical reads: (regular=2660 apf=0 total=2660), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #div_________00000260009805944 scan count 24975, logical reads: (regular=24975 apf=0 total=24975), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: Worktable1 scan count 1, logical reads: (regular=111 apf=0 total=111), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Server Message: Number 3631, Severity 10
Server 'storm_ds', Line 1:
Total actual I/O cost for this command: 55492.
Total writes for this command: 0

Execution Time 1.
SQL Server cpu time: 100 ms. SQL Server elapsed time: 153 ms.
(50 rows affected)

Rubberпопробуй перекомпилить процу с хинтом

select c.division,tn
from zt_register_charges c (index ztui_register_charges_tnrpup)
where period>=@rp_p and period<=@rp and uperiod=@rp_p and c.enterprise_id = @eid
and c.division in (select div_id from #div)

Спасибо, меньше секунды!

Вопрос - насколько часто Вы используете принудительное указание индексов в запросах?
Мне говорили, что это не рекомендуется, так как при изменении кол-ва данных выполнение запросов может резко замедлиться?
А если изменится индексное выражение, добавят в начало новое поле?
Или требовать чтобы индексы не меняли, а создавали новый с теми же полями и + новым полем?

MasterZiv
Eugeny_M пишет:
> Время работы кода SQL в хр.процедуре и в Advantage отличаются на порядок
> (ASE 12.5).

Код давайте, будут советы конкретные.

> Почему это возможно, что может влиять на это?

Запросы в процедурах и вне процедур оптимизируются немного по-разному.
Связано это с тем, что оптимизатор не знает значений переменных, которые
выступают в качестве параметров запросов в процедурах и не
применяет вычисление селективности для этого конкретного значения.


Posted via ActualForum NNTP Server 1.4

Код я дал. Какие можете дать советы, как новичку. Как заставить применять вычисление селективности в хр? И нужно ли всегда задавать индексы жестко в хр.процедуре в тексте запроса?

Rubberпоэтому и говорю - "это не панацея".
Изменение количества данных может замедлить время отработки, для таких вариантов есть разные 'лекарства' от UPDATE STATISTICS до REORG (если схема блокировки не ALL PAGES) и т.п.
[имхо: чтоб база продуктивно работала за ней нужно постоянно "следить" - периодически выполнять профилактику].
А что касается изменения структуры (не важно таблиц или индексов) - так извините, в таком случае - с процедур нужно тоже "смахивать пыль" :)

Спасибо! Почитаю про UPDATE STATISTICS и REORG.

MasterZiv
Eugeny_M пишет:

> Код я дал.

Это не код. Это один запрос. Там ничего не видно.

Весь код занимает около 4 страниц. Меня интересовал тот код, который тормозил.


Как заставить
> применять вычисление селективности в хр?

Использовать в качестве параметров запросов параметры
процедуры. Но это не всегда надо, и не всегда помогает.

Т.е если в том примере я не использовал бы переменные @rp_p, @eid
а только параметры процедуры (т.е вычислял бы их раньше и передавал
в процедуру, в качестве параметров), то запрос был бы оптимизирован
и выполнился быстро (с подключением индекса)?


И нужно ли всегда задавать
> индексы жестко в хр.процедуре в тексте запроса?

Нет, не всегда, а когда только план генерируется плохой.
Как в вашем случае. И нельзя вынести переменные в параметры
процедуры или это не помогает.
Posted via ActualForum NNTP Server 1.4

Как определить в большой хр. процедуре, где 200 строк + вызов еще десятка других
хранимых процедур, для каких конструкций в хр. процедуре план генерируется плохой,
а для каких хороший?

Rubberпочитайте :)
а в указанном запросе производительность будет снижаться при увеличении количества записей в таблице #div, так что если такое предусматривается - именно в этой части надо менять запрос уже сейчас...
удачи !

В таблице #div не больше 100 записей. А при выполнении подзапроса выбирается не больше 10.
create table #div(
div_id int not null,
...
wrk tinyint default 0 not null,
unique clustered (div_id))

Вы имеете ввиду такой вариант:
select c.division,tn
from zt_register_charges c (index ztui_register_charges_tnrpup), #div
where period>=@rp_p and period<=@rp and uperiod=@rp_p and c.enterprise_id = @eid
and c.division=#div.div_id and #div.wrk<2

MasterZiv
Eugeny_M пишет:
> Весь код занимает около 4 страниц. Меня интересовал тот код, который
> тормозил.

Ну и давай . 8 килобайт-то всего. Ну или выкинь все после этого
запроса.
Posted via ActualForum NNTP Server 1.4

Я ошибся, не 4 страницы, там 54 кб - более 1200 строк. Выкладывать всё, зачем?
Не хочу захламлять ветку и сервер.
Или вы хотите стиль написания запросов посмотреть?
Код писал не я! Что он делает без поллитра не разберешься :)

Rubber> Вы имеете ввиду такой вариант:
> select c.division,tn
> from zt_register_charges c (index ztui_register_charges_tnrpup), #div
> where period>=@rp_p and period<=@rp and uperiod=@rp_p and c.enterprise_id = @eid
> and c.division=#div.div_id and #div.wrk<2

не обязательно такой, это зависит от прогнозируемого в будущем кол-ва записей в #div.
если, к примеру, оно перевалит за пару десятков тысяч, то уже сейчас можно это предусмотреть.

Я думаю, максимум, что может произойти за несколько лет, так это удвоение кол-ва записей в таблице #div. Ну а если бы там было 20000 записей, а не 200, то что нужно предусмотреть?

Как заставить
> применять вычисление селективности в хр?

Использовать в качестве параметров запросов параметры
процедуры. Но это не всегда надо, и не всегда помогает.

Т.е. если в том примере я не использовал бы переменные @rp_p, @eid
а только параметры процедуры (т.е вычислял бы их раньше и передавал
в процедуру, в качестве параметров), то запрос был бы оптимизирован
и выполнился быстро (с подключением индекса)?


И нужно ли всегда задавать
> индексы жестко в хр.процедуре в тексте запроса?

Нет, не всегда, а когда только план генерируется плохой.
Как в вашем случае. И нельзя вынести переменные в параметры
процедуры или это не помогает.
Posted via ActualForum NNTP Server 1.4

Как определить в большой хр. процедуре, где 1200 строк + вызов еще десятка других
хранимых процедур, для каких конструкций в хр. процедуре план генерируется плохой,
а для каких хороший?

Rubber, я понял.

MasterZiv
Eugeny_M пишет:
> Как определить в большой хр. процедуре, где 1200 строк + вызов еще
> десятка других
> хранимых процедур, для каких конструкций в хр. процедуре план
> генерируется плохой,
> а для каких хороший?

Процедура работает медленно. Делаешь SET SHOWPLAN ON и
выполняешь ее. Смотришь планы. Ищешь плохие. находишь запросы,
исправляешь.
Posted via ActualForum NNTP Server 1.4

Я такой вариант пробовал :( Там такой листинг после выполнения процедуры ...
что просто просмотреть его, это нужно железное терпение. А тому, кто разберется,
вообще орден давать!

rcryoОдна из возможных причин почему оптимизатор не хочет выбирать оптимальный план в хранимой процедуре в вашем селекте без хинта - это несоответствие типов параметров запроса и типов соответствующих полей в таблице. Например integer и smallint. Пожалуйста проверьте типы переменных @rp, @rp_p, @eid. В частности поэтому народ хотел видеть весь код ХП. Cчитаю что жестко прописывать индексы в запросах неправильно. Оптимизатор в ASE не такой уж и тупой

Все переменны типа int. Правда в таблице поля описаны как zd_period (User Defined Datatypes), что соответствует int. Из-за того, что поле в таблице описано типа zd_period, а переменная объявлена типа zd_rp, но оба типа ссылаются на int, оптимизатор не выбирает оптимальный план?

MasterZiv
Eugeny_M пишет:
> Как определить в большой хр. процедуре, где 1200 строк + вызов еще
> десятка других
> хранимых процедур, для каких конструкций в хр. процедуре план
> генерируется плохой,
> а для каких хороший?

Процедура работает медленно. Делаешь SET SHOWPLAN ON и
выполняешь ее. Смотришь планы. Ищешь плохие. находишь запросы,
исправляешь.
Posted via ActualForum NNTP Server 1.4

Без SET SHOWPLAN ON процедура работает 1 сек.
Ради интереса запустил эту хр.процедуру с SET SHOWPLAN ON.
Метелило 1 час ! Листинг занимает 17 Мб !

Ну всё! Всем огромное спасибо!