! Хелп рост TEMP после перехода на oracle11.2.0.2
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Bard
Участник со стажем
Вступление в Клуб: 10.11.2007
|
 Пн Апр 09, 2012 10:01 ! Хелп рост TEMP после перехода на oracle11.2.0.2 |
 |
Полезность: Нет оценки
|
После перехода на Oracle 11.2.0.2 при построении 135 формы происходит взрывной рост temp до 32х гигов. После этого построение формы ломается с ошибкой что не удалось выделить экстенты.
На 10.2.0.4 форма строилась нормально. |
|
 |
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
| Пн Апр 09, 2012 10:28 |
|
Полезность: Нет оценки
|
| У какого-то тяжелого запроса изменился план не в лучшую сторону |
|
|
Bard
Участник со стажем
Вступление в Клуб: 10.11.2007
|
| Пн Апр 09, 2012 10:30 |
|
Полезность: Нет оценки
|
да запрос мы поймали какой. а вот что с ним делать?
SELECT A1.ID X, DECODE(D1.C_PR_CLASS,'DEPOSIT_ORG',1,3) SECT, A1.C_TUNINGS TUNINGS, A1.C_PRODUCT_LINK PROD, A2.C_CODE PROD_CODE, A1.C_EXCLUDE EXCLUDE, C1.ID CR, C1.CLASS_ID CLASS_ID, D1.C_NUM_DOG NUM_DOG, C1.C_CLIENT PR_CLIENT, C1.C_LIST_PLAN_PAY LIST_PLAN_PAY, C1.C_JOUR_CALC_PRC CALC_PRC, C1.C_LIST_PAY LIST_PAY, C1.C_ACCOUNT ACCOUNT, B1.ID AC, B1.C_MAIN_V_ID MAIN_V_ID, B1.C_COM_STATUS COM_STATUS, NVL(B1.C_CLIENT_R,B1.C_CLIENT_V) CLIENT, D1.C_DATE_BEGIN DATE_BEGINING, D1.C_DATE_BEGIN PROL_BEGIN, D1.C_DATE_ENDING DATE_ENDING, C1.C_FINTOOL FINTOOL, C1.C_VID_DOG VID_DOG, C1.C_NOT_USE_SUMM NOT_USE_SUMM, C1.C_NOT_USE_VAL NOT_USE_VAL, C1.C_LIST_PROL LIST_PROL, C1.C_SUMMA_DOG SUMMA_DOG, C1.C_PERIOD_CALC_PRC PERIOD_CALC_PRC, D1.C_ARRAY_DOG_ACC ARRAY_DOG_ACC, B1.C_FILIAL C_BRANCH FROM ( SELECT E1.C_DATE_BEGIN C_DATE_BEGIN, E1.C_DATE_ENDING C_DATE_ENDING, E1.C_ARRAY_DOG_ACC C_ARRAY_DOG_ACC, E1.ID PR_ID, E1.C_NUM_DOG C_NUM_DOG, ( SELECT MAX(TO_CHAR(F1.C_DATE_BEG,'yyyymmdd')||F1.C_ACCOUNT_DOG#1#2) TXT FROM Z#HOZ_OP_ACC F1 WHERE F1.COLLECTION_ID=E1.C_ARRAY_DOG_ACC AND (F1.C_DATE_BEG <= :B1 -1 AND F1.C_NAME_ACCOUNT = 9330747) ) C_PRD_ACC, E1.CLASS_ID C_PR_CLASS FROM Z#PRODUCT E1 WHERE NVL(E1.C_DATE_CLOSE,:B1 ) >= :B1 AND E1.CLASS_ID IN ('DEPOSIT_ORG','DEPOSIT_PRIV') ) D1, Z#DEPN C1, Z#ACCOUNT B2, Z#AC_FIN B1, Z#PATTERN_PRODUCT A2, Z#PATTERN_LIST A1 WHERE A1.C_PRODUCT_LINK=A2.ID(+) AND B1.ID=B2.ID AND (B1.C_FILIAL = :B2 AND B2.C_DATE_OP < :B1 AND NVL(B1.C_DATE_CLOSE,:B1 ) >= :B1 AND B1.C_MAIN_V_ID LIKE A1.C_PATTERN||'%' AND D1.PR_ID = C1.ID AND B1.ID = SUBSTR(NVL(D1.C_PRD_ACC,'19000101'||C1.C_ACCOUNT),9)) |
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
| Пн Апр 09, 2012 10:36 |
|
Полезность: Нет оценки
|
цитат из ответа поддержки по похожей проблеме
| Цитата: | > Изменение планов запросов при миграциях на новые версии СУБД Oracle – это вполне обычное дело.
> Планы запросов могут меняться как в лучшую, так и в худшую сторону.
> Происходит это по причине того, что стоимостной оптимизатор от версии
> к версии изменяется (появляются новые алгоритмы оценки стоимостного
> доступа, новые методы доступа к данным и.т.д.).
> Почему запрос при переходе на новую версию может вдруг начать выполняться медленее:
> 1) Разный способ сбора статистики
> Необходимо убедиться, что ранее (на версии 10g) вы собирали статистику
> для оптимизатора точно таким же способом, как на новой версии (11g)
> 2) Разные параметры, влияющие на оценку стоимости оптимизатором
> Необходимо убедиться, что после миграции (или в процессе миграции) не
> меняли параметры. Это могут быть как параметры, влияющие
> непосредственно на оценку стоимости, например,
> _optimizer_index_cost_adj, так и иные параметры способные косвенно
> повлиять на поведение оптимизатора.
> 3) Необходимо убедиться, что все необходимые индексы имеют статус "VALID".
> Из планов выполнения видно, что запрос начал использовать иные
> индексы. Это может быть связано с тем, что какой-то из индексов (или
> часть) по какой-то причине стали "INVALID", либо попросту
> "деградировали". Поэтому необходимо проверить наличие всех индексов, а
> также с целью устранения деградации можно попробовать перестроить
> индексы (естественно, что перестраивать индексы необходимо внерабочее
> время)
>
> Таким образом, причин, по которой планы запросов могут различаться много.
> В качестве быстрого решения проблемы можно попробовать воспользоваться
> SQL Advisor. Может быть, что sql advisor сможет предложить более
> лучший план выполнения или даст какие-то рекомендации (естественно,
> что перед тем как выполнять такие действия на боевой базе
> рекомендуется сначала это выполнить на тестовой).
>
> По поводу рекомендаций "переноса" планов выполнения:
> В случае, если вы желаете заставить оптимизатор Oracle думать как
> раньше, вы можете воспользоваться параметром
> optimizer_features_enables. Т.е. вы можете установить значение этого
> параметра, например, в 10.2.0.4 и таким образом заставите оптимизатор
> вычислять стоимость как ранее.
>
> Вообще при переходе на новые версии, мы всегда рекомендуем проделывать
> это на тестовых схемах – выявлять и оптимизировать возникшие узкие
> места запросов и после этого уже переходить на боевом.
|
|
|
|
Bard
Участник со стажем
Вступление в Клуб: 10.11.2007
|
| Пн Апр 09, 2012 12:19 |
|
Полезность: Нет оценки
|
optimizer_features_enables=10.2.0.4
и сбор статистики по схеме Ibs не помог... |
|
|
prog
Эксперт
Вступление в Клуб: 03.03.2008
|
| Пн Апр 09, 2012 12:35 |
|
Полезность: Нет оценки
|
Таким образом, причин, по которой планы запросов могут различаться много.
В качестве быстрого решения проблемы можно попробовать воспользоваться
SQL Advisor |
|
|
Bard
Участник со стажем
Вступление в Клуб: 10.11.2007
|
| Пн Апр 09, 2012 13:05 |
|
Полезность: Нет оценки
|
| prog пишет: | Таким образом, причин, по которой планы запросов могут различаться много.
В качестве быстрого решения проблемы можно попробовать воспользоваться
SQL Advisor |
Как им пользоваться, в двух словах если можно.
Ни разу не трогали. |
|
|
Alkov
Профи
Вступление в Клуб: 23.09.2010
|
| Ср Апр 11, 2012 05:38 |
|
Полезность: Нет оценки
|
Статистику по словарю пересобирали ?
Посмотрите план на 11g и на старой схеме 10g, можно попробовать хинтами привести план к нужному.
SQL Advisor выдаст достаточно общие советы вроде как такой индекс не используется потому-то или по вот этому полю желательно построить индекс...хотя план он обычно предлагает с меньшим костом, но не всегда оптимальный. |
|
|
Serj
Профи
Вступление в Клуб: 02.08.2007
|
| Пн Апр 16, 2012 05:40 |
|
Полезность: Нет оценки
|
| optimizer_index_cost_adj =3 и посмотрите как поведет себя запрос |
|
|
Bard
Участник со стажем
Вступление в Клуб: 10.11.2007
|
| Чт Апр 19, 2012 09:34 |
|
Полезность: 1
|
Всем спасибо за ответы.
Проблема решена.
Дело оказалась в курсоре библиотеки CLC_DEPN_001.
Мы прогнали через оптимизатор запросов от TOAD.
Оптимизатор показал как видоизменить запрос(не хватало соединения между таблицами)
ЦФТ признало ошибку и предоставило исправленное хранилище, более того проблема с этим курсором была не только у нас видимо...
Проблема актуальна только для 11.19 |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
