redo log space requests – чтобы это значило?

dbstalker, 20 марта

Для того чтобы транзакция закончилась, записи повторения должны быть записаны из Redo Log Buffer в Redo Log (из памяти на диск). Обычно это происходит достаточно быстро, чтобы обеспечить в Redo Log Buffer место для новых записей. Однако иногда могут возникнуть задержки при записи в Redo Log Buffer. Это приводит к потере производительности.

При помощи V$SYSSTAT можно обнаружить наличие данной проблемы на вашем сервере. Так можно увидеть значение этой статистики:

Если раньше считалось, что статистика redo log space requests отражает число раз, когда процессу, записывающему в Redo Log Buffer, приходилось ожидать освобождения памяти. И считалось , что увеличивая размер Log Buffer, можно добыться решения проблемы.

Пример подобного совета: «Это [большое значение статистики redo log space requests] говорит о том, что пользовательские процессы ждут освобождения места в буферах журнала повтора [в идеале это значение должно быть около нуля]. Поэтому нам следует немного увеличить существовавший до этого размер LOG BUFFER и через некоторое время поглядеть, какое влияние это изменение окажет на redo log space request.»

То сейчас redo log space requests трактуется иначе. Нарастание этой статистики происходит, когда активный log file уже заполнен, и оракл в ожидании доступа к дисковому пространству для размещения новых redo log entries (в новый redo log), которое будет получено путем переключения журнальных файлов. Простым языком: Online Redo Log file уже полный и сервер ждет доступа к следующему Redo Log file. До того времени, когда произойдет переключение журналов на новый журнальный файл, оракл должен гарантировать, что все закомиченные грязные буфера будут записаны на диск. Если имеется большая SGA , заполненная грязными буферами и маленькие redo log files, то переключение произойдет только тогда, когда процесс DBWR запишет dirty buffers на диск. Таким образом, маленькие Log files по сравнению с размером SGA или частые commit-ы - основные причины возникновения данной проблемы.

Такое объяснение более точное – пришлось убедиться на практике, когда Redo Log Buffer имел огромный размер, а статистика росла значительными темпами.

Обратите внимание на такое замечание отсюда.

10.2.4.1 Redo Log Space Requests Statistic The V$SYSSTAT statistic redo log space requests indicates how many times a server process had to wait for space in the online redo log, not for space in the redo log buffer. A significant value for this statistic and the wait events should be used as an indication that checkpoints, DBWR, or archiver activity should be tuned, not LGWR. Increasing the size of log buffer does not help.

Можно пойти также таким путем: Увеличить размер redo logs, redo logs разместить на «быстрых» дисках, уменьшить размер log_buffer.

Also see the value of the 'log file space/switch' wait event i V$SESSION_WAIT

1 комментарий

Прокоментировать

Новичек
20 марта 2009 г. в 20:05

Вероятно также можно настроить более редкое выполнение инкрементальной контрольной точки.

 

Новый комментарий

Я не спамер: введите суму 9+0



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум