Comments on: Detect chained and migrated rows in Oracle – Part 1

By: Marek

Marek — Wed, 08 Feb 2012 08:03:50 +0000

Hi Tanel,
thanks for this excellent work. The query I made based on your article for detecting row migration.
Kind regards.

SELECT
NVL(VSE.USERNAME,’BACKGROUND’) USERNAME,
VSE.SID,
VSE.PROGRAM,
TFCR.VALUE AS “TABLE FETCH CONTINUED ROW”,
TFBR.VALUE AS “TABLE FETCH BY ROWID”,
ROUND(((1-(TFBR.VALUE-TFCR.VALUE)/TFBR.VALUE))*100,2) AS RATIO
FROM
(
SELECT
VSE.SID, VSE.VALUE
FROM
V$SESSTAT VSE
INNER JOIN V$STATNAME VSN
ON VSE.STATISTIC#=VSN.STATISTIC#
WHERE
UPPER(VSN.NAME)=’TABLE FETCH CONTINUED ROW’
) TFCR
INNER JOIN
(
SELECT
VSE.SID, VSE.VALUE
FROM
V$SESSTAT VSE
INNER JOIN V$STATNAME VSN
ON VSE.STATISTIC#=VSN.STATISTIC#
WHERE
UPPER(VSN.NAME)=’TABLE FETCH BY ROWID’
) TFBR
ON TFCR.SID=TFBR.SID
INNER JOIN
V$SESSION VSE
ON TFCR.SID=VSE.SID
WHERE
TFCR.VALUE>0
ORDER BY VSE.USERNAME

By: Andrew

Andrew — Thu, 24 Mar 2011 18:52:29 +0000

Hi Tanel,
may I ask you when do plan to publish Part 2 of your very interesting article?

Thanks.
Andrew

By: Donatello Settembrino

Donatello Settembrino — Thu, 25 Feb 2010 17:02:50 +0000

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

Tanel Poder — Wed, 27 Jan 2010 18:23:15 +0000

@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

Petr — Wed, 13 Jan 2010 10:29:25 +0000

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

Tanel Poder — Sun, 06 Dec 2009 16:52:40 +0000

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

Ron van Zijl — Thu, 03 Dec 2009 11:02:04 +0000

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

Blogroll Report 30/10/2009-06/11/2009 « Coskan’s Approach to Oracle — Tue, 10 Nov 2009 18:14:47 +0000

[...] Tanel Poder-Detect chained and migrated rows in Oracle Part 1 [...]

By: Tanel Poder

Tanel Poder — Sat, 07 Nov 2009 23:13:08 +0000

Thanks Uwe and Raj!

By: Raj

Raj — Sat, 07 Nov 2009 11:15:25 +0000

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