Path: text.usenetserver.com!out02b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!l12g2000cwl.googlegroups.com!not-for-mail
From: "Anurag Varma" <avoracle@gmail.com>
Newsgroups: comp.databases.oracle.server
Subject: Re: Oracle Chaining
Date: 12 Dec 2006 14:23:44 -0800
Organization: http://groups.google.com
Lines: 26
Message-ID: <1165962224.745377.283610@l12g2000cwl.googlegroups.com>
References: <1165959325.251501.186110@80g2000cwy.googlegroups.com>
NNTP-Posting-Host: 13.13.137.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Trace: posting.google.com 1165962230 23103 127.0.0.1 (12 Dec 2006 22:23:50 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 12 Dec 2006 22:23:50 +0000 (UTC)
In-Reply-To: <1165959325.251501.186110@80g2000cwy.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: l12g2000cwl.googlegroups.com; posting-host=13.13.137.2;
   posting-account=Bjij0w0AAACWMZ9jVkCMjBKLT0Yf1PAH
Xref: usenetserver.com comp.databases.oracle.server:419070
X-Received-Date: Tue, 12 Dec 2006 17:23:50 EST (text.usenetserver.com)


aprinsloo@sagetelecom.net wrote:
> Oracle 9i standard.
>
> Ive noticed by looking at DBA_TABLES that some tables have excessive
> CHAIN_CNT, the highest been 3266085 on a 45 million row table.
> I've set the pct_free to 35 up from 10 but the CHAIN_CNT continues to
> climb, is there anything else I can try ?
>
> Thx in advance

Find out if its row chaining or row migration! If its row chaining,
then there is nothing
you can do about it assuming you don't want the drastic route of
increasing block size.
Row chaining refers to a row which does not fit in the existing block
size. Tweaking pctfree
is not going to do anything about it.
If its row migration then increasing pctfree might decrease incidences
of future row migrations.
For row migration in existing data, you might want to "alter table
move" followed by rebuilding
all indexes to fix the issue...

Anurag