Quelquepart

Je vous conseille d’aller lire cet article à sa nouvelle adresse : Migration BW3 – BI7 : vous reprendrez bien un peu de hash ?

Ce matin, j’étais tranquillement en train de m’occuper de ma migration, quand tout à coup l’un de mes chargements dump. Je suis interloqué car le dump apparait lorsque je lance l’infopackage, sur le mode actif. Pas en background comme cela arrive habituellement.

En-tête du DUMP

Log du dump :

Category : ABAP Server Resource Shortage
Runtime Errors : TSV_TNEW_PAGE_ALLOC_FAILED

What happened?
You attempted to extend an internal table, but the required space was not available.

Information on where terminated
Termination occurred in the ABAP program "SAPLRSSM_LOAD" - in "RSSM_RSSELDONE_READ".  The main program was "RSAWBN_START ".  In the source code you have the termination point in line 245 of the (Include) program "LRSSM_LOADU08".

Allant voir plus loin dans le log je me rend compte que le dump survient sur un select avec des conditions dynamiques

Fragment de code en cause pour le DUMP

Me voici donc partit pour débugger le tout. J’arrive rapidement à trouver la valeur des paramètres et après un petit tour dans SE16, je suis catastrophé. 6.8 millions d’entrées correspondent à cette sélection. Voici donc pourquoi le chargement dump. Ca fait un peu beaucoup de lignes à mettre dans une table interne…

En revanche j’ai du mal à m’expliquer pourquoi SAP fait ce chargement. La table RSSELDONE contient les paramètres de chargement de toutes les requests. Quel intérêt d’aller charger en mémoire tout l’historique des paramètres de sélection sur ma source ???

Après arrachage de poignées de cheveux et traitage de noms d’oiseaux des développeurs de Waldorf, j’ai fini par comprendre. SAP a ajouté un hash code dans cette table. Il n’était pas présent sur la version 3.x et se trouve dans la 7.x. Dès qu’on fait un chargement en BI7.x, le hash code correspondant est généré et stocké dans RSSELDONE. Mais quid des entrées 3.x lors d’une migration ? Et bien SAP a décidé que le PREMIER CHARGEMENT serait le parfait moment pour générer LA TOTALITE des hash code de chargement de la source correspondante !

Bon c’est bien, je sais maintenant pourquoi ca dump, mais ça ne m’aide pas à corriger. J’ai fini par trouver un programme standard qui permet de générer les hash code : RSSM_HASH_ENTRIES_CREATE. Malheureusement il a probablement été écrit par un stagiaire… son temps d’exécution est très très très (trop) long. Aussi, pour les besoins du projet, j’ai du faire une version light qui appelle directement la fonction standard de génération de hash, sans appeler des tonnes de fonctions inutiles autour…

2h plus tard, j’ai pu relancer mon infopackage qui a chargé sans problème mes données. Affaire classée !

Au cas où cette mésaventure vous arrive, voici le programme dont je me suis servi.

Télécharger le programme correctif