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

Увеличение числа разборов после перехода на Oracle 11g
На страницу 1, 2  След.
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеПт Янв 13, 2012 12:56   Увеличение числа разборов после перехода на Oracle 11g Ответить с цитатой
Полезность: Нет оценки
Здравствуйте!

Перешли на Oracle 11g и сразу после перехода столкнулись с одной проблемой: очень сильно увеличилось число разборов.

В 10-ке параметр "Execute to Parse %" был порядка 99%, после перехода на 11g он упал до 80%. После flush shared_pool переразборов не происходит до тех пор, пока shared pool не заполнится. Не помогло увеличение shared pool почти в 2 раза по сравнению с 10-й.

Кто-нибудь еще столкнулся с такой проблемой? Нашли какое-нибудь решение?

Заранее спасибо за информацию!
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеПт Янв 13, 2012 13:00    Ответить с цитатой
Полезность: Нет оценки
гм, hard parse или soft parse ? Потестируйте
_optimizer_use_feedback = false
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеПт Янв 13, 2012 13:38    Ответить с цитатой
Полезность: Нет оценки
Уже пробовал. Не помогает.

Soft parses
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеСб Янв 14, 2012 06:15    Ответить с цитатой
Полезность: Нет оценки
cursor_sharing - чему равен?
У нас на 11.2.0.3 примерно как и было (на 10G - 98.7) тут чуть меньше
Execute to Parse %: 97.85

Еще вот это по-тестите - помогает несколько снизить количество частичных раборов
_OPTIM_PEEK_USER_BINDS=false
_OPTIMIZER_EXTENDED_CURSOR_SHARING_REL = NONE
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеПн Янв 16, 2012 11:14    Ответить с цитатой
Полезность: Нет оценки
Это я тоже пробовал. Перешли уже 3 месяца назад и за это время я успел перепробовать много всего. Нельзя сказать, что работать просто невозможно, но база все равно здорово притормаживает из-за этого. А на какой платформе работаете вы? Мы на AIX 5.3
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеПн Янв 16, 2012 12:06    Ответить с цитатой
Полезность: Нет оценки
Solaris 10/09 SPARC, думаю причина софт парсинга кроется не в платформе - что то заставляет СВО активно парсить запросы - софт парсинг происходит когда многократно используется уже разобранный (распарсенный) курсор, по идее cursor_sharing все таки должен влиять на это у меня выставлено

cursor_sharing=force
_optimizer_use_feedback = false
_OPTIM_PEEK_USER_BINDS=false
_OPTIMIZER_EXTENDED_CURSOR_SHARING_REL = NONE
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеПн Янв 16, 2012 13:11    Ответить с цитатой
Полезность: Нет оценки
Спасибо!
И так тоже пробовал, еще раз проверил, не помогает....((
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеПн Янв 16, 2012 13:43    Ответить с цитатой
Полезность: Нет оценки
Как собирается статистика на схеме? В течении дня собирается ? Системная статистика собрана ? Стандартный job сбора статистики работает?
Может ссылка что подскажет?

http://www.pythian.com/news/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms/
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеВт Янв 17, 2012 11:16    Ответить с цитатой
Полезность: Нет оценки
Каждую ночь, в 4:00, на уровне операционной системы, запускается shell-скрипт, который запускает следующие процедуры:

EXEC dbms_stats.gather_schema_stats('IBS',Degree=>4,Cascade=>true,method_opt=>'FOR ALL COLUMNS SIZE 1');
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS(degree=>4);
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(NULL);

На сбор статистики уходит менее 4-х часов.

На уровне Oracle Scheduler GATHER_STATS_JOB в состоянии DISABLE. Т.е. статистику статистику собирает только shell-скрипт.

Спасибо за ссылку! Проработаю этот вариант.
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеВт Янв 17, 2012 11:35    Ответить с цитатой
Полезность: Нет оценки
altuns пишет:
Каждую ночь, в 4:00, на уровне операционной системы, запускается shell-скрипт, который запускает следующие процедуры:

EXEC dbms_stats.gather_schema_stats('IBS',Degree=>4,Cascade=>true,method_opt=>'FOR ALL COLUMNS SIZE 1');
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS(degree=>4);
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(NULL);

На сбор статистики уходит менее 4-х часов.

На уровне Oracle Scheduler GATHER_STATS_JOB в состоянии DISABLE. Т.е. статистику статистику собирает только shell-скрипт.

Спасибо за ссылку! Проработаю этот вариант.

EXEC DBMS_STATS.GATHER_DICTIONARY_STATS(degree=>4);
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(NULL); - это лишнее, единожды собранная статистика по словарю будет самодостаточной. У вас скольки ядерный сервер ? По-пробуйте поставить degree=кол-во ядер/2 , по крайней мере для SPARC 64 VII такой подход у нас позволил собирать статистику по схеме IBS за 1:10 , размер MAIN_DOCUM в Гб
Код:
select blocks*8/1024/1024 from all_tables where table_name='Z#MAIN_DOCUM';

BLOCKS*8/1024/1024
------------------
        10.0651398
- сама база занимает 210 Гб. Еще можно попробовать чистить shared_pool после окончания сбора статистики, при излишне раздутом пуле помогает избавится от тормозов - было такое на 10-ке когда использовали AMM, потом отказались - shared_pool слишком раздувается. [/quote]
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеСр Янв 18, 2012 06:08    Ответить с цитатой
Полезность: Нет оценки
У нас 8 ядер, так что мы как раз и используем половину. Но база более чем в два раза больше вашей. У нас только схема IBS весит 214GB.

Гистограмм в схеме IBS нет. BIND PEEKING в любом случае отключен.

Все-таки у меня есть подозрение, что дело в платформе. На Metalink есть пару слов об этом, не знаю мой ли это случай, но ни Workaround, ни bugfix нет. Пробую развернуть ИБСО на SPARC и посмотреть, повторится ли проблема там.
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеСр Янв 18, 2012 06:42    Ответить с цитатой
Полезность: Нет оценки
Моя теория не подтвердилась, но зато смотрите, что получается.

Тестовая площадка: Сервер SPARC Solaris 10/09. Есть две базы 10.2.0.4, 11.2.0.2. Обе базы – копии рабочей IBSO за разные периоды времени. Настройки памяти абсолютно одинаковые.

С боевой базы я выловил SQL statements, у которого executes примерно равно parse_calls. Таких выражений достаточно много.

SELECT TO_CHAR(NVL(A2.C_NE_SUMM,0)) FROM Z#DOC_TO_OFF A2, Z#DOC_CARD_INDEX A1 WHERE A1.C_DOCS_OFF=A2.COLLECTION_ID AND (A2.C_MAIN_DOC = :B1 )

Написал PL/SQL программу и прогнал ее на обеих базах:

declare
i number;
stmt constant varchar2(200) := 'SELECT TO_CHAR(NVL(A2.C_NE_SUMM,0)) FROM Z#DOC_TO_OFF A2, Z#DOC_CARD_INDEX A1 WHERE A1.C_DOCS_OFF=A2.COLLECTION_ID AND (A2.C_MAIN_DOC = :B1 )';
begin
for i in 1..10000 loop
execute immediate stmt using 172530243;
execute immediate stmt using 172530244;
execute immediate stmt using 172530245;
execute immediate stmt using 172530246;
execute immediate stmt using 172530247;
execute immediate stmt using 172530248;
execute immediate stmt using 172530249;
execute immediate stmt using 172530250;
end loop;
end;
/

Результаты следующие

10g:

Executions=80000
Parse_calls=19

11g:

Executions=80000
Parse_calls=80000
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеСр Янв 18, 2012 09:09    Ответить с цитатой
Полезность: Нет оценки
Как вариант брать часто парсимые запросы, пробовать привязать к ним планы через baseline обязательно- fixed=YES, уж это точно должно помочь.
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеСр Янв 18, 2012 09:18    Ответить с цитатой
Полезность: Нет оценки
altuns пишет:
Моя теория не подтвердилась, но зато смотрите, что получается.

Тестовая площадка: Сервер SPARC Solaris 10/09. Есть две базы 10.2.0.4, 11.2.0.2. Обе базы – копии рабочей IBSO за разные периоды времени. Настройки памяти абсолютно одинаковые.

С боевой базы я выловил SQL statements, у которого executes примерно равно parse_calls. Таких выражений достаточно много.

SKIP

Результаты следующие

10g:

Executions=80000
Parse_calls=19

11g:

Executions=80000
Parse_calls=80000
- еще бы прогнать на 11g с OPTIMIZER_FEATURES_ENABLE =10.2.0.4
altuns
Участник
Неподтвержденный


Вступление в Клуб: 30.12.2011
СообщениеСр Янв 18, 2012 09:52    Ответить с цитатой
Полезность: Нет оценки
OPTIMIZER_FEATURES_ENABLE ситуацию не изменило.

Привязывать Baseline я уже пробовал – тоже не помогает. В любом случае baseline избавляет нас только от hard parses, а здесь soft parses. Не стоит забывать, что у вас 11.2.0.3, а у нас 11.2.0.2. Попробую выискать ресурсы, чтобы прокачать тестовую базу ИБСО до 11.2.0.3 и посмотреть, что из этого получится.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
На страницу 1, 2  След.
Страница 1 из 2

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