Re: lacing redo logs on Raw Devices instea dof cooked File Systes,

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. Received on Tue Sep 28 2004 - 21:43:50 CDT