ViolinaБывает ли такое, что оптимайзер заклинивает, и он упорно использует далеко не самый оптимальный план?
А как узнать в DB2 что этот план не самый оптимальный? Хинтов-то нет, чтобы вариацию попытаться сделать. М.б. поэтому DB2-ники думают, что сервер им даёт правильные планы?
NewYearпро oracle я знаю только, что там есть какие-то дурацкиe rollback-segments, которые никому не нужны
Ну Вам-то они может и не нужны...
NewYear и что при попытке откатить трарзакцию скажем, в 100 мегов он заваливается
Хто заваливается? Сервер? С core dump-ом?
_______________
Alex
There are three kinds of people: those who can count and those who can't

ViolinaЗапросы оптимайзер преобразует в некий граф с оценкой по статистики, которая всегда поддерживается в актуальном состоянии, что позволяет выбрать оптимальный план. Таким образом в шаманстве по переписыванию запросов в их более оптимальные эквиваленты попросту нет необходимости. Нужно просто написать запрос на выборку нужных данных, а отимайзер преобразует его в оптимальный внутренний эквивалент.
Опыт подсказывает (когда-то я занимался схожими алгоритмами), что при большом количестве элементов графа (неколько десятков) будет:
- возрастать неточность прогноза
либо
- возрастать время расчёта (причём нелинейно).
Это так? Т.е.:
Правильные (оптимальные) ли строятся планы для больших запросов?
ViolinaКонтраргументом был вопрос, как разработчик может знать состояние данных лучше, чем оптимайзер, если статистика всегда актуальна?
Могу привести пример: разработчик может знать, минимизация чего является целью оптимизации запроса. Либо времени отклика, либо суммарного выполнения запроса. Сервер БД про это никак сам догадаться не может
_______________
Alex
There are three kinds of people: those who can count and those who can't

Nikolay KulikovХранение блокировок в страницах имеет следствие - более высокиe требования к IO.
Не сказал бы. Всё равно блок на диск писать. Ну заодно в нём и десяток байт под "служебные нужды" поиспользовать.
Nikolay KulikovСколько времени ты тратишь на оптимизацию одного сложного запроса???
Смотря какого... ;-) У меня-то лично с Oracle-овым оптимизатором проблем нет. Мы, типа, дружим.
Если серьёзно, то с оптимизацией дело обстоит так, что если я вижу "плохой" план, то пытаюсь понять причину его выбора. Как правило, у оптимизатора на это есть какие-то основания. Если причина понятна, то пытаюсь модифицировать SQL-запрос. Вот способы:
1) Использовать exists вместо, in. И наоборот.
2) Написать выражение заведомо так, чтобы индекс не подцепился (если индекс вредит).
3) Пересмотреть принцип построения запроса.
итп.
rimanЗЫ. Объясните на пальцах, что такое хинты?
Хинты - это подсказки оптимизатору, заставляющие его использовать (или говорящие, что _не_ надо использовать) определённый путь доступа к извлечению данных.
rimanдля каждого из этих путей Optimizer выполняет определение стоимости запроса на основе имеющейся статистики, посчитать лучше человек практически не сможет.
не верю, что оптимизатор делает _полный_ перебор вариантов. Он наверняка сразу откидывает некоторые "ветки" графа как по его мнению заведомо (оптимизатора) неоптимальные. Вот тут он может ошибиться.
Кстати, это распространённое заблуждение про "мощь" оптимизатора по сравнению с человеком. Почему:
1) Оптимизатор "думает" очень мало времени.
2) Принципы мышления человека и машины отличаются...
К тому же не предлагается строить _все_ планы за оптимизатор. Речь идёт об ответственных и ресурсоёмких/частых запросах.
rimanReading rows directly from the table (dataspace scan processing)
Reading rows through an access path (using either key selection or key positioning)
Creating an access path directly from the dataspace
Creating an access path from an existing access path (index-from-index)
Using the query sort routine (if conditions are satisfied)
Стоп-стоп-стоп. Это ведь про выборку из одной таблицы? Фактически, что тут от оптимизатора требуется, так это сказать, как лезть за данными: через индекс или через полный просмотр таблицы. Интересен вопрос, когда таблиц _несколько_. Тут надо уже рассматривать различные варианты соединения таблиц и разные способы соединения... И поэтому вариантов становится настолько много, что "оценить" каждый нет возможности.
Nikolay KulikovВариацию плана можно сделать поигравшись с индексами.
А если БД производственная? Кто же разрешит "левый" индекс на БД повесить? А запрос-то нужно написать... И план знаешь, какой должен быть оптимальным... Вот только воздействовать на оптимизатор через индексы у тебя возможности нет. В Oracle это решается как раз использованием хинта.
_______________
Alex
There are three kinds of people: those who can count and those who can't

riman, мы исходим из разных посылок:
Я говорю, что все (оптимизаторы) не идеальны и поэтому должны быть какие-то "ручки" к БД для подкручивания.
Вы же исходите из понятия идеального оптимизатора. В принципе, изначальный вопрос Виолины и сводится к тому, что: настолько ли идеален оптимизатор IBM?
rimanМожет тогда администратора к БД вообще не подпускать?
Добавление к "покупной" системе лишнего индекса может разные последствия иметь:
1) Снижение производительности
2) Потеря тех. поддержки
В гос. конторах, вроде ЦБ, админ просто прав по служебным иструкциям такими вещами не имеет прав заниматься.
rimanТем более, что плохой индекс оптимизатор точно не использует для плана доступа
Мы исходим из разных посылок.
_______________
Alex
There are three kinds of people: those who can count and those who can't

rimanКак я понял Вы полагаете, что оптимизатор может выдать неверный план запроса.
Вы неправильно меня понимаете. Я полагаю, что оптимизатор может выдать неотимальный план. Вы, наверное, согласитесь, что понятия "неверный план" и "неоптимальный план" - всё-таки разные понятия. И истолковываю "неверный" как синоним слова "неосуществимый".
rimanЯ же говорю, что он показывает лучший из существующих.
Что значит "лучший"? Оптимизатор оценивает планы в неких виртуальных "попугаях" (С) Шин. Лучший в "попугаях" - возможно. Но почему можно утверждать, что этот план будет самым лучшим на работающей системе? Ведь, если действительно стремиться построить наиоптимальнейший план, то надо учитывать текущую и будущую (на неск. минут, скажем) загрузку дисков и CPU.
rimanЕсли можно написать лучше - Adviser предлагает создать новый план (здесь я не говорю, что этот новый план есть лучший), если администратор может обойтись без него - он пишет свой план. Если всё прошло удачно Adviser больше ничего не посоветует
Что это за Adviser? Виолина, похоже, им и интересуется. Что он может? Как выглядит?
_______________
Alex
There are three kinds of people: those who can count and those who can't