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)