Skip to Content

Hello experts,

recently I was involved in a HANA migration project and we faced a lot of issues which are not or bad documented.

So I will share this awareness with you to prevent you from big time losses.

Situation

source system

BW 7.30 SPS10 NUC system

AIX 6.1

DB2

distibuted (both AIX)

Kernel 720_EXT

target system

HANA Rev.84 (SLES)

BW 7.30 SPS10 UC system

CI: AIX 7.1

Kernel 721_EXT

First Issue

Error while Importing package SAPSSEXC:

Table: PKRT_LOAD

(DB) INFO: deleted/truncated

cnv_pkrt_convert_content: illegal entry head 0in load 000000000000317a

cnv_pkrt: failed to convert content

First of all what is PKRT_LOAD?

It is a generic load table for Package Runtime (Package checking)

detailed information help.sap.com

to fix this issue there are two notes available which can’t be found regarding the context of this error:

1399534 – Corrupt Package Check Environment Loads

1439496 – Cleanup of package-check related inconsistency

So we analyzed the issue with report RS_PKRT_DEFENV_CONSISTENCY_720 (over 4h runtime!) in the first step and got hundreds of errors source system.

Second step we fixed the issue with report RS_PKRT_CREATE_ENV with option ‘Beforehand, delete all Loads’ in source system.

Afterwards export the package/table once again and import it in the target system.

Another option is to finish the import in the target system and execute the report RS_PKRT_CREATE_ENV there. This way saves a lot of time!

Second issue

The second issue is more related to DB2.

The error occured after finishing the import in the postprocessing phase during recreation of the nametabs with dipgntab:

/nuc/linuxppc64/dipgntab -rwr40 -srctt DDNTT -srctf DDNTF -dsttt DDNTT -dsttf DDNTF -ttonly TT finished with status TST_ERROR

The solution can be found more easier in the following notes:

2095316 – R3load corrupts DDNTF table when changing the database

2044380 – R3load dependency loop if calles with -o option and other corrections

“The error occurs only then the database is changed during system copy and the maximum length size for the source database (maxlongsize) parameter of the source database is not the same as the maximum length size of the target database (so R3load has to re-pack LRAW records according to new size).”

“Previously R3load ignored the size of the LOB fields in the extended statistics output (option -stats), which caused wrong speed and size reports on table having LOB fields, like DYNPSOURCE. Now R3load correctly calculate the size of LOB fields in the total result.”

So it is a kernel bug, but there is no downport in kernel versions < 741!

It is solved only in the follwoing kernel:

SAP KERNEL 7.41 64-BIT NUC           P114

SAP KERNEL 7.41 64-BIT UNICODE  P114

Regardless if it is HANA migration!

The affected DB transitions are:

  •     IBM DB2 für z/OS (DB2) <-> Oracle, MS SQL, MaxDB, Hana, Sybase ACE
  •     IBM DB2 for AS400 (DB4) <-> Oracle, MS SQL, MaxDB, Hana, Sybase ACE
  •     IBM DB2 for Unix (DB6) <-> Oracle, MS SQL, MaxDB, Hana, Sybase ACE

=> both directions are affected!

So we changed the kernel, repeated the step and finished the migration and changed it back to 721_EXT afterwards (730 base release; kernel 741 is supported SAP NetWeaver 7.40 Support Package 2 upwards => 1969546 – Release-Roadmap Kernel 740).

Summary

Both errors are really strange because the first can’t be found in its context and the second one is only fixed in 741 kernel!

Before you migrate, it could be helpful to check if there are inconsistencies in the source system regarding PKRT_LOAD.

If you have any further questions, don’t hestate to comment the blog or contact me or one of my colleagues at Q-Partners ( info_at_qpcm_dot_de )

Best Regards,

Jens Gleichmann

Technology Consultant at Q-Partners (www.qpcm.eu)

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply