Malentendidos en el contexto de Hana

El tiempo de arranque hasta que el sistema SAP está disponible puede ser superior a 30 o 60 minutos para cargar todos los datos en la memoria principal: Sí, lleva algún tiempo cargar todos los datos en la memoria principal, pero esto no es diferente con un AnyDB.

También tarda algún tiempo en llenar el búfer. Esto suele ocurrir después de que se accede a los datos por primera vez y permanecen allí hasta que el algoritmo LRU (Least Recently Used) entra en acción y los desplaza.

Hana carga el almacén de filas completo en la RAM en cada arranque. Después, el sistema está inmediatamente disponible. Breve descripción del proceso de arranque:

1. Abra los archivos de datos;
2. Lectura de la información del último punto de guardado correcto (asignación de páginas lógicas a páginas físicas en los archivos de datos y carga de la lista de transacciones abiertas);
3. Carga del Almacén de Filas (dependiendo del subsistema de E/S - aprox. cinco minutos para 100 GB);
4. Reproduce los redologs;
5. Retroceso de transacciones guardadas sin éxito (commit);
6. Escribiendo un savepoint;
7. Carga del almacén de columnas marcado como Precarga
8. "lazy load" de las tablas restantes (carga asíncrona de las tablas de columnas que ya estaban cargadas antes del reinicio).

El sistema de prueba es un BW en Hana en IBM Power. El tamaño de la base de datos es de 40 GB, Row Store tiene 6 GB y el proceso de inicio tarda unos 60 segundos, el proceso de parada unos 75 segundos.

En la segunda ejecución, se añade una tabla de columnas de 5 GB (REPORSRC), así como SQL para la precarga: alter table REPOSRC preload all. De nuevo, el proceso de inicio tardó unos 60 segundos y el de parada unos 75 segundos.

¿Por qué no se ha alargado significativamente el proceso de arranque, a pesar de que hay más datos que cargar?
Desde SPS7, el proceso de precarga, junto con la recarga de las tablas, tiene lugar de forma asíncrona, directamente después de que se haya completado el proceso de arranque de la Hana DB.

De esta forma, el sistema vuelve a estar disponible inmediatamente sin esperar a que se carguen las tablas orientadas a columnas. Si quieres probar cuánto tardan en cargarse todas las tablas en la RAM, puedes hacerlo con el script loadAllTables.py (location: /usr/sap/HDB/SYS/exe/hdb/python_support/) (como sidadm): python ./loadAllTables.py -user=System -password= -address= -port=3xx15 -namespace=

Las estadísticas ya no son necesarias con Hana; no es necesario programar más ejecuciones de resumen de estadísticas: parcialmente correcto. Para las tablas orientadas a columnas, la afirmación es correcta. No se necesitan ejecuciones de resumen especiales porque el optimizador conoce la distribución muy rápidamente a través del diccionario.

Las estadísticas se generan automáticamente para la memoria de línea en cuanto se necesitan (sobre la marcha). Tampoco es necesario programarlas mediante ejecuciones colectivas. Actualmente, no está documentado oficialmente cómo influir en estas estadísticas (por ejemplo, tamaño de la muestra, ejecución manual de estadísticas, etc.).

Copia de seguridad

¡Una restauración siempre necesita registros para una recuperación consistente! Error, las copias de seguridad de Hana se basan en la tecnología de instantáneas. Por lo tanto, se trata de un estado completamente congelado de la base de datos, que viene determinado por la posición del registro en el momento en que se ejecuta la copia de seguridad.

Por tanto, la copia de seguridad se encuentra en un estado coherente sin ningún registro. Ciertamente, los registros son necesarios para avanzar, por ejemplo, en la recuperación puntual o hasta el último estado posible antes de un fallo.

Copia de seguridad del catálogo: La información del catálogo se guarda como con Oracle (archivo *.anf), que es absolutamente necesario para la recuperación. El catálogo de copia de seguridad se guarda con cada copia de seguridad de datos y registros.

No es un archivo normalmente legible. Incluso sin este archivo original de la copia de seguridad, se puede realizar una recuperación (véase la nota SAP 1812057, Reconstrucción del catálogo de copias de seguridad con hdbbackupdiag).

Puede encontrarse en la ubicación de la copia de seguridad (en el caso de la copia de seguridad en disco) o en el conjunto de copias de seguridad de un proveedor externo, y puede reconocerse por el nombre log_backup_0_0_0_0..

El catálogo contiene toda la información necesaria para una recuperación, como qué registros se necesitan en cada momento o qué archivos pertenecen a cada conjunto de copias de seguridad.

Si las copias de seguridad se borran físicamente a nivel de disco, VTL o cinta, el catálogo de copias de seguridad sigue conservando esta información no válida. Actualmente no existe ningún automatismo que limpie esta información.

¿Qué tamaño tiene este archivo de catálogo en el sistema? Puedes comprobarlo tú mismo. Puedes obtener información con Hana Studio en el editor de copias de seguridad mostrando todas las copias de seguridad, incluidos los registros.

Si este archivo tiene más de 20 MB, debe prestar atención a la limpieza, porque como ya se ha mencionado, se realiza una copia de seguridad con cada copia de seguridad. Esto significa más de 200 veces al día. 200 multiplicado por 20 MB multiplicado por 3 (porque el paisaje es de 3 sistemas) son ya 12.000 MB.

El resultado del informe de dimensionamiento debe duplicarse: Los nuevos resultados de dimensionamiento de los informes SAP son definitivos y no es necesario duplicarlos de nuevo, como puede seguir ocurriendo con la documentación antigua.

Como ejemplo, se puede tomar una solución de escalado BW. Esto significa que los nodos maestro y esclavo están ubicados en un servidor. Según las recomendaciones de SAP, un enfoque scale-out en el entorno BW consiste en un nodo maestro, que soporta la carga transaccional, y al menos dos nodos esclavos, que se encargan de la generación de informes.

El dimensionamiento de la memoria principal de SAP consta de una parte estática y otra dinámica. La parte estática son los índices, así como los datos de columnas y filas, que corresponden a la suma de los datos de usuario.

La parte dinámica son los ficheros temporales para reporting (consultas OLAP BW), delta merge así como ordenación y agrupación, que en total corresponde a la memoria temporal que se libera de nuevo una vez finalizada la acción.

Un ejemplo: El Almacén de Filas con 53 GB multiplicado por 2 es igual a 106 GB; la Columna Maestra tiene 11 GB multiplicado por 2 es igual a 21 GB (redondeado) más 67 GB multiplicado por 2 es igual a 135 GB (redondeado). El resultado es un total de 156 GB. Se necesitan 50 GB de cachés y servicios para cada servidor. Lo que al final suma 312 GB.