Re: sun solaris / oracle tuning ideas

Agreed sar does exaggerate waits on I/O in an SMP environment, but even then a 20% wait on I/O seems to be on the higher side. You never really mentioned what sort of RAID is being used in the system, RAID5 or RAID0+1? The answer depends on a large extent on this. Whether you are using raw or cooked devices? how the data/index/redo logs are laid out etc. A fair answer can only be given after considering all these facts. The best bet for isolating i/o problems and finding for sure where the problem is would be to use iostat and even better use the siostat.se script in the SE toolkit. You should be looking for disks that are atleast more than 5 to 10% busy and have service times greater than 30 to 50ms. You could look at the excellent book "Sun Performance and Tuning" by Adrian Cockroft on ways to help you with this. You could also look at the excellent web site http://www.ixora.com.au for relevant answers.

Walter T Rejuney <BlueSax_at_Unforgetable.com> wrote in message news:3A27B8E9.8F334821_at_Unforgetable.com...
> Sybrand Bakker wrote:
>
> > I guess that is 1 single RAID-5 array?
> > Make sure the online redolog files and the controlfiles are *not*
 located on
> > RAID-5. This is an ultimate bottleneck for any Oracle database, let
 alone
> > for a dot com.
> > Other than that this is of course a way to broad question. Books have
 been
> > written about the interaction between Unix and Oracle.
> > You may want to check
> > James Morle Scaling Oracle 8i.
> >
> > Hth,
> >
> > Sybrand Bakker, Oracle DBA
> >
>
> I'll add to this that you should make sure that your online redo logs are
 large
> enough so that they are not switching rapidly. I try to aim for at least a
 10
> minute interval under average load. The reason for this is that every time
 a
> redo log switch occurs you will also get a checkpoint and there is a lot
 of
> overhead involved in a checkpoint. Also, make sure that you have at least
 4
> online redo logs so that you'll never encounter an instance where the redo
 log
> switch cannot occur because archiving has not been completed on the next
 log
> file to be used.
>
> Beyond that, consider adding another disk array and start striping the
 database
> usage across both arrays to reduce head contention.
>
> BTW, a 20% wio level isn't all that bad - especially considering that sar
 may
> not be very accurate in a multi-processor environment.
>
Received on Mon Dec 04 2000 - 08:28:43 CST