About _log_io_size

_LOG_IO_SIZE specifies the max number of redo blocks to write out per IO request.
By default the value is 1/3 of log buffer size, number in blocks.Its range is between 1/3 (default) and 1/2 (max) of the log buffer size. Note that the log block size is not the same as DB block size, which is platform-dependent. e.g, in HP-UX, it is 1K.


To check it values , below two ways work.
1. check BLOCK_SIZE from v$archived_log.
-- This is the logical block size of the archived log, which is the same as the logical block size of the online log from which the archived log was copied. The online log logical block size is a platform-specific value that is not adjustable by the user.
-- For my x86 Linux 32bit , it is 512 bytes.

2. select distinct lebsz "LGWR block size (Bytes)" from X$KCCLE;


While, The max IO size on HPUX 11 is 256K, on HPUX 10.20 it is 64K. Async IO on HPUX 11 has a limit of 1MB.

If the Oracle redo log block size on the systems are 1K, and we are doing large batch commits, and using a large log buffer to reduce LGWR IOs, then it is possible we will be doing IO writes that are larger than the OS I/O size. Hence we are not doing efficient IO writes.

e.g. 1MB Log buffer, 1/3rd of that is 341K, which will be 341 redo blocks written in redo log. This incurs two I/O request, right?

So, if we are doing large commits and we want better efficient IOs:

If HPUX 11 LVM has a max IO size of 256K, and
my redo log block size is 1K, then should I set this parameter to 256?


As lgwr writes whatever to be written out in one i/o ie it uses one system call to write all the buffered data so lgwr may flush 1/2 of the log buffer if this _log_io_size is changed. So in theory setting it to the max i/o size of the OS LVM should help.
(Never had a chance to tweak with this parameter, so can't say for sure that it'll improve performance, but looking at the facts it should.)