RE: now what??

From: Bobak, Mark <Mark.Bobak_at_il.proquest.com>
Date: Tue, 24 Aug 2004 19:26:14 -0400
Message-ID: <4C9B6FDA0B06FE4DAF5918BBF0AD82CF09EFEB26@bosmail00.bos.il.pqe>

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_at_freelists.org on behalf of Robyn
Sent:	Tue 8/24/2004 6:08 PM
To:	oracle-l_at_freelists.org
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_at_yahoo.com> wrote:
> --- Robyn <robyn.sands_at_gmail.com> 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://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_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Tue Aug 24 2004 - 18:21:55 CDT