|
|
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Добрый день, товарищи. прошу помочь: при разработке представления подставляю хинт DRIVING_SITE? чтобы передать датасет из моей выборки по линку, но по неведомой причине, он не подхватывается, и селект тупо умирает: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. что делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:35 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, /*+ DRIVING_SITE(a1) */ ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:40 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:40 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за изменений условий на ходу. Запрос в финале меняется вот на такой: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Возможно ли в таком случае подставить 2 алиаса? Если нет, как можно поступить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:48 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfioВозможно ли в таком случае подставить 2 алиаса? Куда подставить 2 алиаса? Для зачем? Запрос должен отрабатывать под чутким руководством SQL-машины одного из сайтов, которая будет координатором и раздаст работу прочим участникам, ибо одна голова хорошо, а две - змей Горыныч. DRIVING_SITE не "передает датасеты", но подсказывает оракелям, кто из них должен стать главным. wolfioЕсли нет, как можно поступить? Можно забить на линки в пользу ETL-инструментов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:57 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio Возможно ли в таком случае подставить 2 алиаса? Если нет, как можно поступить? Как заставить Oracle использовать хинт /*+DRIVING_SITE() */ ??? ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 17:57 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousМожно забить на линки в пользу ETL-инструментов. можно чуть подробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 18:09 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfioandrey_anonymousМожно забить на линки в пользу ETL-инструментов. можно чуть подробнее? https://www.guru99.com/top-20-etl-database-warehousing-tools.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 18:21 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfioЕсли нет, как можно поступить? Выкинуть код. Зачем лезть в A2 если мы его left джойним и ничего из A2 не берем. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 18:21 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
SY, если a2.agree_no не уникально, то может размножить строки, играет ли это роль в данном случае для ТС - судить не могу . Regards Maxim ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2018, 21:52 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Коллеги, почему в такой реализации запрос зависает? F1 имеет лишь 17 тыс записей, и выгружается относительно быстро. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 09:24 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, А Вы его точно сами писали? А то у меня много вопросов к ТАКОМУ селекту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 11:33 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, задавайте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 14:52 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, 1. /*+ DRIVING_SITE(a2) */ - Вы выгружаете данные f1 (17к по Вашим словам) и CC_CARD@SIEBELV8_SS3.WORLD - все на CC_AGREEMENT ... Вы думаете это обоснованно? может отойти от left Join и перейти к подзапросам в select? 2. Действительно не можете это сделать одним проходом? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 3. Вам реально надо эти таблицы? Задвоить (если они для этого) можно и после выполнения подзапросов. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 15:23 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, 1. подзапросы в селекте как раз и породили гемор с этим вопросом. CC_CARD и CC_AGREEMENT имеет около 100 миллионов записей, и обращение в подзапросе раздельно по каждой строке просто не отработает до вселенной смерти. 2. если вы про эстетику, то да, конечно возможно обернуть парой скобок и выкрутить логику в обратную сторону, чтобы избавиться от лишних экзистов, но по факту ускорения это не даст. Такое ветвление вызвано тем, что изначально источник данных для CC_CARD и CC_AGREEMENT это и есть одна эта колонка. Ее пришлось разбить просто для связки. 3. как я уже сказал, внутренний подзапрос (f1) отрабатывает приемлемо быстро. Можно конечно же, поиграться с освобождением содержимого и выиграть доли секунд по скорости, но по факту, вся проблема упирается в связку через ДБ-линк. я потому и упростил запрос максимально, чтобы убедиться, что это не я туплю с использованием хинта, а система. По факту у меня умирает даже этот запрос: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. зы. вы так забавно реагируете на гавнокод, что боюсь, что если покажу вам полное продуктовое представление, вы сильно разочаруетесь. Забавы ради, план этого маленького запроса указанного выше: Код: 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. 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. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 15:48 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, Коректировка: /*+ DRIVING_SITE(a2) */ - это отправка данных F1 и CC_AGREEMENT@SIEBELV8_SS3.WORLD a1 на источник CC_CARD. НО в Вашем запросе a2 начинает работать ТОЛЬКО когда данные в f1.POS_NUM_DOG is null а f1.CARDS_NUM_DOG is not null, а каков процент таких ситуаций? т.е. первая проверка стоит f1.CARDS_NUM_DOG is null и вывод данных начнеться с CC_AGREEMENT@SIEBELV8_SS3.WORLD a1, и как следствие данных на вывод из CC_CARD@SIEBELV8_SS3.WORLD a2 может не быть вообще. Тогда зачем гнать ВСЕ данные на тот сервер где самая малая вероятность получения данных напрямую. Может и витьевато излагаю, но по приоритетам a2 имеет самый малый приоритет и гнать туда данные не вижу смысла (как-то так) З.ы. DRIVING_SITE(a2) - указание выполнять этот запрос на сервере CC_CARD, т.е. F1 и a1 будут работать по линкам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 15:53 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
MaximaXXL, ну как я понял из доки, и это подтвердил оратор выше - датасеты не гонятся туда. Передается лишь хинт, что удаленная машина главная. Кроме того, я как раз и хотел бы узнать о возможном анализе ораклом этого хинта - увидит ли он, что и а1 и а2 являются источниками на одном хосте? Можно ли сделать так, чтобы он это понял? про null однозначно не могу сказать, но вероятнсть, что данных из cc_agreement не будет вообще крайне мала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 16:08 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, а если разделить Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 16:40 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Stax, Там похоже в другом трабла, CC_CARD и CC_AGREEMENT это вьюхи и когда переносят работу на их сервак они становятся лидирующие, а это не совсем правильно с точки зрения получения данных. Может там LEADING или ORDERED нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 16:47 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Staxwolfio, а если разделить ..... stax не помогло MaximaXXL, вероятно, да, но я пробовал подставить ORDERED хинт, и эффекта не было. хз даже что тут еще можно предпринять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 17:19 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, если запрос/сы выполнять "локально" на удаленных сайтах (без @ххх), то быстро? мож вьюхи сами по себе тяжелые ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 17:27 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
Stax, да, вьюхи реально тяжелые. И при прямом указании agree_no = '123456' отрабатывает за 1-1.5 сек по 1 записи. Но вопрос то в том, почему за те же 10 секунд по 2 записям не отрабатывает даже в элементарном примере.. Т.е. тяжесть вьюх этим фактом немного облегчается :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 17:42 |
|
||
|
DRIVING_SITE - не подхватывает хинт
|
|||
|---|---|---|---|
|
#18+
wolfio, если по отдельности (CC_AGREEMENT,CC_CARD) быстро, Код: plsql 1. 2. 3. 4. 5. 6. 7. то пробовать как-то соеденять, надо домучить напр Код: plsql 1. 2. 3. 4. .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2018, 17:55 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=101&tid=1883468]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 360ms |

| 0 / 0 |
