|
|
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
также написан был и обсуждаемый запрос, но он работать отказался. какая-то хня с этими линками, честное слово ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 16:17 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
barrabasу меня есть рабочий код (собственно для которого я давно создавал тему), где идет вставка в локальную таблицу из нескольких линкованных таблиц через execute immediate. без хинта висит по полчаса, с хинтом пара минут всего хотя Вячеслав Любомудров утверждал обратное.Это не только я утверждал, но и нота "Limitations of DRIVING_SITE Hint For DMLS and DDLS (Doc ID 825677.1)" Хотя, тут я неправ -- когда все таблицы в запросе удаленные и на одном сайте , то да, все соединения могут быть выполнены на том удаленном сайте. Это работает как для INSERT, так и для CTAS (хотя из ноты я понял обратное). Оно, кстати, и без всякого DRIVING_SITE так выполнится. Если хоть одна таблица локальная или на разных сайтах, то все будет выполнятся на target сайте (соответственно, при любом UPDATE/DELETE/MERGE тоже) и никакой DRIVING_SITE не поможет Код: 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. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. PS. Все твои домыслы "так работает, так почему-то не работает" звучат не убедительно. Если действительно хочешь разобраться -- включай трассировку, смотри ожидания, реальный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 04:24 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудровbarrabasу меня есть рабочий код (собственно для которого я давно создавал тему), где идет вставка в локальную таблицу из нескольких линкованных таблиц через execute immediate. без хинта висит по полчаса, с хинтом пара минут всего хотя Вячеслав Любомудров утверждал обратное.Это не только я утверждал, но и нота "Limitations of DRIVING_SITE Hint For DMLS and DDLS (Doc ID 825677.1)" Хотя, тут я неправ -- когда все таблицы в запросе удаленные и на одном сайте , то да, все соединения могут быть выполнены на том удаленном сайте. Это работает как для INSERT, так и для CTAS (хотя из ноты я понял обратное). Оно, кстати, и без всякого DRIVING_SITE так выполнится. Если хоть одна таблица локальная или на разных сайтах, то все будет выполнятся на target сайте (соответственно, при любом UPDATE/DELETE/MERGE тоже) и никакой DRIVING_SITE не поможет Код: 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. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. PS. Все твои домыслы "так работает, так почему-то не работает" звучат не убедительно. Если действительно хочешь разобраться -- включай трассировку, смотри ожидания, реальный план. Вячеслав Любомудровbarrabasу меня есть рабочий код (собственно для которого я давно создавал тему), где идет вставка в локальную таблицу из нескольких линкованных таблиц через execute immediate. без хинта висит по полчаса, с хинтом пара минут всего хотя Вячеслав Любомудров утверждал обратное.Это не только я утверждал, но и нота "Limitations of DRIVING_SITE Hint For DMLS and DDLS (Doc ID 825677.1)" Хотя, тут я неправ -- когда все таблицы в запросе удаленные и на одном сайте , то да, все соединения могут быть выполнены на том удаленном сайте. Это работает как для INSERT, так и для CTAS (хотя из ноты я понял обратное). Оно, кстати, и без всякого DRIVING_SITE так выполнится. Если хоть одна таблица локальная или на разных сайтах, то все будет выполнятся на target сайте (соответственно, при любом UPDATE/DELETE/MERGE тоже) и никакой DRIVING_SITE не поможет Код: 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. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. PS. Все твои домыслы "так работает, так почему-то не работает" звучат не убедительно. Если действительно хочешь разобраться -- включай трассировку, смотри ожидания, реальный план. да, на самом деле для получения Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. достаточно было NO_MERGE, DRIVING_SITE не влиял никак Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 09:34 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
без хинта NO_MERGE и при любых вариациях DRIVING_SITE Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 09:35 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Не работал пример с курсором . По времени выполнения и без плана было понятно , что хинт не пользовался. В этом загвоздка. Хотя бы угадать, как оптимизатор обрабатывает запрос с удаленными таблицам с применением pl/sql типов. А вы делаете теоретические выкладки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 09:41 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
но почему план чисто в SQL, в plsql блоках for c in (select ...) и в open c for 'select ' разный я так и не понял. еще и при разных способах фетча (с bulk collect и без) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 09:42 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
fortnetИнтересно, что с fetch хинт не влияет на план запроса , а с fetch bulk collect влияет. кстати, такое ощущение что хин не работает вообще. с fetch bulk collect работает 2 секунды что с хинтом что без. а простой фетч висит 15 минут, так-же на хинт не обращая внимания. записей всего 8000 в результате получаю, т.е. это не то чтобы долгая построчная выборка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 09:52 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
еще наблюдение переписываю на forall загрузку транзакций из внешней системы в ней дата хранится как дата без времени и в отдельном поле время в виде кол-ва секунд в дне если фетчить получать поля по отдельности - все ок если написать в запросе t.DATA + t.VREMYA/86400 OPER_DATE, чтобы получить дату со временем сразу, план ломается и все старания летят к чертям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2017, 15:45 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
fortnetНе работал пример с курсором . По времени выполнения и без плана было понятно , что хинт не пользовался. В этом загвоздка. Хотя бы угадать, как оптимизатор обрабатывает запрос с удаленными таблицам с применением pl/sql типов. А вы делаете теоретические выкладки.Если ты не знаешь, как это работает (должно работать), то метаться методом тыка можно долго. Например, некоторые вещи работать просто не будут, они так устроены (тот же DRIVING_SITE) А если не работает то, что по всем прикидкам должно работать, то нужно и подходить более серьезно -- делать трассировку, смотреть планы, ожидания. А не метаться со всякими "давай попробуем так, а еще так" и делать глубокомысленные выводы из обрывков информации, неизвестно когда и на каких данных полученной Это если, конечно, интересен результат, а не процесс PS. Это, конечно, больше к ТС. Остальным, собственно, пофиг, какие давать советы, можно и "пометаться" и "выводы поделать" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 11:03 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровPS. Это, конечно, больше к ТС. Остальным, собственно, пофиг, какие давать советы, можно и "пометаться" и "выводы поделать" Зато можно почувствовать себя "мега -исследователем", несмотря на переливание из пустого в порожнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 13:27 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
ElicВячеслав ЛюбомудровPS. Это, конечно, больше к ТС. Остальным, собственно, пофиг, какие давать советы, можно и "пометаться" и "выводы поделать" Зато можно почувствовать себя "мега -исследователем", несмотря на переливание из пустого в порожнее.Если это про меня, то да, мне интересно "поисследовать" что-то, с чем мне не приходится (часто) сталкиваться Ну и записать, ибо так оно лучше запоминается. Ну не писать же в свой блокнотик, его же никто не прочитает, чтож я, зря старался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 15:33 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЕсли это про меняНет, конечно же. Вячеслав Любомудровчтож я, зря старался?И истинных исследователей это основной результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:01 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#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. даёт нужный Код: plaintext 1. 2. 3. 4. 5. 6. а если напишу t.DATA + VREMYA/86400, чтобы получить дату и время в одном поле Код: 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. получу Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. что с того что я узнаю что план строится неправильный при простом fetch, а не fetch bulk collect на одном запросе? я и так по времени что неправильно работает. как трассировка бы помогла выбрать именно fetch bulk collect ? как она помогла бы с t.DATA + VREMYA/86400? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:15 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Нет ли переменной с именем VREMYA ? Ну и возможно стоит переходить на 10053 -- сам я в этом не силен, но иногда удается понять почему был выбран именно такой план ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:21 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
вот и приходится перебирать варианты и искать тормозные куски в запросе постепенно подключая их ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:21 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНет ли переменной с именем VREMYA ? Ну и возможно стоит переходить на 10053 -- сам я в этом не силен, но иногда удается понять почему был выбран именно такой план нет. я транслитом переменные не называю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:22 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Не надо перебирать, надо постараться понять -- почему Для этого есть инструменты и надо научиться ими пользоваться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:22 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
10053? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:23 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНе надо перебирать, надо постараться понять -- почему Для этого есть инструменты и надо научиться ими пользоваться ну с t.DATA + t.VREMYA/86400 как понять то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:24 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
barrabasВячеслав ЛюбомудровНет ли переменной с именем VREMYA ? Ну и возможно стоит переходить на 10053 -- сам я в этом не силен, но иногда удается понять почему был выбран именно такой план нет. я транслитом переменные не называю :) там реально было t.DATA + t.VREMYA/86400 конечно. это уже в сейчас скопировал неудачно. план это не меняет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:27 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
barrabasну с t.DATA + t.VREMYA/86400 как понять то?Ну тут просто - оторвать горе-архитектору ногти по самые уши. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:29 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
И еще такие "метания", как разные, например, NLS_* настройки у текущей сессии и сессии по db-линку (на мой взгляд, это может повлиять на всякие сортировки/группировки) Опять же, локальные переменные, передаваемые как бинды -- возможно, не всегда их можно передать В общем, если 10046 кажет явно неожиданный план и его не удается хинтами отправить выполняться на удаленный узел (к моему стыду, я не сильно вчитывался в твои листинги и не понял, что все [не]выполняется на одном удаленном узле), то наверное, есть смысл подключать тяжелую артилерию в виде 10053 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:32 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Elicbarrabasну с t.DATA + t.VREMYA/86400 как понять то?Ну тут просто - оторвать горе-архитектору ногти по самые уши. это внешняя система данная нам в ощущениях а пот мегаинформативный трейс Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 16:41 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровfortnetНе работал пример с курсором . По времени выполнения и без плана было понятно , что хинт не пользовался. В этом загвоздка. Хотя бы угадать, как оптимизатор обрабатывает запрос с удаленными таблицам с применением pl/sql типов. А вы делаете теоретические выкладки.Если ты не знаешь, как это работает (должно работать), то метаться методом тыка можно долго. Например, некоторые вещи работать просто не будут, они так устроены (тот же DRIVING_SITE) А если не работает то, что по всем прикидкам должно работать, то нужно и подходить более серьезно -- делать трассировку, смотреть планы, ожидания. А не метаться со всякими "давай попробуем так, а еще так" и делать глубокомысленные выводы из обрывков информации, неизвестно когда и на каких данных полученной Это если, конечно, интересен результат, а не процесс PS. Это, конечно, больше к ТС. Остальным, собственно, пофиг, какие давать советы, можно и "пометаться" и "выводы поделать" Ну, не так уж и долго продолжалось метание... А интересные вопросы почему игнорируете, все поучаете только. barrabas но почему план чисто в SQL, в plsql блоках for c in (select ...) и в open c for 'select ' разный я так и не понял. еще и при разных способах фетча (с bulk collect и без) кстати, такое ощущение что хин не работает вообще. с fetch bulk collect работает 2 секунды что с хинтом что без. а простой фетч висит 15 минут, так-же на хинт не обращая внимания. записей всего 8000 в результате получаю, т.е. это не то чтобы долгая построчная выборка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 14:13 |
|
||
|
Тормоза при join-е нескольких таблиц чероз DBlink
|
|||
|---|---|---|---|
|
#18+
fortnetвсе поучаете только.Да ни в коем разе Стараюсь просто отбросить заведомо неработоспособные варианты и формализовать доступность возможных И потом кто сказал, что это твоя записная книжка -- это моя fortnetВячеслав Любомудров... А интересные вопросы почему игнорируетеДа если бы я сам знал, неужели бы молчал? Обязательно бы по-"поучал" Пока предположения -- разные версии, разное окружение (NLS), разная цель запроса -- для одной строки лучше FIRST_ROWS, для BULK -- ALL_ROWS (не уверен, что сейчас оптимизатор что-то меняет, в 8-ке, вроде было такое), ошибка в статистике, какие-то трансформации -- причину выбора конкретного плана можно увидеть в 10053, но его надо уметь читать (я не умею, вот и молчу) PS. По-последнему запросу ТС очень похоже, что он нас либо троллит, либо что-то слишком скрывает (where 1=1 and t.DATA = sysdate and t.DATA = sysdate - 1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2017, 15:11 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39397790&tid=1886480]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 477ms |

| 0 / 0 |
