|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
ASE 15.7 SP101 Есть простой курсор: ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2013, 16:33 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
ASE 15.7 SP101 Есть простой курсор: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
все хорошо! только почему-то падает производительность. каждая следующая итерация замедляется. где-то после 1000 обработанных строк, совсем "опанька". сама процедура x_proc отрабатывает мгновенно. и поданный в нее параметр не влияет на производительность. в errorlog появилось вот это авторIncrease the config parameter 'number of open objects' to avoid descriptor reuse. Reuse may result in performance degradation. увеличил в четверо, по данным sp_monitorconfig стало достаточно. но на производительность это не повлияло, так же постепенно падает. что делаю не так? чтоб как-то ускорить процесс, запускаю скрипт параллельно(в двух коннектах), разбивая месяц на 2 части and date_field >= '20130701' and date_field < '20130715' и and date_field >= '20130715' and date_field < '20130801' но после того как отработал первый процесс, все равно он ждет когда работу закончит второй. как будто второй что-то блокирует для первого. но mon_Locks показывает только shared intent по таблице x_table. чего тогда ждет первый процесс? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2013, 17:00 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
cherrex_Den, Я не знаток ASE но могу предположит, дело в distinct и ошибочно само ожидание постоянного времени выполнения. С продвижением по списку ДБМС просмотривает много строк но не находит новых значений. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2013, 18:52 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
cherrex_Den, авторв errorlog появилось вот это автор Increase the config parameter 'number of open objects' to avoid descriptor reuse. Reuse may result in performance degradation. увеличил в четверо, по данным sp_monitorconfig стало достаточно. но на производительность это не повлияло, так же постепенно падает. Это тут точно ни при чём, у тебя нет тут роста кол-ва используемых объектов по мере выполнения скрипта. Просто совпало. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:43 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
Надо смотреть внутрь процедуры x_proc, и ещё я бы убрал PRINT-ы, хотя бы для того, что бы убедится, что они не тормозят. А они могут. И в таком случае виноват будет не сервер, а клиент, он тормозит. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:45 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
cherrex_Denчтоб как-то ускорить процесс, запускаю скрипт параллельно(в двух коннектах), разбивая месяц на 2 части and date_field >= '20130701' and date_field < '20130715' и and date_field >= '20130715' and date_field < '20130801' но после того как отработал первый процесс, все равно он ждет когда работу закончит второй. как будто второй что-то блокирует для первого. но mon_Locks показывает только shared intent по таблице x_table. чего тогда ждет первый процесс? Не должен он ничего ждать. Если конечно в процедуре нет какой-то ждущей логики. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2013, 18:47 |
|
Курсоры в ASE
|
|||
---|---|---|---|
#18+
а процедура x_proc не инсёртит или апдейтит в x_table? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2013, 13:15 |
|
|
start [/forum/topic.php?fid=55&msg=38389721&tid=2009940]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 258ms |
0 / 0 |