Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: resolving buffer busy waits

Re: resolving buffer busy waits

From: Noons <wizofoz2k_at_yahoo.com.au>
Date: 15 Sep 2003 15:53:23 -0700
Message-ID: <73e20c6c.0309151453.12a643e2@posting.google.com>


cdyke_at_corp.home.nl (Casey) wrote in message news:<8bc6b8d7.0309150722.3e002b14_at_posting.google.com>...
> what i can add (or expand on my first post) is the following:
>
> - all file systems are UFS
> - this is due to usage of cluster software that was imcompatible
> w/veritas
> - UFS at 2.8 can make use of forcedirectio option, but this caused
> issues early on in the project (last year) and was turned off

up until now nothing weird.

> - archive file systems are striped in w/the datafile file systems

that *is* weird. What do you mean "striped in"? Never seen that before.

>
> and here's something to either laugh at or simply ponder: we have two
> datafile file systems - one had very recently jumped to 92% capacity
> after a normal growth extension. at a stretch, i decided to relocate
> a file, taking that file system down to 87%. these odd numbers w/in
> oracle did drop, but are still whacky -- however, we nearly doubled
> the number of checkpoints completed in an avg 24 hour period that
> evening after the outage. that throughput increase manifested itself
> in much higher application throughput and has been sustained since.
> IO problem you say?

I'd say you have very bad UFS fragmentation. I'd suggest looking into this. It can happen easily when file systems have mixed use, ie, they are used for both database data files and other files (temp, OS, file server, print server, etc). Isolate the database files into their own file systems, fully dedicated. Make the file system block size the same as the database block size. Try to not rely on autoextend. Allocate the datafiles with expected final growth sizes. If you MUST rely on autoextend, then use big NEXT increments and isolate each database file in its own file system mount point. Do NOT mix other files in with the database files in the same file system. Another option is to use raw files. If you have access to a good LVM, then it is easy to set up and worth a try.

>
> in summation: there are a lot of oddities here. but i have to tread
> carefully.

Nothing wrong with that.

>
> ah - nuno - no NFS ... that i can say w/certainty!
>

that's a relief! :)

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Mon Sep 15 2003 - 17:53:23 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US