Désolé ! Plus jamais ...

Ma femme m'accueille à la porte d'entrée, amusée :

"Tu as fait sortir le monde de ses gonds ? Sur ton smartphone personnel, pas mal de gens veulent te joindre".

Je lui explique brièvement les circonstances de mon reportage raté et réfléchis en même temps à un plan pour me racheter : inviter en interne mes hommes de base à déjeuner à la cantine et organiser une telko avec le rédacteur en chef Färbinger et ses amis.

Voici les résultats :

Depuis Hana 2 SPS3, la base de données supporte la mémoire persistante Optane DC d'Intel. Intel et SAP ont développé ce concept ensemble. L'argument est que lors d'un benchmark avec un équipement de mémoire mixte - Dram (Dynamic Random Access Memory) et Persistent Memory (Optane ou Pmem) - le démarrage de Hana est accéléré de 12,5 fois.

C'est un ordre de grandeur qui correspond également aux résultats des collègues d'Evonik et de Siemens, présentés par Accenture. Jusque-là, tout va bien.

Mais ces résultats sont-ils pertinents et utiles ? Ou, comme le rédacteur en chef Färbinger me l'a fait savoir : la solution cherche le problème ! Toute théorie est grise, et visiblement celle d'Accenture aussi, car comme l'a dit un ex-collègue de SAP : "Par défaut, les tables sont chargées en mémoire à partir du disque dur ou du SSD la première fois qu'elles sont "attaquées".

Le démarrage d'un hana de 1 To devrait être rapide si aucun utilisateur ne travaille. Valable uniquement pour les Column Tables, pas les Row Tables. Mais comme 99% des tables sont des column stores, cette affirmation est valable pour toute la BD.

Chaque table a un paramètre IS_PRELOAD, qui est réglé "par défaut" sur "false". Ainsi, les tables ne sont pas chargées en mémoire au démarrage de Hana, cela ne se fait que lors de l'accès à ces tables.

Jusqu'à récemment, il était possible de contrôler ce qui était chargé dans la mémoire Hana par partition et par colonne. Depuis SP4 et la Native Storage Extension, cela est également possible au niveau des pages. (Un grand merci à l'ancien collaborateur de SAP qui a tout vérifié sur un vrai serveur Hana - ici, l'expérience pratique bat la théorie d'Accenture ! Nous lirons encore beaucoup de choses de cet expert confirmé dans le magazine E-3 à l'avenir, comme me l'a dit le rédacteur en chef Färbinger par téléphone).

SAP a largement confirmé ces conclusions :

"NVRam signifie Ram non volatile ou encore mémoire persistante [...] Avec NVRam, les performances sont moindres pour un redémarrage, car les données ne sont accédées que lorsqu'elles sont utilisées".

D'après des déclarations internes et externes, la taille future de la mémoire d'un serveur Hana pourrait à nouveau être passionnante. Car Optane, ou comme dit aussi Intel :

Pmem/NVRam, a une densité plus élevée, chaque échange d'une barre de mémoire Dram contre Pmem permet d'augmenter la mémoire d'un serveur Hana.

Chez Intel, nous avons trouvé des sources qui faisaient état d'un rapport de un à quatre, ce qui pourrait alors apporter 4,5 To par socket pour un serveur à 4 sockets.

Si l'on lit attentivement certaines notes SAP, cette bonne nouvelle est vite relativisée. Il est évident qu'en raison de l'architecture Hana, le rapport reste de un à un, comme le confirment également les sources de Färbinger.

Il y a eu encore un deuxième "échange de coups" entre SAP et notre groupe d'experts virtuel : de manière générale, les nombreuses corrections de bugs et les Service Packages ont été critiqués.

"Donc, tant que SAP publie un nouveau patch toutes les six semaines et que les recommandations pour les paramètres changent encore plus souvent ..."

La réponse de SAP :

"Tant les mises à jour que le boot-through sont des décisions du client - la fréquence des mises à jour relève uniquement de sa décision. La plupart des paramètres Hana peuvent être modifiés en ligne - sans redémarrage".

Très amusant - tous nos experts internes et externes étaient d'accord : pourquoi SAP sort-il un patch avec une belle régularité, si ce n'est pour que les clients l'appliquent, afin de corriger des bugs identifiés qui faussent parfois le résultat des calculs (Qui peut alors encore faire confiance à son système ?).

Lorsque le client existant escalade le problème à l'assistance, celle-ci dit en premier lieu "Pourquoi ne pas mettre à jour le patch avant même d'y jeter un coup d'œil ?"

De toute façon, le rapport Early Watch indique ici depuis longtemps des feux "rouge vif" - c'est ce que je dois dire à SAP via ma chronique.