Troubleshooting: High Version Count Issues [ID 296377.

1]

Может это банальный BIND_MISMATCH. Из v$sql_shared_cursor будет видно.

1) минимизировать хард парсинг

2) разобраться, на чем висит парсящая сессия. варианты:
а) library cache lock или аналогичное ожидание, удерживаемое еще какой-то сессией
(вариант -- сбор статистики с последующей инвалидацией курсоров)
б) какое-то другое ожидание
в) долго тупит на CPU из-за какого-то бага оптимизатора (например, попадался случай
когда запрос с длинным IN LIST вешал чуть ли не всю базу -- оказалось, на MOS есть
соотв. баг)
г) не может влезть на CPU из-за того, что тот чем-то занят. в 10-ке мутексы вообще
жутко жрали процессор и могли приводить к инверсии приоритетов (например так:
http://blog.tanelpoder.com/2010/04/21/cursor-pin-s-waits-sporadic-cpu-spikes-and-
systematic-troubleshooting/), в 11-й вроде бы это пофиксили (у Андрея Николаева в
блоге где-то было, точной ссылки под рукой нет)

Андрея Николаева в блоге где-то был

dbms_photoshop
Тоже столкнулся. Может кому пригодится (This is due to an unpublished bug that is
fixed in 12g Release 2)
High Waits for 'cursor: pin S wait on X' due to Dynamic Sampling Against Parallel
Queries (Doc ID 2006145.1)

Мы в свое время заводили SR по этой же теме.

Рекомендовали существенно увеличить значение параметра session_cached_cursors и
снизить параллелизм.

Помимо этого есть два класса запросов, генерируемых внешними системами и написанные
альтернативно одаренными личностями, которые
1) используют хинт parallel без указания степени параллельности. благодаря чему она
более 100
2) используют хинт precompute_subquery
В этих случаях очевидно, что надо фикстить.

Но есть еще ряд запросов, которые долго парсятся, но не попадают ни в одну

категорию выше.
В часности, некоторые просто висят на CPU, так что надо ковырять глубже.
------------
Если для всех таблиц запроса всегда имеется актуальная статистика, можно
попробовать установить:

optimizer_dynamic_sampling = 0
optmizer_adaptive_features = false
-----------

http://blog.tanelpoder.com/2010/02/15/new-versions-of-latchprof-and-latchprofx-for-
latch-contention-troubleshooting-and-tuning/

!!!!!!!Мы на базах, где наблюдается подобная проблема, выставляем

_kks_use_mutex_pin=false

select
z.kspftctxdf as isdefault,
x.ksppinm as name,
 substr(y.ksppstvl,1,10) as value
FROM
sys.x$ksppi x,
sys.x$ksppcv y,
sys.x$ksppcv2 z
where
x.inst_id=userenv('Instance')
and y.inst_id=userenv('Instance')
and x.indx=y.indx
and x.ksppinm like '%mutex%'
and z.kspftctxpn = x.indx+1

If you have mutex related problems the following should be helpful:

Note: 1377998.1 Troubleshooting: Waits for Mutex Type Events
Note: 1349387.1 Troubleshooting 'cursor: pin S wait on X' waits.
Note: 1357946.1 Troubleshooting 'library cache: mutex X' waits.

Bug 5079609/4402255 APPSST GSI 10G THOUSANDS OF SESSIONS WAITING ON 'CURSOR

PIN S WAIT ON X'

Bug 5095738/4402255 APPSST - 10GGSI - HIGH CURSOR PIN S WAIT ON X WAITS ON

PRODUCTION INSTANCE

opatch lsinventory | grep 7462072

7462072, 7600026, 6679303, 7197583, 7172752, 7326645, 7008262, 9173244