CftClub.ru

[altuns]

Здравствуйте!

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

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

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

Заранее спасибо за информацию!

[Serj]

гм, hard parse или soft parse ? Потестируйте
_optimizer_use_feedback = false

[altuns]

Уже пробовал. Не помогает.

Soft parses

[Serj]

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]

Это я тоже пробовал. Перешли уже 3 месяца назад и за это время я успел перепробовать много всего. Нельзя сказать, что работать просто невозможно, но база все равно здорово притормаживает из-за этого. А на какой платформе работаете вы? Мы на AIX 5.3

[Serj]

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]

Спасибо!
И так тоже пробовал, еще раз проверил, не помогает....((

[Serj]

Как собирается статистика на схеме? В течении дня собирается ? Системная статистика собрана ? Стандартный job сбора статистики работает?
Может ссылка что подскажет?

http://www.pythian.com/news/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms/

[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-скрипт.

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

[Serj]

[altuns]

У нас 8 ядер, так что мы как раз и используем половину. Но база более чем в два раза больше вашей. У нас только схема IBS весит 214GB.

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

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

[altuns]

Моя теория не подтвердилась, но зато смотрите, что получается.

Тестовая площадка: Сервер 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]

Как вариант брать часто парсимые запросы, пробовать привязать к ним планы через baseline обязательно- fixed=YES, уж это точно должно помочь.

[Serj]

[altuns]

OPTIMIZER_FEATURES_ENABLE ситуацию не изменило.

Привязывать Baseline я уже пробовал – тоже не помогает. В любом случае baseline избавляет нас только от hard parses, а здесь soft parses. Не стоит забывать, что у вас 11.2.0.3, а у нас 11.2.0.2. Попробую выискать ресурсы, чтобы прокачать тестовую базу ИБСО до 11.2.0.3 и посмотреть, что из этого получится.