SAP · Infrastruttura · scheda YoctoIT

HANA

Il database in-memory alla base di tutto il mondo SAP: colonne, transazioni e analytics nello stesso motore, alla velocità della RAM.

FOCUS · IL CUORE DELL'ERPSizing, replica e alta affidabilità di HANA: il mestiere che facciamo ogni giorno
Richiedi il Free Assessment Scopri di più
Materiale YoctoIT per clienti e partner · SAP, S/4HANA, HANA, BTP e gli altri prodotti citati sono marchi di SAP SE o di sue affiliate.
01 · Cos'è

SAP HANA, in chiaro.

HANA tiene i dati in memoria e li organizza per colonne: transazioni e analisi convivono senza copie, e l'ERP risponde in tempo reale. Il rovescio: la memoria va dimensionata bene e protetta meglio — un database in-RAM non perdona improvvisazioni.

In-memory
il dato vive in RAM: latenze di microsecondi, analytics sul dato vivo
Colonnare
compressione spinta e scansioni velocissime, senza indici da coltivare
HSR
HANA System Replication: la replica nativa, sincrona o asincrona
SAP HANA
VESTE UFFICIALE SAP · HANA
INTERFACCIA REALE · SAP HANA CON JOULE · FONTE: SAP NEWS
INTERFACCIA REALE · SAP HANA CON JOULE · FONTE: SAP NEWS
02 · Come lo si usa bene

Le cose che fanno la differenza.

L'architettura di HANA

Applicazioni SAP e non-SAPS/4HANA, BW, custom via SQL/HDI
Motore colonnare
Motore transazionale
Analytics & ML
un solo dato, tre usi
HANA System Replicationla copia calda, pronta al takeover
Persistenza su discolog e savepoint: la RAM che non dimentica
In-memory, ma con i piedi per terra

Sizing di memoria

La RAM è il vincolo e il costo: dimensioniamo su dati reali di crescita, non su fattori moltiplicativi da listino.

Scale-up prima di scale-out

HANA rende al meglio su macchine grandi: per questo la casa naturale è spesso IBM Power.

System Replication a livelli

Sincrona nel campus per l'HA, asincrona geografica per il DR: RPO zero dove serve, distanza dove conta.

Backup che tengono il passo

Savepoint, log backup continui e verifiche di ripristino: il backup di un in-memory è un processo, non un job.

03 · In profondità

Dentro il motore: colonne, delta e persistenza

Il motore colonnare di HANA scrive prima in un delta store ottimizzato per gli insert e consolida poi nel main store compresso (delta merge): è così che convivono OLTP e analytics. La persistenza è garantita da savepoint periodici e redo log su storage certificato; la RAM si dimensiona di norma al doppio del dato compresso, e con NSE (Native Storage Extension) i dati tiepidi restano su disco senza uscire dal perimetro HANA.

  • Delta merge — lo scrittore non blocca il lettore: insert nel delta, query sul main compresso
  • Compressione colonnare — dizionari e run-length: tipicamente 3-7x sul dato sorgente
  • Savepoint & redo log — persistenza ogni 5 minuti di default + log continuo: la RAM che non dimentica
  • NSE — warm data — i dati tiepidi su disco con buffer cache dedicata: meno RAM, stesso SQL
  • MDC multitenant — più tenant database isolati in una sola istanza: consolidamento con ordine
  • Certificazione TDI — hardware e storage validati (KPI di latenza log <1ms): niente configurazioni fai-da-te
04 · Numeri e ciclo di vita

I numeri che contano.

2x
la regola di sizing RAM vs dato compresso (dati + working memory)
3-7x
la compressione colonnare tipica sul dato sorgente
5 min
il savepoint di default: la finestra massima di replay del log
2/anno
gli SPS di HANA 2.0: revision strategy da pianificare, non subire
HANA 2.0 SPS07/SPS08 sono le basi correnti; ogni revisione va provata su QA con backup verificato: i nostri run-book coprono upgrade, replica e restore point-in-time.
05 · Use case

Dove rende davvero.

Sotto S/4HANA

Il motore dell'ERP: la salute di HANA è la salute del gestionale.

Datamart in tempo reale

Analytics sul dato operativo senza ETL notturni: il report vive sul presente.

Consolidamento BW

Il data warehouse SAP sullo stesso motore: meno copie, meno attese.

HANA è il cuore che monitoriamo più da vicino: memoria, replica e backup sotto controllo H24 con Yocto Vision.