Этот баннер — требование Роскомнадзора для исполнения 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 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=38217782&tid=1601460]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 11ms |
| total: | 182ms |

| 0 / 0 |
