The following blog provides an introduction and additional information on the table comparison option of DMO: DMO: table comparison and migration tools
This blog focuses on analyzing the results of the table comparison option of DMO and discusses the possible options to handle typical checksum errors.
The table comparison option, which can be switched on as part of a DMO migration, compares the content of table rows before and after the migration.
Basically there are two general cases how differences between the source tables and the target tables can arise:
At this point we have several options to handle the checksum differences:
2EETQ170 CRC differences for table 'USR04', key fields: "MANDT" "BNAME"
4EETQ171 Key: I '000' 'DDIC_TEST2'
2EETQ170 CRC differences for table 'USRBF2', key fields: "MANDT" "BNAME" "OBJCT" "AUTH"
4EETQ171 Key: I '000' 'DDIC_TEST' 'S_USER_TCD' '&_SAP_ALL' - '000' 'DDIC_TEST2' 'C_KLAH_BSE' '&_SAP_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'C_KLAH_BSE' '&_SAP_ALL' - '000' 'DDIC_TEST2' 'S_BRAN_ADM' '&_SAP_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'S_BRAN_ADM' '&_SAP_ALL' - '000' 'DDIC_TEST2' 'S_LANG_ADM' 'S_LANG_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'S_LANG_ADM' 'S_LANG_ALL' - '000' 'DDIC_TEST2' 'S_RS_PLST' '&_SAP_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'S_RS_PPM' '&_SAP_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'S_RS_PPMAD' '&_SAP_ALL'
4EETQ171 Key: I '000' 'DDIC_TEST2' 'S_RS_RSFC' '&_SAP_ALL'
…
MIGRATE_UT_CRC_CHECKDIFF.LST
#
# By choosing "Accept errors" in the repeat dialogue,
# the following lines in the list below will be handled as follows:
# Line | Repeat cloning | Check again
# | table contents |
# ----------------------------+----------------+---------------
# <TABLENAME> | yes | yes
# #<TABLENAME> | no | yes
# <TABLENAME> ignchecks | no | no
#
# Remarks:
# - Commenting out the line is useful if the wrong count/checksum was
# fixed on the DB manually.
# - In case the cloning is to be repeated, one can change the
# behaviour during cloning by adding phrases like 'nosplit'
# after the table name.
#
# Tables with different row counts/checksums:
INDX # 1 bad checksum(s)
CCMSBITHRH # 1 bad checksum(s)
USREFUS # 1 bad checksum(s)
TEMSGU # 1 bad checksum(s)
USRSTAMP # 1 bad checksum(s)
CCMSBIDATA # 1 bad checksum(s)
USR04 # 1 bad checksum(s)
NRIV # 1 bad checksum(s)
ALTSTLOD # 1 bad checksum(s)
TUCON # 1 bad checksum(s)
CDPOS # 1 bad checksum(s)
CCMSBIMETH # 1 bad checksum(s)
USRBF2 # 1 bad checksum(s)
USRBF3 # 1 bad checksum(s)
INDX # 1 bad checksum(s)
CCMSBITHRH # 1 bad checksum(s)
USREFUS nosplit # 1 bad checksum(s)
#TEMSGU # 1 bad checksum(s)
#USRSTAMP # 1 bad checksum(s)
#CCMSBIDATA # 1 bad checksum(s)
#USR04 # 1 bad checksum(s)
#NRIV # 1 bad checksum(s)
#ALTSTLOD # 1 bad checksum(s)
TUCON ignchecks # 1 bad checksum(s)
CDPOS ignchecks # 1 bad checksum(s)
#CCMSBIMETH # 1 bad checksum(s)
#USRBF2 # 1 bad checksum(s)
#USRBF3 # 1 bad checksum(s)
CDPOS igncount igncrcdiffs
TUCON igncount igncrcdiffs
ℹ Note:
The table comparison option is useful as a preparation step in non-productive DMO runs to reveal potential issues before a productive run.
However, comparing the table content will extend the downtime, so it is not recommended to enable table comparison for a DMO run on a productive system.
As a safeguard, DMO will in any case compare the number of rows for each table (count *) before and after the migration. This cannot be switched off.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
29 | |
18 | |
18 | |
17 | |
11 | |
11 | |
11 | |
10 | |
8 | |
7 |