SAP · Infrastruttura · YoctoIT tech page

HANA

The in-memory database underneath the whole SAP world: columns, transactions and analytics in the same engine, at RAM speed.

FOCUS · THE HEART OF THE ERPHANA sizing, replication and high availability: the craft we practice every day
Request the Free Assessment Learn more
YoctoIT material for clients and partners · SAP, S/4HANA, HANA, BTP and the other products mentioned are trademarks of SAP SE o di sue affiliate.
01 · What it is

SAP HANA, made clear.

HANA keeps data in memory and organizes it by columns: transactions and analytics coexist without copies, and the ERP responds in real time. The flip side: memory must be sized well and protected better — an in-RAM database does not forgive improvisation.

In-memory
data lives in RAM: microsecond latencies, analytics on live data
Columnar
aggressive compression and blazing scans, with no indexes to tend
HSR
HANA System Replication: native replication, synchronous or asynchronous
SAP HANA
OFFICIAL SAP BRANDING · HANA
INTERFACCIA REALE · SAP HANA CON JOULE · FONTE: SAP NEWS
REAL INTERFACE · SAP HANA WITH JOULE · SOURCE: SAP NEWS
02 · How to use it well

The things that make the difference.

The HANA architecture

SAP and non-SAP applicationsS/4HANA, BW, custom via SQL/HDI
Columnar engine
Transactional engine
Analytics & ML
one copy of the data, three uses
HANA System Replicationthe hot copy, ready for takeover
Persistence on disklogs and savepoints: RAM that doesn't forget
In-memory, but with feet on the ground

Memory sizing

RAM is the constraint and the cost: we size on real growth data, not on price-list multipliers.

Scale-up before scale-out

HANA performs best on big machines: that's why its natural home is often IBM Power.

Tiered System Replication

Synchronous in the campus for HA, asynchronous geographic for DR: zero RPO where needed, distance where it counts.

Backups that keep pace

Savepoints, continuous log backups and restore checks: backing up an in-memory database is a process, not a job.

03 · In depth

Inside the engine: columns, delta and persistence

HANA's columnar engine writes first into a delta store optimized for inserts and then consolidates into the compressed main store (delta merge): that's how OLTP and analytics coexist. Persistence is guaranteed by periodic savepoints and redo logs on certified storage; RAM is normally sized at twice the compressed data, and with NSE (Native Storage Extension) warm data stays on disk without leaving the HANA perimeter.

  • Delta merge — writers don't block readers: inserts in the delta, queries on the compressed main
  • Columnar compression — dictionaries and run-length: typically 3-7x on the source data
  • Savepoints & redo log — persistence every 5 minutes by default + continuous log: RAM that doesn't forget
  • NSE — warm data — warm data on disk with a dedicated buffer cache: less RAM, same SQL
  • MDC multitenant — multiple isolated tenant databases in one instance: consolidation with order
  • TDI certification — validated hardware and storage (log latency KPIs <1ms): niente configurazioni fai-da-te
04 · Numbers and lifecycle

The numbers that matter.

2x
the RAM vs compressed data sizing rule (data + working memory)
3-7x
the typical columnar compression on source data
5 min
the default savepoint: the maximum log replay window
2/anno
HANA 2.0 SPS releases: a revision strategy to plan, not endure
HANA 2.0 SPS07/SPS08 are the current baselines; every revision must be tested on QA with a verified backup: our run-books cover upgrades, replication and point-in-time restore.
05 · Use cases

Where it really pays off.

Under S/4HANA

The ERP's engine: HANA's health is the ERP's health.

Real-time datamarts

Analytics on operational data without nightly ETL: reports live on the present.

BW consolidation

The SAP data warehouse on the same engine: fewer copies, less waiting.

HANA is the heart we watch most closely: memory, replication and backups under 24/7 control with Yocto Vision.