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