Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Почему могла не собраться статистика?  [new]
Valergrad
Member

Откуда:
Сообщений: 605
Добрый день!

Продакшен встал колом в один из дней. Проблема обнаружилась в том,

1. Что у одного из запросов ( который генерится динамически ) сдвинулся план с обычного к ужасному.
2. Анализ причины, почему сдвинулся план показал, что дело в том, что не собралась статистика по одной из партиции одного из индексов.
Точнее, она показывается как собравшаяся ( last_analyzed = корректное время ), но все значения там 0 - количество строк, ndv и т.п.
3. Статистика собиралась сразу после загрузки данных и прямо перед построением плана процедурой содержащей схематично следующий вызов:

begin
   DBMS_STATS.GATHER_TABLE_STATS(
      ...,
   cascade => true
    );
    exception 
    when others then null;
end;
/


Соответственно по индексам статистика собирается благодаря cascade => true. По самой таблице и по двум индексам из трех она нормально собралась, а когда дело дошло до записи информации о третьем индексе - что-то случилось. Т.к. мой предшественник при написании кода посчитал что падать на сборе статистики - плохая идея, и даже логировать ошибку не нужно - сейчас неизвестно что произошло.
А то, что оракл при очевидно упавшем сборе статистики зачем-то обновил last_analyzed, заставляя оптимизатор считать эту статистику актуальной - это уже недоработка оракла.

Проблема не воспроизводится - при повторном сборе статистики она собралась нормально. Тем не менее это важный кусок продакшена, и хотелось бы разобраться что произошло и как подобное предотвратить в будущем.

Ранее, я уже наблюдал, что dbms_stats написан нетракзакционно, делает там кучу коммитов внутри, и получить, скажем так "половину статистики" ( при том, что оптимизатор будет считать ее полной ) - как раз плюнуть.
До этого я сталкивался с этим когда в процессе работы dbms_stats кончилось место в tablespace SYSTEM ( записалась "половина статистики" ) и когда в процессе работы dbms_stats.gather_schema_stats было превышен лимит на количество открытых курсоров.
Но в данном случае ни то ни то не актуально - место есть, курсоров хватает.
Было ли в вашей практике еще что-нибудь?

И как вы решали подобные проблемы? Сейчас я обдумываю между добавлением в процедуру сбора статистики функции check_stats_gathered с перезапуском ее сбора, и просто захинтованием этого запроса так, чтобы плохой план в принципе не мог пролезть ( что будет очень сложно ).
3 дек 18, 02:52    [21751713]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
Valergrad,

что показывает DBA_OPTSTAT_OPERATION_TASKS?
3 дек 18, 05:41    [21751724]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
Elic
Member

Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
Сообщений: 28484
Valergrad
 when others then null;
Говнокод.
3 дек 18, 08:22    [21751737]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
kinky cat
Member

Откуда: с дивана23
Сообщений: 1231
Valergrad,
Заметил, иногда разваливается джоб sql tuning advisor с ORA-13668: The current operation was aborted because it was blocking another session. Может что то подобное и со stats. Правда с таким "обработчиком" этого уже не узнать
3 дек 18, 12:56    [21751946]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
kinky cat,

Dbms_stats логгирует в свои таблицы. Вьюха выше это бы показала. С sql tuning обычно приведенная проблема связана с оптимизацией dml
3 дек 18, 15:07    [21752146]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 16899
Valergrad
как вы решали подобные проблемы?

Убирали "when others then null" с занесением в душу автору этой пакости, подло скрывающей проблемы.
Затем наблюдали и, установив реальную проблему, решали по показаниям.
Это общее правило, к джобам тоже вполне себе применимое.
3 дек 18, 15:32    [21752171]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
Valergrad
Member

Откуда:
Сообщений: 605
xtender
Valergrad,

что показывает DBA_OPTSTAT_OPERATION_TASKS?


Увы, у нас 11.2 - там такой вьюшки еще нет...Есть только DBA_OPTSTAT_OPERATIONS , там для этой партиции есть только две записи как и полагается - одна из кода, а другая когда я пересобирал статистику сам.
Также там видно, что в этот момент собиралось по этой таблице статистика аж по 4-м партициям сразу ( различными процессами ), возможно они друг другу и помешали.
3 дек 18, 18:37    [21752352]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
Valergrad
Member

Откуда:
Сообщений: 605
andrey_anonymous
Valergrad
как вы решали подобные проблемы?

Убирали "when others then null" с занесением в душу автору этой пакости, подло скрывающей проблемы.
Затем наблюдали и, установив реальную проблему, решали по показаниям.


Это само собой, об этом можно и не говорить отдельно ( хотя автор этого кода давно уже не с нами, и скажу более того - автор этого кода очень авторитетный и уважаемый человек ;) ) Можно ли что-то попробовать до того, как код фикса попадет на продакшен, и ишью произойдет еще раз ( или не раз) ?
3 дек 18, 18:40    [21752353]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
Valergrad,

a wri$_optstat_opr_tasks есть?
3 дек 18, 19:08    [21752369]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
Valergrad
Member

Откуда:
Сообщений: 605
xtender
Valergrad,

a wri$_optstat_opr_tasks есть?


не, тоже нет)
Есть только sys.WRI$_OPTSTAT_HISTHEAD_HISTORY , вот что удалось накопать в ней.

Это время загрузки данных в таблицу:
select SCN_TO_TIMESTAMP(min(ORA_ROWSCN)) from XXXXXXX.XXXXXXXXX partition (P_RUN_59979); 
SCN_TO_TIMESTAMP(MIN(ORA_ROWSCN))                 
--------------------------------------------------
11/30/2018 2:16:21.000000000 PM                   


Для начала селект из DBA_OPTSTAT_OPERATIONS - что работало в это время. Мы видим, что почти параллельно статистика собиралась по 3м партициям:
OPERATION                      TARGET                                                           START_TIME                               END_TIME
------------------------------ ---------------------------------------------------------------- ---------------------------------------- ----------------------------------------
gather_table_stats             XXXXXXX.XXXXXXXXX.P_RUN_59984                                    30-NOV-18 02.16.20.392852 PM +00:00      30-NOV-18 02.16.28.861009 PM +00:00
gather_table_stats             XXXXXXX.XXXXXXXXX.P_RUN_59978                                    30-NOV-18 02.16.20.504914 PM +00:00      30-NOV-18 02.16.29.269022 PM +00:00
gather_table_stats             XXXXXXX.XXXXXXXXX.P_RUN_59979                                    30-NOV-18 02.16.23.322569 PM +00:00      30-NOV-18 02.16.29.638496 PM +00:00



Вот как выглядит история сбора статистики по "нормальной" партиции 59984, по индексу по которому возникли проблемы ( в другой партиции ):
SAVTIME                                                                          FLAGS     ROWCNT ANALYZETI
--------------------------------------------------------------------------- ---------- ---------- ---------
30-NOV-18 02.01.00.140515 PM +00:00                                                  0
30-NOV-18 02.16.26.697329 PM +00:00                                                 10          0 30-NOV-18
30-NOV-18 02.16.27.161823 PM +00:00                                                 10     223097 30-NOV-18 


SAVTIME - это время сбора статистики, а статистика там дается которая была перед запуском ( т.е. какая собралась в этот момент - надо смотреть в следующей строке ).
Обращает на себя внимание, что в истории показывается как будто статистика по индексу собралась два раза - в течении полсекунды. Отчего, почему - я не знаю. У таблицы - была одна строка ( сорри, не могу сюда скопировать результат - запускал DBA по моей просьбе, и этот результат потерялся ). Но видно, что уже первый раз она собралась нормально - потому что "следующая" строка для 2.16.26 содержит 223097 строк - правильное значение.

Теперь посмотрим то же самое по нашей, плохой партиции 59979, но "хорошему" индексу, по которому собралось:
SAVTIME                                                                          FLAGS     ROWCNT ANALYZETI
--------------------------------------------------------------------------- ---------- ---------- ---------
30-NOV-18 02.01.02.165163 PM +00:00                                                  0
30-NOV-18 02.16.27.903977 PM +00:00                                                 10          0 30-NOV-18
30-NOV-18 02.16.28.267288 PM +00:00                                                 10     223097 30-NOV-18
30-NOV-18 06.13.55.416252 PM +00:00                                                 10     223097 30-NOV-18 


Здесь тоже почему-то она собралась как будто бы два раза, и снова уже с первого раза нормально. Дополнительный сбор статистики в 6 вечера - это я запускал, чтобы починить проблему.

И наконец, тот самый индекс по которому почему-то не собралось:
SAVTIME                                                                          FLAGS     ROWCNT ANALYZETI
--------------------------------------------------------------------------- ---------- ---------- ---------
30-NOV-18 02.01.00.140515 PM +00:00                                                  0
30-NOV-18 02.16.26.697329 PM +00:00                                                 10          0 30-NOV-18
30-NOV-18 02.16.27.161823 PM +00:00                                                 10          0 30-NOV-18
30-NOV-18 06.13.54.688213 PM +00:00                                                 10          0 30-NOV-18

Тоже два раза, но не собралось оба раза. Когда я собирал в 06 вечера - уже собралось норм, но здесь не видно, т.к. смотреть нужно в следующей строке - которой нету.

Вопросы на которые у меня нет ответов:

1. Почему по этому индексу статистика не собралась, а оракл посчитал это нормальным явлением?
2. Почему когда собираешь статистику по таблице, в истории статистики по индексу появляется две строки? Это всегда так, или что-то значит?
3. Почему время сбора статистики ( SAVTIME ) по одному и тому же индексу совпадает вплоть до микросекунды? Может ли быть такое, что у оракла как-то пересеклись сборы статистики между партициями и поэтому вышла ерунда?
Ведь сборы статистики по P_RUN_59984 и P_RUN_59978 стартовали чуть раньше, чем данные появились в P_RUN_59979, и там как раз было пусто в этот момент. Или дело всего лишь в том, что оракл просто сохраняет историю статистики с определенным интервалом, поэтому у разных объектов одно и то же SAVTIME?
4 дек 18, 21:33    [21753723]     Ответить | Цитировать Сообщить модератору
 Re: Почему могла не собраться статистика?  [new]
xtender
Member

Откуда: Мск
Сообщений: 4959
Valergrad
SAVTIME - это время сбора статистики
это время сохранения в историческую таблицу, а analyzetime - время сбора этой статистики.


Valergrad
1. Почему по этому индексу статистика не собралась, а оракл посчитал это нормальным явлением?
слишком мало информации. Смотрел ASH за этот период по сессии джоба? И на случай, если это повторится, можешь включить трассировку сбора статистики: https://blog.pythian.com/options-for-tracing-oracle-dbms_stats/

Valergrad
2. Почему когда собираешь статистику по таблице, в истории статистики по индексу появляется две строки? Это всегда так, или что-то значит?
это не нормально. предположения есть, но гадать неохота. Глянь ASH или трассу.

Valergrad
3. Почему время сбора статистики ( SAVTIME ) по одному и тому же индексу совпадает вплоть до микросекунды?
SAVTIME - не время сбора, как я уже выше написал. Смотреть надо, что тогда выполнялось.
6 дек 18, 02:29    [21755215]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить