wizofoz2k_at_yahoo.com.au (Noons) wrote in message news:<73e20c6c.0409281843.398a7a31_at_posting.google.com>...
> premmehrotra_at_hotmail.com (Prem K Mehrotra) wrote in message news:<43441e77.0409280712.2ae1762d_at_posting.google.com>...
> > Our application/database is clearly disk bound. We are using SAN. All
> > our file systems are cooked.
>
> Yeah, but is it disk writes or disk reads?
>
> > bypasses UNIX buffer so should have some performance improvements. We
> > have 3 redo logs of 10K size. On the average every 3 minute a redo log
> > switch is made.
>
> I believe you meant 10M. If you get a switch every three minutes,
> then you probably need to bump your redo log size to 50M or even 100M
> to get less checkpointing. But that is not your problem. Your problem
> is that you are generating 10M of redo every three minutes. That will most
> likely be the bottleneck. Not the checkpointing. Check if the devices
> supporting the redo log file system have I/O queues (with sar -d or
> iostat).
> If so, you need to improve the write speed. And that means moving the
> redo log files to raw (or using a specialised file system such as
> Veritas vxfs).
>
> You might also want to consider additional measures.
> Check out the following:
> - Are you generating a lot of undo (rollback)? Is it causing I/O queueing
> in its supporting devices? If so, then move it as well to a separate
> raw device.
> - Is your DBWR causing waits? If so, then increase the number of
> dbwr servers (even if you have asynch_io turned on!).
> - Check out which file systems are getting hammered, then spread
> the load across more disks for these. Or move some of the tablespaces
> in them to other file system(s).
>
> > Does any one see any problem in using raw devices for redo logs only?
>
> No, not at all. In fact, that is my first choice in databases with
> lots of update activity and problems with I/O queueing.
We alreayd us evxfs file system. I woouldthink raw is better than
vxfs? Appreciate your answer.
Received on Wed Sep 29 2004 - 08:49:14 CDT
