Granularity of row change tokens and false negatives

For example, a row change timestamp column, defined using either of the following statement clauses, causes the Db2® server to store the time when a row is last changed (or initially inserted). This provides a way to capture the timestamp of the most recent change to a row. This is a timestamp column and it is maintained by the database manager, unless the GENERATED BY DEFAULT clause is used to accept a user-provided input value.

     GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP 

     GENERATED BY DEFAULT FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP 

Therefore, when an application uses the new ROW CHANGE TOKEN expression on a table, there are two possibilities to consider:

• The table does not have a row change timestamp column: A ROW CHANGE TOKEN expression returns a derived BIGINT value that is shared by all rows located on the same page. If one row on a page is updated, the ROW CHANGE TOKEN is changed for all the rows on the same page. This means an update can fail when changes are made to other rows, a property referred to as a false negative.
  Note: Use this mode only if the application can tolerate false negatives and does not want to add additional storage to each row for a ROW CHANGE TIMESTAMP column.
• The table has a row change timestamp column: A ROW CHANGE TOKEN expression returns a BIGINT value derived from the timestamp value in the column. In this case, false negatives can occur but are more infrequent: If the table is reorganized or redistributed, false negatives can occur if the row is moved and an application uses the prior RID_BIT() value.