Чё?

Ну горячий блок

Ну насували индексов на монотонно возрастающее поле и при вставке всё в один блок стучится

Short Hangs waiting for Enq: CT - CTWR Large Concurrency Wait Event (Doc ID 2601295.1), как раз 12.1.0.2, есть патч и тюнится скрытыми параметрами, но не факт, что оно

у нас есть супер большая таблица в которую пишут сразу несколько нагруженных приложений, которые по ресурсозатратам нельзя держать на 1 ноде

т.е грубо говоря 4 прилаги на 4 разных нодах пишут туеву хучу данных в супер огромную таблицу

Да и по ожиданиям gc есть баги, типа "Database hangs: "gc buffer busy acquire/release" and "gc current block busy" pointing to the tempfile block #2 (Doc ID 2192851.1)", но чем гадать, лучше копнуть детальнее причину

она отпартиционирована, но толку от этого похоже мало

дак у тебя поди кластерные фризы, когда идет синхронизация

я помню дба ребилдил на ней индексы и там были цифры в районе с 600Гб до 40Гб индекс уменьшился

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

Смотрите p1, p2, p3 параметры ожиданий, и ищите горячий блок конкретно...

Там же смотрите для группы топ-событий повторяющиеся sql_id, file#, block#, class#, разбирайтесь - проблема размазана по всей БД или всё из-за вашей супер-таблицы, смотрите цепочку блокировок, есть данные по блокирующим сессиям в этой же view, смотрите что блокирующие делали и т.п.

Чтобы не ковырять это всё руками - снимите AWR за минимальный интервал, чтобы попало как можно меньше "шума" вокруг проблемного промежутка времени

спасибо за советы. будем переваривать

не удивлюсь, если все 4 приложения работают с одними и теми же данными в таблице

насколько я понял логику работы, одно приложение добавляет строку, другое спустя время апдейтит ей некоторые поля

:D

ну тогда понятно....  либо все приложения на одной ноде либо боль синхронизации )))

ох уж эти разработчики..

наговнокодят а мы потом страдаем