MasterZivКак-то в поледнее время гложит мысль, что cost-based оптимизатор - не обязательно есть польза.
..... если используется в том стиле, в котором привыкли использовать rule-based.

Между ними есть одна ключевая разница: rule-based держит план запроса "раз и навсегда" (если не меняется структура базы). Таким образом, его оптимизация сводится к "отпинали ногами, заставив работать по нужной схеме". И до тех пор, пока схема остается нужной - все неплохо. Cost-based, наоборот, адаптирует план к мелким вроде бы изменениям, и оптимизация сводится к тому, чтобы дать ему возможность для правильных маневров, убирая в то же время возможность для неправильных. "Отпинать ногами" с ним не работает.

Если CBO неудачен (в конкретном сервере, для конкретной задачи итп) - лучше пользоваться RBO, возможно, подключая CBO для отдельных случаев, где он даст выигрыш. Если же он хорош - надо учиться давать ему возможность принять правильное решение.

gardenmanТ.е. как правило нет гемороя с изменением планов запросов по волатильным табицам (которые часто меняют свой объем и статистику) Достаточно один раз написать запрос и он будет таким всегда. Т.е. то что в Оракле называется "стабилизацией плана запроса", или написание абстрактых планов запросов как в Sybase ASE в DB2 вообще не нужно.
Честно говоря, я пока что не сталкивался с необходимостью как раз "стабилизировать план запроса" - и у меня есть ощущение, что это сделано в основном ради тех, кто никак не перейдет с седьмой версии оракла :)

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

А, да. Если "стабилизация планов запросов" - мера, которая поможет на серверах с, назовем так, непредсказуемым администрированием. Там, где администратор относится к категории "молодых экспериментаторов", это может помочь :)

gardenmanЯ очень хочу разобраться в одном вопросе. Как часто срабатывает оптимизатор?[/q]
Это зависит от задачи. Например, в любой задаче, ориентированной на ad-hoc queries, оптимизатор может и должен срабатывать на каждый чих. С другой стороны, в обычной OLTP - когда я как-то взглянул на статистику production-а, нашел запросы с execution count в сорок-пятьдесят миллионов раз (при единственном срабатывании оптимизатора).

[quot gardenman]И имеет ли смысл засталять его срабатывать на каждый чих?
Это вопрос, на который надо давать свой ответ для каждого запроса.

gardenmanЯ, например, в этом вопросе полностью поддерживаю IBM. Пакет скомпилен, план по нему построен, и, как правило в 99,99% случаев этот план останется тем же самым, несмотря на то, что параметры запроса могут поменяться. Т.е. работа оптимизатора просто не нужна. (это операторы типа:
Давайте я отмечу два недостатка, которые вижу в этом случае по сравнению с оракловым подходом:

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

Напротив, в Oracle план редко, но перестраивается; раз в несколько недель, но подвергается пересмотру. Полагаю, раз в несколько недель переоптимизировать - копеечные затраты вообще и нулевые - по сравнению недобором скорости на каждом запросе, выполняющемся по плану нескольколетней давности.

- иногда случаются проблемы. Например, индекс может пострадать в результате сбоя на диске. При "хранимом раз и навсегда" плане это приведет к ошибке при выполнении запроса; гибкий оптимизатор просто перестроит план, исключив поврежденный индекс. Разумеется, новый план может оказаться и очень плохим - но имеет все шансы оказаться "приемлимым", и система будет работать, пока чинят индекс.

gardenmanselect * from table where id=:host_variable, - доступ чисто по индексу, или join 2-3 таблиц). Проще просто хранить уже известный план запроса.
Oracle, собственно, так и делает. Причем - в чем прелесть - я могу управлять этим процессом; если я напишу


Этот запрос будет строить план для каждого нового значения f2 (использовать гистограммы), но в то же время повторно использовать план для любого значения f1.

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


А для оставшегося 0,01% и для хранилищ данных, где хранение плана не имеет смысла - пользовать REOPT или динамический SQL.
А вообще-то я вчера присутствовал на презентации DB2. Надо признать, очень грамотно рассказывали, захотелось повозиться.

К вопросу "зачем нужно редактирование сообщений" :) Еще раз, в более читаемом формате.

gardenmanЯ очень хочу разобраться в одном вопросе. Как часто срабатывает оптимизатор?
Это зависит от задачи. Например, в любой задаче, ориентированной на ad-hoc queries, оптимизатор может и должен срабатывать на каждый чих. С другой стороны, в обычной OLTP - когда я как-то взглянул на статистику production-а, нашел запросы с execution count в сорок-пятьдесят миллионов раз (при единственном срабатывании оптимизатора).

gardenmanИ имеет ли смысл засталять его срабатывать на каждый чих?
Это вопрос, на который надо давать свой ответ для каждого запроса.

gardenmanЯ, например, в этом вопросе полностью поддерживаю IBM. Пакет скомпилен, план по нему построен, и, как правило в 99,99% случаев этот план останется тем же самым, несмотря на то, что параметры запроса могут поменяться. Т.е. работа оптимизатора просто не нужна. (это операторы типа:
Давайте я отмечу два недостатка, которые вижу в этом случае по сравнению с оракловым подходом:

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

Напротив, в Oracle план редко, но перестраивается; раз в несколько недель, но подвергается пересмотру. Полагаю, раз в несколько недель переоптимизировать - копеечные затраты вообще и нулевые - по сравнению недобором скорости на каждом запросе, выполняющемся по плану нескольколетней давности.

- иногда случаются проблемы. Например, индекс может пострадать в результате сбоя на диске. При "хранимом раз и навсегда" плане это приведет к ошибке при выполнении запроса; гибкий оптимизатор просто перестроит план, исключив поврежденный индекс. Разумеется, новый план может оказаться и очень плохим - но имеет все шансы оказаться "приемлимым", и система будет работать, пока чинят индекс.

gardenmanselect * from table where id=:host_variable, - доступ чисто по индексу, или join 2-3 таблиц). Проще просто хранить уже известный план запроса.
Oracle, собственно, так и делает. Причем - в чем прелесть - я могу управлять этим процессом; если я напишу


Этот запрос будет строить план для каждого нового значения f2 (использовать гистограммы), но в то же время повторно использовать план для любого значения f1.

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


А для оставшегося 0,01% и для хранилищ данных, где хранение плана не имеет смысла - пользовать REOPT или динамический SQL.
А вообще-то я вчера присутствовал на презентации DB2. Надо признать, очень грамотно рассказывали, захотелось повозиться.[/quot]

nkulikovЕсть такое понятие как autonomics. Который говорит как, когда, какую статистику собирать.
Насколько я понимаю, это тот самый Query Patroller, о котором ты вчера рассказывал? ;-)