Troubleshooting Guide

DB2 DataPropagator

DB2 DataPropagator allows the management of multiple copies of redundant data. To determine which log file contains the log record identified by a given log sequence number, use the db2flsn (Find Log Sequence Number) command.

The command db2flsn -q input_LSN specifies that only the log file name be printed. No error or warning messages will be printed, and status can only be determined through the return code.

Valid error codes are:

• --100 Invalid input
• --101 Cannot open LFH file
• --102 Failed to read LFH file
• --103 Invalid LFH
• --104 Database is not recoverable
• --105 LSN too big
• --500 Logical error
• 0 Successful execution
• 99 Warning: the result is based on the last known log file size. For example:

  db2flsn 000000BE0030
  Warning: The result is based on the last known log file size.
  The last known log file size is 23 4K pages, starting from log extend 2.
  Given LSN is contained in log file S0000001.LOG
  

Using the Log Header Control File with db2flsn

The input_LSN file contains a 12-byte string that represents the internal (6-byte) hexadecimal value for the log sequence number. There may be leading zeros to completely fill the 12-byte string.

The log header control file sqlogctl.lfh must reside in the current directory. Since this file is located in the database directory, the tool can be run from the database directory, or the control file can be copied to the directory from which the tool will be run.

The tool uses the logfilsiz database configuration parameter. DB2 records the three most recent values for this parameter and the first log file that is created with each logfilsiz value; this enables the tool to work correctly when logfilsiz changes.

If the specified LSN predates the earliest recorded value of logfilsiz, the tool uses this value, and returns a warning.

The tool can be used with database manager, prior to DB2 Universal Database Version 5.2.

For more information see the sqlurlog (Asynchronous Read Log) API in the Administrative API Reference.

Example of Using the db2flsn Command and the db2diag.log File

You notice that in your db2diag.log file a restart has taken place:

1999-04-06-11.51.31.237000  Instance:DB2   Node:000
PID:254(DB2SYSCS.EXE)   TID:247   Appid:*LOCAL.DB2.990406154954
recovery_manager   sqlpresr   Probe:170   Database:SAMPLE
DIA3909W Crash recovery completed. Next LSN is "0000003E800C".

You can use the db2flsn command to investigate the relevant log file:

D:\DB2\NODE0000\SQL00001>db2flsn 0000003E800C
Given LSN is contained in log file S0000000.LOG

DB2 DataPropagator Enhancements

DB2 DataPropagator supports copying a BIGINT source to a BIGINT target between DB2 Universal Database products. For target servers that do not support BIGINT, a BIGINT column can still be copied but the target column is defined as DECIMAL.

DB2 DataPropagator supports copying large objects between DB2 Universal Database OS/390s, between DB2 Universal Database products, and between DB2 Universal Database OS/390 and DB2 Universal Database.

LOB Restrictions and Requirements

Copying LOBs between DB2 OS/390 and DB2 UDB

DB2 Connect Version 6 is required.

DB2 Universal Database does not support the role of an LOB Application Server

To copy large objects from a Universal Database to DB2 OS/390, the push technique must be used.

LOB column data is not captured in the CD table

An indication of LOB column data change is captured. The actual LOB data is copied by APPLY directly from the source table to the target for those LOB columns that are changed. For this reason, the user table must have the same primary key columns as the target table. The LOB change indicator is a nullable CHAR(1) column in the source table, so it requires more than one indication column in the CD table. The value of an LOB indication column is significant for update rows only. If the LOB column data was changed in an UPDATE operation, the indicator contains U. In all other cases, it is set to null.

Before_image copy is not supported for LOB columns

LOB columns are copied only to read-only targets

The target type may not be replica or replica2.

Note:

A replica is a target table that can be updated. Changes to this table are replicated back to the replication source table. This table is used in an update-anywhere scenario. A replica2 is a type of update-anywhere replica without transaction semantics. Conflicts are detected row by row, not transaction by transaction as for replicas.

Target must be condensed, because only the current value is available

The apply program always copies the most current version of a LOB column directly from the source table (not the CD table), even if that column is more current than other columns in the target table. Synchronization anomalies may occur, because the LOB column value is copied from the source table and may be much more current, possibly inconsistent, with the other column values being applied.

For Capture to detect LOB changes, the user table must be created or altered specifying DATA CAPTURE CHANGES.

The LOGGED or NOT LOGGED option in the CREATE TABLE statement for Universal Database does not affect capturing LOB changes. The LOG YES/NO option in the CREATE LOB TABLESPACE statement for DB2 OS/390 does not affect capturing LOB changes. DB2 OS/390 and DB2 Universal Database use different syntaxes for supporting LOBs. In DB2 Universal Database, the proper statements are CREATE TABLE, CREATE LOB TABLESPACE, and CREATE AUXILIARY TABLE.