Re: Table with ~255+ columns

Mladen,

My comment was about migrated rows, not chained rows, ,and I specifically said that Oracle "MIGHT also do something sensible with chained rows". There are too many variations that would need investigating with chained rows (especially with the 11g bugs) to make it worth anyone's time looking at them unless they really, really, needed to.

The suggestion you've heard, though, SOUNDS LIKE a red herring. Chained rows (like migrated rows) have not moved - i.e. their rowids have not changed - therefore enabling row movement should be irrelevant. On the other hand the chained row pieces have to have their directory entries deleted if they're going to taken back to their original block, so there may be some cases where it matters.

Regards
Jonathan Lewis

On Tue, 1 Dec 2020 at 22:41, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> Hi Jonathan,
>
> I have known about that for some time, but I missed your article. However,
> I was told that enabling row movement is a requirement for moving chained
> rows back to the original block. You didn't enable row movement in your
> example. Is there any difference, can you comment on that?
>
> Regards
> On 11/30/20 5:05 PM, Jonathan Lewis wrote:
>
>
> Mark,
>
> You missed a memo - Oracle can MIGRATE a row back to its original location
> on an update:
> https://jonathanlewis.wordpress.com/2014/02/10/row-migration/
> The note is a bit old, so I really ought to check it for newer versions, I
> guess.
>
> Oracle MIGHT also do something sensible with rows that are chained because
> of column lengths when the number of columns is no more than 255, but
> anything might happen if there are more than 255 non-null columns in the
> row.
>
> Regards
> Jonathan Lewis
>
>
>

--
http://www.freelists.org/webpage/oracle-l