В общем, в сабже версии 1.6 работающем на 10.2/64 есть проблема с конкуренцией за защелки.
Проявляется после достижения определенной нагрузки на приложение (порядка 15000 просмотров в час).

Удалось установть что проблемы с ожиданиями этих защелок имеются практически у всех запросов, у таких запросов много child cursors, а представление V$SQL_SHARED_CURSOR показывает 2 причины
AUTH_CHECK_MISMATCH VARCHAR2(1) (Y|N) Authorization/translation check failed for the existing child cursor
LANGUAGE_MISMATCH VARCHAR2(1) (Y|N) The language handle does not match the existing child cursor

Используется кастомная аутентификация.
Проблеме продвержены как запросы в пакетах (package) с правами создателя, так и те что запускаются непосредственно в регионах APEX.

А что означают указанные выше причины неразделения?

и еще, используется Row Level Security...
политики созданы еще на 9.2 (до миграции на 10.2) с static_policy=>FALSE
может теперь попробовать на перейти на SHARED_CONTEXT_SENSITIVE...

Заглянул
Вот Library Cache Internals by Julian Dyke действительно интересно почитать.

вот это?
http://julian.dyke.users.btopenworld.com/com/Presentations/LibraryCacheInternals.ppt

качаю...

надо полагать AUTH_CHECK_MISMATCH связан с RLS?
Грустно....

Кстати, в пятницу вечером я пересоздал на пром-базе политики безопосности, перешел на SHARED_CONTEXT_SENSITIVE, и результат таков:
Например сравнивая время с 9 до 10 часов в пятницу и сегодня

Среднее время отклика по некоторым популярным страницам
Стр до после
21 0,284 0,204
23 0,224 0,161
22 0,225 0,169
70 0,51 0,441
72 0,518 0,336

Нагрузка в час практически одинаковая (в пятницу 24882, сегодня 23931 просмотров страниц)

Профиль системы (AWR top 5)
В пятницу:
CPU 53,7%
Latch:shared pool 23.2%
Latch: library cache 15.5%

Сегодня:
CPU 66,9%
Latch:shared pool 15,7%
Latch: library cache 7,0%

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

Я уже грешным делом RLS весь выкурил, в итоге конечно, скопище child cursor-ов исчезло, но на конкуренцию по защелкам это не повлияло абсолютно.

нашел на металинке вот такое

у меня такие значения
_kghdsidx_count = 2
_kgl_latch_count = 0

может знатоки могут чего посоветовать по поводу упомянутого?

п.с. на сервере 8 гигов, в базе sga_target=5G

поставил я _kghdsidx_count = 4, час пик прошло намано, на 42000 с гаком страниц в час.
ловил сессии на ожиданиях latch free, но очередь за ними не выстраивалась, система в ступор не входила.

2evostr
а про книжку "Oracle Wait Interface" - совсем забыл, спасибо, уже читаю.

да уж, давят обстоятельства, с одной стороны система должна выполнить в кратчайший срок свою функцию, с другой стороны, еще пару дней и такой нагрузки не будет, а мне, и моим начальникам, в общем вкрай интересно знать на что способны приложения сделаные в APEX.

да, шаред пула я конечно же добавил, поставил нижний предел в 1.5 ГБ (sga_target=7G).

ожидания проскакивали и library cache и shared pool. Но еще раз повторю, система выдавала небывалую пропускную способность (кстати сказать следующий час был пиковым, было сгенерено почти 50 тыс. страниц при среднем времени отклика/генерации страниц 0.2 сек), в отдельно взятые моменты времени ожидающих сессий было десяток, максимум два-три.

В отличие от того как было до изменения, тогда ожидающих сесий могло быть сотню, две, и в таком случае система входила в ступор. Время отклика начинало уходить за 10-20 секунд, а то и на минуты счет шел.