Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Во такой вопрос - есть view, построенная на одной таблице, в ней 5-ть полей такие же как в таблице , 3-ри поля вычислимых. Она используется в запросе и не подтягивается индекс - join идет в том , по 3-ом полям (которые совпадают с табличными - не вычислимые). Тоесть если я в запрос ставлю таблицу (на которой базируется view) в такой же связке - то индекс подтягивается, если view ставлю в запрос, то нет... 1. В MSSQL я бы попробовал написать HINT типа , select * from t where id = 1 with (INDEX = id_ind) 2. Так как view базируется на одной таблице, то попробовал бы постоить индекс - прям на view. Что можно попытаться сделать в DB2 (Version 9.7) 2- по- моему там точно нельзя, а вот есть в каком то виде 1-ый пункт в DB2? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2013, 16:42 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, Хорошо бы привести DDL как таблицы (с индексами), так и view. Ну и сам запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 09:49 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
CawaSPbmedoed, Хорошо бы привести DDL как таблицы (с индексами), так и view. Ну и сам запрос. 1. Скрипт таблицы Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 2. Скрипт view: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. Запросы: s Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Индекс, который подтягивается для таблицы: Код: plsql 1. 2. 3. 4. 5. Планы: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 13:07 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, Здравствуйте. Запросы не равнозначные - в представлении есть использование olap функции для поля END_DATE. Вы когда вставляете такое же выражение при обращении в запросе к таблице, у вас что - индекс используется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 13:42 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoed, Здравствуйте. Запросы не равнозначные - в представлении есть использование olap функции для поля END_DATE. Вы когда вставляете такое же выражение при обращении в запросе к таблице, у вас что - индекс используется? Да Марк, упростим задачу, раз вы радееете за оптимизатор DB2 и верите что он безгрешность)) -- из таблицы select tTotal.ID_PERSON_FUND ,coalesce(max(tTotal.BOOK_DATE) over (partition by tTotal.ID_BANKROLL, tTotal.ID_ALLOC_TIME, tTotal.VARIANT_DATE, tTotal.ID_PERSON_FUND order by tTotal.BOOK_DATE ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING) - 1 DAY, nullif(tTotal.VARIANT_DATE, '0001-01-01') , '9999-01-01') as END_DATE from TOTAL.BANKROLL_SDEPO tTotal where tTotal.ID_PERSON_FUND = 3 and tTotal.ID_BANKROLL = 5 and tTotal.ID_ALLOC_TIME = 4 and tTotal.VARIANT_DATE = date(1) -- из view select tTotal.ID_PERSON_FUND , END_DATE from TOTAL.VBANKROLL_SDEPO tTotal where tTotal.ID_PERSON_FUND = 3 and tTotal.ID_BANKROLL = 5 and tTotal.ID_ALLOC_TIME = 4 and tTotal.VARIANT_DATE = date(1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 14:14 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, Попробуйте выкинуть из индекса второе поле, или постваить его на последнее место. Если хотите использовать "хинты", почитайте тут: Influence query optimization with optimization profiles and statistical views in DB2 9 medoedраз вы радееете за оптимизатор DB2 и верите что он безгрешность))Я не верю ни в чью безгрешность. Из каких моих высказываний вы сделали такой вывод? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 15:22 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoed, Попробуйте выкинуть из индекса второе поле, или постваить его на последнее место. Если хотите использовать "хинты", почитайте тут: Influence query optimization with optimization profiles and statistical views in DB2 9 medoedраз вы радееете за оптимизатор DB2 и верите что он безгрешность))Я не верю ни в чью безгрешность. Из каких моих высказываний вы сделали такой вывод? >> 1.Попробуйте выкинуть из индекса второе поле, или постваить его на последнее место. Не помогло и то и то пробовал >> 2. Если хотите использовать "хинты", почитайте тут: Influence query optimization with optimization profiles and statistical views in DB2 9 Я так понял там надо таблицу создавать - а потом профайл запроса подсовывать в XML виде. В Mssql это тоже доступно, но там это в крайнем случае используют. Я так делать не хочу. >> 3. Из каких моих высказываний вы сделали такой вывод? Ну вы же засомневались, в моих выводах, что с таблицей индекс подхватывается, а во view нет - значит в априоре были уверены в безгрешности DB2. Ну может конечно я погорячился с выводами, Марк ничего личного! 4. P.S. В очередной раз DB2 проиграл другим распространённым СУБД (MSSQL, SYBASE, ORACLE) а) Нельзя индекс накатить на view. б) Нельзя хинтовать по имени индекса. Пунктом б) конечно тоже лучше не пользоваться - но если припрёт... А в DB2 просто такой возможности нет (чтоб быстро и на лету для разработчика) - это конечно тоже огромный минус DB2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 16:13 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedP.S. В очередной раз DB2 проиграл другим распространённым СУБД 1.Не трогайте морковеведов. 2.Второе поле в индексв BOOK_DATE в запросе во view не используется. 3.Банально, но еще раз собрать статистику. 4. Попробуйте разбить индекс на два,возможно ваш индекс избыточен. Проявите уважения к DB2 оптимизатору, как правило он действительно прав, даже если в начале я так не считаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 16:57 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, тут вопрос не к DB2, а разработчику. Index на view - это физически как выглядит? Я понимаю, когда view материализована - это физически таблица со всеми свойствами. А если нет - тогда все равно этот самый индекс будет фактически урезанная до набора полей индекса materialized view. Вы определили порядок полей, на основании которых будете брать BOOK_DATE partition by { tTotal.ID_BANKROLL, tTotal.ID_ALLOC_TIME, tTotal.VARIANT_DATE, tTotal.ID_PERSON_FUND } а индекс создаете в другой последовательности, от которого толку никакого ID_BANKROLL ASC, BOOK_DATE ASC, ID_PERSON_FUND ASC, ID_ALLOC_TIME ASC, VARIANT_DATE ASC нужен ID_BANKROLL ASC, ID_ALLOC_TIME ASC, VARIANT_DATE ASC , ID_PERSON_FUND ASC, BOOK_DATE DESC Очень стоит присмотреться к аккуратности при написании VARIANT_DATE DATE NOT NULL DEFAULT '0001-01-01' и далее в тексте nullif(t1.VARIANT_DATE, '0001-01-01') Andy "не ищите проблемы у DB2, ищите их у себя"(с) Мой Я эту мантру разработчикам читаю уже лет дцать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 17:15 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
A.Panskikhmedoed, Тут вопрос не к DB2, а разработчику. Index на view - это физически как выглядит? Я понимаю, когда view материализована - это физически таблица со всеми свойствами. А если нет - тогда все равно этот самый индекс будет фактически урезанная до набора полей индекса materialized view. Вы определили порядок полей, на основании которых будете брать BOOK_DATE partition by { tTotal.ID_BANKROLL, tTotal.ID_ALLOC_TIME, tTotal.VARIANT_DATE, tTotal.ID_PERSON_FUND } а индекс создаете в другой последовательности, от которого толку никакого ID_BANKROLL ASC, BOOK_DATE ASC, ID_PERSON_FUND ASC, ID_ALLOC_TIME ASC, VARIANT_DATE ASC нужен ID_BANKROLL ASC, ID_ALLOC_TIME ASC, VARIANT_DATE ASC , ID_PERSON_FUND ASC, BOOK_DATE DESC Очень стоит присмотреться к аккуратности при написании VARIANT_DATE DATE NOT NULL DEFAULT '0001-01-01' и далее в тексте nullif(t1.VARIANT_DATE, '0001-01-01') Andy "не ищите проблемы у DB2, ищите их у себя"(с) Мой Я эту мантру разработчикам читаю уже лет дцать. Очень много букв и пожеланий отвечу: 1. Построил индекс: Код: plsql 1. 2. 3. 4. 5. План запроса не изменился, table scan остался при использовании view. За аккуратность наверное вы правы, но запрос писал не я, мне нужно только его оптимизировать. >>Index на view - это физически как выглядит? Я понимаю, когда view материализована - это физически таблица со всеми >>свойствами. А если нет - тогда все равно этот самый индекс будет фактически урезанная до набора полей индекса materialized >>view. Почитайте тут, в MSSQL можно строить не только на материлизованные представления: http://msdn.microsoft.com/en-us/library/ms191432.aspx >>не ищите проблемы у DB2, ищите их у себя"(с) Мой >>Я эту мантру разработчикам читаю уже лет дцать Вы уж простите, но DB2 по сравнению с MSSQL, Sybae and Oracle - это как ручная коробка передач с автоматической и Вы мне говорите: Нафига автоматическая - ручная рулит)) Но вы хотя бы попробовали автомат, а потом был бы спор и мудрые поучения про дцать лет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 17:52 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed>> 2. Если хотите использовать "хинты", почитайте тут: Influence query optimization with optimization profiles and statistical views in DB2 9 Я так понял там надо таблицу создавать - а потом профайл запроса подсовывать в XML виде. В Mssql это тоже доступно, но там это в крайнем случае используют. Я так делать не хочу.Политика IBM в плане влияния на оптимизатор в порядке следования, если предыдущее не помогло: - собираем статистику - создаём статистические представления - используем статистические профили Только, если всё предыдущее не помогает и никак нельзя/очень не удобно этим пользоваться, вы заключаете NDA с IBM и вам рассказывают, как пользоваться хинтами в тексте запроса. Это самый нерекомендуемый способ по очевидным причинам - текст запроса в рабочей стистеме как правило гораздо сложнее изменить (или вообще невозможно), если вдруг звёзды сошлись по-другому с течением времени. А статистические профили, например, гораздо проще менять, не меняя сам текст запроса. Хотя да, разработчику надо больше приседать... medoed>> 3. Из каких моих высказываний вы сделали такой вывод? Ну вы же засомневались, в моих выводах, что с таблицей индекс подхватывается, а во view нет - значит в априоре были уверены в безгрешности DB2. Без обид :) Логика напомнила анекдот про логическую цепочку "Рыбка -> Рыба -> Щука -> С зубами -> Хищник -> Собака -> С*ка" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:04 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, "Вот так и рождаются нездоровые сенсации" (C) :) Вы смело делаете далеко идущие выводы и спешите ими поделиться. В то же время не замечаете, что у Вас меняется семантика OLAP функции. Код: sql 1. 2. 3. 4. 5. в одном случае (с вью или вложенным запросом) она работает на полном сете данных исходной таблицы, а в другом на ограниченном сете Код: sql 1. 2. 3. 4. Это будет совсем другая FOLLOWING строка. Даже если на ваших данных результат идентичен, запрос имеет право строиться по-другому. В DB2 вообще плохие планы как правило свидетельствуют о том, что в данных есть некоторая закономерность, про которую вы знаете, а СУБД - нет. Т.е. хорошее проектирование - фундамент хорошей производительности. Какой должен быть план (какой план лучше) - это уже предмет дальнейшего обсуждения. Факт - запросы разные . Изучайте мат.часть и не гоните на серьёзный продукт, извиняюсь за грубость. PS Посмотрите внимательней на порядок колонок в индексе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:05 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
TrogloditmedoedP.S. В очередной раз DB2 проиграл другим распространённым СУБД 1.Не трогайте морковеведов. 2.Второе поле в индексв BOOK_DATE в запросе во view не используется. 3.Банально, но еще раз собрать статистику. 4. Попробуйте разбить индекс на два,возможно ваш индекс избыточен. Проявите уважения к DB2 оптимизатору, как правило он действительно прав, даже если в начале я так не считаю. >>1.Не трогайте морковеведов. Я и не трогаю, так чуть чуть сравниваю)) Кстате почему морковеды? Это каста специальная - её кто возглавляет, хотелось бы знать >> 2.Второе поле в индексв BOOK_DATE в запросе во view не используется. Я уж вроде разные строил , из рекомендованных мне - проку не было! >>3.Банально, но еще раз собрать статистику. Пробовал раза 3 - не помогло! >> 4. Попробуйте разбить индекс на два,возможно ваш индекс избыточен. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. >>Проявите уважения к DB2 оптимизатору, как правило он действительно прав, даже если >>в начале я так не считаю. Я бы сказал, что чаще он все таки прав, но крайне не всегда! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:11 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed>>Index на view - это физически как выглядит? Я понимаю, когда view материализована - это физически таблица со всеми >>свойствами. А если нет - тогда все равно этот самый индекс будет фактически урезанная до набора полей индекса materialized >>view. Почитайте тут, в MSSQL можно строить не только на материлизованные представления: http://msdn.microsoft.com/en-us/library/ms191432.aspx Насколько я знаю, MSSQL-ное понятие MQT - это как раз и есть эти indexed view, только с урезанной функциональностью, судя по ограничениям. Разве нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 18:15 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoed>>Index на view - это физически как выглядит? Я понимаю, когда view материализована - это физически таблица со всеми >>свойствами. А если нет - тогда все равно этот самый индекс будет фактически урезанная до набора полей индекса materialized >>view. Почитайте тут, в MSSQL можно строить не только на материлизованные представления: http://msdn.microsoft.com/en-us/library/ms191432.aspx Насколько я знаю, MSSQL-ное понятие MQT - это как раз и есть эти indexed view, только с урезанной функциональностью, судя по ограничениям. Разве нет? Да отчасти я был не прав... В MSSQL если на view накатываем индекс (1-н обязательно должен быть кластерным, дальше могут быть произвольные), то она становится как бы реальной-материальной таблицей, но никакие refresh делать не нужно (сам сервер MSSQL будет следить за её обновлением) и никаких блокировок особо не будет, кроме возможных провисаний при вставке или массовых апдейтах (но опять же не блокировок), если они не будет происходить по 100000 раз вставок в секунду в базовую таблицу. Хотя такими видами view особо не пользуются в MSSQL. Я сварганил похожий простейший пример на MSSQL - как в DB2 и указал принудительный индекс в запросе для view: i Код: sql 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. Посмотрите, как можно эффективно организовывать хинтование в MSSQL... Я хотел что то подобное сделать и в DB2 - но походу такой возможности нет. Тема закрыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2013, 22:40 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, По теме топика, если всё ещё интересно. Я не смог повторить такое поведение оптимизатора. Данными набивать таблицу не стал, вместо этого сделал: Код: sql 1. DDL Код: sql 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. План Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 09:49 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedВ MSSQL если на view накатываем индекс (1-н обязательно должен быть кластерным, дальше могут быть произвольные), то она становится как бы реальной-материальной таблицей, но никакие refresh делать не нужно (сам сервер MSSQL будет следить за её обновлением)Если интересно, то в DB2 такая же функциональность с похожими ограничениями обеспечивается с помощью REFRESH IMMEDIATE MQT. Можете в CREATE TABLE поискать по фразе 'REFRESH IMMEDIATE'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 09:57 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinmedoedВ MSSQL если на view накатываем индекс (1-н обязательно должен быть кластерным, дальше могут быть произвольные), то она становится как бы реальной-материальной таблицей, но никакие refresh делать не нужно (сам сервер MSSQL будет следить за её обновлением)Если интересно, то в DB2 такая же функциональность с похожими ограничениями обеспечивается с помощью REFRESH IMMEDIATE MQT. Можете в CREATE TABLE поискать по фразе 'REFRESH IMMEDIATE'. Да я в курсе, коллеги пробовали - тормоза и блокировки при такой модели наступают... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 10:07 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoed, По теме топика, если всё ещё интересно. Я не смог повторить такое поведение оптимизатора. Данными набивать таблицу не стал, вместо этого сделал: Код: sql 1. DDL Код: sql 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. План Код: 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. И я попробовал и все равно план запроса включает table scan Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Марк, а в DB2 есть понятие вычислимых полей - в MSSQL можно было бы попробовать столбец вычислимый сделать и на него индекс накатить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 10:12 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedИ я попробовал и все равно план запроса включает table scan Попробуйте Код: sql 1. Кроме того: - когда создаёте индекс, то желательно собирать статистику на него сразу, т.е. что-то типа: Код: plaintext Код: plaintext medoedа в DB2 есть понятие вычислимых полей - в MSSQL можно было бы попробовать столбец вычислимый сделать и на него индекс накатить?В DB2 это generated always поля по выражению. См. CREATE TABLE. На эти поля можно создавать индексы так же, как и на обычные поля. Только как это поможет в вашей ситуации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 10:44 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinmedoedИ я попробовал и все равно план запроса включает table scan Попробуйте Код: sql 1. Кроме того: - когда создаёте индекс, то желательно собирать статистику на него сразу, т.е. что-то типа: Код: plaintext Код: plaintext medoedа в DB2 есть понятие вычислимых полей - в MSSQL можно было бы попробовать столбец вычислимый сделать и на него индекс накатить?В DB2 это generated always поля по выражению. См. CREATE TABLE. На эти поля можно создавать индексы так же, как и на обычные поля. Только как это поможет в вашей ситуации? Попробовал, не помогло. >> когда создаёте индекс, то желательно собирать статистику на него сразу Я опять в небольшую засаду попал от DB2, в MSSQL при создании индекса статистика по умолчанию собирается (но можно эту опцию отключить). >> На эти поля можно создавать индексы так же, как и на обычные поля. >> Только как это поможет в вашей ситуации?[/quot] Попробовать поле END_DATE - добавить как вычислимое к таблице и это поле включить в составной индекс. Да впрочем наверное брошу я эту затею - запрос работает 28 секунд и пусть пока дальше так же работает. Он 1-2 раза дергается за день. Что терпимо... Устал я с DB2 воевать, хочется назад уже в MSSQL вернуться или хотя бы к Oracle... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 11:04 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, как уже сказали неоднократно - учите матчасть. И перед тем как ответить, проверьте себя - гугл всем доступен. DB2 Cookbook должен быть изучен на предмет особенностей. А db2, oracle, mssql принципиально не отличаются. Учитесь оперировать множествами. Тот же экплейн четко описывает на каждом шаге почему выбрана именно такая стратегия. За 15 лет я лишь три или четыре ошибки в оптимизаторе встретил лично, хотя такие извращения от разрабов повидал... При обучении я показываю наглядную агитацию - представьте себе таблицу физически! В виде листочков (eq pages) в папке (eq tbs), сделайте к ней индексы из набора бумажных квадратиков: на одной стороне значение, на другой номер страницы (rowid ) и попробуйте "выполнить" запросы. Поверьте, многие вопросы отпадут. Это безо всякой привязки к выбранной субд. Чистая физика. Andy ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 14:11 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
A.Panskikhmedoed, как уже сказали неоднократно - учите матчасть. И перед тем как ответить, проверьте себя - гугл всем доступен. DB2 Cookbook должен быть изучен на предмет особенностей. А db2, oracle, mssql принципиально не отличаются. Учитесь оперировать множествами. Тот же экплейн четко описывает на каждом шаге почему выбрана именно такая стратегия. За 15 лет я лишь три или четыре ошибки в оптимизаторе встретил лично, хотя такие извращения от разрабов повидал... При обучении я показываю наглядную агитацию - представьте себе таблицу физически! В виде листочков (eq pages) в папке (eq tbs), сделайте к ней индексы из набора бумажных квадратиков: на одной стороне значение, на другой номер страницы (rowid ) и попробуйте "выполнить" запросы. Поверьте, многие вопросы отпадут. Это безо всякой привязки к выбранной субд. Чистая физика. Andy Я конкретно говорил, чего мне не хватает в DB2 - это принудительное хинтование с указанием конкретного индекса (как показал вчера в примере на MSSQL), да пусть эта опция нужна в 0.1% случае запросов. Но иногда она выручает эта опция. Насчет чему мне учиться - спасибо за совет, но я в нём не нуждался, автор той вьюхи не я, я просто пытался разобраться почему не подтягивается индекс, не получилось - хотел использовать хинт, именно тот случай 0.1%. Но опять же DB2 не умеет нормально хинтовать... Вообщем то и все... P.S. Почитайте мои посты в этой ветке, сколько я выявил недостатков за 3-ри месяца работы с DB2. Даже если предположить, что я просто не умею готовить DB2 - вот факты, который не красят DB2 нельзя DISABLE триггер, посмотрите как давно в DB2 команда truncate появилась, есть ли встроенная команда по перевороту строки (Reverse) и т.д. - список можно продолжать долго.... Данную ветку особо продолжать не вижу смысла, лично я потихоньку возвращаюсь на MSSQL. Может быть ошибочно, но считаю, что шансов в России у СУБД DB2 составлять конкуренцию Oracle and MSSQL очень мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2013, 15:59 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedЯ конкретно говорил, чего мне не хватает в DB2 - это принудительное хинтование с указанием конкретного индекса (как показал вчера в примере на MSSQL), да пусть эта опция нужна в 0.1% случае запросов. Но иногда она выручает эта опция.Но опять же DB2 не умеет нормально хинтовать... И она есть - но не в привычной вам форме. А не умеет - это бред. medoedНасчет чему мне учиться - спасибо за совет, но я в нём не нуждался, автор той вьюхи не я, я просто пытался разобраться почему не подтягивается индекс, не получилось - хотел использовать хинт, именно тот случай 0.1%. вот тут и следовало как раз поучиться - не просто так не подтягивался индекс. И потом - о чем приниципиально отличается tablescan от indexscan? Особенно, если нужно потом построить иное множество - вполне нормально, когда дешевле один раз считать bulk массив и из него вырезать готовое множество, чем прочитать индекс чуть меньшего размера, потом еще фетчить недостающие данные из таблицы и потом еще раз фильтровать. medoedПочитайте мои посты в этой ветке, сколько я выявил недостатков за 3-ри месяца работы с DB2. Это смешно. Напоминает анекдот про юниксоида и мышковода. Переход на юникс: сначала бьемся в истерике, сплошные проблемы, потом читаем доку и блаженствуем. Переход на винды: сначала блаженствуем, потом получаем проблему, читаем доку и начинаем биться в истерике. Без обид. Но юношеский задор и маскимализм нужно направить в правильное русло и все получится. Тем более, что и задатки есть, и желание тоже есть. Andy ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 08:43 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
>> To Andy >> И она есть - но не в привычной вам форме. А не умеет - это бред. Да но такой способ есть и в MSSQL, но есть и более удобная форма с именем указания индекса. Нет такого в DB2 (дело не в привычке) - минус данной СУБД. >> вот тут и следовало как раз поучиться - не просто так не подтягивался индекс. Смысл тратить время на неудобный оптимизатор, я не вижу! >>И потом - о чем приниципиально отличается tablescan от indexscan? Особенно, если нужно потом построить иное множество - >>вполне нормально, когда дешевле один раз считать bulk массив и из него вырезать готовое множество, чем прочитать индекс >>чуть меньшего размера, потом еще фетчить недостающие данные из таблицы и потом еще раз фильтровать. Выбираем индекс для 100 строк и потом считаем по ним агрегаты. Думаю MSSQL сделал бы именно так. >>Без обид. Но юношеский задор и маскимализм нужно направить в правильное русло и все получится. Тем более, что и задатки >>есть, и желание тоже есть. У меня другое сравнение - Дос + интерфейс и горячие кнопки = DB2 , и windows интерфейс с кнопками и манипулятором мыши =MSSQL. Большинство в современном обществе выбирают Windows и не только за монополизм, а как правило за удобство. И потом , с чего вы взяли, что я юноша, то что я горячо порой высказываюсь, дык это скорее характер. У меня 4-ре года опыта работы с MSSQL, 2 c ASE, 0.5 c Oracle. Например при работе с Oracle после MSSQL, на все мои запросы - находились ответы. Например мне нужно было провести аудит и визуализировать нагрузку на DB2 (тяжелые и долгие запросы) - ушло 2 дня. В MSSQL - это бы заняло пол дня от силы, при том что большая часть таких отчетов уже визуализирована (без всяких дополнительных параметров на базе) в Management studio. >> To Andy Вы попробуйте Profiler от MSSQL заюзать и сравните его с профайлером от DB2 и вы все поймёте)). Но впрочем не буду настаивать, пусть каждый останется при своем мнении. Но я от вымирающего динозавра (DB2) решил отойти. Всем спасибо, особенно Mark - у Barinstain -у. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2013, 10:38 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed, честно говоря, у меня очень противоположное мнение. Разрабатывая и эксплуатируя разнообразные системы под ms sql c 1995 года v6.0-2008R2, oracle с 2000 года v8.1.5-11gR2, db2/400 под r5v4, sybase ase и db2luw 9.1-9.7fp8 именно последнюю считаю самой устойчивой, беспроблемной и логично организованной. Непонимания и возмущения в разработке у меня вызывали все rdbms, но, как правило, проблемы были только в моем уровне недопонимания особенностей каждого конкретного оптимизатора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 13:56 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukmedoed, честно говоря, у меня очень противоположное мнение. Разрабатывая и эксплуатируя разнообразные системы под ms sql c 1995 года v6.0-2008R2, oracle с 2000 года v8.1.5-11gR2, db2/400 под r5v4, sybase ase и db2luw 9.1-9.7fp8 именно последнюю считаю самой устойчивой, беспроблемной и логично организованной. Непонимания и возмущения в разработке у меня вызывали все rdbms, но, как правило, проблемы были только в моем уровне недопонимания особенностей каждого конкретного оптимизатора. Ну не знаю мне первое время не хватало в DB2 (я и сейчас так считаю) профайлера и визуальных средств, оные присутствуют в MSSQL, начиная с 2000 версии. Я работал в крупной страховой не так давно, там был как раз SQL-2008R2 , особых проблем со стабильностью серверов тоже не наблюдал. А вот отладка и оптимизация, под SQL была значительно проще... Кстате в логе монитора от MSSQL, нет затроеенности команд, которая встречается в системном мониторе DB2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 15:13 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedНу не знаю мне первое время не хватало в DB2 (я и сейчас так считаю) профайлера и визуальных средств, оные присутствуют в MSSQL, начиная с 2000 версии. Я работал в крупной страховой не так давно, там был как раз SQL-2008R2 , особых проблем со стабильностью серверов тоже не наблюдал. А вот отладка и оптимизация, под SQL была значительно проще... Кстате в логе монитора от MSSQL, нет затроеенности команд, которая встречается в системном мониторе DB2 Я пользуюсь ibm datastudio и optim для визуализации планов. Ну и для ковыряний с Oracle 10&11, MS SQL 2005&2008, DB2/400 :) Плюс Optim perfomance metrics для db2 9.7 Аналогом трейса ms sql выбрал CREATE EVENT, который пишет в отдельный tablespace не создавая нагрузки на основном массиве. Кстати, поковырялся со своими PMR, открытыми в IBM, оказалось, что есть похожий, проявившийся как раз при создании view. План исполнения меняется используются индексы для t1.fld1 и t2.fld2 select t1.fld1 from table1 t1 inner join table2 t2 on ... left outer join table3 t3 on ... where t1.fld1 = ? and t2.fld2 = ? не используются индексы для t1.fld1 и t2.fld2 select fld1 from ( select t1.fld1 from table1 t1 inner join table2 t2 on ... left outer join table3 t3 on ... ) zzz where zzz.fld1 = ? and zzz.fld2 = ? До решения проблемы затычка была сделана в виде udf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 16:49 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukmedoedНу не знаю мне первое время не хватало в DB2 (я и сейчас так считаю) профайлера и визуальных средств, оные присутствуют в MSSQL, начиная с 2000 версии. Я работал в крупной страховой не так давно, там был как раз SQL-2008R2 , особых проблем со стабильностью серверов тоже не наблюдал. А вот отладка и оптимизация, под SQL была значительно проще... Кстате в логе монитора от MSSQL, нет затроеенности команд, которая встречается в системном мониторе DB2 Я пользуюсь ibm datastudio и optim для визуализации планов. Ну и для ковыряний с Oracle 10&11, MS SQL 2005&2008, DB2/400 :) Плюс Optim perfomance metrics для db2 9.7 Аналогом трейса ms sql выбрал CREATE EVENT, который пишет в отдельный tablespace не создавая нагрузки на основном массиве. Кстати, поковырялся со своими PMR, открытыми в IBM, оказалось, что есть похожий, проявившийся как раз при создании view. План исполнения меняется используются индексы для t1.fld1 и t2.fld2 select t1.fld1 from table1 t1 inner join table2 t2 on ... left outer join table3 t3 on ... where t1.fld1 = ? and t2.fld2 = ? не используются индексы для t1.fld1 и t2.fld2 select fld1 from ( select t1.fld1 from table1 t1 inner join table2 t2 on ... left outer join table3 t3 on ... ) zzz where zzz.fld1 = ? and zzz.fld2 = ? До решения проблемы затычка была сделана в виде udf Ну может быть со временем, в 10 или 11 версии DB2 сделают нормальный родной профайлер, который будет по имени машины, Application, логину фильтровать и запускаться с компа юзера локально, а не грузить сервер DB2 в файлы или в таблицы (может у меня на серваке места нет), но в MSSQL такой профайлер уже лет 10 есть. По запросу - я понимаю, что индексы не подтягиваются, поэтому и хотел оптимизатору сделать подсказку на лету с именем индекса, а не через ж.опу udf. Но безусловно, если долго мучиться и в DB2 все получиться. Мне лично времени и сил жалко... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 17:23 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedНу может быть со временем, в 10 или 11 версии DB2 сделают нормальный родной профайлер, который будет по имени машины, Application, логину фильтровать и запускаться с компа юзера локально, а не грузить сервер DB2 в файлы или в таблицы (может у меня на серваке места нет), но в MSSQL такой профайлер уже лет 10 есть. По запросу - я понимаю, что индексы не подтягиваются, поэтому и хотел оптимизатору сделать подсказку на лету с именем индекса, а не через ж.опу udf. Но безусловно, если долго мучиться и в DB2 все получиться. Мне лично времени и сил жалко... Мне вот, к примеру, страшно жалко моих сотрудников, которые пишут сотни отчетов на Оракле. Такого обьема хинтования и сопровождающего его чувства обреченности я ни от кого больше не слышу. Как им только не жалко своего времени и сил :) А коллега с MS SQL замучался балансировать между необходимость написать hash перед словом join и падением боевого 2008R2 от этого. Зато ленивый dba автоматически ловит изменившиеся планы запросов на продакт db2 и также лениво лечит их с помощью db2advis. Так что у каждого свои проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 17:52 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukmedoedНу может быть со временем, в 10 или 11 версии DB2 сделают нормальный родной профайлер, который будет по имени машины, Application, логину фильтровать и запускаться с компа юзера локально, а не грузить сервер DB2 в файлы или в таблицы (может у меня на серваке места нет), но в MSSQL такой профайлер уже лет 10 есть. По запросу - я понимаю, что индексы не подтягиваются, поэтому и хотел оптимизатору сделать подсказку на лету с именем индекса, а не через ж.опу udf. Но безусловно, если долго мучиться и в DB2 все получиться. Мне лично времени и сил жалко... Мне вот, к примеру, страшно жалко моих сотрудников, которые пишут сотни отчетов на Оракле. Такого обьема хинтования и сопровождающего его чувства обреченности я ни от кого больше не слышу. Как им только не жалко своего времени и сил :) А коллега с MS SQL замучался балансировать между необходимость написать hash перед словом join и падением боевого 2008R2 от этого. Зато ленивый dba автоматически ловит изменившиеся планы запросов на продакт db2 и также лениво лечит их с помощью db2advis. Так что у каждого свои проблемы. >>Мне вот, к примеру, страшно жалко моих сотрудников, которые пишут сотни отчетов на Оракле. >>Такого обьема хинтования и сопровождающего его чувства обреченности я ни от кого больше не слышу. Как им только не >>жалко своего времени и сил :) Ваши они по крепостному праву? Может всё таки коллег? А зачем так много хинтовать, что на Oracle, что на Mssql хинтование нужно не более 1% , а может и 0.1% от кода, как я писал выше. Тем более в Оракле функциональные индексы возможны... >>А коллега с MS SQL замучался балансировать между необходимость написать hash перед словом join и падением боевого 2008R2 >>от этого. Ну х.з. зачем hash - принудительно писать, можно это добиться правильным построением запроса, exists побольше в запросы и все получится Какой то фантастишь вы рассказываете)) >>Зато ленивый dba автоматически ловит изменившиеся планы запросов на продакт db2 и также лениво лечит их с помощью >>db2advis. В моем случае с примером table scan по view - мне db2advise - не помог. А в случае ленивого админа MSSQL даже отдельную утилиту запускать не нужно, а можно сразу автоматический джоб создать, который периодически будет напоминать, ему или разрабам об индексах: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 18:32 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Ссылку забыл: статья: http://imamyshev.wordpress.com/2009/06/19/sql-server-2005-2008-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%8E%D1%89%D0%B8%D1%85-%D0%B8%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%D0%BE%D0%B2/%5D]http://imamyshev.wordpress.com/2009/06/19/sql-server-2005-2008-создание-недостающих-индексов/] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 18:33 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedПо запросу - я понимаю, что индексы не подтягиваются, поэтому и хотел оптимизатору сделать подсказку на лету с именем индекса, а не через ж.опу udf Нашёл свой старый пост по теме. Ж.оп и udf не надо использовать :) План выполнения и статистика. Может, кому-то будет интересно, как это делать с представлениями, и они не покинут нас так безвременно (в лучшем смысле этого слова), как автор топика :) Ещё раз DDL для удобства Код: sql 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. Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Обратите внимание, как мы обращаемся к таблице, на которой построено представление: "tTotal/t1" В плане мы увидим: Код: plaintext 1. 2. 3. 4. 5. Ну и обращаем мнимание, что текст запроса надо набирать в профиле в точности (тот же регистр букв) такой же, как и в приложении. Пробелы, символы возврата каретки/перевода строки (если, конечно, они не внутри констант) не учитываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 18:40 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Марк, вы бы лучше помогли по другому топику, как внутри функции в динамическом скрипте данные из NickName считать, тогда бы я совсем к Вам вернулся. А то меня ругачка на доступ к федеративному объекту из функции, прежде всего добила. Может Ваш старый пост, тоже Вам откроется)) А то хинтование - это повод, а вот невозможность выбрать данные из скалярной функции - это был основной удар, как инсульт по моему самолюбию: http://www.sql.ru/forum/actualthread.aspx?tid=1005493 Кстати обещанное пиво в силе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2013, 18:50 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedкак внутри функции в динамическом скрипте данные из NickName считатьЯ уже говорил, что надо написать в IBM такое требование, где описать систему, для чего это надо, почему никак нельзя по-другому (например, на процедурах) это сделать. Тогда вашу заявку рассмотрят и, если повезёт, через некоторое время вам это сделают. Но времени может пройти много, а сейчас всё, что я могу от себя предложить, это сделать такую табличную функцию общего типа: Код: sql 1. 2. jdbc:db2://host:port/dbname - это jdbc url для баз DB2, но здесь можно подцепляться к любой БД, только JDBC драйвер надо будет "зарегистрировать" в базе DB2. Работать она будет так: - обращаться она будет напрямую в dbname и сама соединять результаты запроса с другими таблицами из локальной или какой-то другой базы, естественно, не будет - Если надо будет параметризовать запрос, то в его текст надо будет подставлять значение этого параметра, т.е. что-то типа: Код: sql 1. 2. 3. - перед каждым вызовом всего внешнего запроса она будет устанавливать соединение с dbname, в конце вызова - разрывать соединение - регистрационные данные можно держать либо в локальной таблице, либо в файле на сервере или в параметрах передавать (тогда эту ф-цию вообще можно будет как no sql объявить) - возвращать она будет результат select'а в табличном виде В 9.7 нет generic table function, поэтому вам под запрос, возвращающий определённый набор полей, надо будет дописать маленький класс с вызовом типа: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 10:28 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinЖ.оп[/s] и udf не надо использовать :) Guidelines как мне кажется, аналогичная *опа, только сбоку. Кстати, иногда очень помогает затупление оптимизатора до уровня 3 для конкретного запроса выставление на драйвере QUERY OPTIMIZATION или выполнением SET QUERY OPTIMIZATION. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 11:09 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukMark BarinsteinЖ.оп[/s] и udf не надо использовать :) Guidelines как мне кажется, аналогичная *опа, только сбоку. Не обижайте Марка, он и так выжал, всё что можно из DB2, самое обидное при его статусе он всё равно хрен напишет в IBM: Cделайте нормальное хинтование для разработчиков что то типа Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 11:37 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukGuidelines как мне кажется, аналогичная *опа, только сбоку.Нет. Если вы имеете возможность менять приложение, то у вас, конечно, гораздо больше выбора. Но если у вас нет доступа к коду, то иногда это единственная возможность повлиять на оптимизатор. Выставлять пониженный уровень оптимизации ради одного запроса можно, наверное, но что будет с остальными запросами этого приложения? А с guidelines, например, вы можете выставить нужный уровень только для этого запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 11:44 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoedкак внутри функции в динамическом скрипте данные из NickName считатьЯ уже говорил, что надо написать в IBM такое требование, где описать систему, для чего это надо, почему никак нельзя по-другому (например, на процедурах) это сделать. Тогда вашу заявку рассмотрят и, если повезёт, через некоторое время вам это сделают. Но времени может пройти много, а сейчас всё, что я могу от себя предложить, это сделать такую табличную функцию общего типа: Код: sql 1. 2. jdbc:db2://host:port/dbname - это jdbc url для баз DB2, но здесь можно подцепляться к любой БД, только JDBC драйвер надо будет "зарегистрировать" в базе DB2. Работать она будет так: - обращаться она будет напрямую в dbname и сама соединять результаты запроса с другими таблицами из локальной или какой-то другой базы, естественно, не будет - Если надо будет параметризовать запрос, то в его текст надо будет подставлять значение этого параметра, т.е. что-то типа: Код: sql 1. 2. 3. - перед каждым вызовом всего внешнего запроса она будет устанавливать соединение с dbname, в конце вызова - разрывать соединение - регистрационные данные можно держать либо в локальной таблице, либо в файле на сервере или в параметрах передавать (тогда эту ф-цию вообще можно будет как no sql объявить) - возвращать она будет результат select'а в табличном виде В 9.7 нет generic table function, поэтому вам под запрос, возвращающий определённый набор полей, надо будет дописать маленький класс с вызовом типа: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 1.У меня коллеги писали в IBM, самый ранний ответ через пол года, в среднем год. Писать особого смысла нет! 2.Марк, а функция универсальная, у меня например 20 разных NickName - разной структуры, она подойдёт для всех? 3. Также возникает вопрос насчет out класса, для каждого NicName он будет свой и если у меня , 10 баз получателей - мне этот класс на все базы разворачивать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 11:46 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed1.У меня коллеги писали в IBM, самый ранний ответ через пол года, в среднем год. Писать особого смысла нет! 2.Марк, а функция универсальная, у меня например 20 разных NickName - разной структуры, она подойдёт для всех? 3. Также возникает вопрос насчет out класса, для каждого NicName он будет свой и если у меня , 10 баз получателей - мне этот класс на все базы разворачивать? 2. Функция не будет работать с nickname вообще. Она будет устанавливать соединение с удаленной базой так же, как это делает обычное java приложение, т.е. даже регистрировать удаленную базу не надо. 3. Вам нужна будет отдельная SQL функция и класс (вы можете даже в одном классе собрать все java-функции для SQL функций) для всех разных комбинаций выходных полей. От числа и типа удаленных баз это не зависит. Т.е., например, вы знаете, что у вас будут: Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 12:03 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinmedoed1.У меня коллеги писали в IBM, самый ранний ответ через пол года, в среднем год. Писать особого смысла нет! 2.Марк, а функция универсальная, у меня например 20 разных NickName - разной структуры, она подойдёт для всех? 3. Также возникает вопрос насчет out класса, для каждого NicName он будет свой и если у меня , 10 баз получателей - мне этот класс на все базы разворачивать? 2. Функция не будет работать с nickname вообще. Она будет устанавливать соединение с удаленной базой так же, как это делает обычное java приложение, т.е. даже регистрировать удаленную базу не надо. 3. Вам нужна будет отдельная SQL функция и класс (вы можете даже в одном классе собрать все java-функции для SQL функций) для всех разных комбинаций выходных полей. От числа и типа удаленных баз это не зависит. Т.е., например, вы знаете, что у вас будут: Код: plaintext 1. 2. Код: plaintext 1. 2. Тоесть вместо NickName на получателе, я должен написать функцию на получателе взамен каждого NickName например и она будет получать данные на прямую данные из источника? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 12:16 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedТоесть вместо NickName на получателе, я должен написать функцию на получателе взамен каждого NickName например и она будет получать данные на прямую данные из источника?Да, напрямую из источника. Ещё раз: отдельная функция пишется для своей комбинации типов возвращаемых полей. Если вы знаете, что ваш запрос возвращает, скажем, 2 поля - строка и целое, то вы пишете 1 функцию и используете её с любыми базами. Главное, чтобы запрос в эту удалённую базу возвращал ровно 2 поля с этими типами и в этой последовательности. За этим соответствием функция - набор возвращаемых полей вам надо будет при вызове следить самому. Ну или можно использовать ф-цию с более длинным списком полей для запроса, но те поля, которые присутствуют в запросе, должны будут идти на первых местах списка полей в том же порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 12:33 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoed1.У меня коллеги писали в IBM, самый ранний ответ через пол года, в среднем год. Писать особого смысла нет! Правды ради. За последний год у нас пара PMR'ов, переродившихся далее в APAR и пофиксеных в 9.7.6. По прочим PMR'ам (которые, собственно, не есть ошибки, а, например, наше незнание "как настроить" и нерабочесть прям так из коробки) каких-либо нареканий высказать не могу. Скорее нас теребили, когда за прочими делами по продуктивным системам мы откладывали "исследовательскую" работу "как сделать ..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 13:16 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinmedoedТоесть вместо NickName на получателе, я должен написать функцию на получателе взамен каждого NickName например и она будет получать данные на прямую данные из источника?Да, напрямую из источника. Ещё раз: отдельная функция пишется для своей комбинации типов возвращаемых полей. Если вы знаете, что ваш запрос возвращает, скажем, 2 поля - строка и целое, то вы пишете 1 функцию и используете её с любыми базами. Главное, чтобы запрос в эту удалённую базу возвращал ровно 2 поля с этими типами и в этой последовательности. За этим соответствием функция - набор возвращаемых полей вам надо будет при вызове следить самому. Ну или можно использовать ф-цию с более длинным списком полей для запроса, но те поля, которые присутствуют в запросе, должны будут идти на первых местах списка полей в том же порядке. Спасибо Марк, подумаем над этим предложением, но хотелось бы максимально открытое решение сделать средствами самой СУБД (SQL), без внешних воздействий (java функций или java классов). Опять же как устойчиво такое решение будет работать и исправлять возможные ошибки на лету - тоже не очень понятно!? Немножко, пофлеймлю - раз пятница)) P.S. У меня три раза за 4-ре года работы с MSSQL было желание CLR функцию написать на C#: 1) Для считывания информации об учетках в домене (ФИО, телефоны и т.д). - не успел... 2) Для создания функции по склонению ФИО и наименования предприятий по падежам)) 3) Для обращения к Web- сервису из СУБД - обошелся OLE средcтвами в самой СУБД . Кстати это ни хрена не правильно архитектурно (web-service дергать из СУБД), но это сейчас используют в той страховой, мою тестовую поделку, вот и описывай после этого все в Wike ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 13:24 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedНе обижайте Марка, он и так выжал, всё что можно из DB2, самое обидное при его статусе он всё равно хрен напишет в IBM: Cделайте нормальное хинтование для разработчиков что то типа [src PLSQL] select * from table with (index = my_index) Никоим образом вообще никого не хотел обижать. У нас, к счастью или сожалению, у каждого своя *опа и, как мне пока кажется, у ibm есть решения для них :) Для меня хинт в тексте запроса - это очень некрасиво для эксплуатирующих. Хотя, если вы совмещаете разработку, оптимизацию и эксплуатацию, то допустимо. А степенью оптимизации в приложениях я только начинаю управлять, как и степенью параллелизма. Очень забавные и приятные эффекты получаются, могу заметить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 13:31 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
aserdjukmedoedНе обижайте Марка, он и так выжал, всё что можно из DB2, самое обидное при его статусе он всё равно хрен напишет в IBM: Cделайте нормальное хинтование для разработчиков что то типа [src PLSQL] select * from table with (index = my_index) Никоим образом вообще никого не хотел обижать. У нас, к счастью или сожалению, у каждого своя *опа и, как мне пока кажется, у ibm есть решения для них :) Для меня хинт в тексте запроса - это очень некрасиво для эксплуатирующих. Хотя, если вы совмещаете разработку, оптимизацию и эксплуатацию, то допустимо. А степенью оптимизации в приложениях я только начинаю управлять, как и степенью параллелизма. Очень забавные и приятные эффекты получаются, могу заметить. Я выше писал, что 0.1 -1% хинт в тексте запроса допустим, и что в IBM это реализовано убого, более ничего. Наоборот отметил способности Марка , что он может из УГ конфетку сделать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 14:58 |
|
||
|
Оптимизировать запросик на DB2 , problem with view (9.7)
|
|||
|---|---|---|---|
|
#18+
medoedхотелось бы максимально открытое решение сделать средствами самой СУБД (SQL), без внешних воздействий (java функций или java классов). Опять же как устойчиво такое решение будет работать и исправлять возможные ошибки на лету - тоже не очень понятно!?Java процедуры/функции официально поддерживаются в DB2. У меня похожее решение работало в продуктивной системе, правда, там была процедура, которая результатами удаленного запроса наполняла локальную таблицу. DB2 не исправляет ошибки в любых процедурах, а сообщает о них с помощью кодов возврата - здесь будет то же самое. Федеративный NLJOIN :) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2013, 19:37 |
|
||
|
|

start [/forum/topic.php?all=1&fid=43&tid=1601460]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 278ms |
| total: | 436ms |

| 0 / 0 |
