3.4 I/O Related Root Causes and Solutions
This section covers troubleshooting of I/O performance problems. Although SAP HANA is an in-memory
database, I/O still plays a critical role for the performance of the system.
From an end user perspective, an application or the system as a whole runs slowly, is unresponsive or can even
seem to hang if there are issues with I/O performance. In the Disk Volume Monitor available in the Disk Usage
tile in SAP HANA cockpit you can see the attached volumes and which services use which volumes. For details
of the attached volumes, such as les and I/O statistics, select a row.
In certain scenarios data is read from or written to disk, for example during the transaction commit. Most
of the time this is done asynchronously but at certain points in time synchronous I/O is done. Even during
asynchronous I/O it may be that important data structures are locked.
Examples are included in the following table.
Scenario
Description
Savepoint A savepoint ensures that all changed persistent data since the last savepoint gets written
to disk. The SAP HANA database triggers savepoints in 5 minutes intervals by default. Data
is automatically saved from memory to the data volume located on disk. Depending on the
type of data the block sizes vary between 4 KB and 16 MB. Savepoints run asynchronously
to SAP HANA update operations. Database update transactions only wait at the critical
phase of the savepoint, which is usually taking some microseconds.
Snapshot
The SAP HANA database snapshots are used by certain operations like backup and system
copy. They are created by triggering a system wide consistent savepoint. The system keeps
the blocks belonging to the snapshot at least until the drop of the snapshot. Detailed
information about snapshots can be found in the SAP HANA Administration Guide.
Delta Merge
The delta merge itself takes place in memory. Updates on column store tables are stored
in the delta storage. During the delta merge these changes are applied to the main storage,
where they are stored read optimized and compressed. Right after the delta merge, the new
main storage is persisted in the data volume, that is, written to disk. The delta merge does
not block parallel read and update transactions.
Write Transactions
All changes to persistent data are captured in the redo log. SAP HANA asynchronously
writes the redo log with I/O orders of 4 KB to 1 MB size into log segments. Transactions
writing a commit into the redo log wait until the buer containing the commit has been
written to the log volume.
Database restart
At database startup the services load their persistence including catalog and row store
tables into memory, that is, the persistence is read from the storage. Additionally the redo
log entries written after the last savepoint have to be read from the log volume and replayed
in the data area in memory. When this is nished the database is accessible. The bigger the
row store is, the longer it takes until the system is available for operations again.
Failover (Host Auto-Fail-
over)
On the standby host the services are running in idle mode. Upon failover, the data and log
volumes of the failed host are automatically assigned to the standby host, which then has
read and write access to the les of the failed active host. Row as well as column store tables
(the latter on demand) must be loaded into memory. The log entries have to be replayed.
114 PUBLIC
SAP HANA Troubleshooting and Performance Analysis Guide
Root Causes and Solutions