El Paradigma de Performance In-Memory
En bases de datos tradicionales, el tuning se centra en minimizar I/O de disco. En SAP HANA, aunque el I/O sigue importando (log writers), el foco principal se desplaza a la eficiencia de CPU (paralelismo), la gestión de memoria y la optimización del flujo de datos entre los motores de cálculo (Join Engine, SQL Engine).
Gestión de Memoria y OOMs
El recurso más crítico es la RAM. Un administrador debe diferenciar entre:
- Used Memory: Memoria realmente ocupada por datos y código.
- Allocation Limit (GAL): El techo duro configurado en
global.ini.
El Peligro de los Column Unloads: Cuando la memoria se acerca al límite, HANA comienza a
descargar (unload) columnas de tablas de la memoria al disco basadas en LRU (Least Recently Used). Esto
no causa error inmediato, pero cuando un usuario consulte esa tabla, el sistema sufrirá una latencia
masiva recargándola. Monitorizar la vista M_CS_UNLOADS es obligatorio.
Out of Memory (OOM): Si no se puede liberar espacio, la sentencia falla y genera un dump
OOM. El análisis del archivo de traza (trace file) indicará qué consulta o proceso consumía la memoria
(Allocator: Pool/JoinEvaluator, Pool/PersistenceManager, etc.).
SQL Tuning y PlanViz
La optimización de consultas es el día a día. La herramienta estándar es HANA PlanViz (visualización del plan de ejecución).
Code-Pushdown
La regla de oro: "Trae la lógica a los datos, no los datos a la lógica". Evitar traer millones de registros a la capa de aplicación (ABAP/Java) para filtrarlos. Usar agregaciones y filtros en la base de datos.
Expensive Statements Trace
Para cazar queries pesadas en producción, se activa la traza de "Expensive Statements" con un umbral (ej.
> 1000ms). Esto guarda en M_EXPENSIVE_STATEMENTS cualquier consulta que exceda ese tiempo,
permitiendo análisis post-mortem.
Particionamiento de Tablas
El particionamiento no es opcional para grandes volúmenes debido al límite técnico:
Estrategias de particionamiento:
- HASH: Distribuye filas aleatoriamente usando un algoritmo hash sobre la Primary Key. Ideal para distribuir la carga de lectura/escritura uniformemente entre nodos (Scale-out).
- RANGE: Divide por rangos (ej. Fechas: Año 2023, Año 2024). Obligatorio para estrategias de Data Aging y archivado.
- ROUND-ROBIN: Simple asignación cíclica. Usado cuando no hay una clave de particionamiento clara, pero no permite "Pruning" (podar particiones en consultas).
Índices y Delta Merge
¿Índices en Column Store? Generalmente NO. Cada columna actúa como su
propio índice. Crear índices secundarios B-Tree adicionales consume memoria y ralentiza la escritura.
Solo se justifican en columnas de muy alta cardinalidad (muchos valores únicos) usadas frecuentemente en
filtros WHERE.
Delta Merge: Es el proceso de mover datos del buffer de escritura (Delta) al almacenamiento principal comprimido (Main). Un merge costoso puede bloquear la tabla. Se debe optimizar con parámetros de "Smart Merge" para que ocurra en momentos de baja carga.
Preguntas Frecuentes (FAQ)
¿Qué es el Column Unload y cómo afecta al rendimiento?
Es cuando HANA expulsa una columna de la memoria al disco para liberar espacio. Esto causa latencia la próxima vez que se requiera esa columna, ya que debe recargarse desde el disco.
¿Cuándo es necesario particionar una tabla en HANA?
Es obligatorio cuando la tabla supera los 2 mil millones de registros o por razones de performance para distribuir la carga entre varios nodos de CPU.
¿Por qué no se suelen usar índices secundarios en tablas columnares?
En tablas columnares, cada columna actúa intrínsecamente como un índice. Los índices adicionales consumen memoria RAM preciosa y pueden ralentizar las operaciones de escritura.
Páginas relacionadas
Monitorización Avanzada (Detectar bloqueos y esperas)
Column Store vs Row Store (Entender el almacenamiento)