CftClub.ru
Клуб специалистов ЦФТ-Банк

! Хелп рост TEMP после перехода на oracle11.2.0.2

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
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
СообщениеПн Апр 09, 2012 10:34    Ответить с цитатой
Полезность: Нет оценки
Тут писали про тормоза в 11g

http://www.cftclub.ru/viewtopic.php?t=1785&postdays=0&postorder=asc&start=60
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
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru