Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: A little baffled by "chained rows"....
"Tanel Poder" <change_to_my_first_name_at_integrid.info> wrote in message news:<3f389cba_1_at_news.estpak.ee>...
> Hi!
>
> How many chained rows you got before exp/imp and now? In percentage, in
> mean. If avg row is 700 bytes, maybe you got lots of 200 byte rows, but also
> some 9000 byte ones?
>
> How many columns do you have in your table? If over 255, then intra-block
> chaining mechanism is used to represent more than 255 columns in a row.
> (There's only one byte for number of columns in row structure, thus some
> workaround had to be used..)
>
> Tanel.
>
> "Jodi Elisabeth" <theheadchick_at_elisabethco.com> wrote in message
> news:Gy%Za.12777$Pb7.475765_at_twister.southeast.rr.com...
> > and I say "chained rows" but they aren't really, they must be migrated
> > because my block size is 8K and my avg row len for this table is 700
> bytes.
> >
> > SO, that said...I had a theory and I ran it past oracle...My theory to fix
> > the "chained" rows was to copy the data out to another table (create table
> > as select OR insert into select *), drop the offending table, recreate the
> > table (with the new pctfree and pctused params) as select from my copy.
> >
> > Oracle said SURE, that's one way to fix it all in one swoop without having
> > to exp/imp.
> >
> > Well, I didn't work. I still have the chained rows. I was hoping to avoid
> > the whole exp/imp thing...is that the only thing that will work for this?
> > How is that fundamentally different than what I tried?
> >
> > Thanks!
> > Jodi (the baffled!)
> >
> >
Jodi, because you copied the data from the existing table to a new one the presence of chained rows should mean that you do in fact have some rows larger than a block. There was also no need to copy the data back since you could instead probably have used the rename command to rename the original table and then create table as select to rebuild it, drop the constraints, indexes, triggers off the old table, rebuild them on the new table. This usually saves a little time.
HTH -- Mark D Powell -- Received on Tue Aug 12 2003 - 08:09:49 CDT