Здравствуйте!

Очень подозрительно выросло "log file sync" ожидание. Подозрительно от-того, что новый резлиз не ставился, данные не заливались и не закачивались, диски в порядке. Что может быть причиной?

Ещё немного графики

trace.log,

Только постфактум установил statspack вчера standard edition :( (мониторится всё через ignite).

Понимаю кое-чего в этом, спасибо, интересная причина, попрошу ребят проверить, но алертов в контроллерах рейда нет никаких.

DВАа еще криворукие разработчики, часто делающие комиты ))
Вот именно. Но софт продали, поддержки от разраба по факту нет, а базу сопровождать надо :/
В этой БД создаётся немеренное количество объектов и потом дропаются, настолько много, что каждые 3 месяца количество сиквенсов подходит к максимальному значению... Воркэраунд - экспорт и импорт в новую БД.

Касательно темы. С железом всё ОК. Логика не менялась.

Нарылось вот что: начиная с 11gR2 LGWR может работать в двух режимах, "Post/wait" и "Polling".
Post/wait - традиционный метод, когда лограйтер явно оповещает все ждущие процессы, что коммит завершён.

Polling - Foreground процессы засыпают на "некоторое время", а затем опрашивают, был зи завершён коммит.


В трейсах LGWR





Log file sync switching to polling - вот здесь была собака зарыта.

Есть такое параметр - “_use_adaptive_log_file_sync” который был введён начиная с 11gR2 , он контролирует будет ли включено адаптивное автоматическое переключение между post/wait и polling.
Начиная с версии 11.2.0.3 (это как раз моя версия БД), Oracle имеет значение параметра "_use_adaptive_log_file_sync" = true.

Полечилось тем, что установили параметр в false.

Avg wait (ms) log file sync уменьшилось с 15 на 0. Вот такие вот пироги.

Всем спасибо!

Подскажите, можно рассматривать Foreground процессы как процессы пользователя?