Ещё раз про db file parallel read

анипроблем
Дата: 24.03.2011 23:29:10
Почитал про это ожидание на форуме. Но из того, что нашёл, так чёткого понимания и нет - в каких случаях Oracle использует данное ожидание?

В доке написано:

автор
db file parallel read

This happens during recovery. It can also happen during buffer prefetching, as an optimization (rather than performing multiple single-block reads). Database blocks that need to be changed as part of recovery are read in parallel from the database.


Сначала я думал, что это используется когда идёт параллельный доступ через индекс.

Однако я поймал запрос, который в тексте не имел никакого указания на параллелизм, у таблицы и у индекса DEGREE=1(0). При этом происходило чтение одновременно 9-ти дата-файлов, текущим объектом была таблица.
В плане было:
TABLE ACCESS BY INDEX ROWID

И ASH репорт тоже показал, что наиболее нагруженные были именно те датафайлы, в которых расположена таблица.

То есть налицо параллельный доступ к таблице, но не через direct path, а через db file parallel read.

При этом в БД получается наблюдается нехилая просадка производительности.
Когда данная сессия читает с помощью db file parallel read, 2-ве сотни сессий висят на read by other session.

Хотелось бы выслушать мнения специалистов.
wurdu
Дата: 25.03.2011 02:48:40
Вопрос обсуждался вот здесь: про однопоточное случайное чтение. У ожидания db file parallel read есть параметр obj#, из которого видно, какой объект читается. Я там видел только индекс, собственно префетч работает для индексных блоков. Возможно в 11g что-то поменялось, не проверял. Используется AIO. Советую посмотреть на obj#, т.к. из поста мне показалось, что выводы по чтению таблицы через db file parallel read не имеют достаточных оснований и сделаны по косвенным признакам. Также не уверен, что есть связь между read by other session и db file parallel read. Надо смотреть планы запросов, которые висят на read by other session. Обычно они выполняют table fullscan / index fast ful scan, что и приводит к этому ожиданию.
анипроблем
Дата: 25.03.2011 08:44:00
wurdu
Вопрос обсуждался вот здесь: про однопоточное случайное чтение. У ожидания db file parallel read есть параметр obj#, из которого видно, какой объект читается. Я там видел только индекс, собственно префетч работает для индексных блоков. Возможно в 11g что-то поменялось, не проверял. Используется AIO. Советую посмотреть на obj#, т.к. из поста мне показалось, что выводы по чтению таблицы через db file parallel read не имеют достаточных оснований и сделаны по косвенным признакам. Также не уверен, что есть связь между read by other session и db file parallel read. Надо смотреть планы запросов, которые висят на read by other session. Обычно они выполняют table fullscan / index fast ful scan, что и приводит к этому ожиданию.


У меня 11g и там нет параметра obj#.
Если речь идёт про параметры p1(количество файлов),p2(количество блоков),p3(количество запросов ввода/вывода).

Ожидание read by other session возникает, когда одна сессия читает блок, а другая сессия намеревается получить тот же блок, но вынуждена ждать, пока первая сессия закончит чтение с диска.
wurdu
Дата: 25.03.2011 08:50:20
анипроблем
wurdu
Вопрос обсуждался вот здесь: про однопоточное случайное чтение. У ожидания db file parallel read есть параметр obj#, из которого видно, какой объект читается. Я там видел только индекс, собственно префетч работает для индексных блоков. Возможно в 11g что-то поменялось, не проверял. Используется AIO. Советую посмотреть на obj#, т.к. из поста мне показалось, что выводы по чтению таблицы через db file parallel read не имеют достаточных оснований и сделаны по косвенным признакам. Также не уверен, что есть связь между read by other session и db file parallel read. Надо смотреть планы запросов, которые висят на read by other session. Обычно они выполняют table fullscan / index fast ful scan, что и приводит к этому ожиданию.


У меня 11g и там нет параметра obj#.
Если речь идёт про параметры p1(количество файлов),p2(количество блоков),p3(количество запросов ввода/вывода).

Ожидание read by other session возникает, когда одна сессия читает блок, а другая сессия намеревается получить тот же блок, но вынуждена ждать, пока первая сессия закончит чтение с диска.
Объект видно в 10046:
WAIT #5: nam=\'db file parallel read\' ela= 19211 files=14 blocks=33 requests=33 obj#=4613909 tim=197186407648