RE: Table with ~255+ columns

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <jlewisoracle@xxxxxxxxx>, "'Lok P'" <loknath.73@xxxxxxxxx>
  • Date: Mon, 30 Nov 2020 15:56:55 -0500

I’m not aware of Oracle doing anything like repatriating migrated rows or row 
pieces due to just an update in any version of Oracle.

 

I tend to think that would require the instantiation of a deity to code 
correctly and I can think of dozens of optimizations that would be of greater 
utility to the user base. Moving segments was provided to do that functionality 
in a bulletproof and relatively simple way, so I doubt we will ever see it.

 

Please let me know if I missed a memo.

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Jonathan Lewis
Sent: Monday, November 30, 2020 6:03 AM
To: Lok P
Cc: Oracle L
Subject: Re: Table with ~255+ columns

 

 

The answer to that question may be dependent on the version of Oracle and on 
how the row got to the state it was in before the update to null of the 276th 
column.

 

The first point to consider, though, is that the row HAS to be in at least two 
pieces if any column after the 255th is non-null, so updating just the 276th 
isn't likely to have any significant effect.  Given that you're on 11.2.0.4 I 
doubt if Oracle will do anything nice all you do is set that column to null - 
in fact it may simply find another way of doing something nasty, but you'd have 
to do some experiments to find out what that could be.

 

Regards

Jonathan Lewis

 

 

On Sun, 29 Nov 2020 at 19:55, Lok P <loknath.73@xxxxxxxxx> wrote:

One thing i saw, few of the stats gather statements on this table are logging 
heavy statistics "table fetch continued row" on this table, And another thing i 
notice, as per the NULL/NOT NULL data pattern i published from one of the 
sample partition, it shows out of total 277 columns , we have 276th position 
column populated with NOT NULL value for almost all the rows, so its confirm 
that we must be having the rows split into two parts as we have 276th column 
inserted as NOT NULL. And , as we have the row size restricted to ~avg 
~277bytes, so my thought was , at max it will intra row chaining considering we 
are not updating the columns in this table. But then I observed in old 
partitions that the 276th position column is UPDATED to NULL value for all of 
those rows, so in that case will Oracle try to readjust them into a single 
piece again, or it will be in the same two rowpiece only?

 

Other related posts: