¡Disculpe! Nunca más...
Mi mujer me recibe divertida en la puerta principal:
"¿Has desquiciado al mundo? Mucha gente quiere contactar contigo en tu smartphone privado".
Le explico brevemente las circunstancias de mi infructuoso reportaje y al mismo tiempo ideo un plan para enmendarlo: invitar internamente a mi gente de base a comer en la cantina y organizar una teleconferencia con el redactor jefe Färbinger y sus amigos.
Aquí están los resultados:
Desde Hana 2 SPS3, la base de datos es compatible con la memoria persistente Optane DC de Intel. Intel y SAP desarrollaron juntos este concepto. Se argumenta que en un benchmark con memoria mixta -Dram (Dynamic Random Access Memory) y Persistent Memory (Optane o Pmem)- la puesta en marcha de Hana se acelera 12,5 veces.
Es un orden de magnitud que también se corresponde con los resultados de los colegas de Evonik y Siemens presentados por Accenture. Hasta aquí, todo bien.
Pero, ¿son estos resultados relevantes y útiles? O, como me dijo el redactor jefe Färbinger: ¡La solución busca el problema! Toda teoría es gris, y al parecer esta de Accenture también lo es, porque como dijo un ex colega de SAP: Por defecto, las tablas se cargan desde el disco duro o SSD a la memoria la primera vez que se "accede" a ellas.
El arranque de un Hana de 1 TB debe ser rápido cuando no hay ningún usuario trabajando. Válido sólo para tablas de columnas, no de filas. Pero como el 99% de las tablas son almacenes de columnas, la afirmación se aplica a toda la BD.
Cada tabla tiene el parámetro IS_PRELOAD, que se establece en "false" por defecto. Esto significa que las tablas no se cargan en la memoria cuando se inicia Hana; esto sólo ocurre cuando se accede a estas tablas.
Hasta hace poco, se podía controlar lo que se cargaba en la memoria de Hana por partición y columna. Desde SP4 y la Extensión de Almacenamiento Nativo, esto también es posible a nivel de página. (Muchas gracias al ex-empleado de SAP que comprobó todo en un servidor Hana real - ¡la experiencia práctica gana a la teoría de Accenture aquí! Leeremos mucho más de este experto en la revista E-3 en el futuro, como me dijo el redactor jefe Färbinger por teléfono).
SAP ha confirmado ampliamente estos resultados:
"NVRam significa ram no volátil o también memoria persistente [...] Con NVRam, el rendimiento de un reinicio es menor porque sólo se accede a los datos cuando se utilizan".
Según declaraciones internas y externas, el futuro tamaño de la memoria de un servidor Hana podría ser apasionante. Porque Optane, o como también dice Intel:
Pmem/NVRam, tiene una mayor densidad de empaquetamiento, la memoria de un servidor Hana puede incrementarse con cada intercambio de una barra de memoria Dram por Pmem.
En Intel, encontramos fuentes que informaban de una proporción de uno a cuatro, lo que podría suponer 4,5 TB por socket en un servidor de 4 sockets.
Si se leen con atención algunas de las notas de SAP, esta buena noticia se relativiza rápidamente. Obviamente, debido a la arquitectura Hana, la proporción sigue siendo de uno a uno, como también confirman las fuentes de Färbinger.
Hubo un segundo "intercambio de golpes" entre SAP y nuestro panel virtual de expertos: en general, se criticaron las numerosas correcciones de errores y los paquetes de servicios.
"Así que mientras SAP lance un nuevo parche cada seis semanas y las recomendaciones para la configuración de los parámetros cambien aún más a menudo..."
La respuesta de SAP:
"Tanto las actualizaciones como el reinicio son decisiones del cliente: la frecuencia de actualización es decisión exclusivamente suya. La mayoría de los parámetros de Hana pueden modificarse en línea, sin reiniciar".
Muy divertido - todos nuestros expertos internos y externos estaban de acuerdo: ¿Por qué SAP publica un parche con una regularidad agradable, si no es para que los clientes lo apliquen para corregir los errores detectados que a veces falsifican el resultado de los cálculos (¿Quién puede confiar en su sistema entonces?).
Cuando el cliente actual eleva el problema al servicio de asistencia, lo primero que le dicen es: "¿Por qué no lo arreglas al estado actual antes de que lo veamos?"
De todos modos, el Informe de Vigilancia Temprana lleva mucho tiempo mostrando aquí luces "rojas brillantes", eso es lo que se supone que debo decirle a SAP a través de mi columna.
1 comentario
Werner Dähn
Ein paar interessante Tests, Erkenntnisse und Kommentare bei Microsoft zu dem Thema:
https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/sap-hana-fast-restart/bc-p/1091766
Werner Dähn
Bezüglich Statup-Zeiten, wird die Wahrheit irgendwo dazwischen liegen.
Klar, wenn zum Start gleich mal gar keine Tabellen geladen werden, ist der Start sehr schnell und PMEM hilft an der Stelle nichts.
In Realität stürzen sich aber sofort 1000te Anwender auf das frisch gebootete Hana und warten ungeduldig bis all die benötigten Tabellen endlich geladen sind. Also sollte man den Begriff Boot-Zeit sowieso etwas weiter fassen, hin zu “bis die Anwender vernünftig arbeiten können”.
Umgekehrt, werden die benötigten Tabellen/Partitionen anfänglich nur 10%(?) der Gesamtmenge ausmachen.
Irgendwo zwischen den beiden Extremen liegt die Wahrheit. Entsprechend ist PMEM keine Wunderlösung für Alles und Jeden, aber trotzdem eine tolle Sache. Und dann hat PMEM ja noch weitere genannte Vorteile…
Einverstanden?