If an update makes a row too long to fit on its current page, the row is forwarded to another page. A reference to the row is maintained on its original page, the row’s home page, and all access to the forwarded row goes through this reference. Thus, it always takes two page accesses to get to a forwarded row. If a scan needs to read a large number of forwarded pages, the I/Os caused by extra page accesses slow performance.
reorg forwarded_rows undoes row forwarding by either moving a forwarded row back to its home page, if there is enough space, or by deleting the row and reinserting it in a new home page. If the table spans partitions, you can specify the partition with the partition_name parameter.
You can dipslay statistics on the number of forwarded rows in a table by querying systabstats and using optdiag.
The syntax for reorg forwarded_rows is:
reorg forwarded_rows table_name partition partition_name
[with {resume, time = no_of_minutes}]
For information about the resume and time options, see “resume and time options for reorganizing large tables”.
reorg forwarded_rows does not apply to indexes, because indexes do not have forwarded rows.
