Фига вы спамеры. за ночь >300 сообщений только с утра дочитал

Ребят, а тут можно чем-то помочь?

Посажелеть. А может там и не надо трогать?) И для вашего продукта это норм косты.

Да уж. Неделю назад никаких проблем не было

Ага. Раньше такого не было, и вот опять  (с).

Может там этих контр док на порядок больше стало, например.

За лайки выше читайте. Уже обсуждали.

Вот.

И ниже читаем, изучаем.

благодарю

free buffer waits и buffer busy waits висят запросы,  как-то можно посмотреть какие запросы все буфера заняли?

В AWR и ADDM у тебя, скорее всего, будет инфа по горячим блокам.

number get reads   чисто смотреть или там по буферам есть раздел?

Вообще, сразу стоит задуматься, почему у тебя не хватает места под размещение блока в буфферном кэше. Тут вариантов может быть несколько:
1. Buffer cache тупо мелкий. Надо посмотреть на его отношение к Shared Pool. Возможно, второй из-за неэффективного динамического SQL разросся, и отъел у Buffer Cache.
2. Ленивый чекпоинт. Возможно, стоит поиграться с параметром fast_start_mttr_target, чтобы сделать сброс грязных блоков на диск более активным.
3. Собственно, горячие объекты. Разобраться, почему наряду с free buffer waits у тебя висит ещё и buffer busy wait... Может, индекс какой долбится оч часто.

У эвента есть два параметра. Номер файла и номер блока. Посмотри, что это за объект в этом блоке лежит.

У buffer busy waits также те же два параметра. Номер файла и блока