Re: Row migrated in new data blocks

"Mark D Powell" <Mark.Powell_at_eds.com> wrote:
> Sybrand Bakker wrote:
> > On 17 Aug 2006 17:13:34 GMT, xhoster_at_gmail.com wrote:
> >
> > >Will migrated rows effect full table scans if the rowid for the
> > >selected rows are needed for some reason? Does the new location of
> > >the row contain a pointer back to the original block it was migrated
> > >from, so that the real rowid can be determined solely from the new
> > >location? If not, it seems like the only way to get the rowid and the
> > >data at the same time is for the FTS to break rank when it encounters
> > >a pointer to a migrated row and go get the row data rather than
> > >waiting for it run across that data during the normal course of the
> > >scan.
> >
> >
> > The old row contains a pointer to the new one, and a block read is a
> > block read, so the migrated row is read immediately.
> >
> > --
> > Sybrand Bakker, Senior Oracle DBA
>
> I am not sure I understand Sybrand's response so I am going to repeat
> what happens.
>
> Being that the question was in reference to a full table scan the
> migrated row header is ignored and the row piece is read when the full
> scan reads the block that contains the migrated row piece. This block
> could be read before or after the block that contains the migrated row
> header, that is, the original block that contained the row before it
> was migrated.

OK, but now let's say that Oracle, for some reason, needs the rowid of the row (say, because "rowid" is in the select list). The rowid of the row would be, AFAICT, the rowid of the head-piece, not the rowid of the data-piece. Once the FTS finds the data-piece, it obviously knows the rowid of the data-piece. But how does it figure out the rowid of the corresponding head-piece? Does the data pieces have a reverse pointer, going back to the head-piece?

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB