|
|
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
есть запрос: Код: plsql 1. 2. 3. 4. 1.большое количество parse - 1420 для запроса, правда при этом cpu и elapsed на парс чрезвычайно малы. 2. большое значение execute для запроса, 390334 раз... возможно главное и не увидел (подозреваю, что так и есть) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. как это можно оптимизировать? снизить количестве executions? меня смущают: OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS Код: plsql 1. в трейсе запросов +100500, но Код: plsql 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. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2016, 14:03:28 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
Мне в который раз интересно, ты увлекся конкретным запросом, но при этом непрерывно вываливаешь "OVERALL TOTALS FOR ALL % STATEMENTS". Наверное ты что-то этим показать хочешь? Ну так хоть намекни... Или ты не понимаешь разницу между RECURSIVE и NON-RECURSIVE STATEMENTS ? Хинт: есть SQL-операторы (включая BEGIN-END), посланные с клиента, а есть вызванные изнутри этих операторов Что касается конкретного запроса -- конечно, лучше уменьшить количество его выполнений, если есть возможность. Парсов относительно выполнений совсем чуть, так что здесь все нормально. Но каждый вызов этого запроса приведет к EXECUTE и FETCH Да и вообще -- ты не указываешь временной промежуток, о чем тут можно судить? Если трейс снят за сутки -- то тут даже смотреть не на что, а если за те же 7 мин, то, собственно, а что ему еще делать, как не работать? Например, среднее обращение к диску занимает 0.007 с, это очень хороший результат. А "SQL*Net message from client" в нерекурсивных операторах говорит о том, что сервер ждал команды от клиента Не понятен смысл этого трейса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2016, 15:55:07 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровМне в который раз интересно, ты увлекся конкретным запросом, но при этом непрерывно вываливаешь "OVERALL TOTALS FOR ALL % STATEMENTS". Наверное ты что-то этим показать хочешь? Ну так хоть намекни... Или ты не понимаешь разницу между RECURSIVE и NON-RECURSIVE STATEMENTS ? Хинт: есть SQL-операторы (включая BEGIN-END), посланные с клиента, а есть вызванные изнутри этих операторов Что касается конкретного запроса -- конечно, лучше уменьшить количество его выполнений, если есть возможность. Парсов относительно выполнений совсем чуть, так что здесь все нормально. Но каждый вызов этого запроса приведет к EXECUTE и FETCH Да и вообще -- ты не указываешь временной промежуток, о чем тут можно судить? Если трейс снят за сутки -- то тут даже смотреть не на что, а если за те же 7 мин, то, собственно, а что ему еще делать, как не работать? Например, среднее обращение к диску занимает 0.007 с, это очень хороший результат. А "SQL*Net message from client" в нерекурсивных операторах говорит о том, что сервер ждал команды от клиента Не понятен смысл этого трейса Вячеслав, пользователь пожаловался, что " ну 3,14*ц долго " выполняется некий отчёт. Я снял трейс, получил 790 elapsed seconds in trace file, увидел, что большая часть времени потрачено на рекурсивные вызовы. Да, выполнялся некий begin-end. Мне бросилось в глаза, что очень много executions. По времени - это не день, 13 минут.. Пользователь написал руководству, что он такой молодец, всё делает, а " программа висит " Возник вопрос, куда копать дальше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2016, 16:34:40 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
жвачкинВозник вопрос, куда копать дальше?Казалось бы очевидно.. Смотреть самому(или просить объяснить программистов), зачем код генерит столько вызовов этого запроса.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2016, 18:45:08 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
В трассировке план наверное есть... Смотри план, если сервер ентерпрайз в SQL Monitoring запрос найдешь и можешь прям там у советника попросить подсказку, может подскажет какой индекс создать. Может план подскажет удачный и закрепишь этот план за запросом. Можно самому план создать и закрепить его за запросом, но это уже надо немного копать интернет, тут видела такую тему. Может таблицу по дате секционировать, если таблица большая и за много лет (я к этому стремлюсь, но пока страшно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 06:50:29 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
И звиздец долго понятие относительное, 13 минут для отчета ни о чем, у меня запросы по 9 часов выполнялись, отключила параметр оптимизатора и уговорила разработчика не пихать везде ORDERED, свела их к 6 минутам, пользователи уже счастливы. А 13 минут это пользователю кофе сходить попить, не постоянно же он его делает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 06:57:31 |
|
||
|
Большие значения execute в трейсе файле
|
|||
|---|---|---|---|
|
#18+
nata44845А 13 минут это пользователю кофе сходить попить, не постоянно же он его делает. неизвестно о каком отчете идет речь, может и 13 минут это долго. но 390 тысяч вызовов - имхо, перебор. автор, можете намекнуть на содержание (данные) отчета? может надо просто разработчика попинать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2016, 09:05:37 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39284565&tid=1887735]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
225ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 192ms |
| total: | 474ms |

| 0 / 0 |
