как я провел лето

Коллеги для тестирования выбрали распоследний AIX 7.1, Oracle 11.2.0.2, установили PSU (стало 11.2.0.2.2).  Хранение данных на ASM.  Немедленно после попытки старта ~3000 сессией kernel time взлетел в потолок, а диски наоборот. Разработчики AIX думали недолго, и исправленный код будет включен в 7.1.0 SP2

Особенно доставил комментарий к  патчу  "the changes are complicated and involve legacy code that has not been touched in 20 years". Проблема оказалась в том, что нагрузочный тул запускал работу всех сессий одновременно, а не давал им работать сразу после входа. Понятно, что ситуация нежизненная, а искусственная. Надо сказать, что почти одновременно был поставлен и патч  Bug 11800170 - ASM IN KSV WAIT AFTER APPLICATION OF 11.2.0.2 GRID PSU, и возможно он также помог.

Немедленно после того как удалось справиться с kernel time, почта доставила вот такой AWR:



с исконно русским вопросом - кто виноват и что делать ?  Тема mutex X беспокоит народ очень давно, и кажется что каждый новый пачтсет привносит свои изменения. В нашем случае у меня сложилось убеждение что новый PSU не исключение. Поиск по My Oracle Support навел на Bug 12431716 - Mutex waits may cause higher CPU usage in 11.2.0.2.2 PSU / GI PSU [ID 12431716.8]  и рекомендацией to apply Patch:12431716 on top of the 11.2.0.2.2 PSU. В нашем случае применение патча  - никаких изменений к лучшему.  Внимательное чтение вышеприведенного привело к обнаружению Bug 10411618 - Enhancement to add different "Mutex" wait schemes [ID 10411618.8] и понимаю наличия параметра _mutex_wait_scheme. Проводились эксперименты с установкой этого параметра в 0, и надо отметить, что поведение системы меняется. Поэтому если мы поставили уже PSU, и mutex вдруг появились - можно это попробовать. По молчанию _mutex_wait_scheme = 2, так мы и решили продолжать.

Продолжать кстати оказалось удобно с помощью весьма известного скрипта snapper by Tanel Poder:

SQL> @snapper ash=sql_id+event+wait_class+blocking_session+p2+p3 5 1 all
Sampling SID all with interval 5 seconds, taking 1 snapshots...

-- Session Snapper v3.52 by Tanel Poder @ E2SN ( http://tech.e2sn.com )


------------------------------------------------------------------------------------------------------------------------------------
Active% | SQL_ID          | EVENT                     | WAIT_CLASS      | BLOCKING_SES | P2                   | P3
------------------------------------------------------------------------------------------------------------------------------------
  5175% | 5xqa6qnbagf2b   | ON CPU                    | ON CPU          |              |                      |
  3200% |                 | db file parallel write    | System I/O      |              | 0                    | 2147483647
  2725% | ampvmj3gx3n16   | ON CPU                    | ON CPU          |              |                      |
  1475% | 06bfg06g97f27   | ON CPU                    | ON CPU          |              |                      |
  1050% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency     | 7374         | 60073707569152       | 82
   900% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency     |              | 60073707569152       | 82
   850% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency     | 15371        | 54885387075584       | 82
   700% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency     |              | 54885387075584       | 82
   625% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency     |              | 29781303230464       | 82
   600% |                 | ON CPU                    | ON CPU          |              |                      |



SQL> @snapper ash 5 1 12062
Sampling SID 12062 with interval 5 seconds, taking 1 snapshots...

-- Session Snapper v3.52 by Tanel Poder @ E2SN ( http://tech.e2sn.com )


-----------------------------------------------------------------------
Active% | SQL_ID          | EVENT                     | WAIT_CLASS
-----------------------------------------------------------------------
    68% | gvzx29hj54zfm   | library cache lock        | Concurrency
    32% | gvzx29hj54zfm   | library cache: mutex X    | Concurrency



Wow.  Найден проблемный sql_id ! Не тут то было. Обнаружить этот sql_id в v$sql  не удалось. Это интересный момент кстати, и что это было не очень понятно. Чуть позже разработчик признался, что был ошибочный запрос (в котором была указана несуществующая таблица) и возможно это и было причиной всех бед и это и был наш 'непойманный' sql_id.

А пока я провел несколько  дней  на замечательном блоге Андрея Николаева (РДТЕХ), который  описал возможность  пометить некоторые объекты как горячие в библиотечном  кэше. Обязательно прочитайте, крайне рекомендую. Описанная в блоге Андрея технология была приведена в действие.

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


Это была если не победа, то по крайне мере серьезный прогресс. Конечно, это не окончание истории, еще не ответили за свое "kokc descriptor allocation latch",  требуется разбираться с ORA-00600: internal error code, arguments: [pesld02: nlui] (которая признается на metalink как следствие использования Edition Based Redefinition, которые не использовались) но это другая история. 

Вместо заключения: установка PSU на 11.2.0.2 - дело не такое простое как может показаться. Вернее не сама установка, а ее возможные последствия. Если вы решитесь, то сразу вместе с PSU ставьте и указанные тут патчи и все что выйдут к тому времени. Удачи !

Update 1: Убедитесь в том то у вас стоит Patch 10190759: PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO 'USLA HEAP'

Update 2: Коллеги предложили немного другой AWR, за другой диапазон времени, в которой история представляется не такой счастливой как показалось мне:

Так что to be continued по полной программе -(

4 комментария:

  1. Анонимный10/6/11 10:54 AM

    Жесть...
    Догадываюсь на 99% что и совместно с кем Вы тестировали :-)
    Работаю в этой компании и с Вами Дмитрий не однократно встречались на совместных семинарах и пр.
    Вот смотрю на все эти телодвижения с каждой новой версией/релизом СУБД и становится все грустнеее и грустнее...
    Раньше я был за прогресс - вышла новая версия - почему бы не обновиться. Теперь - работает - не трогай. Может старше стал, опыт, нервотрепки не хочется. Но ведь все равно заставят переводить клиентов на новую версию.
    Ээээх...

    ОтветитьУдалить
  2. Анонимный10/6/11 2:19 PM

    Дмитрий, не подскажите каким образом настроена доставка AWR отчётов на email?

    Snapshot-ы в OEM формируются автоматически, а вот отчёты - нет.

    Всё что в интернете встречалось - подразумевало "ручную" генерацию отчётов скриптами.

    ОтветитьУдалить
  3. >каким образом настроена доставка AWR отчётов на email

    Я вас расстрою, я знаю как сделать только скриптами:
    sqlplus, awrrpt.sql, mailx

    ОтветитьУдалить
  4. Анонимный21/6/11 2:51 PM

    Спасибо за теплые слова.
    AWRы классные.
    Вот это задача для настоящих DBA!
    Добавлю 5коп вопросов:
    1. Enqueue hash chains latch. Это не deadlock trace пишутся?
    2. AIX 7.1 не видел еще. Но 6.3 в похожей конфигурации обожает постепенно отьесть
    до половины RAM и начать выкидывать Oracle вызывая вспышки ожиданий mutex и latch
    И это не файловый кеш. Что он там делает с десятками GB - до сих пор изучает IBM
    Помогли настройки VMM, LP, мониторинг SVMON, но главное - скромные размеры SGA

    ОтветитьУдалить