1,You can use the DATA CAPTURE CHANGES option on the ALTER TABLE statement to have data changes to that table written to the log in an expanded format. You can then retrieve the log by using a program such as the log apply feature of the Remote Recovery Data Facility (RRDF) program offering, or DB2 DataPropagator.

LOB values are not available for DATA CAPTURE CHANGES. To return a table back to normal logging, use DATA CAPTURE NONE.

2,

VOLATILE CARDINALITY or NOT VOLATILE CARDINALITY
Indicates to the optimizer whether or not the cardinality of table table-name can
vary significantly at run time. Volatility applies to the number of rows in the
table, not to the table itself. CARDINALITY is an optional keyword. The default
is NOT VOLATILE.

VOLATILE
Specifies that the cardinality of table table-name can vary significantly at
run time, from empty to large. To access the table, the optimizer will use
an index scan (rather than a table scan, regardless of the statistics) if that
index is index-only (all referenced columns are in the index), or that index
is able to apply a predicate in the index scan. The list prefetch access method
will not be used to access the table. If the table is a typed table, this option
is only supported on the root table of the typed table hierarchy (SQLSTATE 428DR).

NOT VOLATILE
Specifies that the cardinality of table-name is not volatile.
Access plans to this table will continue to be based on existing statistics and
on the current optimization level.