Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
15.12.2021, 12:51
|
|||
---|---|---|---|
|
|||
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Ребят есть вопрос как мне подсчитать примерное время окончания работы SQL запроса основываясь на системных таблицах? Мне нужно отображать в интерфейсе бар прогресса в процентах и я так понимаю для просчета мне нужно два разреза времени: 1) Текущее время выполнения скрипта (это я возьму с execution Time) 2) Примерное время когда запрос выполниться (я могу конечно выполнить его и просто записать время его работы в таблицу и брать это значение как максимальное время для следующих запусков но я думаю это не лучший подход так как время выполнения может быть разным). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 13:17
|
|||
---|---|---|---|
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Если разовое выполнение то зачем прогресс? Если нужно частое выполнение то лучше всего не писать такие запросы, для которых нужен прогресс-бар. Если запрос выполняется менее минуты, то хватит какой-нибудь крутилки, чтобы показать что идёт некий процесс. Если дольше - вплоть до десятков минут и даже часов, то лучше разбить на серию последовательных запросов с сохранением промежуточных вариантов во временные таблицы и прогресс - количество выполненных шагов из их общего количества. Когда то обсуждалась схожая задача и пришли к варианту: после каждого выполнения запроса сохранять время выполнения последних пяти вызовов. В качестве ожидаемого времени очередного выполнения использовать среднее арифметическое от времени выполнения этих самых последних пяти вызовов. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 13:30
|
|||
---|---|---|---|
|
|||
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 13:41
|
|||
---|---|---|---|
|
|||
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Евгения Зайцева Ребят есть вопрос как мне подсчитать примерное время окончания работы SQL запроса основываясь на системных таблицах? это нетривиальная задача. в общем случае есть v$sql_plan.time - предположение оракл о том, сколько этот запрос (шаг запроса, нужно будет взять корневой) будет работать. оценка нередко сильно расходится с реальностью, но реалистично вы вряд ли напишете что-то лучшее. ну либо делать какую-то эвристику с учетом специфики ваших запросов. V$SESSION_LONGOPS ничем не поможет, он показывается динамику выполнения отдельных шагов запроса (допустим, когда закончится текущий full table scan, а их может быть десять). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 13:49
|
|||
---|---|---|---|
|
|||
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Агрох Когда то обсуждалась схожая задача и пришли к варианту: после каждого выполнения запроса сохранять время выполнения последних пяти вызовов. В качестве ожидаемого времени очередного выполнения использовать среднее арифметическое от времени выполнения этих самых последних пяти вызовов. когда-нибудь, в следующей жизни, у меня дойдут руки, и я напишу простенькую ML-модельку, которая будет предсказывать таймауты наших запрсов, которые очень хорошо инструментированы... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 14:22
|
|||
---|---|---|---|
|
|||
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Агрох Если разовое выполнение то зачем прогресс? Если нужно частое выполнение то лучше всего не писать такие запросы, для которых нужен прогресс-бар. Если запрос выполняется менее минуты, то хватит какой-нибудь крутилки, чтобы показать что идёт некий процесс. Если дольше - вплоть до десятков минут и даже часов, то лучше разбить на серию последовательных запросов с сохранением промежуточных вариантов во временные таблицы и прогресс - количество выполненных шагов из их общего количества. Когда то обсуждалась схожая задача и пришли к варианту: после каждого выполнения запроса сохранять время выполнения последних пяти вызовов. В качестве ожидаемого времени очередного выполнения использовать среднее арифметическое от времени выполнения этих самых последних пяти вызовов. Спасибо большое! я думаю всегда брать 5 последних запусков и вычислять среднее значение нормальный вариант для лоадера на данном этапе . Есть проблема с разибитием запросов в том что у меня нету доступа к sql скриптам и я не могу их менять =) Так что в моем случае остаеться только время или системные таблицы =) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 15:31
|
|||
---|---|---|---|
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Евгения Зайцева я думаю всегда брать 5 последних запусков и вычислять среднее значение нормальный вариант для лоадера на данном этапе . Часто бывает, достаточно показывать время которое прошло со старта Пользователи (кроме новичков) и так знают среднее , + ети 5значений где-то ж надо хранить ps мож есть система логирования, и данные брать оттуда ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 15:53
|
|||
---|---|---|---|
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
Stax Евгения Зайцева я думаю всегда брать 5 последних запусков и вычислять среднее значение нормальный вариант для лоадера на данном этапе . Это тоже не гарантирует правильной оценки. Время выполнения может очень сильно отличаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2021, 16:14
|
|||
---|---|---|---|
примерное время когда SQL выполниться (Прогресс бар) |
|||
#18+
SQL*Plus Это тоже не гарантирует правильной оценки. Время выполнения может очень сильно отличаться. понятно что не может как гарантировать в многопользовательской системе точное время при разных нагрузках я немножко о другом программист старается, мучается, изобретает систему и ее поддерживает (напр для Прогресс бар), а конечному пользователю она и не очень то нужна, не помешает, но стоит ли она затрат, хз ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=52&mobile=1&tid=1879680]: |
0ms |
get settings: |
16ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
35ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
240ms |
get tp. blocked users: |
1ms |
others: | 6ms |
total: | 312ms |
0 / 0 |