Re: unable to produce sequential writes to redo log

a little more fiddling reveals (no, this is not the final answer):

putting the log on a raw device eliminates the read traffic (resulting in nice multiblock writes and much lower utilization numbers from iostat).

so my *guess* is that some interaction between oracle and ufs is causing ufs to perform read-ahead. i can't imagine what that would be, since oracle has no reason to do any reads on the redo log and writes should not trigger read-ahead.

how incredibly annoying...

aoki_at_faerie.CS.Berkeley.EDU (Paul M. Aoki) writes:
| i have a oracle 8.0.3 installation on a sun ultra 30 running solaris
| 2.5.1. i am running a homebrew microbenchmark that measures the
| ability of the system to absorb insertions, and i have tuned my system
| and schema so that the system is fully bottlenecked on the redo log.
| for testing purposes, i've turned off ARCHIVELOG at the database
| level. i have observed the following curious behavior:
|
| % iostat -D -l 1 sd8 5
| sd8
| rps wps util
| 23 115 35.0
| 26 123 39.6
| 25 113 37.9
| 26 128 40.1
| ^C
| %
|
| that is, the redo log disk is getting a significant number of READS in
| the steady state in spite of the fact that archiving is turned off!
| obviously, this is killing performance - it forces a large number of
| disk seeks (meaning that the disk can't do sequential writes to the
| log tail - hence the low disk utilization).
|
| my installation has two redo log files, each of which is by itself on
| a separate disk (literally - there's one unix file system on each
| disk, and there are no other files in either of the file systems). as
| mentioned, archiving is turned off; the system is set up to checkpoint
| at log switches (only), and the block checksumming options are not
| enabled.
|
| does anyone have any idea why oracle would need to perform ongoing
| reads from its redo log files? for example, is there some kind of
| bizarre read-ahead it needs to do to scrub redo log blocks before they
| are reused?

--

  Paul M. Aoki         | Computer Science Division, EECS #1776
  aoki_at_CS.Berkeley.EDU | University of California
                       | Berkeley, CA 94720-1776 USA