Comments on: Detect chained and migrated rows in Oracle – Part 1 http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/ Oracle troubleshooting, internals and performance tuning Mon, 15 Mar 2010 01:50:11 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Donatello Settembrino http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-3928 Donatello Settembrino Thu, 25 Feb 2010 17:02:50 +0000 http://blog.tanelpoder.com/?p=479#comment-3928 Hi Tanel, Your interesting post has confirmed me a consideration that I did some time ago, or rather to consider effectively costs and benefits.For the migrated rows it could think to do an ALTER TABEL T MOVE to allow at a migrate row to fit it in a single block. But, I think it's not very easy, because after an ALTER TABLE..MOVE I should do REBUILD of the index, because if I don't do it, the query it will not be able to use the index that remains in a unusable status. And if the indexes are more than one? The operation could start to become costly... If I use ALTER TABLE..SHRINK SPACE I can bypass the indexes problem and reuse the space. But if my table, is a partitioned table with storical data and with several hundreds of millions of lines and I realize that there are migrated rows (and I have a performance problem) maybe I should isolate the problem at partition level and execute SHRINK on the single partition, provided that's worth it. Surely, this conversation it's not valid for the Chained, inasmuch if a row bigger than the dimension block is chained, it will remain chained also after an ALTER TABLE MOVE or SHRINK. Is it correct my interpretation? Thank you a lot. Best Regards Donatello Settembrino Hi Tanel,
Your interesting post has confirmed me a consideration that I did some time ago, or rather to consider effectively costs and benefits.For the migrated rows it could think to do an ALTER TABEL T MOVE to allow at a migrate row to fit it in a single block. But, I think it’s not very easy, because after an ALTER TABLE..MOVE I should do REBUILD of the index, because if I don’t do it, the query it will not be able to use the index that remains in a unusable status. And if the indexes are more than one? The operation could start to become costly…

If I use ALTER TABLE..SHRINK SPACE I can bypass the indexes problem and reuse the space. But if my table, is a partitioned table with storical data and with several hundreds of millions of lines and I realize that there are migrated rows (and I have a performance problem) maybe I should isolate the problem at partition level and execute SHRINK on the single partition, provided that’s worth it.

Surely, this conversation it’s not valid for the Chained, inasmuch if a row bigger than the dimension block is chained, it will remain chained also after an ALTER TABLE MOVE or SHRINK.

Is it correct my interpretation?

Thank you a lot.
Best Regards

Donatello Settembrino

]]> By: Tanel Poder http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-3699 Tanel Poder Wed, 27 Jan 2010 18:23:15 +0000 http://blog.tanelpoder.com/?p=479#comment-3699 <a href="#comment-3599" rel="nofollow">@Petr</a> Yep, its possible to do correlation analysis - IF you have correlated fluctuation in LIOs per segment and system wide stats. I've done something similar in past with other stats, but found it to be not reliable enough in systems with lots of diverse workloads, batch jobs running etc... @Petr
Yep, its possible to do correlation analysis – IF you have correlated fluctuation in LIOs per segment and system wide stats. I’ve done something similar in past with other stats, but found it to be not reliable enough in systems with lots of diverse workloads, batch jobs running etc…

]]> By: Petr http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-3599 Petr Wed, 13 Jan 2010 10:29:25 +0000 http://blog.tanelpoder.com/?p=479#comment-3599 Hallo Tanel, I suppose AWR/Statspack is good starting point to find out which read intensive segments have many chained rows (and are candidates for rebuild). I wrote AWR script which shows read intensive segments with high correlation between logical reads and some system statistics (here it would be 'table fetch continued row') on some day(s). Best Regards, Petr Hallo Tanel,

I suppose AWR/Statspack is good starting point to find out which read intensive segments have many chained rows (and are candidates for rebuild). I wrote AWR script which shows read intensive segments with high correlation between logical reads and some system statistics (here it would be ‘table fetch continued row’) on some day(s).

Best Regards,
Petr

]]> By: Tanel Poder http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-3292 Tanel Poder Sun, 06 Dec 2009 16:52:40 +0000 http://blog.tanelpoder.com/?p=479#comment-3292 Yes, that's exactly what ENABLE ROW MOVEMENT does - it allows also row headers move around. Normally row headers don't move around even if they migrate to other blocks, that way no index updates are needed when row migrates. Yes, that’s exactly what ENABLE ROW MOVEMENT does – it allows also row headers move around. Normally row headers don’t move around even if they migrate to other blocks, that way no index updates are needed when row migrates.

]]> By: Ron van Zijl http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-3235 Ron van Zijl Thu, 03 Dec 2009 11:02:04 +0000 http://blog.tanelpoder.com/?p=479#comment-3235 Hey Tanel, Very interesting article. Have you looked into the effects of having ROW MOVEMENT enabled on the table. Especially the 11g option to combine that with an ALTER TABLE SHRINK SPACE COMPACT may relocate the header to where the block actually is. Hey Tanel,

Very interesting article. Have you looked into the effects of having ROW MOVEMENT enabled on the table. Especially the 11g option to combine that with an ALTER TABLE SHRINK SPACE COMPACT may relocate the header to where the block actually is.

]]> By: Blogroll Report 30/10/2009-06/11/2009 « Coskan’s Approach to Oracle http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-2952 Blogroll Report 30/10/2009-06/11/2009 « Coskan’s Approach to Oracle Tue, 10 Nov 2009 18:14:47 +0000 http://blog.tanelpoder.com/?p=479#comment-2952 [...] Tanel Poder-Detect chained and migrated rows in Oracle Part 1 [...] [...] Tanel Poder-Detect chained and migrated rows in Oracle Part 1 [...]

]]> By: Tanel Poder http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-2926 Tanel Poder Sat, 07 Nov 2009 23:13:08 +0000 http://blog.tanelpoder.com/?p=479#comment-2926 Thanks Uwe and Raj! Thanks Uwe and Raj!

]]> By: Raj http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-2919 Raj Sat, 07 Nov 2009 11:15:25 +0000 http://blog.tanelpoder.com/?p=479#comment-2919 Tanel Thank you very much for this piece , especially method 2 and the ratio evaluation. When I got this issue for the first time a couple of days back , "table fetch row continued" stats in v$sesstat and "db file sequential read" in v$session_wait are the things I got when the table was merging about 2 million rows by comparing on the PK. Later on , I was able to confirm this by 'analyze table ...partition...list chained rows into chained_rows' and then I rebuilt the table. So, it very much complies with your first method. Though I would admit the second method is very elegant and gives us better metrics. However, when the issue is till on , it would be very nice to do a block dump on the blocks appearing in P2 parameter of 'db file sequential read' waits and get the confirmation. I just found a link to detect row-chaining via block dump [by Steve Adams]. Just wanted to share. http://www.ixora.com.au/q+a/0107/27152941.htm ---Raj Tanel

Thank you very much for this piece , especially method 2 and the ratio evaluation.

When I got this issue for the first time a couple of days back , “table fetch row continued” stats in v$sesstat and “db file sequential read” in v$session_wait are the things
I got when the table was merging about 2 million rows by comparing on the PK. Later on , I was able to confirm this by ‘analyze table …partition…list chained rows into
chained_rows’ and then I rebuilt the table.

So, it very much complies with your first method. Though I would admit the second method is very elegant and gives us better metrics.
However, when the issue is till on , it would be very nice to do a block dump on the blocks appearing in P2 parameter of ‘db file sequential read’ waits and get the confirmation.
I just found a link to detect row-chaining via block dump [by Steve Adams]. Just wanted to share.
http://www.ixora.com.au/q+a/0107/27152941.htm

—Raj

]]> By: Uwe Hesse http://blog.tanelpoder.com/2009/11/04/detect-chained-and-migrated-rows-in-oracle/comment-page-1/#comment-2905 Uwe Hesse Thu, 05 Nov 2009 08:17:47 +0000 http://blog.tanelpoder.com/?p=479#comment-2905 Tanel, thank you for this excellent posting about chained resp. migrated rows! Especially the part why migrated rows don't matter much in case of full table scans and the part about how to determine, whether row migration is a problem at all was very interesting to me. Keep up your good work! Kind regards Uwe Tanel, thank you for this excellent posting about chained resp. migrated rows!
Especially the part why migrated rows don’t matter much in case of full table scans and the part about how to determine, whether row migration is a problem at all was very interesting to me.
Keep up your good work!
Kind regards
Uwe

]]>