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