Oracle 10.2.0.4.0 / OC Windows Server 2003
Работаю с базой недавно. Предыдущий админ не в помощь.
Последние три дня все пользователи начали шквально жаловаться на торможение работы проги. Юзаю ASH Viewer для быстрого просмотра того, что происходит в базе. Вижу, что при выполнении sql типа insert или PL/SQL EXECUTE образуется высокое concurrency типа latch: library cache.
Собрала AWR репорт, к сожалению за последние 5 дней (тк сервер останавливали). Файл прикрепила.
Здесь основные выдержки. которые привлекли мое внимание.

Execute to Parse %: 27.94
Parse CPU to Parse Elapsd %: 2.41

В топ 5 Timed Events на первом месте:
Waits Time(s) Avg Wait(ms) % Total Call Time Wait Classlatch: library cache 13 821 68 454 4 953 57.8 Concurrency

Time Model Statistics
Statistic Name Time (s) % of DB Timesql execute elapsed time 73 350.30 61.92parse time elapsed 43 426.25 36.66 DB CPU 43 424.03 36.66 PL/SQL execution elapsed time 9 550.12 8.06 hard parse elapsed time 5 262.82 4.44 connection management call elapsed time 3 000.80 2.53

Не знаю, что предпринять. Не увеличивать же размер shared pool-а. Дмуаю flush shared pool-а тоже не то, что мне нужно.
Прошлась по форуму, решенных подобных вопросов преимущественно нет, нашла всего парочку. И то, проблема была в нехватке памяти на жестком.
Конечно куча ссылок на то, что нужно оптимизировать запросы. Но это невозможно, тк нет исходников проги. И работала же она как-то раньше с теми же запросами.

В общем, помогите кто чем может или пристрелите меня, голова уже кругом от причин и следствий этой ерунды.

И для наглядности PinHits
SELECT namespace, pins, pinhits, reloads FROM V$LIBRARYCACHE ORDER BY namespace;

NNAMESPACE PINS PINHITS RELOADSBODY 775591 775506 0CLUSTER 901 891 0INDEX 72813 72444 2JAVA DATA 0 0 0JAVA RESOURCE 0 0 0JAVA SOURCE 0 0 0OBJECT 0 0 0PIPE 0 0 0SQL AREA 20407407 19966800 3687TABLE/PROCEDURE 2452398 2446354 639TRIGGER 99846 99806 4

Вячеслав ЛюбомудровВот лениво смотреть отчет, но если там, судя по предыдущему сообщению, в основном ожидания "library cache pin", "library cache lock", то в общем-то вырисовывается картинка установка обновлений/компиляция на работающей системе
Т.е. ситуация:
-- сессия1 запустила долгую пакет1.процедуру1
-- сессия2 решила установить новую версию PACKAGE (декларации) пакет1 -- просит исключительную блокировку на [строку] в library cache для этого пакета, но она уже удерживается сессией1 в разделяемом режиме -- виснет на ожидании "library cache pin"
-- любая другая сессия, пытающаяся запустить что-либо из пакет1, становится в очередь за сессией2 как правило, на том же ожидании
...
-- и все это не прочухается пока не закончится/прибъется сессия1

А ожидать одновременно может сотня сессий, а все ожидания суммируются...


Дааа, и вся эта ерудна происходит скачкообразно. Как уйти от этого? никак что ли. Почему тогда раньше этого не было? Изменений никаких не вносилось ни в базу, ни в прогу

Вячеслав Любомудров,огрооооооооооооооооомное спасибо, что почекал, поразмышлял, подсказал и потратил время. Когда написал про фреймворки. Я опять задумалась насчет памяти, которую в первую же очередь, как начались проблемы я проверяла и увеличивала. Оказалось, что другой админ развернул на этом диске еще одно приложение, которое благополучно все съедало. Максимально бомбит с этого конечно. Но в общем, все у кого будет подобная ситуация, 100 раз перепроверьте наличие свободного места на жестком, не л*ханитесь как я

Вячеслав Любомудров, еще раз спасибо, и извини, что в итоге потратил время из-за такой ерунды