Saturday, January 13, 2018

Row Chaining and Migrating

Whenever  DML operation performed in oracle database ,there are two situations where a data row may not fit into a single data block:

Row chaining The row is too large to fit into one data block when it is first inserted, or the table contains more than 255 columns (the maximum for a row piece).In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment.Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG or LONG RAW.Row chaining in these cases is unavoidable.Due to  insertion of a large row in a data block. The row is too large for the left block, so the database chains the row by placing the first row piece in the left block and the second row piece in the right block.

row_chaning


Row Migration  A row that originally fit into one data block has one or more columns updated so that the overall row length increases, and the block's free space is already completely filled.
In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block.
Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row.The rowid of a migrated row does not change.The left block contains a row that is updated so that the row is now too large for the block. The database moves the entire row to the right block and leaves a pointer to the migrated row in the left block.

row_migration
When a row is chained or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row.
  • Row chaining is typically caused by INSERT operation.
  • Row migration is typically caused by UPDATE operation

No comments:

Post a Comment

About the Author : Anurag Pandey | Database cloud Architect | Oracle | SQL Server | PostgreSQL | AI and Data Platform Enthusiast

Anurag Pandey is a Database Architect with expertise in Oracle, PostgreSQL, SQL Server, Linux, and enterprise database platforms and specializes in database architecture, performance tuning, high availability, disaster recovery, cloud modernization, and operational excellence. With extensive experience in enterprise-scale environments, Anurag is passionate about leveraging AI, automation, and modern data platforms to improve reliability, scalability, and business outcomes. He actively contributes to technical communities through knowledge sharing, architecture guidance, and thought leadership in database and data engineering domains.

Follow more articles at

Visit Blog

Oracle Database Deep Health Check Checklist

Oracle Database Deep Health Check Checklist Recommended assessment levels Level Purpose Typical scope L1 Operational health Availability, sp...