Can ULT4DB2 handle the reordered row format of DB2 V9?
Yes

Can ULT4DB2 monitor changes in real time?
Since ULT4DB2 only analyses the archived log data sets, a change in a table can only be processed by ULT4DB2 after a log offload has been performed by DB2. The delay between the change and the next log offload is determined by the amount of activity in the DB2 subsystem. It is however possible to force a log offload manually. This could be used to implement near real time monitoring with a delay of several minutes at most.

Can ULT4DB2 work with compressed table spaces?
Yes. ULT4DB2 fetches the compression dictionaries from the page sets when the ULT4DB2L2SQL program processes the minilog. It is recommended to use the option KEEPDICTIONARY when reorganizing a table space in order to enable processing of log records that were created both before and after the reorganization.

Can ULT4DB2 work with LOB or XML table spaces?
No. Tables that contain BLOB, CLOB, DBCLOB or XML columns can be processed by ULT4DB2, but only non-LOB columns will be included in the output.

Can ULT4DB2 work without DATA CAPTURE CHANGES?
ULT4DB2 can perform an analysis of log records for tables that are defined with DATA CAPTURE NONE. You can create reports about how many changes were made based on your filtering criteria, or populate an auditing table with meta data, i.e., information about the user name, plan name, operation (insert/update/delete), timestamp and other information. However, without DATA CAPTURE CHANGES, the actual column contents will not be available. For example, you will be able to see that a row was updated and all associated meta-information, but not exactly which fields of the row were changed.

How does ULT4DB2 handle changes that were made by triggers?
Changes that were made by triggers appear on the log normally just like any other kind of changes to a table. Therefore ULT4DB2 will create the statements that reflect the actions of the trigger as well. If you are executing statements against a set of target tables, keep in mind that if a similar trigger exists on these tables, the changes that ULT4DB2 generates may already have been executed in the target environment. This could result in redundant SQL statements or SQL warnings.

How does ULT4DB2 handle columns with GENERATED ALWAYS?
The contents of these columns appear on the DB2 log normally just like any other value. Therefore, if an INSERT statement is generated, it will contain this column. This has to be taken into consideration if the INSERT statement is supposed to be executed against a target table. It is recommended to remove the GENERATED ALWAYS clause from the target table’s column because it is important that the row receives the same value for the column in question. Otherwise, subsequent UPDATE or DELETE operations may cause the wrong target row to be affected.

How does ULT4DB2 handle mass deletes?
For an analysis of the actual field contents, ULT4DB2 requires the table attribute DATA CAPTURE CHANGES. When this attribute is set, a mass delete appears on the DB2 log as several individual deletes. These separate deletes can be processed by ULT4DB2. The consequence is that ULT4DB2 will generate one delete for each row that was affected by the mass delete.

How does ULT4DB2 handle ON DELETE CASCADE?
Changes that were made by an ON DELETE CASCADE clause appear on the log normally just like any other kind of changes to a table. Therefore ULT4DB2 will create the statements that reflect the actions of the ON DELETE CASCADE clause as well. If you are executing statements against a set of target tables, keep in mind that if a similar clause exists on these tables, the changes that ULT4DB2 generates may already have been executed in the target environment. This could result in redundant SQL statements or SQL warnings.