Particionamiento por temperatura y ejecución de Data Aging Run en proyectos de utilities SAP S/4HANA

Esta es la quinta pieza de la secuencia de 6 guías técnicas de AGT sobre Archiving y Huella HANA en utilities, y es la bisagra entre el bloque “durante el proyecto” y el bloque “después del proyecto”. La pieza anterior configuró los destinos de reubicación de datos —NSE para el dato tibio del flujo Meter-to-Cash, Hadoop/SAP IQ para el verdadero dato frío—. Esta pieza baja al detalle técnico de cómo se mueven realmente los datos entre particiones y qué dispara ese movimiento. La pieza final de la secuencia mostrará cómo sostener esta ejecución en el tiempo después del go-live y su impacto directo en el TCO del contrato RISE.

Fundamento conceptual

Técnicamente, la temperatura del dato se determina mediante una columna adicional (_DATAAGING) que permite particionar horizontalmente las tablas participantes por selección de tiempo: una partición concentra el dato caliente y las demás contienen el dato frío en distintos rangos de temperatura. Por defecto, solo se accede al dato caliente durante la operación normal, ya que reside en una partición separada que HANA carga en memoria; el dato frío permanece en un caché de buffer separado y se carga bajo demanda cuando se lo consulta explícitamente. El movimiento de datos de la partición caliente a la fría ocurre durante una ejecución programada llamada Data Aging Run, que debe configurarse durante la construcción antes de poder programarse periódicamente en operación [1]. Nota de vigencia importante: la adopción de Data Aging entre la base de clientes de SAP ha sido baja, y la guía oficial vigente (SAP Nota 2869647) señala que, basado en la experiencia de clientes, el uso de Data Aging para datos de aplicación —como los objetos funcionales de FI-CA que se describen a continuación— ya no se recomienda, prefiriéndose Native Storage Extension (NSE) para el dato tibio y el archiving clásico para el frío. Esta pieza documenta la mecánica de Data Aging Run porque sigue siendo relevante para sistemas que ya lo tienen activado o en evaluación, pero un proyecto que arranca hoy debería evaluar primero si NSE (descrito en la pieza anterior de esta serie) cubre el mismo objetivo de memoria sin los costos de adecuación de código custom y sin la naturaleza irreversible de Data Aging.

Un matiz técnico importante, que conviene precisar antes de seguir: Data Aging reduce específicamente la memoria requerida para almacenar y manipular el dato dentro de HANA — no reduce el tamaño del dato en disco, ni el tamaño de los backups del sistema. Es decir, el ahorro que produce Data Aging es un ahorro de memoria, no de espacio de almacenamiento en general [2]. Esta distinción es crítica para entender correctamente dónde impacta en el TCO, y se retoma en la aplicación práctica de esta pieza.

Aplicación práctica

Para el flujo Meter-to-Cash, el objeto de Data Aging relevante para los documentos de Contract Accounting es específicamente FICA_DOCUMENT, que cubre las tablas de documentos de facturación, pago y compensación del subledger FI-CA (incluyendo, por ejemplo, la tabla de suplementos de tarjeta para documentos de pago y compensación) [3]. Para que un documento sea candidato a Data Aging, el sistema estándar de SAP exige, entre otras validaciones, que la fecha de contabilización tenga al menos 400 días de antigüedad — un valor por defecto que puede ajustarse mediante la opción de Customizing “Definir Tiempo Mínimo de Residencia” para Contract Accounts Receivable and Payable [3].

Este umbral de 400 días tiene una implicancia directa para una utility con ciclos de facturación mensuales: significa que, sin ajustar el parámetro, un documento FI-CA generado en un ciclo de facturación permanece en la partición caliente durante poco más de trece ciclos de facturación completos antes de calificar para moverse a la partición fría. Con una base de clientes grande, ese período de trece meses acumula, sin ajuste, un volumen considerable de documentos activos en memoria antes de que la primera ejecución de Data Aging Run pueda moverlos. Ajustar deliberadamente este tiempo de residencia —en lugar de dejarlo en el valor por defecto— es una decisión de diseño que debe tomarse durante la construcción, alineada con el patrón real de consulta de documentos de facturación de esa utility en particular: cuánto tiempo después de facturado un cliente sigue necesitando que su documento esté en memoria caliente para atención al cliente o disputas de facturación.

Programar la ejecución del Data Aging Run (vía transacción DAGRUN, definiendo un grupo de objetos de Data Aging, el tiempo máximo de ejecución y la fecha/hora de inicio) con una cadencia alineada al propio ciclo de facturación —por ejemplo, ejecutando la corrida poco después de cerrado cada ciclo mensual— es lo que permite que el movimiento de documentos hacia la partición fría siga el mismo ritmo con el que se generan: cada mes que se agregan nuevos documentos de facturación, pago y morosidad, se mueve a partición fría el volumen correspondiente que ya cumplió su tiempo de residencia, en lugar de dejar que la partición caliente acumule meses de crecimiento sin contrapartida.

Ahora bien: recordando el matiz técnico señalado antes, este ahorro de memoria es exactamente el que impacta el sizing y la memoria contratada del RISE with SAP descrita en la pieza 3 de esta secuencia — pero no reduce el tamaño de los backups del sistema ni el espacio en disco que ocupa el histórico de FI-CA. Para una utility que además busca reducir costos de almacenamiento en disco o de backup, Data Aging por sí solo no es la palanca correcta: esa reducción depende del archiving clásico y la destrucción vía ILM descritos en la pieza 2 de esta secuencia. Confundir ambos beneficios —memoria vs. disco— es un error de expectativas frecuente al justificar el proyecto ante el negocio.

Por último, un factor de costo que suele subestimarse: antes de activar un objeto de Data Aging funcional como FICA_DOCUMENT, es necesario ajustar el código ABAP custom que interactúa con esas tablas, para que tenga en cuenta las particiones y la selección por fecha —de lo contrario, todo el beneficio de la partición se pierde en la práctica, porque el código custom sigue consultando ambas particiones sin distinción [4]. En utilities, donde el subledger FI-CA suele tener un volumen considerable de desarrollos a medida (informes de morosidad, integraciones con sistemas de cobranza, reportes regulatorios), este trabajo de adecuación de código debe presupuestarse como parte del costo del proyecto, no asumirse como gratuito solo porque Data Aging no tiene costo de licencia.

Mejores prácticas y consideraciones

• Ajustar el tiempo mínimo de residencia de FICA_DOCUMENT según el patrón real de consulta de la utility, no dejarlo en el valor por defecto de 400 días. Este ajuste, hecho durante la construcción, determina cuánto tiempo de crecimiento se acumula en memoria caliente antes de la primera oportunidad de aliviarlo.
• Alinear la cadencia de ejecución del Data Aging Run con el propio ciclo de facturación de la utility. Programar la corrida poco después del cierre de cada ciclo mensual evita que la partición caliente acumule varios meses de crecimiento sin contrapartida entre ejecución y ejecución.
• No confundir el ahorro de memoria de Data Aging con un ahorro de espacio en disco o de backup. Si el objetivo del proyecto incluye ambos, Data Aging cubre solo la parte de memoria — la reducción de disco y backup depende del archiving clásico y la destrucción ILM.
• Presupuestar la adecuación de código custom como parte del costo del proyecto. El código ABAP que interactúa con las tablas de FI-CA debe ajustarse para respetar las particiones antes de activar Data Aging; omitir este trabajo anula el beneficio de memoria sin que nadie lo note hasta revisar el resultado real.
• Anti-patrón a evitar: activar Data Aging sobre FICA_DOCUMENT sin validar antes el código custom que toca esas tablas. El resultado visible —particiones creadas, objeto activado— puede dar la falsa sensación de que el ahorro de memoria ya está ocurriendo, cuando en la práctica el código custom sigue forzando la carga completa de ambas particiones.

Con la mecánica de particionamiento y ejecución resuelta, la pieza final de esta secuencia muestra cómo sostener esta disciplina en el tiempo después del go-live, y su impacto directo, mes a mes, en el TCO del contrato RISE with SAP.

Referencias

1. Data Aging in SAP S/4HANA
2. Diving Deep into Data Aging Strategies in SAP S/4 HANA - VE3 — https://www.ve3.global/diving-deep-into-data-aging-strategies-in-sap-s-4-hana/
3. Data Aging - SAP Help Portal — https://help.sap.com/doc/474a13c5e9964c849c3a14d6c04339b5/100/en-US/1d9147fd820e49d78d1bf7df821ed87c.html
4. SAP database growth control: HANA data aging - Saptechnicalguru.com — https://www.saptechnicalguru.com/sap-database-growth-control-hana-data-aging/