One of the requirements for data-only-locked tables is that the row ID of a data row never changes (except during intentional rebuilds of the table). Therefore, updates to data-only-locked tables can be performed by the first two methods described above, as long as the row fits on the page.
But when a row in a data-only-locked table is updated so that it no longer fits on the page, a process called row forwarding performs the following steps:
The row is inserted onto a different page, and
A pointer to the row ID on the new page is stored in the original location for the row.
Indexes do not need to be modified when rows are forwarded. All indexes still point to the original row ID.
If the row needs to be forwarded a second time, the original location is updated to point to the new page—the forwarded row is never more than one hop away from its original location.
Row forwarding increases concurrency during update operations because indexes do not have to be updated. It can slow data retrieval, however, because a task needs to read the page at the original location and then read the page where the forwarded data is stored.
Forwarded rows can be cleared from a table using the reorg command.
For more information on updates, see “How update operations are performed” on page 94 in the Performance and Tuning: Optimizer book.
