Home > Workload Solutions > SAP > Archive > SC Series Storage Configuration Best Practices for SAP HANA TDI > SAP HANA database
SAP HANA is an in-memory database. The data is kept in the RAM of one or multiple SAP HANA worker hosts. All database operations, such as reads, inserts, updates, and deletes, are performed in the main memory of the host. This feature differentiates SAP HANA from other traditional databases, where only a part of the data is cached in RAM and the remaining data resides on disk.
To ensure that you can always restore the SAP HANA database to its most recent committed state, persistent storage is used to provide a fallback in case of failure. The log captures all changes by database transactions (redo logs), and data and undo log information is automatically saved to disk at regular savepoints.
As SAP-certified enterprise storage for SAP HANA, SC Series arrays can be used for both single-host (scale-up) and multihost (scale-out) SAP HANA systems in TDI deployments.
In single-host environments, the database must fit into the RAM of a single server. Single-host environments are preferred for online transaction processing (OLTP)-type workloads such as SAP Business Suite on SAP HANA.
In multihost environments, the database tables are distributed across the RAM of multiple servers. Multihost environments use worker hosts and standby hosts. A worker host accepts and processes database requests and is an active component. A standby host waits for a worker host to fail so that it can take over the worker host role. This process is called host auto-failover. A standby has all database services running, but it has no data in RAM.
Because the in-memory capacity in these deployments can be high, scale-out SAP HANA clusters are perfectly suited for online analytical processing (OLAP)-type workloads with very large data sets, such as SAP Business Warehouse (BW) on SAP HANA.
The following table describes the required file system structure of an SAP HANA setup. For more information, see the SAP HANA Server Installation and Update Guide on the SAP Help Portal.
File system |
Default path |
Description |
Root |
/ |
Root partition |
Installation path |
/hana/shared |
Mount directory, which is used for shared files between all hosts in an SAP HANA system Note: This directory must be accessible to each of the servers in the SAP HANA scale-out system. |
System instance |
/usr/sap |
Path to the local SAP system instance directories |
Data volume |
/hana/data/<SID> |
Default path to the data directory, which depends on the system ID of the SAP HANA host |
Log volume |
/hana/log/<SID> |
Default path to the log directory, which depends on the system ID of the SAP HANA host |
SAP HANA uses disk storage to maintain the persistence of the in-memory data on disk. SAP HANA persistence prevents a loss of data in the event of a power outage and enables host auto-failover. For these purposes, each SAP HANA worker host (scale-out) or single host (scale-up) requires two file systems on disk storage—one for data files and one for log files.
SAP HANA persists in-memory data by using savepoints. Each SAP HANA service has its own savepoints. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has been completed. During a savepoint operation, the SAP HANA database flushes all changed data from memory to the data volumes. Redo log entries are written to the log volumes for all changes to persistent data. In the case of a database restart (after a crash, for example), the data from the last completed savepoint can be read from the data volumes, and the redo log entries that were written to the log volumes since the last savepoint can be replayed.
The SAP HANA persistent file systems have different I/O patterns. For more information, see SAP HANA Storage Requirements. During normal operations, the SAP HANA workload is predominantly WI.
Access to the data file system is primarily random, with various block sizes ranging in size from 4 KB to 64 MB. The data is written asynchronously with parallel I/O to the data file system. During normal operations, most of the data file system I/O operations are writes. Data is read from the data file system only during a database restart, high availability (HA) failover, or column store table load.
All changes in the database are captured in the redo log on the log file system. The log file is written with sequential I/O, with block sizes ranging from 4 KB to 1 MB.
Because data is written synchronously to the log file system on commits, a low latency for I/O to the storage device is important, especially for the smaller 4 KB and 16 KB block sizes.
During normal database operations, most I/O operations of the log file system are writes. Data is only read from the log file system during a database restart, HA failover, or log backup or database recovery.
SAP HANA I/Os can be optimized for specific storage environments. For a description of the specific optimization that is required for the SC Series arrays, see Optimizing file I/Os after SAP HANA installation on page 30.
Customers have the option to run SAP HANA on the VMware vSphere virtualized infrastructure. Some restrictions apply, however, such as the maximum RAM size of an SAP HANA node. See the relevant SAP OSS notes and follow VMware best practices to deploy SAP HANA on vSphere.
For the SAP HANA persistence on SC Series arrays, all physical configuration recommendations in this guide also apply to virtual environments. Also, consider the following recommendations: