SAP HANA support · Consulting and 24×7 DBA support · In-memory and column store engineering · System replication and takeover · Backup and point-in-time recovery · SPS and revision upgrades · HANA Cloud, RISE and IaaS · Data engineering around HANA
SAP HANA Support Measured in Allocation Headroom, Delta Merge Backlog, Replication Shipping Delay and Restore Drills, Not in Ticket Counts
MinervaDB SAP HANA support is delivered by senior database engineers who read M_SERVICE_MEMORY, M_EXPENSIVE_STATEMENTS, M_DELTA_MERGE_STATISTICS and M_SERVICE_REPLICATION before they touch a parameter. The practice covers 24×7 monitoring and incident response under a published severity matrix, memory and column store engineering, workload management, system replication and takeover, backup and point-in-time recovery with scheduled restore drills, SPS and revision upgrades, tenant operations, and the data engineering that moves HANA data into ClickHouse, lakehouses and analytics platforms, on premises, on certified IaaS and alongside HANA Cloud and RISE. Every change ships as a reviewed runbook with a rollback path and the SAP Note behind it.
01 · Why MinervaDB for SAP HANA support
An in-memory database fails on memory first: the allocation limit, the unload storm and the merge that doubled a table are visible in the views long before they page anyone
HANA is operated by three parties at once: the Basis team, SAP support and the database engineer. MinervaDB takes the database engineer’s chair, reads the monitoring views continuously, and writes the boundary with Basis and SAP into the runbook so that every alert has an owner.
Database-internals depth
The engineers on watch have tuned column stores, delta structures and replication on ClickHouse, PostgreSQL and Oracle as well as HANA. SAP HANA support from MinervaDB reads a PlanViz, a delta merge failure or a replication shipping delay the way an application engineer reads a stack trace, and fixes the cause rather than the symptom.
Real 24×7 with a published matrix
Follow-the-sun pods with S1 acknowledged within 15 minutes, S2 in 12 hours, S3 in 24 hours and S4 in 48 hours. Every alert rule maps to a runbook, every S1 closes with a root cause analysis that names the monitoring view behind it, the SAP Note applied and the prevention step. 24×7 consultative support →
Vendor-neutral by principle
MinervaDB sells no SAP licences, no HANA appliances and no cloud capacity. The recommendation can be scale-up instead of scale-out, native storage extension instead of more memory, a smaller instance after tiering, or an analytical workload that belongs in ClickHouse rather than in a HANA sidecar.
Measured before and after
Nothing is reported as improved until the views say so: used memory against the allocation limit, unloads per day, delta size on the hottest tables, statement time and memory per hash, shipping delay per secondary, restore duration per drill. Gains are estimates until the next measurement confirms them.
02 · SAP HANA support operating model
From monitoring views and statistics server alerts to an accountable engineer, with a response target on every page
Instrumentation is layered: the M_ monitoring views, statistics server alerts, trace files and the backup catalog are exported into Prometheus alongside SAP HANA cockpit, correlated with host counters, evaluated by recording rules and routed to the engineer on watch. Expensive view queries are scraped on a slower cadence so monitoring never becomes the load.
Figure 1. The SAP HANA support monitoring and escalation pipeline: signals, collectors, Prometheus, Alertmanager and the on-call engineer, with the severity matrix and representative alert conditions.
Alerts are actionable by design. Thresholds are set per system from its own baseline rather than from a template, so a BW system with nightly merges does not page on delta size and an S/4HANA tenant that should never unload does. Memory is alerted on as headroom against global_allocation_limit with the unload rate beside it, replication as shipping delay and log position gap per secondary, and every rule carries the runbook the engineer executes when it fires.
The stack integrates with what you already run: SAP HANA cockpit, Solution Manager or Cloud ALM, Prometheus and Grafana, Datadog or the cloud provider’s monitoring. A system is not accepted into 24×7 SAP HANA support until a tenant has been restored on an isolated system and a takeover has been rehearsed with the Basis team. Access is through named, least-privilege database users, time-bounded and audited; no shared SYSTEM account.
-- Memory headroom and unloads as the on-call engineer
-- reads them, per service, against the allocation limit
SELECT
host,
service_name,
ROUND(total_memory_used_size / 1024 / 1024 / 1024, 1)
AS used_gb,
ROUND(effective_allocation_limit / 1024 / 1024 / 1024, 1)
AS limit_gb,
ROUND(100 * total_memory_used_size
/ effective_allocation_limit, 1) AS used_pct
FROM m_service_memory
ORDER BY used_pct DESC;
SELECT COUNT(*) AS unloads_24h, MAX(unload_time) AS last_unload
FROM m_cs_unloads
WHERE unload_time > ADD_SECONDS(CURRENT_TIMESTAMP, -86400);
-- Delta backlog on the hottest tables
SELECT TOP 20 schema_name, table_name,
ROUND(memory_size_in_delta / 1024 / 1024, 0) AS delta_mb,
raw_record_count_in_delta AS delta_rows,
last_merge_time
FROM m_cs_tables
ORDER BY memory_size_in_delta DESC;
03 · SAP HANA support for memory and the column store
Main, delta and merge decide both the memory bill and the query time, and each has a view that says whether it is sized right
The column store holds a read-optimised main fragment and a write-optimised delta per column; the delta merge rewrites main and briefly doubles the table’s memory. Allocation limits bound the index server and each statement; native storage extension moves warm data behind a buffer cache. SAP HANA support treats these as one budget and tunes them from the views rather than from defaults.
Figure 2. The in-memory architecture as operated by SAP HANA support: column store main and delta, memory pools and warm data, the persistence layer, and the monitoring view that validates each parameter.
| Parameter or design decision | Starting position | What SAP HANA support monitors before changing it |
|---|---|---|
global_allocation_limit |
From the SAP sizing report and the host, leaving room for the operating system and other services; online change | M_SERVICE_MEMORY used and peak against the effective limit, M_CS_UNLOADS rate, host memory and swap |
statement_memory_limit and workload classes |
A per-statement ceiling well below the allocation limit, with workload classes mapping analytics users to tighter limits; online | M_EXPENSIVE_STATEMENTS memory and duration columns, workload class hit counts, out-of-memory aborts in the trace |
| Delta merge: auto, smart and critical merge thresholds | Defaults kept until a table’s delta or merge history says otherwise; per-table merge settings only with evidence; online | M_DELTA_MERGE_STATISTICS success, duration and memory, M_CS_TABLES delta size and record count against main |
| Table partitioning | Range or hash partitions sized well under the two billion row limit, pruned by the predicate the workload uses; a change to rehearse, not a switch | M_CS_PARTITIONS record counts, partition pruning in PlanViz, merge and load times per partition |
| Table placement in scale-out | Placement rules that keep joined tables and partitions on the same host; standby host configured | M_TABLE_LOCATIONS, cross-host join and data transfer volume in expensive statements, name server topology |
| Native storage extension and data aging | Cold partitions and aged data moved to warm storage with the buffer cache sized from access counts; reversible per partition | M_BUFFER_CACHE_STATISTICS hit ratio, warm table access counts, hot memory reclaimed after tiering |
savepoint_interval_s, log_buffer_size, log_mode |
Defaults unless M_SAVEPOINTS or M_LOG_BUFFERS show blocking or waits; log_mode normal always in production; online |
M_SAVEPOINTS duration and critical phase, M_LOG_BUFFERS wait ratio, M_LOG_SEGMENTS free segments |
| Operating system | SLES for SAP or RHEL for SAP at the version certified for the SPS, with the SAP Notes for kernel, THP, NUMA and I/O scheduler applied; restart of the host | SAP HANA mini checks, hanachecker output, host CPU and memory from node_exporter |
The positions above are starting points SAP HANA support derives from, not a template to copy; final values come from the measured system and the SAP Notes for its exact SPS and revision, and every change is applied on a non-production copy first with online-versus-restart stated in the runbook.
04 · SAP HANA support for system replication and takeover
Synchronous inside the site, asynchronous across sites, and a takeover that is rehearsed with the Basis team rather than assumed
HANA system replication in sync, syncmem and async modes with logreplay operation, a multi-tier or multi-target third site, host auto-failover with a standby host in scale-out, and a Pacemaker cluster that automates the takeover. SAP HANA support designs from the recovery objectives and drills the result every quarter.
Figure 3. High availability and disaster recovery topologies operated by SAP HANA support: system replication modes, multi-tier and multi-target sites, scale-out with host auto-failover, and the selection criteria and quarterly drill.
| Topology | Takeover model | Data-loss and recovery characteristics | When SAP HANA support recommends it |
|---|---|---|---|
System replication, sync or syncmem, same site |
Pacemaker with the SAPHanaSR agents, or a scripted takeover with fencing | Zero loss for committed transactions; syncmem acknowledges on receipt in memory rather than on the secondary’s log write; takeover in minutes |
Every production system; the default inside a data centre or availability zone pair |
System replication, async, second site |
Manual or scripted takeover with the application relocated | Loss bounded by the shipping delay at failure; network sized to the redo rate at peak | Disaster recovery across regions where synchronous commit would be too slow |
| Multi-tier or multi-target | Tier three registered from the secondary, or two secondaries from one primary | Local zero-loss protection plus remote DR from the same primary; re-registration sequence matters after a takeover | Systems that need both a local takeover target and a remote copy |
| Scale-out with host auto-failover | Name server promotes the standby host into the failed worker’s role | No data loss; the failed host’s partitions are reloaded on the standby, which is a latency event | BW and very large systems that have outgrown scale-up; combined with replication for site protection |
| HANA Cloud, HEC and RISE | SAP-operated | SAP runs replication and backups; sizing, tuning, tenants, workload management and the evidence pack remain the engineer’s | Estates that have moved platform operations to SAP and still need database engineering |
Replication and takeover are configured from the SAP HANA System Replication guide and the SAPHanaSR documentation for the operating system in use; planned takeover, failback, application reconnect and re-registration are drilled every quarter with recorded times.
05 · SAP HANA support for backup and point-in-time recovery
A backup that has not been restored is a hope, and a log backup that fell behind is a recovery point nobody agreed to
Full, differential and incremental data backups, continuous log backups, backint to a backup server or object storage, storage snapshots where the storage supports them, and a backup catalog kept clean. SAP HANA support sets the strategy per tenant from its size and its recovery objectives, and schedules the restore drill first.
Figure 4. Backup and recovery as rehearsed by SAP HANA support: the backup path, what each strategy costs, tenant point-in-time recovery and the drill cadence.
Strategy per tenant
Small tenants take a daily full with continuous log backups; large ones take a weekly full with daily differentials; systems on snapshot-capable storage add a prepare-snapshot-confirm sequence for fast full-system recovery, still with log backups for point in time. Retention is expressed in both backup generations and time so the log chain always covers the recoverable window.
The catalog and the chain
Missing log segments are the classic HANA recovery failure. SAP HANA support alerts on log backup age and on backint failures, ships the catalog with the backups, houses catalog cleanup in the runbook with a confirmation gate, and checks files with hdbbackupcheck before a recovery starts rather than during it.
The drill is scheduled
A tenant is recovered to a point in time on an isolated system, consistency-checked, and smoke-tested through the SAP application with the Basis team; restore duration and achieved recovery point are recorded in the runbook and reviewed with you. The mechanics follow the SAP HANA Administration Guide.
06 · SAP HANA performance engineering method
Baseline, attribute, one reversible change, re-measure; the same loop for a slow calculation view and for a merge that fails at two in the morning
Performance in HANA is a memory and a plan question at once. SAP HANA support finds the statements, tables and settings responsible from the system’s own views and PlanViz, changes one thing, and reports the result as measured.
Figure 5. The SAP HANA support performance engineering method, the findings that recur across health checks, and the workload management levers in the order they are applied.
SQL and calculation views
The top statements by total time and memory from M_SQL_PLAN_CACHE and M_EXPENSIVE_STATEMENTS are opened in PlanViz: row engine fallbacks, calculation views that do not unfold, implicit type conversions, missing partition pruning and cross-host joins are named from the plan, and the rewrite or the model change is tested against the captured statement before it ships.
Merges, partitions and tiering
Hot tables with large deltas get partitioning or per-table merge settings; date-keyed tables get range partitions that prune; cold partitions move to native storage extension so hot memory shrinks and the sizing holds longer. Every change is rehearsed on a copy because a repartition or a merge policy is a memory event as much as a performance one.
Workload management
Workload classes map analytics users and integration jobs to statement memory, thread and priority limits; admission control queues or rejects at CPU and memory thresholds so a burst degrades gracefully. Both are applied before anyone proposes more memory, and both are verified with the same views that justified them.
07 · SAP HANA support for lifecycle, landscape and the service boundary
SAP HANA 2.0 SPS 08 is current, SPS 07 is still in maintenance, and every revision is applied secondary-first with the SAP Notes read
Revisions are applied in place with hdblcm after a rehearsal on a copy; SPS upgrades add the operating system matrix and a PlanViz comparison of the top statements. Maintenance dates are verified against SAP Note 2378962 before any plan is written, and the boundary between MinervaDB, the Basis team and SAP support is stated in the runbook for every alert.
Figure 6. Lifecycle, landscape and service boundary as managed by SAP HANA support: SPS and revision lifecycle, tenants and platforms, who owns what, the upgrade sequence and the engagement lifecycle.
Revisions and SPS upgrades
Pre-checks against the SAP Notes for the target, operating system and kernel prerequisites, a verified backup and restore point, the upgrade rehearsed on a copy with expensive statements replayed; then the replication secondary upgraded and re-registered, a takeover to the upgraded node, the former primary upgraded and registered back, and an application smoke test with Basis before the change closes.
Tenants and platforms
Multitenant database containers with a system database and isolated tenants; tenant copy and move for test refreshes; scale-up first and scale-out for BW-class systems; certified instance types on AWS, Azure and Google Cloud for IaaS estates; HANA Cloud, HANA Enterprise Cloud and RISE where SAP operates the platform and the database engineering still needs an owner.
Who owns what
MinervaDB owns database performance, memory, replication, backups, upgrades and the evidence pack; the Basis team owns the application layer, transports, kernel and work processes; SAP support owns product defects and SAP Notes. Licensing positions such as runtime versus full-use are stated in findings and never sold. Escalations to SAP go with the evidence already collected.
08 · Data engineering and DBA support around SAP HANA
HANA is the system of record; the analytics, lakehouse and AI workloads that read from it are engineered so they never become its load
Most estates need HANA data somewhere else: a ClickHouse cluster for high-concurrency analytics, a lakehouse for data science, an operational store for integration. MinervaDB’s data engineering practice builds those pipelines with change data capture rather than extracts, and the same DBA support team keeps HANA’s memory and expensive statement budget protected from them.
Change data capture out of HANA
SLT, Smart Data Integration, Data Services or log-based capture feed Kafka and downstream stores with commit-ordered changes; replication load is measured in expensive statements and memory on the source, and workload classes cap it. Extract jobs that scan whole tables nightly are replaced, not scheduled around. Data analytics platform engineering →
OLAP offload to ClickHouse
Analytical workloads whose concurrency, retention or cost do not fit a HANA sidecar move to ClickHouse through ChistaDATA, with MergeTree schemas designed from the HANA calculation views they replace and reconciliation by row count and checksum. HANA keeps the transactional truth and the reports that must read it. ChistaDATA →
Lakehouse and AI feeds
Delta or Iceberg tables on object storage fed from the same CDC stream, with schema evolution handled and PII masked at the boundary; private, in-VPC GenAI and RAG over HANA-derived data with GDPR, DPDP and HIPAA-class governance. Data modernization → · Cloud database optimization and FinOps →
| SAP HANA support service line | What it covers technically |
|---|---|
| Monitoring and alerting | Monitoring views and statistics server alerts into Prometheus beside SAP HANA cockpit, recording rules per system and tenant, integration with Solution Manager, Cloud ALM, Grafana or Datadog |
| Incident response | Severity-based paging, runbook execution with the Basis boundary stated, root cause analysis naming the view and the SAP Note, prevention ticket, customer communication on a shared channel |
| Memory and column store engineering | Allocation limits from the sizing, unload and merge analysis, partitioning and placement, native storage extension and data aging, verified in M_SERVICE_MEMORY and M_CS_TABLES |
| Performance engineering | Expensive statement and plan cache baselines, PlanViz attribution, calculation view and SQL rewrites, workload classes and admission control, verified before and after |
| Replication and takeover | System replication design and re-registration, Pacemaker and SAPHanaSR configuration review, multi-tier and multi-target sites, quarterly takeover drills |
| Backup assurance | Strategy per tenant, backint and snapshot integration, catalog hygiene behind a confirmation gate, scheduled restore drills with a recorded attestation |
| Upgrades and lifecycle | Revisions within a defined window, SPS upgrades rehearsed on a copy and applied secondary-first, operating system matrix tracked, SAP Notes read for every change |
| Security and compliance | Named least-privilege users and roles, audit policies, TLS and data volume encryption, evidence for SOC 2, GDPR and HIPAA reviews alongside the Basis team |
| Data engineering and offload | CDC pipelines out of HANA, ClickHouse offload through ChistaDATA, lakehouse and AI feeds, all measured against the source’s expensive statement and memory budget |
Engagement models
SAP HANA support is delivered as a 24×7 consultative support and DBA support retainer, as fixed-scope consulting such as a health check, a replication redesign, an SPS upgrade or a data engineering project, and as emergency response for estates outside a subscription. Retainers include the takeover assessment, the runbook with the Basis boundary, monitoring integration, a monthly health report with the view behind every recommendation, and a quarterly restore and takeover drill. Scope and pricing are set from the assessment. Emergency database support →
Access model
VPN or bastion reachability, named database users per engineer with least-privilege roles rather than SYSTEM, SSH certificate or key authentication with MFA to hosts, audit policies on privileged actions, and every production change tied to a ticket, an approver and the SAP Note that justifies it. Backup catalog deletion, tenant drops and takeover commands sit behind a confirmation gate in every runbook.
Standing caveat: every recommendation on this page is tested on a non-production copy before it is applied to production, changes are staged and reversible by design, and a verified backup and DR posture is confirmed before any memory, replication, partitioning, tiering or upgrade change is made.
09 · FAQ
SAP HANA support questions we are asked most
Short answers to what SAP, platform and data leaders ask before the first call.
What does MinervaDB SAP HANA support include?
24×7 monitoring and incident response under a published severity matrix with S1 acknowledged within 15 minutes, S2 in 12 hours, S3 in 24 hours and S4 in 48 hours; memory and column store engineering; performance engineering from expensive statements and PlanViz; workload management; system replication and takeover with quarterly drills; backup strategy per tenant with scheduled restore drills; revisions and SPS upgrades applied secondary-first; tenant operations; and the data engineering that moves HANA data into ClickHouse, lakehouses and AI platforms without loading the source. Every recommendation names the monitoring view and the SAP Note behind it.
Which SAP HANA versions and platforms do you support?
SAP HANA 2.0 on SPS 08 and SPS 07, with upgrade plans for systems on earlier support package stacks that are out of maintenance; multitenant database containers; scale-up and scale-out; on-premises appliances and TDI, certified IaaS instance types on AWS, Azure and Google Cloud, and database engineering alongside HANA Cloud, SAP HANA Enterprise Cloud and RISE where SAP operates the platform. Exact SPS and revision are confirmed and maintenance dates checked against SAP Note 2378962 before any version-sensitive guidance is given.
How does SAP HANA support work with our Basis team and with SAP?
The runbook states the boundary for every alert: MinervaDB owns database performance, memory, replication, backups, upgrades and the evidence pack; the Basis team owns the application layer, transports, kernel and work processes; SAP support owns product defects and SAP Notes. Escalations to SAP go with the evidence already collected, and takeover and restore drills are run jointly with Basis so application reconnect is part of the test.
How do you keep an SAP HANA system inside its memory?
By measuring rather than adding. Allocation limits are set from the SAP sizing report and the host, statement memory limits and workload classes cap runaway analytics, unloads and delta merges are analysed from M_CS_UNLOADS and M_DELTA_MERGE_STATISTICS, hot tables are partitioned, and cold partitions move to native storage extension or data aging so hot memory shrinks. More memory is proposed only when those levers are exhausted and the views prove it.
How do you ensure SAP HANA high availability and disaster recovery?
System replication in sync or syncmem mode inside the site for zero loss, asynchronous replication to a second site for disaster recovery, multi-tier or multi-target where both are needed, host auto-failover with a standby host in scale-out, and a Pacemaker cluster with the SAPHanaSR agents to automate takeover. Planned takeover, failback, application reconnect and re-registration are drilled every quarter with recorded times.
Can you take over an estate that already runs replication, backint and a cluster?
Yes. Onboarding starts with a takeover assessment that documents sizing against the SAP report, parameter deltas from the SAP Notes, replication and backup state, top statements and tenant layout, and produces the runbook we then operate from. Nothing is changed until the assessment is reviewed with you and the Basis team, and the first restore drill and takeover drill happen before the system enters 24×7 coverage.
How is SAP HANA support priced?
As a 24×7 consultative support and DBA support retainer scoped from the takeover assessment, as fixed-scope consulting such as a health check, a replication redesign, an SPS upgrade or a data engineering project, or as emergency response for estates outside a subscription. Retainers include the assessment, the runbook, monitoring integration, a monthly health report and a quarterly restore and takeover drill.
Talk to a senior SAP HANA support engineer
Bring the output of the SAP HANA mini checks, M_SERVICE_MEMORY and M_CS_UNLOADS for the last week, the top twenty entries of M_EXPENSIVE_STATEMENTS, your replication topology, the backup strategy and the date of your last restore drill to the first call. We will tell you what the next incident will be and what we would change first.