cursor: pin s

Oracle 11.2.0.3
win 2008


Второй месяц подряд вылезает проблема, в прошлый раз неведомо почему получилась рестартом БД
Сейчас опять выскочила:

Есть определенный отчет критичный для клиента, во время которого вылазиют постоянно ожидания "cursor: pin s"
Время исполнения медленнее обычного в 5 раз минимум. Крики, истерика... как всегда.

Ни как не могу выловить причину...


Прилагаю AWR, скажите что ещё может помочь залечить проблему?
файл большой стандартной формой не приложился, поэтому пользую файлообменник
https://dropmefiles.com/X9TDM

Судя по AWR, на cursor: pin S ушло 2 секунды. Каким образом пришел к выводу что сессия ждала cursor: pin S ? Не через v$session случайно, без учета STATE?

esir,

2 секунды это так критично ?

ora601, wurdu

ну да.. state - WAITED SHORT TIME...

То есть cursor: pin s, тут злом не является.

Можно спросить тогда, может кто-чего то увидит, чего мои неопытные глаза тут не видят?

esir,

имхо надо смотреть V$active_session_history за этот период. Но что то мне кажеться дело даже не в ожиданиях (а в SQLe).

esir
ora601, wurdu ну да.. state - WAITED SHORT TIME... То есть cursor: pin s, тут злом не является. Можно спросить тогда, может кто-чего то увидит, чего мои неопытные глаза тут не видят?

Да какой смысл AWR смотреть. Есть запрос который висит на CPU. Стандартная ситуация. ПОлучаем план со статистиками выполнения любым удобным способом, либо SQL Monitoring Report. Там все будет видно.

esir,

а если еще поточнее - то top sql ordered by gets

buffer gets 3,416,202.01 SQL_ID - c2jptkcdrdysy. 

Не многовато ли 3M gets на запрос?

ora601
esir, а если еще поточнее - то top sql ordered by gets buffer gets 3,416,202.01 SQL_ID - c2jptkcdrdysy. Не многовато ли 3M gets на запрос?

Можете дураку расшифровать, это обращения к данным?

wurdu
esir ora601, wurdu ну да.. state - WAITED SHORT TIME... То есть cursor: pin s, тут злом не является. Можно спросить тогда, может кто-чего то увидит, чего мои неопытные глаза тут не видят? Да какой смысл AWR смотреть. Есть запрос который висит на CPU. Стандартная ситуация. ПОлучаем план со статистиками выполнения любым удобным способом, либо SQL Monitoring Report. Там все будет видно.

Передал план выполнения запроса c2jptkcdrdysy программистам!

esir
ora601 esir, а если еще поточнее - то top sql ordered by gets buffer gets 3,416,202.01 SQL_ID - c2jptkcdrdysy. Не многовато ли 3M gets на запрос? Можете дураку расшифровать, это обращения к данным?

When Oracle accesses a data block, it first checks to see if the data block is already inside the data buffer. If so, Oracle issues a :logical I/O" (as opposed to a physical get), and fetches the data block directly from RAM.Oracle displays "buffer gets" inside AWR reports (the "SQL ordered by gets" section)

Нашёл спасибо!