Читал доку, но на некоторые вопросы ответы не нашел.

Как происходит эволюция, т.е. превращение бейзлайна из not-accepted в accepted? В доке написано, что для этого оракл запускает запрос с двумя планами и сравнивает их производительность. Вопрос

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

kinky cat,

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

kinky catValergrad,
авторкатегорически не согласен. Кост нового плана будет конечно всегда меньше, иначе он и не попадет в бейзлайны.
С чего ты взял ? Пруф? Для чего evolve task по твоему ? Да и зачем сранивать cost на ходу с разными биндами ?

Какой тебе нужен пруф? Почитай немножко про бэйзлайны и вопрос отпадет.

Или можно попробовать немножко подумать. Если бы процесс эволюции смотрел только на кост - то в нем никакого смысла не было бы. План с минимальным костом прекрасно выбирается CBO во время хардпарса, никаких дополнительных надстроек для и эволюшен тасок не нужно.

Давай я объясню на примере. Представь, что впервые ( на самом деле второй раз, бейзлайны начинают работать для запросов выполняющихся хотя бы два раза) выполняется запрос и у оптимизатор нашел план A с костом, скажем, 500. Этот план попадает в бейзлайны. Т.к. он первый - он будет accepted и будет все время выполняться.

Дальше ситуация изменилась - например мы создали индекс на таблицу из запроса. В следующий раз при хард парсе план A все еще валиден, но еще есть план B, использующий индекс. Если у этого плана будет кост больше, скажем, 800 - то ни в какие бейзлайны он, конечно же не попадет, CBO сам его забракует и возьмет план A. Но если у него кост меньше, скажем, 100, то он попадет в бейзлайны, но будет неаццепед.
Таким образом в обоих вариантах при следующем выполнении будет использоваться план A, но но если у B кост меньше, то он еще попадет в бейзлайны. Правда пока не будет использоваться, пока либо ручная таска, либо в 12с автоматическая, не заверифицирует его и не признает валидным. И именно о деталях этой верификации я и расспрашиваю.

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

А смысл бейзлайна как раз в том, что иногда низкий кост не отражает хороший план. Если из ниоткуда появился новый план с маленьким костом - это часто подозрительно. Например, низкий кост наилучшего плана может быть потому, что кто-то забыл собрать статистику у новой партиции и кардиналити ключевой таблицы внезапно стало 1. Таким образом план B - который по-прежнему с наименьшим костом из возможных - так же попадет в бейзлайны, он так же будет неаццептед, но только он будет забракован эволвинг таской в момент верификации и никогда не станет аццептед.

Ты же сам мне скинул цитату в которой ясно написано:

авторVerification is the process of comparing the execution performances of the nonaccepted plan
and the best accepted plan (plan with the lowest cost). The execution is performed using the conditions (e.g., bind values, parameters, etc.) in effect at the time the unaccepted plan was added to the SQL plan baseline.


"execution performances ". Для этого, собственно должен быть execution. Более того, ты можешь запустить эволвинг таску для какого-то sql, и собственноручно убедиться что в репорте фигурирует время в секундах ( elapsed и cpu), буфер гетсы, и disk writes. Это опять же четко говорит о том, что запросы выполнялись реально, просто наблюдая за планами такую информацию никак не получить.

На всякий случай, если слова в доке
"execution performance" вам кажется недостаточно явно указывают на "execution", то вот цитата из Антогнини где это расписано немножко лучше:

автор To verify whether one of the nonaccepted execution plans will in fact perform better than the ones generated with the help of accepted SQL plan baselines, an evolution must be attempted. This is nothing other than asking the query optimizer to run the SQL statement with different execution plans and finding out whether a nonaccepted SQL plan baseline will lead to better performance than an accepted one. If this is in fact the case, the nonaccepted SQL plan baseline is set to accepted.

Полагаю, хотя бы фраза "run the SQL statement" читается однозначно?

xtender,

спасибо, как обычно!
Жаль нет доступа к sys.sqlobj$auxdata, SQLOBJ$DATA и SQLOBJ$. Но хотя бы знаю, что хинты хранятся там.
А как разрешается вопрос с темповыми таблицами и другими трики кейсами вы не знаете? К сожалению не могу проверить на работе, т.к. нет прав на execute evolve процедуры.

Если конкретно: у нас в базе включены автоматический захват и использование бейзлайнов, но нет автоматического механизма эволюции. Нужно аргументированно, с цифрами обосновать отчего это плохо.

kinky catValergrad,
Valergradkinky cat,

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

Зачем спрашивать на форуме, чтоб потом яро отстаивать свои измышления ?


Чего это они auto captured с большим cost ? Неувязочка товарисч ?

Так вы покажите запрос, планы, подсмотренные бинды, ддл объектов и их статистику - и я вам отвечу на ваш вопрос. А телепатов, извините, на форуме не присутствует. То, что такое в принципе возможно - это очевидно. Вы что, правда никогда не видели как кост плана пляшет от значений биндов? Или как кост плана пляшет от статистики? Т.е. например кост первого плана был меньше на том наборе биндов, но на этом наборе - он больше. Или кост первого плана был меньше на момент попадания в бейзлайны, но теперь-то он уже может быть больше. Или первый план стал невалидным по какой-то причине. Миллион возможных причин.

И да, вы на мои вопросы так и не ответили. Откуда эволвинг таска берет cpu_elapsed_time и disk_reads если она не запускает запрос? Зачем оракл документации и уважаемым людям вроде Антогнини писать об execution если его нет?

AlexFF__|ValergradИ да, вы на мои вопросы так и не ответили. Откуда эволвинг таска берет cpu_elapsed_time и disk_reads если она не запускает запрос? Зачем оракл документации и уважаемым людям вроде Антогнини писать об execution если его нет?
Заканчивайте уже.
kinky cat облажался с выполнением запросов при эволюции, ты - с "Кост нового плана будет конечно всегда меньше, иначе он и не попадет в бейзлайны".
Вам обоим нечем гордится.

Естественно, я понимаю, что кост будет не всегда меньше старого - что возможны исключения, о которых я тремя комментами выше и написал. Так категорично было написано только для того, чтобы объяснить коту что смотреть на кост нет особого смысла, т.к. CBO уже на него посмотрел. Иногда, знаете, достает писать всюду "почти всегда", "почти наверное", "в большинстве случае", "в нормальной ситуации" и подобное - в разговоре об оракле это придется писать "почти наверное" в каждом предложении.

kinky cat , а у вас 12-й оракл? Или 11-й оракл, до ДБА настроил эволвинг? Если есть права на SPM, то можно самому провести простейший эксперимент: запустить запрос дважды, создать более удобный индекс, запустить запрос еще раз, запустить эволюшен таску и оттрассировать ее. Я бы давно это сделал, но у меня недостает прав на рабочем энве.

kinky catValergrad,

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

Как раз правило есть: CBO при хардпарсе выбирает всегда план с наименьшей стоимостью из доступных ( и из этого правила уже есть исключения, типа max_permutations и т.д. и т.п. )
И дальше уже компонент отвечающия за бейзлайны смотрит - а accepted этот план или нет? а fixed ли он? Можно было бы подумать, что
гораздо эффективней было бы сначала посмореть какие планы у нас accepted, а уже потом делать перебор тысяч различных планов - но Oracle сделал по-другому, на что еще Льюис жаловался.

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

Единственное полезное сообщение было от xtender, он показал, где хранятся бинды с которыми вызывается запрос при верификации.