Row migrations cannot be avoided, and increasing the size of each block can reduce the likelihood of row migration, but can also result in greater space waste. This balancing point needs to be determined according to the application.
"Row Migration", Oracle data Saved by block, if a piece of data disk space can not save a data (such as the previous 1K, now update to 2K, and the current block of less than 1K of free space), the new data will be saved to another new block, Then save the address connection for a new location in the previous block.
Like what
The data is stored in a block with 2 free space in the middle, and now the four rows of data have to be enlarged. If a single block is found to be low on free space, evaluate whether the merged free space satisfies
"Row Migration" occurs when you evaluate that the merged free space still does not meet the space requirements
New fourth row data is saved in a new block, and a connection to the new address is saved in the original block. This is the process of row migration.
What is the impact of a 2-row migration?
If you read this line through an index, the index points to the original block, and the block points to the new block. To get concrete row data, it is not generally possible to execute two or so of I/O to get the row data. Alone, this is not a big problem, and it's not even noticeable at all. However, if the proportion of such rows is large and there are a large number of users accessing the rows, you will notice the side effects. The speed at which the data is accessed begins to slow (additional I/O and the I/O-related latches increase access time), the efficiency of the buffer cache begins to fall (two blocks need to be cached, but only one block is needed if the row does not migrate), and the size of the table increases in complexity. For these reasons, you may not want to migrate rows.