Все джобы работают медленно с какого-то момента. Анализ показывает, что планы запросов не изменилось, степень их параллельности то же. В запросах выросла доля ожиданий IO ( а доля CPU соответсвенно уменьшилась).
AWR репорт показывает то же самое на уровне всей базы. Например сравнение двух снапшотов - нормального и не очень:


1st2ndEventWait ClassWaitsTime(s)Avg Time(ms)%DB timeEventWait ClassWaitsTime(s)Avg Time(ms)%DB timeCPU time67 921.3455.93CPU time49 482.9040.59db file sequential readUser I/O6 196 66118 031.612.9114.85db file sequential readUser I/O3 909 75623 413.415.9919.2db file scattered readUser I/O5 591 37510 984.861.969.05direct path read tempUser I/O2 196 56622 016.7710.0218.06direct path read tempUser I/O3 216 7949 723.773.028.01direct path readUser I/O477 69212 445.2926.0510.21direct path readUser I/O1 115 1578 786.627.887.23db file scattered readUser I/O2 300 32510 065.564.388.26enq: TM - contentionApplication7245 430.267 500.354.47enq: TM - contentionApplication7109 482.2713 355.317.78read by other sessionUser I/O1 159 9353 199.692.762.63PX Deq: Slave Session StatsOther3 116 8141 721.350.551.41PX Deq: Slave Session StatsOther3 110 5411 581.440.511.3SQL*Net more data from clientNetwork595 976876.591.470.72cursor: pin S wait on XConcurrency2 2431 432.55638.681.18read by other sessionUser I/O130 773694.065.310.57SQL*Net more data from clientNetwork727 548814.991.120.67Log archive I/OSystem I/O229 640338.671.470.28-Log archive I/OSystem I/O219 112268.371.220.22-cursor: pin S wait on XConcurrency879282.58321.480.23

Как видим среднее время случайного чтения выросоло с 2ms до 4, последовательного - с 3 до 6. На самом деле если построить график по dba_hist_event_histogram видно как оно даже потихоньку увеличивается.

Инфраструктурщики не видят проблемы и только отпинываются что все нормально. Когда среднее время одноблочных и многоблочных чтений достигло 10ms, мы перезагрузили хост и инстанс - и, внезапно это помогло. снова вернулось в норму....но буквально на пару дней. Сейчас я вижу что оно снова начинает расти.
Кто-нибудь сталкивался с таким случаем, куда копать, и как доказать инфраструктурщикам что проблема не в базе, не в ее нагрузке или планах?

"Cмотреть надо не среднее, а гистограммы. Там в AWR отчете они дальше есть и по датафайлам и по ожиданиям"

Так я ж говорю - я смотрел гистограммы.
Там на них видно что дело не в том, что есть небольшое количество длительных вэйтов, а что в среднем вейты просели.
Т.е. в нормальный день - 80-90% укладывается в 1ms, а в "плохой" - 30-40%, еще 30-40% - в 2 ms, ну и далее потихоньку падает.

Наличие свопа смотрел в dba_hist_osstat - его там нет.
SGA, PGA в норме - не растут.
OS там UNIX.

директ IO и своппинг,

можно поподробней, боюсь я не понял?

filesystemio_options = none
disk_asynch_io = TRUE

Что важно, они не менялись, т.е. были такие же и когда база работала прилично.
На OS уровне не могу проверить, нет доступа туда ( можно ли как-то проверить из базы? )
Тем не менее можно написать такой запрос:




Он показывает что 3-5% чтений в каждом снапшоте direct. Если я вообще правильно понял, о чем мы разговариваем.

xtender,

пока да.

х.з.DВАну или какой кэш на дисковом массиве сдох )))
а перезагрузка хоста оживила его на пару дней )

У меня ощущение что файлы БД кэшируются на уровне ОС. А в один прекрасный момент этот кэш засирается и все становится плохо.

Ммм... Update: у нас ASM.
Так что filesystemio_options игнорируется по идее и читается напрямую, без OS кэша.