RE: now what??
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 24 Aug 2004 19:26:14 -0400
Robyn,
Nope, that was the point of my previous message. If the BBW is on
a data block and P3 is 130, freelist increases will do exactly
nothing and are a waste of time. Ditto w/ implementing ASSM.
Rather, these BBWs are secondary to mutiple, concurrent, db file
sequential and scattered reads. You must tune the SQL doing all
the excess I/O, and the BBW problem will disappear. Almost certainly,
it makes sense to start with the scattered reads. Determine the SQL
causing the most scattered reads, look at the execution plan, try to
find a more efficient access path for those queries.
Hope that helps,
-Mark
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Robyn
Sent: Tue 8/24/2004 6:08 PM
To: oracle-l@xxxxxxxxxxxxx
Cc:
Subject: Re: now what??
We are rebuilding a few objects, but all of the remaining buffer busy
waits are type 130/data blocks. If these waits are for data reads, is
it still advisable to increase freelists? I thought I had read that
automatic segment space management would eliminate the need to worry
about freelists. Also, Paula's comment about additional io load
concerned me - is there an additional io load with ASSM I should be
concerned about? I've been using ASSM on some databases already and
thus far, haven't seen any problems. (except with Lob's) What's the
better approach for the objects that do get rebuilt? I've been aiming
for LMT, uniform extents and ASSM, but I'll go slow with ASSM if
others have seen problems.
tia ... Robyn
On Tue, 24 Aug 2004 11:27:12 -0700 (PDT), Paul Drake
<discgolfdba@xxxxxxxxx> wrote:
> --- Robyn <robyn.sands@xxxxxxxxx> wrote:
> > Mark,
>
> > These are primarily data buffer / 130 type
> > waits and the sql causing most of them is
> > cursor type junk that needs to be
> > rewritten. I added freelists to a few
> > objects yesterday and saw the numbers decrease
> > slightly, but I believe everything that is left
> > falls exactly into this category.
>
> > sigh .. further confirmation that this is going to
> > take a long, long time ...
>
> > Robyn
>
> Robyn,
>
> I believe that altering the table for freelists and
> inittrans only affects blocks as they are unformatted.
> Existing blocks that are already allocated are still
> as they were.
>
> a re-org of the affected tables (and their indexes,
> afterwards) may be in order.
>
> hth.
>
> Pd
>
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/ms-tnef
-- File: winmail.dat
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
