|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Есть такой запрос: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Внутренняя часть (using) выполняется около секунды. А весь целиком запрос висит более минуты, затем я его прерываю. По CLIENT_ID есть PK, число строк измеряется тысячами. Из-за чего такая разница? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:04 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B., Ответ на вопрос "что так долго выполняется" всегда один - нужно посмотреть что там так долго выполняется. Мониторинг, ash, session waits: механизмов много. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:09 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B., План посмотрите для начала. Для всего merge. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:21 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
В предполагаемом плане все нормально: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
А реальный я посмотреть не могу, т.к. не дождусь выполнения запроса. Скрипт, который выполнял этот запрос, был аварийно прерван. Может быть остались блокировки или транзакции? В TOAD есть Session Browser, в разделе Long Ops я своего запроса не вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:32 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. Внутренняя часть (using) выполняется около секунды. Полный фетч или первые строки? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:36 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. число строк измеряется тысячами В обеих таблицах? В плане Alibek B. Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:39 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. В TOAD есть Session Browser, в разделе Long Ops я своего запроса не вижу. не надо смотреть в long ops, это не про вас. находите в session browser сессию, выполняющую merge, далее current statement -> explain plan (снизу), желательно выбрать format dbms_xplan из контекстного меню. перед запуском merge выполните alter session set statistics level = all ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:40 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
env Полный фетч или первые строки? Полный, запрос обычно возвращает небольшое количество строк (единицы). env В обеих таблицах? В обоих таблицах возможное количество строк измеряется тысячами. Вот такой запрос показывает, что у меня есть блокировка на таблице B24_QUEUE (lock_type=DML, mode_held=row-x). Видимо из-за прерванного ранее скрипта, подключенного к базе, который в момент прерывания работал с этой таблицей. Нужно дождаться, пока блокировка освободится по таймауту? Или ее можно форсировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:47 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B., Убить сессию, например, если уверены, что это ваша предыдущая. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:50 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
"тысячи" строк в B24_CACHE и B24_QUEUE, но там еще неявный nested loops на эти "тысячи" итераций на BM_PAYMENT, SERVICES и BM_SERVICE_MONEY, и не факт, что там тоже тысячи строк, и что они нормально проиндексированы для таких чтений. а моментально наверняка фетчатся только первые строки, поэтому и иллюзия мгновенности. в общем показывайте план со статстиками, и чего ждет merge, чтобы не гадать. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 17:57 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
кит северных морей, У него блокировка. Видимо, всё гораздо проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:04 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
У меня команда (alter session set statistics level = all) не работает, пишет про неверную опцию сессии (у меня Oracle 10g). Но в explain plan указана кардинальность, на BM_SERVICE_MONEY кардинальность 70к, на остальных соединениях строк немного. Собственно при предыдущих запусках скрипта этот запрос (с merge) выполнялся секунд 8. "Долгоиграющим" он стал сейчас, когда я скрипт прервал аварийно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:07 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
env Убить сессию, например, если уверены, что это ваша предыдущая. Сессию? Сессию я и прервать могу (отменить запрос), но блокировка ведь никуда не денется. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:09 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B., Сессию, которая держит блокировку. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:09 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. alter session set statistics level = all statistics_level (пробела не должно быть). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:13 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
кит северных морей statistics_level (пробела не должно быть). План практически полностью совпадает с тем, что я уже выкладывал вначале: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
env Сессию, которая держит блокировку. Тогда это явно не она. Это сессия, которая сейчас висит. А сессии, которая держит блокировку, сейчас на сервере нет. Если выполнение запроса прервать, то запрос со списком блокировок возвращает пустой результат. В TOAD в разделе Locks блокировки тоже появляются только когда выполняется запрос с merge. Если его отменить, то и блокировка пропадает. А как найти, что изначально вызывает блокировку? В waits верхние три строчки занимают log file sync, db file seq. read и db file scatter read. Это может быть лог (откат транзакции)? Если в моем запросе закомментировать блок, связанный с BM_SERVICE_MONEY, то весь merge выполняется быстро (секунды за 3). То есть запрос "висит" только если внутри using используется BM_SERVICE_MONEY. Хотя в чистом виде подзапрос внутри using выполняется быстро. Как такое может быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:22 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. План практически полностью совпадает с тем, что я уже выкладывал вначале: нас в большей степени интересует не сам план а статистики выполнения. пример: https://oracle-base.com/articles/9i/dbms_xplan#gather_plan_statistics_hint (на уровне запроса gather_plan_statistics работает аналогично statistics_level=all) в TOAD session browser получить его можно, выбрав из контекстного меню current statement: display mode > dbms_xplan. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:40 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
У меня такого нет. Есть дерево, список, диаграмма. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:43 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B., тогда из вкладки information внизу возьмите sql_id и child_number, и выполните запрос select * from table(dbms_xplan.display_cursor(sql_id => ваш sql_id, cursor_child_no=> ваш child_number, format => 'allstats last')) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 18:47 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
child_number=0, а sql_id нет вообще. Есть address и hash_value. Если считать, что sql_id это то же, что hash_value, то результат такой: Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 19:32 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Alibek B. Код: plaintext 1. 2.
alter session забыли? ну или хинт в merge вставьте. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 19:35 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Не забыл, выполнял перед запросом. Хинт это /*+ GATHER_PLAN_STATISTICS */ ? Добавлять к merge? Что-то не вижу эффекта: Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 19:45 |
|
Запрос с merge не выполяется (выполняется очень долго)
|
|||
---|---|---|---|
#18+
Переделал с exists на left join с группировкой, плюс по возможности оптимизировал. Так работает за приемлемое время (в пределах 5 секунд). Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 22:27 |
|
|
start [/forum/topic.php?fid=52&msg=40010597&tid=1880779]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
82ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 195ms |
0 / 0 |