Comments on: Continued Rows

By: I Wish « Oracle Scratchpad

I Wish « Oracle Scratchpad — Fri, 16 Dec 2011 18:32:45 +0000

[...] difference between analyze and dbms_stats Anomalies with counting continued row activity Share this:TwitterLike this:LikeBe the first to like this post. Leave a [...]

By: Jonathan Lewis

Jonathan Lewis — Mon, 05 Jul 2010 18:38:47 +0000

Marcus,

Sorry, I missed this comment when you first posted it.
Your idea has some merit – but may be open to error; but I think I might look at “table fetch by rowid” as the basis for comparison rather than “session logical reads”.

The possible error, though, is implied by my comments about seeing low values for the “table fetch continued row” in some circumstances because Oracle is counting blocks visited for continued rows rather than the rows themselves – it’s possible that your estimates would be under-estimates. (Note that I couldn’t remember where or why I had seen the phenomenon, though).

The other thought to bear in mind is that even if the system stats suggest that the “table fetch continued row” is a small fraction of the fetches, it’s possible that a single, critical, session is the one that’s suffering from the problem and still needs some correction. (And there’s always the issue that the fraction looks low because you have two simultaneous problems – a high count for continued fetches, and a very high count for session logical reads)

By: Jonathan Lewis

Jonathan Lewis — Mon, 05 Jul 2010 18:25:36 +0000

Joaquin,

Yes, it’s possible. Proof is left as an exercise for the reader.

Simplest case:
update a row to make it much longer, commit, check for migration, then update the row to make it shorts, commit, check where it ends up.

By: Joaquin Gonzalez

Joaquin Gonzalez — Mon, 05 Jul 2010 11:51:23 +0000

Jonathan,

“what happens if the row has been updated so that it has migrated back to its original position ?”

Is that possible? I thought it wasn’t.

By: Marcus Mönnig

Marcus Mönnig — Thu, 17 Jun 2010 14:51:42 +0000

A bit off-topic: Does it generally make sense to compare deltas for ‘session logical reads’ and ‘table fetch continued row’ for an interval to prove if chained rows are an instance-wide problem or not? E.g. I have a 9.2 DB that has 1.400 times more ‘session logical reads’ than ‘table fetch continued row’ for an high load interval of 6 hours. Can I deduct that (instance-wide) it’s not worth the effort to reorganize or go through export/import to get lower the number of chained rows?

By: Jonathan Lewis

Jonathan Lewis — Sat, 12 Jun 2010 14:38:22 +0000

Jason,

(Though not curious enough to actually try it myself. ;) )

This is exactly why I have a large document with lots of headings like “Flashback Query” with questions under them like: “possible side effects with migrated / chained rows ?”

There are lots of vague ideas I have that might be worth checking, but aren’t worth the effort until I see a client having problems with some feature and some of the questions look as if they might be relevant.

By: Jonathan Lewis

Jonathan Lewis — Sat, 12 Jun 2010 14:33:12 +0000

Gary,

“Doesn’t that mean that for chained, as opposed to migrated, records it would have to follow the pointer from block 1 to 10 so that it knows both the rowid and value ?”

That’s what I believe happens – which is why my earlier comment says:

so, with suitably modified data, the count and the create index would report “table fetch continued row”

By: Jason Bucata

Jason Bucata — Fri, 11 Jun 2010 03:41:23 +0000

I’d be curious to see what happens when doing Flashback Query. (Though not curious enough to actually try it myself. ;) )

By: Gary

Gary — Thu, 10 Jun 2010 22:46:03 +0000

“A migrated row knows where it came from (the row piece carries the “head rowid”) a chained rowpiece does not”
With this, say you have a record this is chained with the first part on block 1 and the second part on block 10. The column you are indexing is at the end of the record, so is on block 10. If you are full scanning to build the index then, when you pass block 1 you can’t create the index entry because you don’t know the column value, but when you hit block 10 you know the value but not the “head rowid”. Doesn’t that mean that for chained, as opposed to migrated, records it would have to follow the pointer from block 1 to 10 so that it knows both the rowid and value ? Or will it store the “head rowid” and “chain rowid” from block 1 and tie that up with the index value when it reaches block 10 ?

By: Jonathan Lewis

Jonathan Lewis — Thu, 10 Jun 2010 10:51:01 +0000

Flado,

A problem with using analyze and checking the chain_cnt appears in another blog item: http://jonathanlewis.wordpress.com/2009/04/30/analyze-this

The optimizer uses the chain_cnt to cost an indexed access if it has been set – even though dbms_stats() won’t set it.