Troubleshooting Guide

DpropR

DpropR 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

input_LSN is a 12 byte string that represents the internal (6-byte) hexadecimal value with leading zeros.

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 UDB Version 5.2

For more information see "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

DpropR Enhancements

DpropR 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 still can be copied but the target column will be defined as DECIMAL.

DpropR 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 base 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 base 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

Synchronization anomalies may occur, because the LOB column value 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.

[ DB2 List of Books | Search the DB2 Books ]