Oracle Log Block Size
Although the size of redo entries is measured in bytes, LGWR writes the redo to the log files on disk in blocks. The size of redo log blocks is fixed in the Oracle source code and is operating system specific. Oracle's documentation uses the term "operating system block size" to refer to the log block size. Normally it is the smallest unit of I/O supported by the operating system for raw I/O, but on some operating systems it is the smallest possible unit of file system based I/O. The following table shows the most common log block sizes and some of the operating systems that use them.
Log Block Size | Operating Systems |
---|---|
512 bytes | Solaris, AIX, Windows NT/2000, Linux, Irix, DG/UX, OpenVMS, NetWare, UnixWare, DYNIX/ptx |
1024 bytes | HP-UX, Tru64 Unix |
2048 bytes | SCO Unix, Reliant Unix |
4096 bytes | MVS, MPE/ix |
The log block size is the unit for the setting of the log_checkpoint_interval, _log_io_size and max_dump_file_size parameters. Therefore, it is an important constant to know. If your operating system is not listed in the table above, then you can find your log block size using the following query.
select max(lebsz) from sys.x$kccle;
This query is available as the APT script log_block_size.sql. If your operating system is not listed in the table above, please click on the feedback icon below and send us an email so that we can add it to the list.
The log block size can also be inferred from the system statistics in StatsPack reports. There is a 16 byte header for each log block, and the size of the data area is approximately the number of bytes of redo generated (redo size) plus the number of bytes of redo space left unused (redo wastage) divided by the number of log blocks written (redo blocks written). Thus the approximate formula is
16 + (redo size + redo wastage) / redo blocks written
This formula will commonly understate the log block size by a few bytes, because it does not allow for redo that has been generated but not yet written, and the redo size statistic is commonly a little inaccurate.
----------------------------------------------------------
《高性能SQL调优精要与案例解析》
blog1:http://www.cnblogs.com/lhdz_bj
blog2:http://blog.itpub.net/8484829
blog3:http://blog.csdn.net/tuning_optmization