Статистики REDO из представлений V$SESSTAT and V$SYSSTAT
redo log space requests
Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing. Also examine the log file space and log file space switch wait events in V$SESSION_WAIT
Для того чтобы транзакция закончилась, записи повторения должны быть записаны из Redo Log Buffer в Redo Log (из памяти на диск). Обычно это происходит достаточно быстро, чтобы обеспечить в Redo Log Buffer место для новых записей. Однако иногда могут возникнуть задержки при записи в Redo Log Buffer.
Нарастание этой статистики происходит, когда активный 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 будет переключаться а ей нужно место в redo buffer, но все операции в redo buffer замораживаются при переключении ,до того момента когда не появиться новое место(файл не переключиться) и статистика увеличиться.
Вы должны отдавать себе отчет в том что появление этой статистики неизбежно при достаточно плотной работы транзакций .
redo buffer allocation retries
Total number of retries necessary to allocate space in the redo buffer. Retries are needed either because the redo writer has fallen behind or because an event such as a log switch is occurring.
redo entries
Number of times a redo entry is copied into the redo log buffer
redo blocks written
Total number of redo blocks written. This statistic divided by "redo writes" equals number of blocks per write.
redo wastage (redo потери)
Number of bytes wasted because redo blocks needed to be written before they are completely full. Early writing may be needed to commit transactions, to be able to write a database buffer, or to switch logs.
redo log space wait time
Total elapsed waiting time for "redo log space requests" in 10s of milliseconds. If this value for redo log space wait time is low, your log buffer size (log_buffer) is sized properly.
redo log switch interrupts
Number of times that another instance asked this instance to advance to the next log file
redo ordering marks
Number of times that a system change number was allocated to force a redo record to have an higher SCN than a record generated in another thread using the same block
redo size
Total amount of redo generated in bytes (размер журнальной информации)
redo write time
Total elapsed time of the write from the redo log buffer to the current redo log file in 10s of milliseconds
redo writer latching time
Elapsed time in 10s of milliseconds needed by LGWR to obtain and release each copy latch
redo writes
Total number of writes by LGWR to the redo log files. "redo blocks written" divided by this statistic equals the number of blocks per write
redo log space requests
Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing. Also examine the log file space and log file space switch wait events in V$SESSION_WAIT
Для того чтобы транзакция закончилась, записи повторения должны быть записаны из Redo Log Buffer в Redo Log (из памяти на диск). Обычно это происходит достаточно быстро, чтобы обеспечить в Redo Log Buffer место для новых записей. Однако иногда могут возникнуть задержки при записи в Redo Log Buffer.
Нарастание этой статистики происходит, когда активный 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 будет переключаться а ей нужно место в redo buffer, но все операции в redo buffer замораживаются при переключении ,до того момента когда не появиться новое место(файл не переключиться) и статистика увеличиться.
Вы должны отдавать себе отчет в том что появление этой статистики неизбежно при достаточно плотной работы транзакций .
SELECT name, value
FROM v$sysstat
WHERE name = 'redo log space requests';
redo buffer allocation retries
Total number of retries necessary to allocate space in the redo buffer. Retries are needed either because the redo writer has fallen behind or because an event such as a log switch is occurring.
redo entries
Number of times a redo entry is copied into the redo log buffer
select round((SELECT value FROM v$sysstat WHERE name='redo buffer allocation retries')/(SELECT value FROM v$sysstat WHERE name='redo entries')*100,3) from dual;
-- должно быть меньше 1%
redo blocks written
Total number of redo blocks written. This statistic divided by "redo writes" equals number of blocks per write.
redo wastage (redo потери)
Number of bytes wasted because redo blocks needed to be written before they are completely full. Early writing may be needed to commit transactions, to be able to write a database buffer, or to switch logs.
redo log space wait time
Total elapsed waiting time for "redo log space requests" in 10s of milliseconds. If this value for redo log space wait time is low, your log buffer size (log_buffer) is sized properly.
redo log switch interrupts
Number of times that another instance asked this instance to advance to the next log file
redo ordering marks
Number of times that a system change number was allocated to force a redo record to have an higher SCN than a record generated in another thread using the same block
redo size
Total amount of redo generated in bytes (размер журнальной информации)
redo write time
Total elapsed time of the write from the redo log buffer to the current redo log file in 10s of milliseconds
redo writer latching time
Elapsed time in 10s of milliseconds needed by LGWR to obtain and release each copy latch
redo writes
Total number of writes by LGWR to the redo log files. "redo blocks written" divided by this statistic equals the number of blocks per write
