Как зафиксировать "внутренний" план выполнения у VIEW
Sergey Zaytsev
Oracle 10.2.0.3
Используется трехуровневая система с сервером приложений, базирующемся
на Oracle. В сервере приложений есть свой урезанный вариант SQL,
который транслируется в Оракловый SQL, допускающий достаточно
ограниченное количество возможностей. Единственный способ
как-то настраивать запросы - это использовать свои VIEW, с хорошо
настроенным планом выполнения. Беда в том, что когда получается
итоговый запрос, содержащий JOIN'ы с моии VIEW и Оракл начинает его
выполнять (у меня есть возможность увидеть "результирующий" запрос
к Оркаклу) весь мой вылизанный план для VIEW может изменится и
скорость выполнения катастрофически падает. Можно ли как-нибудь в плане
запроса (такие инструкции сервер приложений тоже пропускает) или при
создании VIEW сказать: все что хочешь крути, а план для запроса VIEW
не трогай!
С уважение, Сергей Зайцев.
Oleg Vershinin
> скорость выполнения катастрофически падает. Можно ли как-нибудь в плане
> запроса (такие инструкции сервер приложений тоже пропускает) или при
> создании VIEW сказать: все что хочешь крути, а план для запроса VIEW
> не трогай!
См. хинт NO_MERGE, а также прочие хинты из
B19306_01/server.102/b14211/hintsref.htm
16.1.2.3 Hints for Query Transformations
--
Oleg Vershinin
Denis Zaitsev
В ответ на твое письмо от 10 Jul 07:
SZ> запроса (такие инструкции сервер приложений тоже пропускает) или при
SZ> создании VIEW сказать: все что хочешь крути, а план для запроса VIEW
SZ> не трогай!
может глянуть в сторону outline?
Искренне ваш.
Alexander Dubrovsky
13:08, 10 Июля 2007. Ты взглянул(а) на Sergey Zaytsev и сказал(а):
А вы уверены, что умнее оптимизатора ораклового?
В 10-ке есть визарды, которые позволяют выловить долгоиграющие запросы и
оттюнить их.
Чем меньше хинтов и больше индексов, тем круче оптимизатор отрабатывает.
Только статистику по объектам и системную собирай вовремя.
Good bye Denis. [Posted by FBI pack]
Sergey Zaytsev
>> запроса (такие инструкции сервер приложений тоже пропускает) или при
>> создании VIEW сказать: все что хочешь крути, а план для запроса VIEW
>> не трогай!
OV> См. хинт NO_MERGE, а также прочие хинты из
Хинты уже практически все перепробовал, вроде помогает NO_USE_MERGE
(я так понимаю, десяточный вариант/аналог NO_MERGE), но пока уверенности
нет. Запрос вроде нормально по скорости заработал, но местами ведет себя
довольно странно...
Но все равно спасибо за совет.
С уважение, Сергей Зайцев.
Sergey Zaytsev
SZ>> создании VIEW сказать: все что хочешь крути, а план для запроса VIEW
SZ>> не трогай!
DZ> может глянуть в сторону outline?
stored outline в общем конечно вариант, только предугадать и описать
все варианты связок моего VIEW в формируемых Application-сервера, к тому-же
поймать их в рабочее время сложно, а во время тестирования всех вариантов
не просчитать :-(
С уважение, Сергей Зайцев.
Sergey Zaytsev
Не всегда, но бывает. Долгоиграющие запросы иногда ускоряю до 100 раз.
AD> В 10-ке есть визарды, которые позволяют выловить долгоиграющие запросы и
AD> оттюнить их.
Подскажите плиз где эти визарды спрятаны, буду благодарен.
AD> Чем меньше хинтов и больше индексов, тем круче оптимизатор отрабатывает.
К сожалению на хинты во VIEW он похоже порой плюет, а жаль... Создавать
индексы по каждому чиху дело неблагодарное, может стать только хуже... Да
в принципе и есть они, только оптимизатор их использовать не хочет, а
запретить использовать HASH_JOIN и использовать USE_NL почему-то не удается.
С уважение, Сергей Зайцев.
Andrey Bоgdanov
SZ> К сожалению на хинты во VIEW он похоже порой плюет, а жаль... Создавать
SZ> индексы по каждому чиху дело неблагодарное, может стать только хуже...
SZ> Да
SZ> в принципе и есть они, только оптимизатор их использовать не хочет, а
SZ> запретить использовать HASH_JOIN и использовать USE_NL почему-то не
SZ> удается.
Иногда HASH_JOIN действительно лучше, чем USE_NL. Hу а для того, чтобы понять
почему Oracle вибирает тот или иной план, полезно хотя бы один раз взять и
руками посчитать стоимость запроса по двум сравниваемым планам. Сразу станет
понятно какие параметры и где используются. И какие из них подкрутить надо.
Решайте головоломки http://diogen.h1.ru
Тарасенко И.О.
> все варианты связок моего VIEW в формируемых Application-сервера, к тому-же
> поймать их в рабочее время сложно, а во время тестирования всех вариантов
> не просчитать :-(
Разве этих связок не ограниченный набор? Все они выявляются с помощью тех
же хранимых шаблонов плана выполнения, нужно только включить их автоматическую
генерацию и прогнать полностью приложение. Плюс покрутить режим работы
оптимизатора.
Sergey Zaytsev
SZ>> индексы по каждому чиху дело неблагодарное, может стать только хуже...
SZ>> Да
SZ>> в принципе и есть они, только оптимизатор их использовать не хочет, а
SZ>> запретить использовать HASH_JOIN и использовать USE_NL почему-то не
SZ>> удается.
AB> Иногда HASH_JOIN действительно лучше, чем USE_NL. Hу а для того, чтобы
AB> понять почему Oracle вибирает тот или иной план, полезно хотя бы один раз
AB> взять и руками посчитать стоимость запроса по двум сравниваемым планам.
AB> Сразу станет понятно какие параметры и где используются. И какие из них
AB> подкрутить надо.
Про то, что HASH_JOIN бывает лучше я знаю. Но в моем конкретном случае он
НАМНОГО медленней. Возможно Оракл и считает такой вариант дешевле, но на
практике он работает в разы (десятки раз) медленнее. Так что я бы предпочел
средства, которые позволяли бы мне самому указывать план выполнения. В 10-ке
слышал появилось что-то помощнее и поудобнее outline, не подскажете, где
про это почитать можно?
С уважение, Сергей Зайцев.
Sergey Zaytsev
А хинт NO_MERGE все-таки оказался тем. что нужно. NO_USE_MERGE все равно
позволял "дробить" план VIEW, а с NO_MERGE все заработало как надо.
Большое спасибо!
С уважение, Сергей Зайцев.
Alexander Dubrovsky
12:58, 11 Июля 2007. Sergey Zaytsev взглянул(а) на меня и сказал(а):
SZ> Подскажите плиз где эти визарды спрятаны, буду благодарен.
Hу в энтерпрайз менеджере надо тыкать в адвайзерах - там в 10-ке чего только
не наворочали.
Щас не вспомню так.
Good bye Sergey. [Posted by FBI pack]