|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Просветите, почему запрос Код: sql 1. 2. 3. 4.
Выполняется минимум в 2 раза дольше чем Код: sql 1. 2. 3. 4.
Результат запроса на моих данных один и тот же. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 19:28 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, explain plan ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 19:30 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
-2-, Когда плюс, то индекс ACCESS не используется а идёт TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 218 Bytes: 4,972,716 Cardinality: 101,484 Недоумеваю, почему ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:07 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
index of ADDRESS table, not ACCESS ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:08 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, Вы решили использовать ANSI синтаксис совместно внутренним оракловым? Да вы знаете толк в извращениях. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:14 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
feagor, Предложения есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:30 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
LEFT JOIN? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:34 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4.
Так те же яйца, тот же план с TABLE ACCESS FULL ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2019, 20:37 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin Код: sql 1. 2. 3. 4.
Так те же яйца, тот же план с TABLE ACCESS FULLИ чё? Оптимизёр выбрал такой план. Ты возражаешь? P.S. Яйца спрячь. Зри в корень! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2019, 00:06 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Изя КацманОптимизёр выбрал такой план. Он не оптимален ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2019, 20:23 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor CookinИзя КацманОптимизёр выбрал такой план. Он не оптималенпотому что запрос (и девелопер?) "не оптимален" ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2019, 20:55 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Вот план с простым JOIN, быстрый: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Вот план с LEFT JOIN, медленный: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
Удивительно, но VW_NOLICENSE_VK не использует ни тот ни другой запрос, только если FULL. Да, и времени на FULL - столько же что и на LEFT, даром что 100 000 записей, а не 100. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2019, 23:13 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Up ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 17:39 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, я не вижу в твоём запросе предикатов каких-либо кроме связки таблицы с представлением. Если нет предикатов, значит читать надо всё, так почему бы тогда не использовать table access full? покажите код представления Victor Cookin даром что 100 000 записей, а не 100 что это за ограничение, почему до этого про них ничего не говорили? где они в коде? предоставьте пожалуйста план в читаемом формате например выполнив Код: plsql 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 18:12 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
feagor, Медленный запрос /94 rows 500 ms/ Код: plsql 1. 2. 3. 4.
Код: css 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Быстрый запрос /94 rows 150 ms/ Код: plsql 1. 2. 3. 4.
Код: css 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2019, 23:12 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Внутри вьюхи VW_NOLICENSE_VK у тебя full outer join, и из-за условия Код: plsql 1. 2.
в "быстром" варианте oracle понимает, что NL.address_id не должен быть null, а это поле, судя по всему, берется из таблицы ESTABLISHMENT, поэтому oracle трансформирует FULL OUTER JOIN просто в "ESTABLISHMENT left join ESTABLISHMENT_LICENSE", что видно из плана: Victor Cookin Код: css 1. 2. 3. 4. 5. 6. 7.
Это приводит к тому, что оракл снижает кардинальность этой вью до 116 строк со 178273 (при полном FOJ), а в данном случае CBO справедливо считает, что лучше использовать NL и индексный доступ по 116 строкам. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 01:14 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
В медленном же варианте у тебя полноценный FULL OUTER JOIN, да еще и FTS (Full Table Scan) по ADDRESS. ps. в следующий раз сразу показывай реальные планы выполнения со статистиками, а не explain plan. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 01:17 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookinfeagor, Предложения есть? попробуй дописать "where nl.address_id is not null" ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 01:29 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
feagorвыполнив Код: plsql 1. 2.
нет, лучше реальные планы со статистиками, т.е Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 01:34 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtender, Все-тaки не FTS a TABLE ACCESS STORAGE FULL, т.е. EXADATA и посему я бы убедился что smart scan действительно offloading. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 03:07 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
SY, Я обратил на это внимание, но посмотри примеры и вопрос внимательно: 1. В медленном варианте оффлоудить нечего, тк там FOJ и left join к address; 2. Второй вариант и так быстрый. С ним у тс вопроса не стоит, да и оффлоудинг по блум фильтру в непаралелльном запросе по небольшим несекционированным таблицам ничего обычно не даёт; 3. Заморачиваться на оффлоудинг при очевидных проблемах с планом бессмысленно и слишком рано. Кроме того, эксплейн ничего интересного про оффлоудинг не даёт и смотреть надо, как я выше показал, отчёт rtsm ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 04:08 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
кит северных морейVictor Cookinfeagor, Предложения есть? попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 04:14 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
4. теоретически, конечно, возможно прибить в первом варианте хинт no_swap_join_input, чтобы попытаться форсировать оффлоудинг по address, но, очевидно, что это бессмысленно при таком малом кол-ве возвращаемых записей из нее и потенциально огромном кол-ве записей из вью, иначе индексный доступ был бы выгоднее, что определяется на этапе построения плана, а как будет и будет ли работать смарт скан - уже во время выполнения запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 04:28 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtenderкит северных морейпропущено... попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id ну да. на это и расчет. обрати внимание на фильтр в строке 4 "быстрого" плана и на название вьюхи - я подозреваю, внутри неё что-то типа select * from ( select * from establishment full join establishment_license ) where el. establishment_license_Id is null а фулл джоин просто обернут в ещё одну вьюху, которую мы не видим из-за view merging. то есть на самом деле ему нужны все establishment БЕЗ establishment_license, и с адресами - у кого есть. для этого не нужен FOJ между е и el. плюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 05:01 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
кит северных морей, кит северных морейплюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам. Вы наверно имели в виду : Код: plsql 1.
establishment_id не может быть равен null Собственно, вот вьюха: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:05 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, Какова логика establishment и establishment_license? Не надо ли создать внешний ключ по establishment_id между ними? Victor Cookinestablishment_id не может быть равен nullПриведи полный DDL всех трех таблиц с их констрейнтами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:14 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
кит северных морейто есть на самом деле ему нужны все establishment БЕЗ establishment_license, и с адресами - у кого есть. для этого не нужен FOJ между е и el. плюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.это все гадания... и проще спросить напрямую ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:15 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, Victor Cookinestablishment_id не может быть равен null Тьфу ты, конечно же может. То что в базе такого нет, не значит что не может быть висячих лицензий без бизнеса. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:15 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtender, Моя ошибка в том, что я создал вьюху, которая показывает не только А) бизнесы без лицензий, но и Б) лицензии без бизнесов. Собственно, каждодневная забота, это чтобы не было А). Б) - это нужно когда чистят базу. А поскольку в establishment_license стоит FK на establishment.establishment_ID, то и в принципе FULL JOIN во вьюхе не нужен, так как случай Б возможен только при отключении FK, что исключено. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:22 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, если бы establishment_ID был NOT NULL и был FK, оракл бы сам догадался FOJ заменить на left join ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:24 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Переписал VW_NOLICENSE_VK с FULL JOIN на LEFT JOIN Теперь всё работает одинаково быстро. Странно, Оптимизатор плюёт на FK, получается. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:25 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor CookinСтранно, Оптимизатор плюёт на FK, получается.он не "плюёт", а делает логично, учитывая, что поле establishment_ID nullable в establishment_license ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:27 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtender, Только что проверил establishment_id - и NOT NULL и FK в establishment_license Вот establishment_license_id - только NOT NULL ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:28 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#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. 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:32 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor CookinТолько что проверил establishment_id - и NOT NULL и FK в establishment_licenseне верю©. Покажи трассу 10053 для Код: plsql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:33 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtender, У меня нет доступа к файлам трасс. Если подскажете как сделать в без записи в файлы, сделаю. Я - разработчик, не DBA вот план: Plan Hash Value : 975423473 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | Time | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 178273 | 4635098 | 87 | 00:00:01 | | 1 | VIEW | VW_FOJ_0 | 178273 | 4635098 | 87 | 00:00:01 | | * 2 | HASH JOIN FULL OUTER | | 178273 | 1782730 | 87 | 00:00:01 | | 3 | INDEX STORAGE FAST FULL SCAN | PK_ESTABLISHMENT | 28057 | 140285 | 13 | 00:00:01 | | 4 | INDEX STORAGE FAST FULL SCAN | ESTABLISHMENT_LICENSE_IX1 | 177388 | 886940 | 74 | 00:00:01 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): ------------------------------------------ * 2 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID") ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:50 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
xtender, Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 18:52 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 19:20 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
кит северных морей, Ну меня не интересует LICENSE_TYPE_CODE. И я его нигде не запрашиваю. И таблицу LICENSE_TYPE не трогаю. Какое это всё может иметь влияние на план? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 19:47 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookinкит северных морей, Ну меня не интересует LICENSE_TYPE_CODE. И я его нигде не запрашиваю. И таблицу LICENSE_TYPE не трогаю. Какое это всё может иметь влияние на план? никакого. я невнимательно прочитал ddl. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 19:51 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
кит северных морей, странное всё таки поведение, может из-за того что EXADATA? Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 20:28 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookin, Приведи VW_NOLICENSE_VK для полноты картины. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 20:29 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
Victor Cookinстранное всё таки поведениепроверил только что на нескольких базах 12.1-19.3: действительно, несмотря на то, что у оракла есть трансформация FULL_OUTER_JOIN_TO_OUTER, но она не учитывает внешние ключи. Видимо, не подумали, что разработчик может воткнуть FOJ на таблицах, связанных через FK + not null... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 20:36 |
|
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
|
|||
---|---|---|---|
#18+
SY, 21932966 сейчас я исправил FULL на LEFT и всё заработало, но вроде должно было бы работать и с FULL ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2019, 20:37 |
|
|
start [/forum/topic.php?all=1&fid=52&tid=1882275]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
others: | 254ms |
total: | 410ms |
0 / 0 |