Комментарии 12
Мне кажется если сбор статистики отключить, то получим +100% к производительности, а то и больше.
есть вопрос. а есть какие-то методы борьбы с меняющейся скоростью дисковой полки? я так понимаю скорость доступа к hdd это системная статистика, собирается в момент старта истанса, когда нагрузка на полку с других систем минимальна. а потом я наблюдаю печальку. оптимизатор выбирает нестед луп, рассчитывая на скорость простаивающей полки, а реально там в час пик скорость ниже плинтуса.
может есть какие-то методы борбы с этим?
может есть какие-то методы борбы с этим?
Да, конечно, по идее вы должны откалибровать IO именно в момент высокой нагрузки: I/O Calibration
Однако, это не всегда нужно, т.к. по дефолту оракл выставляет достаточно адекватные статистики, ну и, конечно, проверяйте свою на баги калибровки перед тем как ее запустить, т.к. я помню на старых версиях была баг с занижением в 1000 раз.
Однако, это не всегда нужно, т.к. по дефолту оракл выставляет достаточно адекватные статистики, ну и, конечно, проверяйте свою на баги калибровки перед тем как ее запустить, т.к. я помню на старых версиях была баг с занижением в 1000 раз.
У вас в скрипте баг"
[Error] Execution (87: 14): ORA-19202: Возникла ошибка при обработке XML
ORA-01489: результат строковой конкатенации слишком велик
ORA-06512: на «SYS.XMLTYPE», line 343
ORA-06512: на line 1"
[Error] Execution (87: 14): ORA-19202: Возникла ошибка при обработке XML
ORA-01489: результат строковой конкатенации слишком велик
ORA-06512: на «SYS.XMLTYPE», line 343
ORA-06512: на line 1"
Видимо, у вас у какого-то запроса очень длинные или необычные предикаты. Какая, кстати, версия оракла? Можете создать табличку
экспортнуть ее и отправить мне ее на почту? Тогда я смог бы пофиксить это
create table temp_sql_plan as select * from v$sql_plan;экспортнуть ее и отправить мне ее на почту? Тогда я смог бы пофиксить это
Версия 12.2.0.1, могу, отправил в ЛС.
Проверьте вот этот запрос, пожалуйста: gist.github.com/xtender/fe7a1d8c0dff83fe886cb1de95a436bc
У меня та же самая ошибка, решил фильтром на длину предиктов в самом нижнем подзапросе:
С боевой прома не могу отправить, по соображению безопасности, вьюху, но пару строк об которые ломаются копья пришлю сейчас в ЛС.
Select 1
from v$active_session_history h
,v$sql_plan p
Where --пропускаем
(length(ACCESS_PREDICATES) < 2000
or length(FILTER_PREDICATES) < 2000)С боевой прома не могу отправить, по соображению безопасности, вьюху, но пару строк об которые ломаются копья пришлю сейчас в ЛС.
Да, увидел старую проблему с разворачиванием ID IN (1,2...,N) в кучу ID=1 or ID=2 or ID=3…
Попробуйте вот этот код с фиксом: gist.github.com/xtender/fe7a1d8c0dff83fe886cb1de95a436bc
Попробуйте вот этот код с фиксом: gist.github.com/xtender/fe7a1d8c0dff83fe886cb1de95a436bc
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Performance tuning and troubleshooting баз данных в наши дни