Альтернатива для OPTIMIZER_FEATURES_ENABLE
Я установил PHP-приложение на клиентском сервере 9i (Oracle9i Release 9.2.0.1.0 - 64-битная версия). Некоторые запросы имеют ужасную производительность (они могут использовать от 15 минут до часов только для расчета плана выполнения!), И я отследил проблему до значения по умолчанию OPTIMIZER_FEATURES_ENABLE параметр: значение по умолчанию для 9i 9.2.0 но клиент изменил его на 8.1.7, Когда я делаю то же самое изменение в своем блоке разработки, у меня возникают те же проблемы с производительностью.
Если бы они работали с Oracle 10 или выше, я мог бы сам изменить его для своих собственных сессий, но в 9i это статический параметр, который нужно установить для всего экземпляра. Изменение было сделано некоторое время назад, чтобы поддержать очень важную унаследованную программу. В настоящее время клиент ожидает ответа от стороннего поставщика, но у меня есть ощущение, что вероятность его изменения невелика.
Итак, каковы мои варианты, если параметр должен остаться нетронутым? Можно ли его эффекты эмулировать с другими изменяемыми настройками? Любая другая идея?
1 ответ
Вы можете попробовать другие подсказки (например, /* + RULE */), чтобы заставить оптимизатор в определенном направлении.
Но в основном вы берете очень старое программное обеспечение (и еще не исправленную / неподдерживаемую версию) и заставляете его работать как еще более старая версия. Я не могу себе представить, что на создание плана выполнения уйдут часы, поэтому звучит так, будто вы попали в ошибку (или фактически выполняете SQL и откатываетесь).
Сделать базовый план объяснения для выбора.....
Возвращаясь к этому вопросу, он использовал общую таблицу для объяснения планов, поэтому сделайте COMMIT впоследствии;
Если это не возвращается сразу же, проверьте, что происходит в v$session. Практически вся статистика таблиц и т. Д. Должна находиться в кэше, поэтому я не ожидаю, что диск будет ждать, и я не могу понять, что еще может привести к очень долгому анализу запроса.