Hello SAP experts,

I faced an really strange issue in my last migration which I want to share with you.

Initial situation:

Source system: BW 7.00

Windows 2003

MaxDB 7.8

Kernel < 720 P513

DB size 2.6TB

46 splitted tables

Target system:

Windows 2012

MaxDB 7.9

Kernel 720 EXT P500

Normal export/import procedure with R3load.

After the import was finished with no errors (all packages were imported shown in migration monitor) the installer (object checker) tells us as normal the invalid objects which includes as usual all splitted tables and some DB dependend objects.

I have checked the .tsk (task files) -> every packages was OK. DB size was only 700GB and this made me really reflective (should be arround 2TB).

I have checked the object_checker.log which includes the splitted table and the known ones ‘DBPROPERTIES’ and ‘DDLOG’.

My guess was on the basis of the size of the DB that the splitted tables are missing. So I have checked the logs and there was an error in all files:

(RFF) ERROR: no entry for table “DYNPSOURCE” in “X:\EXPORT\PBI\ABAP\DATA\DYNPSOURCE-1.TOC”

A normal restart of the command ended in the same error. So I cross checked the TOC and the TSK file:

TSK:

D DYNPSOURCE I ok <<< strange because there should be “err”

WHERE

(“PROGNAME” < ‘GPD2GH1YHUUR2Z73QFELVE68B2T’) OR (“PROGNAME” = ‘GPD2GH1YHUUR2Z73QFELVE68B2T’

AND “DYNPNUMBER” < ‘0001’) OR  (“PROGNAME” = ‘GPD2GH1YHUUR2Z73QFELVE68B2T’

AND “DYNPNUMBER” = ‘0001’ AND “R3STATE” < ‘A’)

TOC:

vn: R7.20/V1.4

id: 252bce3d00000046

cp: 4103

data_with_checksum

tab: [HEADER]

fil: DYNPSOURCE-1.001 1024

1 1

eot: #0 rows 20131109175632

tab: DYNPSOURCE

sel: WHERE (“PROGNAME” < ‘GPD2GI5GE735UCJ74QK05ILGKD1’) OR  (“PROGNAME” = ‘GPD2GI5GE735UCJ74QK05ILGKD1’

sel: AND “DYNPNUMBER” < ‘1000’) OR (“PROGNAME” = ‘GPD2GI5GE735UCJ74QK05ILGKD1’

sel: AND “DYNPNUMBER” = ‘1000’ AND “R3STATE” < ‘A’)

fil: DYNPSOURCE-1.001 1024

2 43863

eot: #13470 rows 20131109183854

eof: #20131109183854

Before importing the dump the R3load cross checks the exact WHERE-clause in TOC and TSK file. And as you can see there are several differences.

For example the enter after WHERE and the space after the first OR. I have corrected these typos in the TOC file like the TSK file.

I rerun the R3load command for the export and it worked! But my situation was really bad, because I had to manually check and rerun round about 400 files.

So I have choosen the easiest way => do the export import again with the newest R3load/R3ldctrl.

Here are notes which were released only a few days after I have done the prepare check for the kernel level:

1905316 – R3load skips table with error message “no entry for table”

1914260 – Abort R3load task if TOC file has no entry for the table

So if you hit the same issue and you only have a few splitted tables which are affected you can fix it manually. If you have over 50, the error rate is to big to do it manually, because there were not always the same typos in the files.

It is not enough to change the R3load for the import! You have to export and import the dump with a kernel > P513!!! (720 based)

changes in P513:

[…]

( 0.513) Abort R3load task if TOC file has not entry for the table (Hinweis 1914260)

( 0.513) R3load stops with Syslog F38 and (CNVPOOL) rscp error occu (Hinweis 1899983)

[…]

I must complain a little bit about the migration monitor why such errors are not recognized and shown in the packages status / task files.

Hope this blog helps other colleagues to avoid such issues.

Thanks and best regards,

Jens

PS: every time use the latest kernel and R3load/R3ta/R3ldcrtl/R3szchk for your migration/system copy

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. Jens Gleichmann Post author

      No, no other issues at this time. With the new kernel the new export/import worked without any error. If there are only a few tables you can fix this manually but with so too many tables you should do the export/import once again. As already mentioned the migration monitor and the tsk files react not as expect and didn’t recognized the error.

      (0) 

Leave a Reply