<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Row chaining in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678926#M798530</link>
    <description>Hi mehul,&lt;BR /&gt;&lt;BR /&gt;Chaining is a serious problem and hard to solve...&lt;BR /&gt;&lt;BR /&gt;Chaining happens when a row that fitted into one block (at insert time) needs, after been updated, 2 blocks: this will strongly impact performance for some tables. You can "feel" this impact if you try to update rows from a highly chained table...&lt;BR /&gt;&lt;BR /&gt;Here are the thing you need is to:&lt;BR /&gt;&lt;BR /&gt;1 - Be sure you have the chained_rows table in SYSTEM: if you don't have this table, run @$ORACLE_HOME/rdbms/admin/utlchain.sql&lt;BR /&gt;&lt;BR /&gt;2 - Execute the following query (never run the analyze table on SYS and SYSTEM tables):&lt;BR /&gt;&lt;BR /&gt;select 'ANALYZE table '||owner||'.'||table_name||' LIST CHAINED ROWS;' &lt;BR /&gt;from all_tables &lt;BR /&gt;where owner not in ('SYS', 'SYSTEM')&lt;BR /&gt;order by owner;  &lt;BR /&gt;&lt;BR /&gt;3 - Execute the result of above query&lt;BR /&gt;&lt;BR /&gt;4 - Check the chained_rows table:&lt;BR /&gt;&lt;BR /&gt;select count(*), table_name &lt;BR /&gt;from system.chained_rows &lt;BR /&gt;group by table_name&lt;BR /&gt;having count(*) &amp;gt; 50 &lt;BR /&gt;order by 1 desc;&lt;BR /&gt;&lt;BR /&gt;5 - For the tables above you need to check the percentage of CHAINED ROWS/TOT ROWS and decide if you have a chaining situation (more than 5%?)&lt;BR /&gt;&lt;BR /&gt;6 - Avoiding future chaining:&lt;BR /&gt;&lt;BR /&gt;In problematic tables increase PCTFREE, for example, from 20 to 30 (you may need to decrease PCTUSED since PCTUSED+PCTFREE cannot exceed 100):&lt;BR /&gt;&lt;BR /&gt;ALTER TABLE &lt;OWNER&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;PCTFREE    x&lt;BR /&gt;PCTUSED    y&lt;BR /&gt;&lt;BR /&gt;7- Solving the present chaining rows:&lt;BR /&gt;&lt;BR /&gt; a) BE SURE no one is logged to the database&lt;BR /&gt; b) BE SURE you have a good backup&lt;BR /&gt; c) Do FOR EACH TABLE:&lt;BR /&gt;&lt;BR /&gt;alter table &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;disable all triggers;&lt;BR /&gt;&lt;BR /&gt;drop table migrated_rows; -- the first time this will fail&lt;BR /&gt;&lt;BR /&gt;create table migrated_rows as&lt;BR /&gt;    select orig.* &lt;BR /&gt;    from &lt;OWN&gt;.&lt;TABLE_NAME&gt; orig, system.chained_rows cr&lt;BR /&gt;    where orig.rowid = cr.head_rowid and&lt;BR /&gt;    cr.table_name = '&lt;TABLE_NAME_UPPER_CASE&gt;';&lt;BR /&gt;&lt;BR /&gt;select count(*) from migrated_rows; -- Confirm this is the same count that the one in chained_rows for this table&lt;BR /&gt;&lt;BR /&gt;delete from &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;where rowid in (select head_rowid from system.chained_rows where table_name = '&lt;TABLE_NAME_UPPER_CASE&gt;');&lt;BR /&gt;&lt;BR /&gt;commit;&lt;BR /&gt;&lt;BR /&gt;insert into &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;select * from migrated_rows;&lt;BR /&gt;&lt;BR /&gt;commit;&lt;BR /&gt;&lt;BR /&gt;alter table &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;enable all triggers;   &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;PS: this should be a database thread.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Best Regards,&lt;BR /&gt;&lt;BR /&gt;Eric Antunes&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME_UPPER_CASE&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME_UPPER_CASE&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWNER&gt;</description>
    <pubDate>Fri, 25 Nov 2005 11:13:01 GMT</pubDate>
    <dc:creator>Eric Antunes</dc:creator>
    <dc:date>2005-11-25T11:13:01Z</dc:date>
    <item>
      <title>Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678923#M798527</link>
      <description>If locally managed table space is enabled then will it eliminates row chaining issue.Our database has a locally managed tablespace(Oracle9i) and executed a sql-script to see any row chaing.I observed that there is a 4 to 5% of row chainging for some tables which is most oftenly used.Will it create any performance issue and need to eliminate the issue by importing table which has a row chaining.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Mehul</description>
      <pubDate>Fri, 25 Nov 2005 06:17:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678923#M798527</guid>
      <dc:creator>mehul_3</dc:creator>
      <dc:date>2005-11-25T06:17:29Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678924#M798528</link>
      <description>Shalom mehul,&lt;BR /&gt;&lt;BR /&gt;There are database defragmentation procedures that may assist with this problem. They are probably available from metalink.oracle.com or technet.oracle.com&lt;BR /&gt;&lt;BR /&gt;SEP</description>
      <pubDate>Fri, 25 Nov 2005 06:35:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678924#M798528</guid>
      <dc:creator>Steven E. Protter</dc:creator>
      <dc:date>2005-11-25T06:35:37Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678925#M798529</link>
      <description>4-5% row chaining does not sound like a major performance issue to me. Surely there is bigger fish to fry.&lt;BR /&gt;&lt;BR /&gt;Best I understand it, row chaining has nothing to do with whether tablespaces are locally managed or not. That only determines where/how the administration for free pages is handled. Row chaining is all about block sizes and PCTFREE no?&lt;BR /&gt;&lt;BR /&gt;When I feed your opening line: "locally managed table space is enabled then will it eliminates row chaining" into google is comes up with several relevant articles for your question. I suggest you check some of those out first, and then come back with detailed question. For example:&lt;BR /&gt;&lt;BR /&gt;a) &lt;A href="http://www.embarcadero.com/resources/tech_papers/managingspace.pdf" target="_blank"&gt;http://www.embarcadero.com/resources/tech_papers/managingspace.pdf&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;b) &lt;A href="http://www.dbasupport.com/oracle/ora9i/rowchaining.shtml" target="_blank"&gt;http://www.dbasupport.com/oracle/ora9i/rowchaining.shtml&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;hth,&lt;BR /&gt;Hein.&lt;BR /&gt;</description>
      <pubDate>Fri, 25 Nov 2005 09:59:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678925#M798529</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2005-11-25T09:59:20Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678926#M798530</link>
      <description>Hi mehul,&lt;BR /&gt;&lt;BR /&gt;Chaining is a serious problem and hard to solve...&lt;BR /&gt;&lt;BR /&gt;Chaining happens when a row that fitted into one block (at insert time) needs, after been updated, 2 blocks: this will strongly impact performance for some tables. You can "feel" this impact if you try to update rows from a highly chained table...&lt;BR /&gt;&lt;BR /&gt;Here are the thing you need is to:&lt;BR /&gt;&lt;BR /&gt;1 - Be sure you have the chained_rows table in SYSTEM: if you don't have this table, run @$ORACLE_HOME/rdbms/admin/utlchain.sql&lt;BR /&gt;&lt;BR /&gt;2 - Execute the following query (never run the analyze table on SYS and SYSTEM tables):&lt;BR /&gt;&lt;BR /&gt;select 'ANALYZE table '||owner||'.'||table_name||' LIST CHAINED ROWS;' &lt;BR /&gt;from all_tables &lt;BR /&gt;where owner not in ('SYS', 'SYSTEM')&lt;BR /&gt;order by owner;  &lt;BR /&gt;&lt;BR /&gt;3 - Execute the result of above query&lt;BR /&gt;&lt;BR /&gt;4 - Check the chained_rows table:&lt;BR /&gt;&lt;BR /&gt;select count(*), table_name &lt;BR /&gt;from system.chained_rows &lt;BR /&gt;group by table_name&lt;BR /&gt;having count(*) &amp;gt; 50 &lt;BR /&gt;order by 1 desc;&lt;BR /&gt;&lt;BR /&gt;5 - For the tables above you need to check the percentage of CHAINED ROWS/TOT ROWS and decide if you have a chaining situation (more than 5%?)&lt;BR /&gt;&lt;BR /&gt;6 - Avoiding future chaining:&lt;BR /&gt;&lt;BR /&gt;In problematic tables increase PCTFREE, for example, from 20 to 30 (you may need to decrease PCTUSED since PCTUSED+PCTFREE cannot exceed 100):&lt;BR /&gt;&lt;BR /&gt;ALTER TABLE &lt;OWNER&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;PCTFREE    x&lt;BR /&gt;PCTUSED    y&lt;BR /&gt;&lt;BR /&gt;7- Solving the present chaining rows:&lt;BR /&gt;&lt;BR /&gt; a) BE SURE no one is logged to the database&lt;BR /&gt; b) BE SURE you have a good backup&lt;BR /&gt; c) Do FOR EACH TABLE:&lt;BR /&gt;&lt;BR /&gt;alter table &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;disable all triggers;&lt;BR /&gt;&lt;BR /&gt;drop table migrated_rows; -- the first time this will fail&lt;BR /&gt;&lt;BR /&gt;create table migrated_rows as&lt;BR /&gt;    select orig.* &lt;BR /&gt;    from &lt;OWN&gt;.&lt;TABLE_NAME&gt; orig, system.chained_rows cr&lt;BR /&gt;    where orig.rowid = cr.head_rowid and&lt;BR /&gt;    cr.table_name = '&lt;TABLE_NAME_UPPER_CASE&gt;';&lt;BR /&gt;&lt;BR /&gt;select count(*) from migrated_rows; -- Confirm this is the same count that the one in chained_rows for this table&lt;BR /&gt;&lt;BR /&gt;delete from &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;where rowid in (select head_rowid from system.chained_rows where table_name = '&lt;TABLE_NAME_UPPER_CASE&gt;');&lt;BR /&gt;&lt;BR /&gt;commit;&lt;BR /&gt;&lt;BR /&gt;insert into &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;select * from migrated_rows;&lt;BR /&gt;&lt;BR /&gt;commit;&lt;BR /&gt;&lt;BR /&gt;alter table &lt;OWN&gt;.&lt;TABLE_NAME&gt;&lt;BR /&gt;enable all triggers;   &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;PS: this should be a database thread.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Best Regards,&lt;BR /&gt;&lt;BR /&gt;Eric Antunes&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME_UPPER_CASE&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME_UPPER_CASE&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWN&gt;&lt;/TABLE_NAME&gt;&lt;/OWNER&gt;</description>
      <pubDate>Fri, 25 Nov 2005 11:13:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678926#M798530</guid>
      <dc:creator>Eric Antunes</dc:creator>
      <dc:date>2005-11-25T11:13:01Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678927#M798531</link>
      <description>hi mehul,&lt;BR /&gt;&lt;BR /&gt;Changes in Database storage parameters like pctfree/pctused can avoid row chaining/migration in the future. You will need to make some calculations of course. &lt;BR /&gt;&lt;BR /&gt;Actually, row chaining can happen without updates: all you need is a few of the rows to be larger than the block size. &lt;BR /&gt;&lt;BR /&gt;hope this helps too&lt;BR /&gt;&lt;BR /&gt;kind regards&lt;BR /&gt;yogeeraj</description>
      <pubDate>Sat, 26 Nov 2005 02:43:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678927#M798531</guid>
      <dc:creator>Yogeeraj_1</dc:creator>
      <dc:date>2005-11-26T02:43:12Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678928#M798532</link>
      <description>I can't change the size of pctused/pctfree as I used locally managed tablespace.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Mehul</description>
      <pubDate>Sat, 26 Nov 2005 02:47:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678928#M798532</guid>
      <dc:creator>mehul_3</dc:creator>
      <dc:date>2005-11-26T02:47:58Z</dc:date>
    </item>
    <item>
      <title>Re: Row chaining</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678929#M798533</link>
      <description>Mehul,&lt;BR /&gt;&lt;BR /&gt;From what I read, I think you meant ROW MIGRATION, which is different from ROW CHAINING. While the latter is almost always unavoidable (most times it has to do with LOBs), the former can be solved for example with the nice procedure provided by Eric. In particular, I believe it would be effective for the 4-5% of row migration you have; depending on the size of the table, you can also consider 'alter table move' but be advised you have to rebuild the associated indexes afterwards since they'll become unusable. Bottom line is that you need to schedule a downtime. However, I wouldnt do that unless I find that 4-5% is substantially affecting performance.&lt;BR /&gt;&lt;BR /&gt;On the other hand, in locally managed tablespace you CAN define PCTFREE, but you CANNOT set PCTUSED (that's a common misconception). So, it would be more important to adjust the PCTFREE value of the segment to avoid row migration to happen in new blocks (extents).&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Ariel&lt;BR /&gt;</description>
      <pubDate>Sun, 27 Nov 2005 20:44:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/row-chaining/m-p/3678929#M798533</guid>
      <dc:creator>Ariel Cary</dc:creator>
      <dc:date>2005-11-27T20:44:00Z</dc:date>
    </item>
  </channel>
</rss>

