Здравствуйте, зиг, Вы писали:

зиг>Внимание, опубликую и запрос и ПЛАН сразу. хрен вам они помогут только гагага.
Довольно интересное отношение к аудитории. Попробую ответить в том же ключе.

зиг>Итак, проблема следующая. есть Запрос, который работает медленно если в первый раз запускаешь. Вторые и последующие запуски (даже с изменением параметров запроса) уже более-менее быстрые — то есть видать что-то там оракл кладет в кэш. Хотелось бы чтоб запрос работал более стабильно!

Внезапно, для таких убогих запросов так быть и должно.

Для тех, кто одарён ничего не знает о СУБД:
Когда СУБД получает запрос на SQL она не знает что с ним делать — может у вас есть индексы, может вы выбираете 100% записей из таблиц и т.д. Что бы понять, как оптимальным образом применить ресурсы сервера к именно вашим данным (ориентируясь на структуру запроса, статистики, структуру данных) СУБД строит кучу планов запросов соответствующих вашему SQL запросу и пытается найти наилучший из них. Прекращается это действо когда он найден (если запрос нормальный) или по таймауту (если запрос как выше + примерно тоже в структуре таблиц) когда найден квази оптимальный план. Когда вы выполняете запрос повторно, хотя возможно и с другими данными — наилучший план запроса уже найден и если он подходит (нет кардинальных отличий в селективности) то используется. Поэтому первый запрос выполняется медленней последующих.

Другой вопрос, что у нормальных DBA при вменяемых данных и запросах такого не происходит, поскольку число потенциальных планов мало ==> их перебор оказываться незаметен.

Как решить: проанализировать, на чем спотыкается оптимизатор и:
1. Упростить запрос (выше пример давали) сохранив его суть.
2. Добавить метаданные (индексы, статистику и т.д.) — кто его знает, что у вас в базе твориться
3. Добавить хинты (не ваш случай)
4. Обносить статистики
5. Прочитать наконец то книжку Тома Кайта.

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

Здравствуйте, зиг, Вы писали:

зиг>Внимание, опубликую и запрос и ПЛАН сразу. хрен вам они помогут только гагага.
Довольно интересное отношение к аудитории. Попробую ответить в том же ключе.

зиг>Итак, проблема следующая. есть Запрос, который работает медленно если в первый раз запускаешь. Вторые и последующие запуски (даже с изменением параметров запроса) уже более-менее быстрые — то есть видать что-то там оракл кладет в кэш. Хотелось бы чтоб запрос работал более стабильно!

Внезапно, для таких убогих запросов так быть и должно.

Для тех, кто одарён ничего не знает о СУБД:
Когда СУБД получает запрос на SQL она не знает что с ним делать — может у вас есть индексы, может вы выбираете 100% записей из таблиц и т.д. Что бы понять, как оптимальным образом применить ресурсы сервера к именно вашим данным (ориентируясь на структуру запроса, статистики, структуру данных) СУБД строит кучу планов запросов соответствующих вашему SQL запросу и пытается найти наилучший из них. Прекращается это действо когда он найден (если запрос нормальный) или по таймауту (если запрос как выше + примерно тоже в структуре таблиц) когда найден квази оптимальный план. Когда вы выполняете запрос повторно, хотя возможно и с другими данными — наилучший план запроса уже найден и если он подходит (нет кардинальных отличий в селективности) то используется. Поэтому первый запрос выполняется медленней последующих.

Другой вопрос, что у нормальных DBA при вменяемых данных и запросах такого не происходит, поскольку число потенциальных планов мало ==> их перебор оказываться незаметен.

Как решить: проанализировать, на чем спотыкается оптимизатор и:
1. Упростить запрос (выше пример давали) сохранив его суть.
2. Добавить метаданные (индексы, статистику и т.д.) — кто его знает, что у вас в базе твориться
3. Добавить хинты (не ваш случай)
4. Обновить статистики
5. Прочитать наконец то книжку Тома Кайта.

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