to Nikolay

Насколько я знаю в 8.2 будет вещь сходная с HINTS только с моей точки зрения реализованная более красиво. Optimization profiles. Некоторый XML документ сужающий для оптимизатора список возможных вариантов оптимизации.

А эти profiles они для базы в целом или для отдельных запросов?

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

Если же для отдельных запросов, то это те же хинты.

to Gt.

Gtбыло бы наивно считать что ИБМ создала универсальный оптимизатор ...

Разумеется. Но определенных успехов судя по всему он достиг. Как я уже сказала

Violina Создать точную картину как это на самом деле можно конечно, только действительно реально поработав с DB2.

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

Да, это еще один пример наряду с first_rows, all_rows когда только dba может знать чего требуется. Но никто не говорит об "устранении" dba. Речь идет о том, чтобы

пользователь указал только то, какие данные ему желательно получить, оставляя на долю оптимизатора запросов РСУБД принятие трудного решения о том, как лучше всего получить доступ к данным и обработать их.

без необходимости шаманства с хинтами и переписыванием запросов.

to Gt.

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

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

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


Это я уже озвучивала:)

Изначально хинты позиционировались как средство, к которому следует прибегать в виде исключения, чтобы "подтолкнуть" оптимайзер. Но их использование стало скорее нормой

to Nikolay

уровень оптимизации could be defined for _each_ query


В таком случае, я тоже считаю что такая реализация более красивая чем хинты. То что хинты находятся "в теле" самого запроса, ИМХО, не есть гут.

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

В таком случае нужно взять абсолютно идентичный текст запроса, например из трейс файла и, меняя установки отпимайзера, собрав статиску, получить его выполнение по желаемому плану. Потом можно создать для этого запроса outline, которая будуче включенной, заставит сервер выполнять такой запрос по тому плану, зафиксированному в outline.

Было бы классно, ИМХО, если бы хинты /или скажем нейтрально доп. информация:)/ не писались в самом запросе, а могли прикрепляться к нему DBA по усмотрению. Таким образом было бы четкое разделение

- чисто декларативный стейтмент, какие данные нужно получить. Его пишет программер в своем коде.
- отдельно прикрепленные хинты (доп. информация). Программер поставляет свой начальный вариант, который в данный момент выверен и обеспечивает хороший план выполения. А DBA может в последствии их изменить, если возникнет необходимость.

Но будет что-то типа если в запросе участвует такая-то таблица повышается приоритетность таких-то индексов.

А вот здесь я считаю что все же было бы лучше давать возможность напрямую сказать USE THAT INDEX IF IT IS POSSIBLE как например в Oracle. А то вроде как получается средство управления наподобие. Непосредсвенно руками руль крутить нельзя, а можно лишь дергая за веревочки, привязанные к нему.

to Nikolay

Для понимания как работает DB2 наверное лучше почитать сначала


Да, наверное:) Потому что здесь

Или же воспоьзоваться утилитами преобразовать dynamic (некоторую часть) в static и опять же увеличить уровень оптимизации.


ни чё не поняла, особенно про уровень оптимизаци.

to ggvP-882148

if the lack of hint is so critical it is a reason to use something else, not db2.


Так ребром вопрос не стоял:) Просто интересно было узнать из первых рук, действительно ли оптимайзер может обходиться без подсказок DBA для выбора эффективных планов выполнения. И насколько он преуспел в этом начинании.

to stdio

stdiobecause it's not according relation model, read what Violina wrote

Думаю, что Виолина ошиблась.

Я не говорила что it is not according relation model. :) Я не могу ни подтвердить, ни опровергнуть сиё утверждение:)

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

Именно такая мысль содержалась в высказанной мною идее, см.

Violina wrote
Было бы классно, ИМХО, если бы хинты /или скажем нейтрально доп. информация:)/ не писались в самом запросе, а могли прикрепляться к нему "сбоку" по усмотрению. Таким образом было бы четкое разделение

- чисто декларативный стейтмент, какие данные нужно получить. Его пишет программер в своем коде.
- отдельно прикрепленные хинты (доп. информация). Программер поставляет свой начальный вариант, который в данный момент выверен и обеспечивает хороший план выполения. А DBA может в последствии их изменить, если возникнет необходимость.

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