SAPFree calculatorPDF, Excel, Word exportSAP HANAAll SAP HANA and Basis tools

SAP HANA Disk Sizing Calculator for /hana/data, /hana/log and /hana/shared

This calculator sizes the three SAP HANA file systems, /hana/data, /hana/log and /hana/shared, for scale-up and scale-out systems from host RAM, net data size and growth. It uses the capacity rules from the SAP HANA Storage Requirements white paper and shows separately where common vendor practice adds headroom.

Your numbers

HANA host RAM

1,024 GB

Physical memory of one HANA host (worker node).

Net data size in memory today

From the sizing report (/SDF/HDB_SIZING or Quick Sizer) or the sum of MEMORY_SIZE_IN_TOTAL in M_CS_TABLES plus row store. For scale-out enter the total across all workers.

Annual data growth

Years to plan

years

Number of worker nodes

1 = scale-up. Standby nodes are not counted for /hana/shared.

Data backup copies kept on local disk

0 if backups go straight to backint or a separate NFS target.

Your results

Total primary disk

2,631.03

GB for data, log, shared and local backups. Add OS and /usr/sap space per node.

Net data size at planning horizon

912.52

GB. Compound growth over the planning period.

/hana/data per white paper (1.2 x net data)

1,095.03

GB, total across all workers. SAP storage white paper: Size data = 1.2 x net disk space for data.

/hana/data with 1 x RAM floor

1,095.03

GB. Many hardware vendors size the data volume at least equal to RAM so a host can be fully loaded; this is common practice, not the SAP formula.

/hana/log per node

512

GB. 0.5 x RAM up to 512 GB RAM; 512 GB minimum above that.

/hana/shared

1,024

GB. Single node: MIN(1 x RAM, 1 TB). Scale-out: 1 x worker RAM per 4 worker nodes.

Local data backup space

GB. Backup size is roughly the used data size; log backups need extra space on top.

Formulas follow the SAP HANA Storage Requirements white paper attached to SAP Note 1900823. SAP revises the paper; check the current version. The 1 x RAM data floor is a vendor rule of thumb, not an SAP formula.

Save results:

/hana/data and total disk vs planning years

Sweeps Years to plan from 0 to 10, holding your other inputs fixed.

Send us your HANA sizing inputs

Share your sizing report and current M_DISKS figures and we will return a reviewed data, log and shared estimate with growth headroom.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Enter the RAM of one HANA host and the net data size as it sits in memory today. The best source is the sizing report (/SDF/HDB_SIZING for ABAP systems) or, for a running system, the column store totals in M_CS_TABLES plus the row store. Set annual growth and the number of years the storage must last, then the number of worker nodes. Leave local backup copies at 0 if you back up through backint or to a separate share. The chart sweeps the planning horizon from 0 to 10 years so you can see when a fixed LUN size runs out. The total is primary capacity only: it excludes snapshots, replication targets and the operating system.

Net data size: in-memory footprint, not the source database size on disk
Scale-out: enter total net data across all workers
Standby nodes need no extra /hana/shared but do need access to it

The rules behind the numbers

The SAP HANA Storage Requirements white paper (attached to SAP Note 1900823) gives the capacity formulas. The data volume is 1.2 x the net disk space for data, so 20 percent headroom over the anticipated data size. The redo log volume is half of RAM for hosts up to 512 GB, and a minimum of 512 GB for larger hosts. /hana/shared for a single node is MIN(1 x RAM, 1 TB); for scale-out it is 1 x the RAM of one worker for every 4 worker nodes. Hardware vendors differ on the data factor: several guides size /hana/data at least equal to RAM so that a fully loaded host can always write a savepoint, which is why the calculator shows both figures. The paper also budgets operating system and /usr/sap space per node on top.

/hana/data = 1.2 x net data
/hana/log = 0.5 x RAM (RAM <= 512 GB), 512 GB minimum otherwise
/hana/shared = MIN(RAM, 1 TB) single node; RAM per 4 workers scale-out

Worked example

A 1,024 GB scale-up host holds 600 GB of net data growing 15 percent a year. After 3 years the data is about 913 GB, so the white paper data volume is about 1,095 GB. That is above RAM, so the vendor floor does not change it. The host has more than 512 GB RAM, so /hana/log is 512 GB. /hana/shared is MIN(1,024, 1,024) = 1,024 GB. With no local backups the total is about 2,630 GB. Change the node count to 6 with the same RAM and the shared file system becomes 2 x 1,024 GB because ceil(6/4) = 2, and the log total becomes 6 x 512 GB.

Capacity is not the hard part: TDI KPIs are

For Tailored Datacenter Integration the storage must also pass the SAP HANA hardware and cloud measurement tools (HCMT, the successor to hwcct) KPIs for log write latency and data throughput. A volume that is big enough but slow on 4 KB and 16 KB log writes will cause long commit times and savepoint delays. Size the log volume for latency first, and keep data and log on separate file systems. Check fill levels in a running system with M_DISKS and M_VOLUME_FILES, and remember that the data volume does not shrink automatically after deletes; a defragmentation (ALTER SYSTEM RECLAIM DATAVOLUME) is needed to return space.

Frequently Asked Questions

What is the SAP HANA memory to disk ratio?

There is no fixed ratio in the current white paper. The data volume is sized from net data (1.2 x), not from RAM. Older appliance rules used multiples of RAM, and many vendors still keep /hana/data at least 1 x RAM. Log is 0.5 x RAM up to 512 GB RAM, and /hana/shared is up to 1 x RAM.

Where is the official SAP HANA sizing formula?

Memory sizing comes from Quick Sizer or the sizing reports such as /SDF/HDB_SIZING, described in the SAP HANA sizing notes. Disk sizing formulas are in the SAP HANA Storage Requirements white paper attached to SAP Note 1900823. Both need an SAP login and both are revised, so check the current version.

How big should /hana/log be on a 2 TB host?

For hosts with more than 512 GB RAM the white paper sets a minimum of 512 GB for the log volume. Larger is fine if log backups may be delayed, because log segments are only freed after they are backed up. Use the log volume full time calculator to test an outage.

Does scale-out need /hana/shared on every node?

No. /hana/shared is one shared file system mounted by all nodes, including standby nodes. Its size grows with the number of workers: 1 x the RAM of one worker for every 4 worker nodes, so 1 to 4 workers need 1 x RAM and 5 to 8 workers need 2 x RAM.

If you want your Basis team to ask HANA capacity and growth questions in plain English on your own servers, we can set up a private AI layer over your monitoring views.

Talk to an Expert Explore More Free Tools