|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
Вот этот запрос взял из сессии которая нагружает БД. Выполняю его в Девелопере в тестовом окне (просто прописываю значения для переменных bind) - исполняется быстро. План смотрю - используются индексы везде. Но с теме же самыми параметрами в Апексе 4.1.0.00.32 - он весит и не фига не исполняется, может так весь день! и в гриде виден в топе вот только этот запрос, что он нагружает БД. Дело явно не в запросе, так в чем может быть дело? Пысы: если в этом запросе в trunc(wd.trading_day) between to_date(:P750_BEGIN_DATE, 'DD.MM.YYYY') - заменить :P750_BEGIN_DATE на просто текст '04.07.2012' - то и в апексе запрос начинает работать быстро! Пните плиз куда копать... Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2012, 13:45 |
|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
Результаты сравнивали? Планы сравнивали? EDUARD_2Дело явно не в запросе, так в чем может быть дело? Обычно при таких симптомах дело как раз в запросах. Например, параметры сессии разные, формат даты по-умолчанию и т.д. EDUARD_2Пысы: если в этом запросе в trunc(wd.trading_day) between to_date(:P750_BEGIN_DATE, 'DD.MM.YYYY') - заменить :P750_BEGIN_DATE на просто текст '04.07.2012' - то и в апексе запрос начинает работать быстро! От trunc в левой части попробуйте избавиться (если на trading_day есть индекс). В Shared Components/Edit Globalization Attributes пропишите DD.MM.YYYY. Ну и наконец :P750_BEGIN_DATE и '04.07.2012' совершенно разные вещи в плане влияния на план. Тут вполне может не быть никакой связи с описанной выше проблемой, а именно разные планы/результаты выполнения в разных средах. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.07.2012, 16:27 |
|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
SvDevРезультаты сравнивали? Планы сравнивали? EDUARD_2Дело явно не в запросе, так в чем может быть дело? Обычно при таких симптомах дело как раз в запросах. Например, параметры сессии разные, формат даты по-умолчанию и т.д. EDUARD_2Пысы: если в этом запросе в trunc(wd.trading_day) between to_date(:P750_BEGIN_DATE, 'DD.MM.YYYY') - заменить :P750_BEGIN_DATE на просто текст '04.07.2012' - то и в апексе запрос начинает работать быстро! От trunc в левой части попробуйте избавиться (если на trading_day есть индекс). В Shared Components/Edit Globalization Attributes пропишите DD.MM.YYYY. Ну и наконец :P750_BEGIN_DATE и '04.07.2012' совершенно разные вещи в плане влияния на план. Тут вполне может не быть никакой связи с описанной выше проблемой, а именно разные планы/результаты выполнения в разных средах. > Результаты сравнивали? Планы сравнивали? запрос взят не с репорта, а из сессии, когда исполняется этот репорт, взял скопировал его в тестовое окно и исполнил с такими же параметрами. > Например, параметры сессии разные, формат даты по-умолчанию и т.д. а апексе Application Date Format = DD.MM.YYYY > От trunc в левой части попробуйте избавиться (если на trading_day есть индекс). на trading_day не может быть индекса, потому что смысла в этом нету. есть индекс на trunc(trading_day) > Ну и наконец :P750_BEGIN_DATE и '04.07.2012' совершенно разные вещи в плане влияния на план. ну это да! это я так к слову- просто решил проверить... планы сравню. пысы просто этот отчет работал быстро, никто ничего не менял, и бац он стал висеть весь день. и таких случаев с другими отчетами уже несколько. не понимаю, почему так о_О ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2012, 07:26 |
|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
автор> От trunc в левой части попробуйте избавиться (если на trading_day есть индекс). на trading_day не может быть индекса, потому что смысла в этом нету. есть индекс на trunc(trading_day) сорри, индекс есть, ктото создал. убрал trunc - в апексе начал быстро работать. в общем щас 2 индекса на trading_day - с trunc и без. но считаю что индекс должен быть с trunc - я прав? ладно тут повезло хранится дата без времени. может дело в том что было 2 индекса? хотя по плану исполнения сессии апекса и в девелопере использовался индекс именно с trunc(trading_day). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2012, 08:07 |
|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
[quot EDUARD_2]авторубрал trunc - в апексе начал быстро работать. убрал trunc в запросе! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2012, 08:08 |
|
Тормозит репорт в апексе, а в pl\sql Developer все отлично.
|
|||
---|---|---|---|
#18+
EDUARD_2убрал trunc в запросе! Это к вопросу о тормозах, к разному поведению в разных средах не имеет отношения. Тут нужна элементарная отладка/сравнивать трассировки и т.д., причиной может оказаться, например, сравнение числа и строки с неявным преобразованием, непечатуемые символы в items, которые вы визуально не увидите и не скопируете, политики vpd, включенные опции типа sort, sum могут вести к дописыванию запроса и тоже влиять на план и т.д. - это к косякам программиста, + максимум с чем я сталкивался, это с проблемами с комментариями вида --, которые откусывали не только 1 строку, но и последующие. Если хотите что-то кроме общих советов, воспроизведите на apex.oracle.com ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2012, 13:39 |
|
|
start [/forum/topic.php?fid=50&gotonew=1&tid=1876074]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
73ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 169ms |
0 / 0 |