Исх. данные:
1. есть вью, состоящая из 20-ти юнион запросов к 20-ти таблицам
2. таблицы во вью со временем добавляются (т.е. еще плюсуются union all селекты)
3. к этой вьюшке есть запрос, который может использовать один из двух индексов этих 20-ти таблиц (в зависимости от входных параметров)

Проблема:
Запрос из п.3 работает быстро (в пределах секунды), но только если выполняется часто, после паузы например 3-5мин, первый старт запроса будет висеть секунд 5 и более.
Трассировку не сделать, но большое подозрение, что основное время первого запуска идет на построение плана.

Вопросы:
1. Если много времени тратится на полный разбор запроса, решает ли проблему фиксация плана (так понимаю, что должна бы))
2. Целесообразно ли фиксировать план отдельно для каждого подзапроса вьюшки или лучше фиксировать уже целиком для запроса, который обращается к вьюшке? Особенно учитывая, что вьюшка будет меняться (в ней могут добавляться/удаляться подзапросы)
3. Если для одного запроса может быть два разных плана в зависимости от параметров (т.е. может использоваться либо один, либо другой индекс), можно пофиксить два плана для запроса и оракл будет сам выбирать, но только из этих двух планов
или лучше сделать два отдельных запроса и запускать каждый отдельно в зав. от вх. параметров и соответственно для каждого запроса пофиксить свой план.?

vox22Скорее всего, повторные запросы у вас работают быстро из-за кэширования.
Фиксируют план для того чтобы неожиданно не получить неудачный, это не ваш случай.
Кэширование это понятно, но быстро они работают с разными значениями вх. параметров, на достаточно больших объемах с очень небольшой общей выборкой из этой массы (единицы из десятков миллионов)
т.е. речь не о том, что данные достаются из кэша, поэтому когда подряд, то работает быстрее.
Понятно и то, что фиксируют, чтобы план не соскочил, но вопрос в том числе и в том, помогает ли фикс плана ощутимо сократить время разбора запроса, если например его план вытесняется из кэша?

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