Problem capturing out-of-row LOBs from DB2 LUW for versions prior to 10.1

This topic contains 0 replies, has 1 voice, and was last updated by  Frank Knot 1 week, 1 day ago.

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #8886

    Frank Knot
    Participant

    HVR log-based capture from DB2 LUW tables can give a NULL values for out-of-row LOB datatypes.

    Root cause

    HVR uses IBM’s DB2ReadLog API for log based capture (LBC). This API can be used in unfiltered or filtered mode.

    DB2LOB

    In unfiltered mode, DB2ReadLog API returns all log records, many of them internal to DB2 and of no interest to HVR. A major limitation of this mode is that column data is not uncompressed.

    In filtered mode, DB2ReadLog API returns only the log records marked as propagatable, by which IBM means log records that would be of interest to replication solutions such as HVR. Filtered mode also decompresses column data.

    Starting with versions 4.7.1/29 and 4.7.3/3, HVR defaults to filtered mode (HVR-785).

    This change was motivated by the realization that DB2 compression is commonly used, yet HVR would only support compression if the environment variable ZIZ_READ_FILTER was set to 1.

    What are my possible recourses?

    Upgrade to DB2 10.1 or higher

    Do not use DB2 compression in DB2 versions prior to 10.1, and add an environment action with /Name=ZIZ_READ_FILTER and /Value=0 to your channel.

    Move all tables containing out-of-row data to a new channel, disable compression for these tables, and add an environment action with /Name=ZIZ_READ_FILTER and /Value=0 to this channel. This is not an option if on the integration side there exist referential constraints between tables captured in separate channels.

    If none of the above options is suitable, please contact HVR Technical Support.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.

© 2017 HVR Software

Free Trial Contact Us