|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр Но зачем получать :p_id и подставлять его в log_id > :p_id, если уже rownum < 1e7 Наверное чтобы каждый раз не выполнять rownum < 1e7, не? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 22:00 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode, Если каждый раз не выполнять, то по любому будет читаться 1e7 записей минимум. Каждый раз кол-во записей будет не меньше предыдущего. То есть, прочитано будет не меньше записей, чем в моем варианте. Значит и выигрыша не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2020, 22:47 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр, Не надо фантазировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2020, 17:43 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
graycode, у вас есть гипотеза? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2020, 19:50 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Egoр Есть протокол. Есть некое внешнее неформализуемое событие. Нужно просмотреть последние записи протокола, которые могут иметь отношение к этому событию. Сколько этих записей - не известно. Начинаю с двухсот. Если не хватает, то увеличиваю, 500, 1000, 5000 ... Прикольная задача. Типа результат нужен ASAP? Чтобы был честный таймаут, пропусти запрос select * from t_log order by log_id desc через PIPELINE функцию, в которой следи за тайматом. Через переменную в глобальном контексте можно будет даже завершать сканирование лога по требованию из отдельной сессии, если результат запроса уже нужен. И немного практической теории. Нужно установить оптимизатору SQL запросов цель FIRS_ROWS (OPTIMIZER_MODE). И избегать операций, которые для выполнения требуют полного набора данных. Поскольку приложение клиента может тянуть записи сервера блоками, нужно ограничить размер такого блока 1 по крайней мере для выборки записей, которые нужны ASAP. Тогда система не будет ждать наполнения маршрутки большого блока (которое может и не случиться), а сразу вернёт первые записи. А дальше по желанию, можно будет выбирать оставшиеся записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2020, 12:21 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Just for fun решение с помощью параллельного concurrent union-all, где в одной части реальный запрос, а во-второй тупо таймаут: 3 seconds Код: 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.
зы. спасибо, SeaGate за фикс с TTT ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 19:28 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
стоп, правка - предыдущее еще не работает так как надо из-за PX SELECTOR (он выполняется в координаторе) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 19:30 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
хотя не, все ок - все вроде работает: Код: 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.
plan Код: 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.
RTSM report Код: 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. 67. 68. 69. 70. 71. 72. 73. 74.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 20:30 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
xtender Код: plsql 1. 2. 3. 4. 5. 6.
Ну говорил жеж - из pipelined швырять ее надо, а не разбрасывать где попало :) Воспроизвести аналогичный предложенному эффект при этом можно посредством parallel pipelined. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2020, 22:44 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
andrey_anonymous, pipeline слишком просто и скучно, к тому же требует создания объектов, жесткой привязки к запросу, да и одним чистым pipeline без какого-нибудь трюка типа этого не получится - если внутри pipeline функции у тебя будет "бесконечный" запрос, который "уйдет в себя", то в pl/sql управление не вернется. С PTF (polymorphic table functions) было бы чуточку интереснее, но все равно в-основном скучный кодинг... а тут все в одном простом запросе. Изначально вообще была более простая идея для хохмы: написать pure sql запрос, который сам закончится по таймауту - это оказалось совсем легко: Код: 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.
оказалось слишком просто, поэтому добавил "типа реальный запрос с данными" ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 02:52 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
В целом, если уж решать такое в реальной задаче для продуктива, то совершенно логично, что делалось бы стандартными средствами (в порядке убывания распространнености решений): 1. обычный запрос + клиентское прерыванием запроса ("ORA-01013: user requested cancel of current operation"); 2. Resource manager с лимитами (со своими общеизвестными нюансами); 3. запуск запроса в отдельном процессе/джобе и передача результатов через стандартные же средства межпроцессорного взаимодействия, типа dbms_pipe, с стандартными же вариантами прерывания этого процесса, типа cancel sql ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2020, 03:01 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
Staxмож в следующих версиях добавят SAMPLE TIME (шучу конечно) Есть недокументированный _query_execution_time_limit. Трассируется через oradebug component time_limit. В описании указано "Query execution time limit in seconds". Тесты в 19.3 для определенного класса запросов с разным значением параметра: Код: 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. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144.
Наблюдается определенный паттерн в том, через какое время прерывается этот класс запросов: Код: 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.
Судя по всему, limitPerNode = timelimt / (execution_plan_lines-1) (исключаем SELECT STATEMENT). Если так, то это можно использовать, чтобы получить окончание запроса в точное время. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2020, 15:39 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
SeaGate Есть недокументированный _query_execution_time_limit. хах, забыл про него за 5 с половиной лет появился в 12.1.0.2: https://www.freelists.org/post/oracle-l/query-execution-time-limit,1 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2020, 15:50 |
|
Ограничить выборку по таймауту?
|
|||
---|---|---|---|
#18+
SeaGate, я тож про отладчик думал, но у меня нет практического опыта, так несколько раз не вполне удачно пробовал, и бросил тут недавно ссылку давали, так там подсмотрел что в новых версияях отличную команду открылы для дба ALTER SYSTEM CANCEL SQL мож из дебагера вытащили наружу ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2020, 15:53 |
|
|
start [/forum/topic.php?fid=52&gotonew=1&tid=1880610]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
10ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 291ms |
total: | 462ms |
0 / 0 |