premmehrotra_at_hotmail.com (Prem K Mehrotra) wrote in message news:<43441e77.0409290549.1318fb84_at_posting.google.com>...
> 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.
File systems are no silver bullet. You are on the wrong track!
You *must* stop symptom fighting and *must* resize your redolog files!
Why do you think I am wrong?
Resizing your online redolog files can be done with no down time, and
is definitely more easy compared to relocating them on raw.
--
Sybrand Bakker
Senior Oracle DBA
Received on Thu Sep 30 2004 - 02:51:01 CDT
