Re: Problem wih Oracle reads from the redo logs.

Hello Ravi,

Oracle writes to the log files in groups of log blocks. The number of block written in a single write depends on what is available in the log_buffer at the time. On Solaris a log block is just 512 bytes. So Oracle is doing writes of sizes much smaller than your filesystem block size, and they are sync write. To satisfy such a write, the file system layer has to read the target filesystem block, modify it, and then write it back. That is probably where your reads are coming from. The only solution to this prevalent problem is to use raw plexes for you log files.

By the way, striping log files is only of benefit to databases that do large DML operations with very few commits.

Regards,
Steve Adams

In article <37135CE9.EE7AA9EC_at_sabre.com>,   Ravi Kommalapati <ravi_kommalapati_at_sabre.com> wrote:
> Hello,
> We have created a volume for redo logs by striping across 6 disks
> using the Veritas volume manger, and we have 4 redo log files 250M each,
> there are no other files on this volume other than the redo logs.
> Currently the redo logs switch every 7 minutes during peak usage. The
> database is in no archivelog mode that is we are not archiving the redo
> logs. We are monitoring the I/O activity through VXSTAT a veritas tool
> for all our database volumes.
> On analyzing the output from vxstat we find that the service wait
> times on redo log volumes are terrible with a huge waits on redo reads
> ?!! The question is why does ORACLE read from the redo logs and that too
> such a huge number of blocks, when it was never in archive log mode? and
> if there is a reason for its reads, how can it be tuned? I have pasted
> an extract of the vxstat output for redo log volume and a copy of the
> init.ora file.
> Any help will be greatly appreciated.
> Ravi Kommalapati
> ravi_kommalapati_at_sabre.com

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Tue Apr 13 1999 - 21:37:32 CDT