Хочу научиться читать SQL...

[fleshold]

По моему вопрос с "подвохом", нет? Оптимизация IN\EXIST выносом в основное тело запроса, исключение\замена на unionы ORов... Это всё азы оптимизации, наверняка известные даже школьникам рисующим сайты на пэхе. (Когда нибудь они тоже сталкиваются с такими проблемами и быстро выгугливают решение.) Не надо даже быть DBA и\или уметь читать планы.

[zVlad]

......

zVlad, так может попросите DBA всетаки показать планы запросов ?

Чем Вас не устраивают те что я (не DBA) уже показал выше?

[iDesperado]

Чем Вас не устраивают те что я (не DBA) уже показал выше?

тем, что это не планы, а куски сырой информации из plan_table. попросите вашего DBA, он поймет о чем речь. в zOS должны быть какие-то утилиты, которые отформатируют информацию из plan_table, покажет хотя бы косты. на сколько я слышал в LUW db2expln, db2exfmt для этого используют.
хотя собственно смысла уже в планах нет. то что вы не понимаете, как нужно разработчику показать план явственно говорит, что вы нифига не DBA и близко у проектов связанными с db2 не стояли. хотя это было понятно и 5 лет назад, когда вы примитивный SQL не смогли прочесть.

[zVlad]

Чем Вас не устраивают те что я (не DBA) уже показал выше?

тем, что это не планы, а куски сырой информации из plan_table. попросите вашего DBA, он поймет о чем речь. в zOS должны быть какие-то утилиты, которые отформатируют информацию из plan_table, покажет хотя бы косты. на сколько я слышал в LUW db2expln, db2exfmt для этого используют.

То что Вы называете "отформатированная информация" это то что можно взять из PLAN_TABLE (в случае DB2 for zOS и еще ряд других таблиц). Я показал лишь часть PLAN_TABLE с вполне конртерной смысловой информацией. Если Вам этой выдержки не достаточно то скажите что Вам хотелось бы еще увидеть и я Вам это покажу. Но это возможно если только Вы нормальным человеческим техническим языком обясните что Вам не хватает.

Что касаемо cost, то они в том что я показал выше есть. Это столбцы PROCMS, и PROCSU. Первый столбец дает costт в милисекундах (MS), второй в Service Units (SU). Обясните чем Вас не устраивают эти cost-ы?

P.S. "Сырая информация" из PLAN_TABLE. Я смеюсь. Вы хоть немножко думайте прежде чeм говорить. "Отформатированная информация" - второй прикол. Если Вы не умеете читать информацию из PLAN_TABLE зaчем Вы вообще ввязываетесь в дискуссии на темы SQL tuning?

[iDesperado]

То что Вы называете "отформатированная информация" это то что можно взять из PLAN_TABLE (в случае DB2 for zOS и еще ряд других таблиц). Я показал лишь часть PLAN_TABLE с вполне конртерной смысловой информацией. Если Вам этой выдержки не достаточно то скажите что Вам хотелось бы еще увидеть и я Вам это покажу. Но это возможно если только Вы нормальным человеческим техническим языком обясните что Вам не хватает.

Влад, ну сходите к DBA, какого черта я должен вам разжевывать основы ? спросите у девелоперов наконец. план это граф, у вас же просто неотсортированные сырые данные, с небольшой частью сырых данных плана. я не могу прочесть документацию для db2, потому что у IBM она самая идиотская из всех субд какие я встречал, а встречал я не мало. судя по всему нужно запускать команду EXPLAIN которая из сырых данных PLAN_TABLE создаст EXPLAIN tables, которые какие-то тулзы должны показывать
http://www-01.ibm.com/support/knowledge ... ables.dita

DB2® uses EXPLAIN tables to store information about the access plan that is uses to process SQL queries, and the tables are populated when the EXPLAIN function is invoked by you, by bind options, or by certain optimization tools. You can create one or more EXPLAIN tables that are qualified by a user ID for your own use and EXPLAIN tables that are qualified by SYSIBM.
http://www-01.ibm.com/support/knowledge ... ta?lang=en

в LUW план выглядит примерно так

Code: Select all

Access Plan:
-----------
        Total Cost:             71.3646
        Query Degree:           1

                         Rows
                        RETURN
                        (   1)
                         Cost
                          I/O
                          |
                      6.64478e-05
                        NLJOIN
                        (   2)
                        71.3646
                        42.3992
               /----------+----------\
           1.13333                 5.86304e-05
           FETCH                     FETCH
           (   3)                    (   5)
           15.1468                   47.1541
              2                      33.8817
         /---+----\                /---+----\
     1.13333       17056       21.1132      360107
     IXSCAN   TABLE: WSCOMUSR  RIDSCN   TABLE: WSCOMUSR
     (   4)      SCHCONFIG     (   6)      SCHSTATUS
     7.58191        Q1         15.1594        Q2
        1                         2
       |                         |
      17056                    21.1132
 INDEX: WSCOMUSR               SORT
    I0000321                   (   7)
       Q1                      15.159
                                  2
                                 |
                               21.1132
                               IXSCAN
                               (   8)
                               15.1559
                                  2
                                 |
                               360107
                           INDEX: WSCOMUSR
                              I0000762
                                 Q2

Что касаемо cost, то они в том что я показал выше есть. Это столбцы PROCMS, и PROCSU. Первый столбец дает costт в милисекундах (MS), второй в Service Units (SU). Обясните чем Вас не устраивают эти cost-ы?

тем что это время одного компонента, а не кост. кост это попугай, в котором учитывается процессорное время, затраты и/о, затраты памяти и миллион других вещей. Влад, это основы.

P.S. "Сырая информация" из PLAN_TABLE. Я смеюсь. Вы хоть немножко думайте прежде чeм говорить. "Отформатированная информация" - второй прикол. Если Вы не умеете читать информацию из PLAN_TABLE зaчем Вы вообще ввязываетесь в дискуссии на темы SQL tuning?

Влад, с вашими знаниями, с вашими сочинениями о проектах и должности DBA не надо лезть на ражен. изучайте команду EXPLAIN и спросите у DBA как в db2 получить графически план. я очень невысокого мнения о db2, но все таки не верю, что в 21 веке кто-то планы в командной строке готовит и читает. должны быть какие-то графические тулзы для DBA, мир Unix этот этап прошел в 90х.

[zVlad]

iDesperado, если Вы может понимать только картинки (которую я безусловно имею), то это очень многое говорит не обо мне или o DB2, а как раз наоборот - о Вас. Хотя мне с Вами уже давно все понятно и я это уже извучивал, не хочу повторятся.

Картинки, которые Вы так любите, строятся исключительно на основе "сырой" информации из PLAN_TABLE. Исключительно означает что ничего такого особого чего нет в PLAN_TABLE в картинках нет и быть не может. Если бы Вы меня спросили об информации которую я не показал в моем запросе в PLAN-TABLE, то я бы Вам с радостью эту информацию предоставил. Но Вы не знаете что спросить и поэтому переходите на личность.

Вы просто, в полном соответсвии с Вашими качествами, цепляетесь за соломинку, за любую возможность, чтобы не имея сказать ничего внятно все таки сказать какую-нибудь гадость и чушь, да еще и с выводами.

Пошлый Вы человек, iDesperado, и общаться с Вами гадко и противно.

P.S. Еще, блин, про EXPLAIN что-то говорите. А подумать каким это я чудесным образом получил информацию в PLAN_TABLE Вам чего не хватило? Ума, или храбрости, а может такого качества как порядочность? Обясните.

[iDesperado]

iDesperado, если Вы может понимать только картинки (которую я безусловно имею), то это очень многое говорит не обо мне или o DB2, а как раз наоборот - о Вас. Хотя мне с Вами уже давно все понятно и я это уже извучивал, не хочу повторятся.

если вы действительно имеете картинку, вас ни на какие мысли не навела она ? не удивило, что на картинке упорядочный граф, а не плеин таблица с записями в рандомном порядке ? что около каждой операции ее кост, информация об индексе, предикатах, количестве сортировок, процент чтений с хдд и множество других вещей ?

Пошлый Вы человек, iDesperado, и общаться с Вами гадко и противно.

гадко в вашем возрасте изображать из себя DBA, судорожно выясняя, что такое план.

[zVlad]

.....
если вы действительно имеете картинку, вас ни на какие мысли не навела она ? не удивило, что на картинке упорядочный граф, а не плеин таблица с записями в рандомном порядке ? что около каждой операции ее кост, информация об индексе, предикатах, количестве сортировок, процент чтений с хдд и множество других вещей ?
....

Я Вас когда-нибудь обманывал? Конечно имею я картинку. Почитайте на интернете про Data Studio for DB2 - вот это тот тул которым мы смотрим картинки.

Вот Вы, iDesperado, пытаетесь быть мастером навешивание разных ярлыков. Но сами даже и не замечаете как подставляетесь. Вас иногда выводят на чистую воду, но чаще машут рукой и отходят.

Вот и с картинками Вы так уперлись потому больше Вам упираться не во что, а хочется. Так что слушайте.
Представьте себе приложение с более чем тремя тысячами программ и с несколькими сотнями SQL statements в каждой и вот Вы рассматривая картинку одного SQL понимаете что нужно переделать имеющийся индекс или создать новый или Вы нашли, как Вам кажется неудачный индекс и считаете что его лучше удалить. Как Вы будете решать такую задачку? Будете смотреть на каждую из сотен тысяч возможных картинок? Сколько Вам на это время понадобится?
Что я хочу сказать. Картинка, граф конечно это хорошо чтобы понять общую картину плана доступа конкретного запроса, но чтобы сделать что-либо серьезное для всей совокупности запросов приложения картинки Вам не помогут и Вы их для этого использовать не будете.
Вот из приведенного мной примера можно увидеть индекс TIIWOTS4. У него много колонок и есть сильные сомнения что есть хотя бы один запрос среди многих сотен тысяч который бы использовал все эти колонки. А сколько максимум колонок этого индекса используется хотя бы в одном запросе? Как Вы решите такую задачу с помощью картинок? Как Вы вообще будете решать такую задачу. Подумайте, но не спешите с ответом. Я пока в ресторан съезжу - праздник сегодня. Вы кстати купель принимали сегодня?

[wassup]

я очень невысокого мнения о db2, но все таки не верю, что в 21 веке кто-то планы в командной строке готовит и читает. должны быть какие-то графические тулзы для DBA, мир Unix этот этап прошел в 90х.

wat?

Человеку который боится работать с коммандной строкой делать в администрировании нечего. В особенности в администрировании систем хранения данных.

[tengiz]

Человеку который боится работать с коммандной строкой делать в администрировании нечего. В особенности в администрировании систем хранения данных.

По-мому Вы смешиваете "набирать команды в кс" с чтением разнообразной информации в различных видах. Одно дело не боятся фигачить пальцАми на клаве, но любоваться ASCII артом в ситуации, когда картинка будет нагляднее портянки на пару тыщ строк - это совсем другое. Хотя своя прелесть в этом есть.

Code: Select all

                             ,-.
       ___,---.__          /'|`\          __,---,___
    ,-'    \`    `-.____,-'  |  `-.____,-'    //    `-.
  ,'        |           ~'\     /`~           |        `.
 /      ___//              `. ,'          ,  , \___      \
|    ,-'   `-.__   _         |        ,    __,-'   `-.    |
|   /          /\_  `   .    |    ,      _/\          \   |
\  |           \ \`-.___ \   |   / ___,-'/ /           |  /
 \  \           | `._   `\\  |  //'   _,' |           /  /
  `-.\         /'  _ `---'' , . ``---' _  `\         /,-'
     ``       /     \    ,='/ \`=.    /     \       ''
             |__   /|\_,--.,-.--,--._/|\   __|
             /  `./  \\`\ |  |  | /,//' \,'  \
            /   /     ||--+--|--+-/-|     \   \
           |   |     /'\_\_\ | /_/_/`\     |   |
            \   \__, \_     `~'     _/ .__/   /
             `-._,-'   `-._______,-'   `-._,-'

 

[iDesperado]

Я Вас когда-нибудь обманывал? Конечно имею я картинку. Почитайте на интернете про Data Studio for DB2 - вот это тот тул которым мы смотрим картинки.

да постоянно, вспомнить хотя бы историю как вы thread за cpu выдавали, после чего выяснилось, что все ваши многолетние басни следует минимум на 16 делить.

Вот Вы, iDesperado, пытаетесь быть мастером навешивание разных ярлыков. Но сами даже и не замечаете как подставляетесь. Вас иногда выводят на чистую воду, но чаще машут рукой и отходят.

боюсь вы искажаете реальность. какой топик не поднимем, везде высмеивание именно ваших познаний.

Вот и с картинками Вы так уперлись потому больше Вам упираться не во что, а хочется. Так что слушайте.

суть вовсе не в картинках, как видите с zgur мы текстовые планы выкладывали. суть в том, что информации вашего обрезка из PLAN_TABLE не хватает, что бы развернуть связанный граф и понять, какие операции запроса отняли большую часть ресурсов. психически здоровый человек не будет строить граф в уме. учитывая, что кол-во узлов графа будет больше из-за колонки MATCHCOLS во многих случаях это просто и не реально. ваш обрезок не дает большей части минимально необходимой информации, ни связей графа, ни очередности операций, ни расклада костов по операциям. т.е. у вас нет понимания, что такое план.
вы можете сколько угодно сочинять очередные басни, но то что вы не DBA и не имели дел с реальными проектами завязанными на db2 факт железобетонный. не может DBA задавать такие вопросы

Представьте себе приложение с более чем тремя тысячами программ и с несколькими сотнями SQL statements в каждой и вот Вы рассматривая картинку одного SQL понимаете что нужно переделать имеющийся индекс или создать новый или Вы нашли, как Вам кажется неудачный индекс и считаете что его лучше удалить. Как Вы будете решать такую задачку? Будете смотреть на каждую из сотен тысяч возможных картинок? Сколько Вам на это время понадобится?

p.s. "неудачный индекс, его лучше удалить" на мем претендует

[ALV00]

Не надо на db2 бочки катить. Нормальная там документация, писаная адекватными людьми. Попробуйте в гугле набрать вопрос по Oracle - вынесет на stackoverflow и форумы разные. В db2 выносит на системные доки. Это объективный показатель их качества.

[iDesperado]

Не надо на db2 бочки катить. Нормальная там документация, писаная адекватными людьми. Попробуйте в гугле набрать вопрос по Oracle - вынесет на stackoverflow и форумы разные. В db2 выносит на системные доки. Это объективный показатель их качества.

да ладно. хуже документации, чем db2 не встречал. мы помниться три дня расшифровывали доку о совместимости блокировок
viewtopic.php?f=46&t=161886&start=375#p4482681

нигде такого безобразия больше не встречал.

[mynameiszb]

Не надо на db2 бочки катить. Нормальная там документация, писаная адекватными людьми. Попробуйте в гугле набрать вопрос по Oracle - вынесет на stackoverflow и форумы разные. В db2 выносит на системные доки. Это объективный показатель их качества.

Не скажу про доки на db2, но вас не смущает, что кроме полноценной и отлично структурированной документации по Ораклу, есть еще Металинк, где под замком лежит прорва технических вещей. Правда, туда доступ лишь официальным пользователям, кто лицензию купил (хотя бы минимальную). И саппорт работает только через Металинк. И патчи только через него раздают...

Жаловаться, что на stackoverflow обсуждают Оракл - это уже из раздела юмора...

[zVlad]

Не надо на db2 бочки катить. Нормальная там документация, писаная адекватными людьми. Попробуйте в гугле набрать вопрос по Oracle - вынесет на stackoverflow и форумы разные. В db2 выносит на системные доки. Это объективный показатель их качества.

Не скажу про доки на db2, но вас не смущает, что кроме полноценной и отлично структурированной документации по Ораклу, есть еще Металинк, где под замком лежит прорва технических вещей. Правда, туда доступ лишь официальным пользователям, кто лицензию купил (хотя бы минимальную). И саппорт работает только через Металинк. И патчи только через него раздают...
...

Кстати я был пользователем Оракловского Маталинк в начале 2000-х пока у нас на МФ стояли оракловский штучки. И даже вытягивал из него патчи. Я также был и есть пользователь IBM-ского IBMLink(ServiceLink) и ShopzSeries. Без предвзятости скажу что ИБМ-вские закрытые суппорты намного лучше и богаче оракловских.

Кстати информация у IBM не лежит под замком. Даже не имея доступа к IBMLink(ServiceLink) можно находить и читать информацию о патчах и многое другое. Под замком лежат только сами патчи.