http://www.ixora.com.au/tips/creation/raw_log_files.htm

http://www.ixora.com.au/tips/creation/raw_log_files.htm

excerpt:

        "Conclusion

         There are two primary performance dangers with file system
         based log files: 

         1.Partial block writes and write fragmentation will severely
           degrade the performance of most redo writes, if the
           writes are buffered. To avoid this it is necessary to
           either use raw log files, or to use a file system that
           supports direct I/O.
      
         2.If multiple file system based log file members must be
           written, the writes will either be performed in series, or
           in parallel but inefficiently. To avoid this it is
           necessary to either use raw log files, or to use hardware
           or software  mirroring in preference to redo log
           multiplexing. 

 Copyright =A9 2000 Ixora Pty Ltd "

---

http://www.ixora.com.au/tips/creation/raw_datafiles.htm

excerpt: 

         "Why Raw Datafiles 

          In a previous tip, Why Raw Log Files, we introduced some of
          the dangers of file system based log files. Those factors 
          can also affect datafile I/O. 



...


          What are delayed write backlogs? 

          It is possible, merely by copying a large file, to fill the
          file system cache with delayed write buffers. Shortly
          afterwards, the operating system will attempt to flush
          those buffers to disk. This can create an enormous queue in
          the device driver or logical volume manager of maybe tens
          of thousands of write requests against a single disk.
          Somewhere in that queue there will also be a few write
          requests to update the file system metadata, such as the
          space allocation maps. These requests wait their turn in
          the queue, and while they wait locks are held on the file
          system, which prevent all file system access. On large
          memory systems, this can cause users who are accustomed to
          sub-second response times to see response times in the
          order of a minute or more. 

          Oracle itself does not use delayed writes. Oracle opens all
          files explicitly for synchronous reading and writing.
          Nevertheless, access to all file system based files is
          susceptible to delayed write backlogs, and although the
          risk can be reduced in various ways, the only true solution
          is to use raw. 



...


          We have seen file system based Oracle databases brought to
          a standstill ... and in each
          case the problem has been resolved by converting to raw. Of
          course, we have also seen plenty of file system based
          Oracle databases that have not had any serious file system
          related performance problems. Nevertheless, our standard
          advice is that raw has a slight performance advantage, and
          none of these potential performance traps, and should
          therefore be adopted without hesitation for all performance
          critical Oracle databases.