75 ways to demystify DB2 #43: Techtip : LOB Data and HADR

Body

Wondering how LOB DATA plays with HADR ? The answer is - Not all LOBs are created equal. There are different types of LOBs:

INLINE-LOBs: The data for an INLINE LOB column is contained in the base table. This feature is enabled through the INLINE LENGTH option on the CREATE TABLE statement or the ALTER TABLE statement. The limit for inline lobs is  32,673 bytes.

LOGGED-LOBs: Specifies that changes made to the column are to be written to the log. The data in such columns is then recoverable with database utilities (such as RESTORE DATABASE). LOGGED is the default.

NOT LOGGED-LOBs: Specifies that changes made to the column are not to be logged. This only applies to LOB data that is not inlined.

NOT LOGGED has no effect on a commit or rollback operation; that is, the database's consistency is maintained even if a transaction is rolled back, regardless of whether or not the LOB value is logged. The implication of not logging is that during a roll forward operation, after a backup or load operation, the LOB data will be replaced by zeros for those LOB values that would have had log records replayed during the roll forward. During crash recovery, all committed changes and rolled back changes will reflect the expected results. 

What this means w.r.t HADR is that when LOBs are either INLINE LOBs or LOGGED LOBs the data is carried over to the standby, but if you have your lobs defined as not-logged then they are not replicated to the standby database.